ZINEE/Experiences

[20160827] GDG WebTech Workshop

zineeworld 2016. 8. 29. 02:00

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

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

발표 슬라이드

http://www.slideshare.net/cwdoh/gdg-webtech-1
http://www.slideshare.net/cwdoh/instant-and-offline-apps-with-service-worker
http://www.slideshare.net/cwdoh/service-worker-101
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

저작자표시 비영리 변경금지