얼마 전 Wilson Page는 Financial Times 웹 앱을 출시한 방법을 자세히 다룬 Smashing Magazine의 유용한 기사를 작성했습니다. 이 기사에서 윌슨은 다음과 같이 지적합니다.
앱이 성장하기 시작하면서 성능이 점점 더 나빠지고 있음을 알게 되었습니다.
Chrome 개발자 도구의 타임라인에서 몇 시간을 보낸 결과, 공포의 충격의 원인을 발견했습니다. - Flexbox는 우리의 새 친구인 Flexbox였습니다. 타임라인에 따르면 일부 레이아웃에는 거의 100밀리초가 걸리는 것으로 나타났습니다. Flexbox 없이 레이아웃을 재작업하면 10밀리초로 단축되었습니다.
윌슨의 설명은 display: box;를 사용한 원래 (기존) Flexbox에 관한 것이었습니다. 안타깝게도 사용자는 최신 Flexbox (display: flex;)가 더 빠른지 답변할 기회를 얻지 못했지만 CSS Tricks에서는 크리스 코이어가 해당 질문을 열었습니다.
Google은 WebKit 및 Blink에서 구현의 많은 부분을 작성한 Ojan Vafai에게 최신 Flexbox 모델과 구현에 관해 물었습니다.
새 Flexbox 코드에는 다중 패스 레이아웃 코드 경로가 훨씬 적습니다. 하지만 여전히 다중 패스 코드 경로에 쉽게 도달할 수 있습니다 (예:
flex-align: stretch는 종종 2 패스임). 일반적으로 일반적인 경우 훨씬 더 빠르지만 똑같이 느린 사례를 구성할 수도 있습니다.
즉, 벗어날 수 있다면 일반 블록 레이아웃 (부동 소수점 수 없음)은 항상 단일 패스이므로 새 Flexbox보다 빠르거나 빠릅니다. 하지만 새 Flexbox는 테이블을 사용하거나 맞춤 JS 기반 레이아웃 코드를 작성하는 것보다 빠릅니다.
숫자의 차이를 확인하기 위해 이전 구문과 새로운 구문을 일대일로 비교했습니다.
이전 및 새 Flexbox 벤치마크
- 이전 Flexbox와 새 Flexbox 비교 (대체 포함)
- 페이지당 요소 500개
- 페이지 로드 비용을 평가하여 요소 배치
- 3번의 러닝에서 평균
- 20%가 데스크톱에서 측정되었습니다 (모바일 속도가 최대 10배 느림)
기존 Flexbox: 레이아웃 비용 ~43.5ms
새 Flexbox: 레이아웃 비용 ~18.2ms
요약: 이전 버전은 새 버전보다 2.3배 느립니다.
어떻게 해야 하나요?
Flexbox를 사용하는 경우 항상 새로운 콘텐츠를 작성합니다. Chrome 21 이상, Safari 7 이상, Firefox 22 이상, Opera(및 Opera Mobile) 12.1 이상, IE 11 이상, Blackberry 10 이상에 있는 IE10 트위너 구문과 새로 업데이트된 Flexbox를 작성합니다. 대부분의 경우 기존 모바일 브라우저로 대체할 수 있습니다.
주의: 규칙이 아닌 도구
더 중요한 것은 중요한 것을 최적화하는 것입니다. 한 가지 작업을 최적화하는 데 시간을 할애하기 전에 항상 타임라인을 사용하여 병목 현상을 파악하세요.
실제로 Wilson 및 Financial Times Labs팀과 협력했으며, 그 결과 레이아웃 성능 도구의 Chrome DevTools 적용 범위를 개선했습니다. 요소의 레이아웃 재배치 경계 보기 기능이 곧 추가될 예정이며, 타임라인의 레이아웃 이벤트는 각 레이아웃의 범위, 루트 및 비용에 관한 세부정보와 함께 로드됩니다.
