[20160827] GDG WebTech Workshop

질의사항이나 피드백은 다음을 통해 부탁드립니다.

• GDG Korea 슬랙: https://gdgkr.herokuapp.com/ #webtech 채널
• 페이스북/트위터: #gdgkr, #perfmatters 태그
• Google+: https://plus.google.com/communities/109067040035659120428

발표 슬라이드

1. http://www.slideshare.net/cwdoh/gdg-webtech-1
2. http://www.slideshare.net/cwdoh/instant-and-offline-apps-with-service-worker
3. http://www.slideshare.net/cwdoh/service-worker-101
4. http://www.slideshare.net/cwdoh/overview-how-to-measure-your-web-app

#1. 크롬 렌더링 성능 인자 이해하기

[ 정리 ]

같은 기능을 "하드웨어"의 지원을 통해 더 빠르게 처리하는 것이 핵심이다. 하드웨어는 분업이 되어 있기 때문에 빠를 수 밖에 없다. 혼자서 주문 받고 요리하고 서빙까지 하는 곳보다, 지배인이 주문 받고 요리사가 요리하고, 종업원이 서빙 하는 곳이 더 빠르게 일을 할 수 있는 것과 같다. 소프트웨어 렌더링 성능은 주요 기능의 수행 시간 + 그래픽스 출력 시간이다.

CPU와 GPU의 차이는 그 작업 처리 방식을 비교해보면 쉽게 알 수 있습니다. 하나의 CPU는 직렬 처리에 최적화된 몇 개의 코어로 구성된 반면, GPU는 병렬 처리용으로 설계된 수 천 개의 보다 소형이고 효율적인 코어로 구성되어 있습니다. http://kr.nvidia.com/object/what-is-gpu-computing-kr.html

CPU와 GPU 사이에 존재하는 이슈들

• 서로 다른 메모리 공간
• CPU는 메인 메모리, GPU 비디오 메모리
• 이 둘을 연결하는 버스(bus)라는게 있는데 느림
• 메모리는 한계가 있다.
• 데이터는 자주 변경된다.
• CPU 데이터 변경 시 GPU 메모리도 변경 필요

GPU가 잘하는 것들

• Vertex & Polygon
• 공간 좌표(버텍스)가 모여 도형(폴리곤)을…
• Texture & Texture Mapping
• 이미지(텍스쳐)를 도형에 씌워 그리기(매핑)
• Transform(변환)
• 회전, 확대, 축소, 기울임

하드웨어 가속 렌더링의 성능 최적화를 위한 첫 걸음

• GPU가 잘하는 것과 못하는 것의 이해
• 장점 : 수신된 데이터로 무언가를 그리는데 적합
• 텍스쳐를 가지고 이미지를 빠르게 출력 가능
• 이미 가진 텍스쳐는 다시 받지 않고 재활용
• 회전, 확대, 축소, 기술임, 반투명 처리 등
• 위 기능들의 동시 처리하는 것도 매우 최적화
• 단점 : 비디오 메모리로의 데이터 전송은 느림
• 데이터 전송 시간 = 데이터 크기 / bus 속도
• 일반적으로 예상되는 데이터 크기
• GPU 명령 < 버텍스 < 텍스쳐 이미지
• 텍스쳐 이미지라는 것은 화면에 보이는 모든것임 (글자도 하나하나 다 그리는 것임)
• GPU 의 데이터는 CPU에서 생성 후 전송
• CPU -> DATA -> VRAM(비디오램) -> GPU -> RENDERING
• 즉, 렌더링의 관점에서 지피유에서 사용될 데이터를 새로 만들어서 이를 전송하는 과정은 하나의 과정!
• 지피유가 그리는 그림은 시피유가 만들어 줌
• 시피유가 새로운 데이터를 만드는 작업은 최소화
• 비디오 메모리로 전송된 데이터를 최소화

웹 페이지의 렌더링

* 크롬의 렌더링

1. 웹 페이지는 파싱을 통해 돔 트리로 해석되어 메모리에 적재

2. 돔 트리를 렌더링 트리로 생성 후 각 노드들을 개별적인 이미지로 생성

3. 트리 구조 및 스타일에 따라 이미지를 배치

* 레이어 모델

웹 페이지를 렌더링 하기 위해 필요한 이미지 단위의 요소

• 각 레이어는 최종적으로 표현될 이미지를 생성하는 단위
• 생성된 이미지는 텍스쳐로서 지피유에 업로드
• 레이어들을 배치/합성하여 최종적인 웹페이지 표현

노트

• 레이어의 이미지는 시피유에서 생성!
• 즉, 레이어에서 생성되는 이미지는 시피유 시간 소모!

* 컴포지트(Composite)

여러개의 이미지를 하나의 이미지로 합성하는 것

* 이슈

• Reflow = layout = lay outing
• 돔 노드가 가지는 레이아웃 정보가 변경되면 레이아웃은 재배치를 위한 계산이 필요
• 리플로우로 발생할 수 있는 일
• 레이아웃의 변경이 트리를 따라 전파(시피유)
• 많은 경우 레이어 이미지의 갱신 필요(지피유)
• 레이어 이미지가 변경되면 비디오램의 텍스쳐 갱신 필요(RAM to VRAM Bandwidth!)
• Repaint
• 레이아웃 내 컨텐츠 변경 시 텍스쳐를 새로 생성 필요
• 지피유가 다시 그리는 건 상관 없는데 시피유부터 다시 처리해야 해서 느려지는 것

* 리플로우 리페인트 발생 요인

• 돔 노드의 동적인 추가/삭제/업데이트
• 돔 노드의 감춤/표시
• display, visibility
• 돔 노드의 이동, 애니메이션
• 스타일시트의 추가 혹은 스타일 속성의 변경
• 미디어 쿼리 역시
• 브라우저 사이즈 변경
• 폰트 변경
• 스크롤

* 크롬 데브툴 : 타임라인 - 프레임

* 빠른 렌더링 패스를 구현하는 것이 아니다.

- 렌더링 패스는 철저하게 브라우저의 영역

웹 렌더링 성능 최적화는 만드는 것이 아니라 병목 구간의 발생 요인을 피해가는 것

<크롬 개발자 도구 : 렌더링 >

녹색 이외에는 리플로우가 일어나지 않는 것

이미지가 이미 지피유에 올라가 있다

스크롤에도 리페인트가 발생

핵 : translateZ(0); 는 노드의 z축을 0으로 정하는 값

강제적인 레이어 분리가 만능은 아니다.

왜? 레이어분리-텍스쳐이미지분리-추가적인 메모리 소모

메모리는 유한 : 송수신 오버헤드 

따라서! 레이어 분리는 최소화 필요!

will-change (https://css-tricks.com/almanac/properties/w/will-change/)

#2. Instant and offline apps with Service Worker

• Goals
• Don’t be big
• Only download what you need
• srcset
• round trips
• script, script defer, script async 차이
• 언제 로딩하고 언제 파싱하냐
• script async defer 라고 적어도 된다
• Regioning / Critical … then Rest
• iFrame
• 아이프레임이 로딩되는 동안 페이지 블락 발생, 자바스크립트 실행 시작도 늦춰짐
• 아이프레임을 직접 박지 않고 페이지 레디가 되면 실행할 수 있도록 코드를 짬
• HTTP 1.1 -> HTTP/2
• http://www.slideshare.net/eungjun/http2-40582114

#3. Service Worker

한글 http://www.slideshare.net/cwdoh/service-worker-101

영문 http://www.slideshare.net/cwdoh/service-worker-101-en

• 웹 워커란?
• 메인 페이지와 병렬 스크립트를 실행하는 백그라운드 워커를 생성하는 API
• 메시지 전송 기반의 스레드와 유사한 동작을 가능하게 한다.
• 모든 워커는 자체적인 스코프가 있다. 윈도우가 아닌 다른 스코프를 가질 수 있다. (self) 그리고 우리의 대부분의 API는 그 글로벌 scope에서 작동한다.
• 오프라인 캐시 
• 이 공룡이 움직이는거였다니!!!!!!!!!!!! 게임소스도 오픈소스!
• 웹앱
• <link rel=“manifest” href=“manifest.json”>
• 데모
• https://github.com/cwdoh/serviceworker-101
• Adding User-Timing
• ns(나노세컨드) 측정 가능
• window.performance.mark
• 크롬 개발자 도구 : Profiles
• Navigation timings APIs
• Performance Timing