2014년 1월 8일 수요일

[업데이트/Summit] 크롬 개발자 서밋: 성능 부문 요약(Chrome Dev Summit: Performance Summary)

오늘은 +Paul Lewis가 Chrome  Dev Summit의 성능과 관련된 세션들의 요약을 업데이트했네요. 개인적으로도 관심이 많은 영역입니다만 도구화, 렌더링, 네트워크, 모바일에 대한 최적화가 한곳에 있으니 다들 읽어보시면 좋을 듯 합니다. 이전과 마찬가지로 자세한 내용은 전문을 참고하시기 바랍니다.


"성능은 언제나 이슈지요. 그래서 성능 역시 기능입니다."


#perfmatters: 퍼포먼스 닌자를 위한 도구화 기술들


개발도구에 대해 방향을 앎에 있어 요점은 성능의 그랜드 마스터가 되는 것입니다.
+Colt McAnlis는 성능과 관련하여 네트워크, 연산, 렌더링에 대한 3개의 기둥을 다루었습니다.

슬라이드


  • 이제 여러분은 데스크탑에서 알고 사랑해온 크롬 개발자도구를 사용하여 안드로이드 크롬(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 레이아웃 및 렌더링


    여러분의 프로젝트에서 60fps에 닿는다는 것은 사용자와의 약속과  프로젝트의 성공에 중대하게 즉각적으로 연관되어 있습니다. 이번 발표에서 +Nat Duca와 +Tom Wiltzius는 크롬의 렌더링 파이프라인에 대해 설명하고 프레임을 떨어뜨리는 몇가지 일반적인 경우와 그를 회피하기 위한 방법을 다룹니다.

    슬라이드


    • 프레임은 16ms입니다. 이는 자바스크립트, 스타일 계산, 페인팅, 합성(Compositing)을 포함하는 과정입니다.
    • 페인팅은 매우 비싼 비용을 소모합니다. 페인팅의 폭풍은 불필요하게 비싼 페인트 동작을 반복합니다.
    • 레이어는 페인팅된 엘리먼트들을 캐싱하는데 사용됩니다.
    • 입력 핸들러들(터치, 마우스휠 리스너들)은 반응성을 죽일 수도 있습니다. 가능하다면 이를 피하세요. 그럴 수 없는 곳에서는 이를 최소화해야 합니다.


    #perfmatters: 즉각적인 모바일 웹앱


    중대한 렌더링 경로(Critical Rendering Path, 이하 CRP)는 페이지 페인팅을 시작할 수 있기 전까지 브라우저가 필요로 하는 어떠한 것(JavaScript, HTML, CSS, 이미지 등)과도 연관될 수 있습니다. CRP에서 애셋의 전달 우선순위를 결정하는 것은 셀룰러 네트워크 상의 스마트폰같이 네트워크가 제한적인 디바이스의 사용자들을 위한 필수적이고 까다로운  것입니다. +Bryan McQuade가 구글의 팀이 어떻게 PageSpeed Insights 웹사이트를 위해 애셋들을 선정과 우선순위의 결정 과정을 진행하는지에 대해 설명하고, 20초의 로딩 시간을 단 1초로 바꿀 수 있었는지에 대해 이야기합니다!

    슬라이드


    • 렌더링을 블록하는 자바스크립트와 CSS를 제거하세요
    • 보여야하는 컨텐츠의 우선순위를 결정하세요.
    • 스크립트는 비동기적으로 로딩하세요.
    • 초기 뷰를 서버 사이드 HTML으로 렌더링하고 이후에 JavaScript로 강화하세요.
    • 렌더링을 블록하는 CSS를 최소화하세요. 초기 뷰포트를 디스플레이하는데 필요한 스타일만 전달하고 그 뒤에 나머지를 전달하세요.
    • 렌더링을 블록하는 CSS 내에서 인라인된 커다란 Data URI들은 렌더링 성능에 치명적입니다. 이미지 URL들이 논-블로킹인 곳에서도 리소스를 블록합니다.