오늘은 +Paul Lewis가 Chrome Dev Summit의 성능과 관련된 세션들의 요약을 업데이트했네요. 개인적으로도 관심이 많은 영역입니다만 도구화, 렌더링, 네트워크, 모바일에 대한 최적화가 한곳에 있으니 다들 읽어보시면 좋을 듯 합니다. 이전과 마찬가지로 자세한 내용은 전문을 참고하시기 바랍니다.
"성능은 언제나 이슈지요. 그래서 성능 역시 기능입니다."
#perfmatters: 퍼포먼스 닌자를 위한 도구화 기술들
개발도구에 대해 방향을 앎에 있어 요점은 성능의 그랜드 마스터가 되는 것입니다.
- 이제 여러분은 데스크탑에서 알고 사랑해온 크롬 개발자도구를 사용하여 안드로이드 크롬(Chrome on Android)를 프로파일링할 수 있게 되었습니다.
- 성능 개선은 데이터를 수집하여 검토한 것을 기록하고 액션을 취하는 작업의 반복적인 루프입니다.
- 페이지에 대해 중대한 렌더링 경로 상의 애셋(Asset)의 우선순위를 결정하세요.
- 페인팅을 피하세요. 이는 엄청나게 비싼 비용을 소모합니다.
- 앱 내에서 메모리 변동(Churn)과 임계시간의 코드 실행을 피하세요.
#perfmatters: 네트워크 성능 최적화
네트워크와 지연시간은 일반적으로 사이트의 전체 페이지 로딩 시간의 70%를 차지합니다. 이는 정말 큰 비율입니다만 또한 사용자를 위한 아주 큰 장점으로 뛰어넘는 개선을 만들 수 있다는 것을 의미하기도 합니다. 이 발표에서 +Ilya Grigorik은 절대적인 최소 시간으로 네트워크 부하를 유지하도록 도와주는 환경을 만들도록 해주는 작은 변화뿐만이 아니라 로딩 타임을 개선할 수 있는 크롬에서의 최근 변경들에 대해 다뤘습니다.
- Chrome M27은 새롭게 개선된 리소스 스케쥴러를 가지고 있습니다.
- Chrome M28은 SPDY 사이트들을(조차도) 더 빠르게 만들었습니다.
- Chrome의 단순한 캐쉬(Simple cache)는 재정비를 받았습니다.
- SPDY / HTTP/2.0는 전송 속도의 엄청난 개선을 제공합니다. (일단 3가지만 나열하자면) nginx, 아파치 그리고 Jetty에서 사용 가능한 우아한 SPDY 모듈이 있습니다.
- QUIC은 UDP의 최상위에 구축된 새롭고 실험적인 프로토콜입니다. 아직 초기지만 사용자가 (성능과의 전쟁에서) 승리할 수 있도록 해줍니다.
#perfmatters: 60fps 레이아웃 및 렌더링
슬라이드
- 프레임은 16ms입니다. 이는 자바스크립트, 스타일 계산, 페인팅, 합성(Compositing)을 포함하는 과정입니다.
- 페인팅은 매우 비싼 비용을 소모합니다. 페인팅의 폭풍은 불필요하게 비싼 페인트 동작을 반복합니다.
- 레이어는 페인팅된 엘리먼트들을 캐싱하는데 사용됩니다.
- 입력 핸들러들(터치, 마우스휠 리스너들)은 반응성을 죽일 수도 있습니다. 가능하다면 이를 피하세요. 그럴 수 없는 곳에서는 이를 최소화해야 합니다.
#perfmatters: 즉각적인 모바일 웹앱
슬라이드
- 렌더링을 블록하는 자바스크립트와 CSS를 제거하세요
- 보여야하는 컨텐츠의 우선순위를 결정하세요.
- 스크립트는 비동기적으로 로딩하세요.
- 초기 뷰를 서버 사이드 HTML으로 렌더링하고 이후에 JavaScript로 강화하세요.
- 렌더링을 블록하는 CSS를 최소화하세요. 초기 뷰포트를 디스플레이하는데 필요한 스타일만 전달하고 그 뒤에 나머지를 전달하세요.
- 렌더링을 블록하는 CSS 내에서 인라인된 커다란 Data URI들은 렌더링 성능에 치명적입니다. 이미지 URL들이 논-블로킹인 곳에서도 리소스를 블록합니다.
댓글 없음:
댓글 쓰기