얼마 전 윌슨 페이지는 Financial Times 웹 앱을 구현한 방법을 자세히 살펴본 Smashing Magazine의 훌륭한 기사를 작성했습니다. 윌슨은 이 도움말에서 다음과 같이 언급합니다.
앱이 성장하기 시작하면서 성능이 점점 더 나빠지는 것을 발견했습니다.
Chrome 개발자 도구의 타임라인을 살펴본 결과 원인을 찾았습니다. 충격적이고 소름끼치는 원인입니다. — 바로 새로운 친구인 flexbox였습니다. 타임라인에 따르면 일부 레이아웃은 거의 100밀리초가 소요되었습니다. flexbox 없이 레이아웃을 수정하여 이 시간을 10밀리초로 줄였습니다.
윌슨의 의견은 display: box;를 사용한 기존 (기존) Flexbox에 관한 것이었습니다. 안타깝게도 최신 flexbox (display: flex;)가 더 빠른지 답변할 기회가 없었지만 CSS Tricks에서 크리스 코이어님이 이 질문을 제기했습니다.
WebKit 및 Blink의 구현 대부분을 작성한 Ojan Vafai에게 최신 flexbox 모델 및 구현에 관해 물었습니다.
새 flexbox 코드에는 멀티패스 레이아웃 코드 경로가 훨씬 적습니다. 하지만 멀티패스 코드 경로를 매우 쉽게 사용할 수 있습니다 (예:
flex-align: stretch는 종종 2패스임). 일반적으로 일반적인 경우에는 훨씬 더 빠르지만 똑같이 느린 경우를 구성할 수 있습니다.
하지만 가능하다면 일반 블록 레이아웃 (플로팅 아님)을 사용하는 것이 좋습니다. 항상 단일 패스이기 때문에 일반적으로 새 flexbox보다 빠르거나 그만큼 빠릅니다. 하지만 새 flexbox는 표를 사용하거나 맞춤 JS 기반 레이아웃 코드를 작성하는 것보다 빠릅니다.
수치의 차이를 확인하기 위해 이전 문법과 새 문법을 직접 비교해 보았습니다.
이전 및 새 Flexbox 벤치마크
- 이전 Flexbox와 새 Flexbox (대체 포함) 비교
- 페이지당 요소 500개
- 요소를 배치하기 위한 페이지 로드 비용 평가
- 실행 3회 평균
- 데스크톱에서 측정됩니다. (모바일은 약 10배 느림)
이전 Flexbox: 레이아웃 비용 ~43.5ms
새 Flexbox: 레이아웃 비용 ~18.2ms
요약: 이전 버전이 새 버전보다 2.3배 느립니다.
어떻게 해야 할까요?
flexbox를 사용할 때는 항상 새 항목을 작성하세요. IE10 트윈너 문법과 Chrome 21 이상, Safari 7 이상, Firefox 22 이상, Opera(및 Opera Mobile) 12.1 이상, IE 11 이상, Blackberry 10 이상에 있는 새롭게 업데이트된 flexbox가 여기에 해당합니다. 대부분의 경우 기존 flexbox로 대체하여 일부 이전 모바일 브라우저를 선택할 수 있습니다.
규칙이 아닌 도구로 생각하세요.
중요한 것은 중요한 사항을 최적화하는 것입니다. 한 가지 작업을 최적화하는 데 시간을 들이기 전에 항상 타임라인을 사용하여 병목 현상을 파악하세요.
실제로 Google은 윌슨과 Financial Times Labs팀에 연락하여 레이아웃 성능 도구에 대한 Chrome DevTools 적용 범위를 개선했습니다. 곧 요소의 재레이아웃 경계를 확인하는 기능이 추가될 예정이며 타임라인의 레이아웃 이벤트에는 각 레이아웃의 범위, 루트, 비용에 관한 세부정보가 로드됩니다.
