GDG DevFair 2014 
프론트엔드 개발자를 위한 
크롬 성능 인자 이해하기
+Changwook.Doh 
cwdoh.com
Agenda 
Rendering Performance 
ServiceWorker
H/W Acceleration?
VS
H/W Acceleration 
for Graphics
VS
S/W 렌더링과 H/W Acc. 렌더링
소프트웨어 렌더링의 실행 구조
소프트웨어 렌더링 성능 
응용 프로그램의 실행 성능 = 
주요 기능의 수행 시간 + 그래픽스 출력 시간
대량의 연산이 필요한 렌더링의 경우
Software only
+ GPU Acceleration 
렌더링 작업 지시
http://www.bedbugbarrieorilliapestcontrol.ca/resources/RestChef2.jpg
CPU와 GPU 사이에 
존재하는 이슈들
이슈 1. 서로 다른 메모리 공간 
“CPU와 GPU는 전혀 다른 메모리 공간을 사용” 
CPU 
Main Memory 
GPU 
Video Memory 
BUS 
무엇을 그려야 하는지 알려주세요!
이슈 2. 메모리는 한계가 있다. 
“처리할 모든 데이터는 메모리에, 하지만 한계가...” 
코드 이미지 데이터 
또 다른 코드 또 다른 데이터 
Memory 
새로운 
데이터 
????? 
“더 이상 저장할 수 없으면...
이슈 3. 데이터는 자주 변경된다. 
“CPU의 데이터 변경 시 GPU 메모리도 변경 필요” 
CPU가 변경한 이미지(메인 메모리) GPU가 알고 있는 이미지(VRAM) 
디스플레이? 
“모르는 걸 어떻게 그려요?”
GPU에서 일어나는 일들
간단한 3D 그래픽스 개념 & 
GPU의 렌더링 동작
Vertex & Polygon 
“공간 좌표(Vertex)가 모여 도형(Polygon)을...”
Texture & Texture Mapping 
“이미지(Texture)를 도형에 씌워 그리기(Mapping)”
변환(Transform) 
“회전/확대/축소/기울임/...”
20년 전의 렌더링 파이프라인 
우리가 말하는 비디 
오 메모리 
버텍스가 모여서 
폴리곤에 
텍스쳐를 입혀서 
디스플레이 이미지로
하드웨어 가속 렌더링의 
성능 최적화를 위한 첫걸음: 
GPU가 잘하는 것과 못하는 것의 이해
GPU가 잘하는 것 
“GPU는 수신된 데이터로 무언가를 그리는데 적합” 
1. 텍스쳐를 가지고 이미지를 빠르게 출력 가능 
2. 이미 가진 텍스쳐는 다시 받지 않고 재활용 
3. 회전, 확대, 축소, 기울임, 반투명 ...
그렇다면 
GPU의 동작을 방해하는 일들은?
비디오 메모리로의 데이터 전송 속도 
FACT> “비디오 메모리로의 데이터 전송은 느림” 
CPU 
Main Memory 
GPU 
Video Memory 
BUS
이슈: 비디오 메모리로의 전송 속도 
“데이터 전송 시간 = 데이터의 크기 / BUS 속도” 
● 일반적으로 예상되는 데이터 크기: 
o GPU 명령 < 버텍스 < 텍스쳐 이미지
더 큰 이슈: CPU 처리 시간 
FACT> “GPU의 데이터는 CPU에서 생성 후 전송” 
CPU 
데이터 
GPU 
2 VRAM 
1 
3 
렌더링 
예> 코드에 의해 
텍스쳐로 사용될 
이미지를 생성 
즉, 렌더링...
중간 점검: 렌더링 성능의 주요 인자 
1. GPU는 회전/확대/축소/기울임/반투명 처리 등에 최적화 
a. 이 범주의 기능으로 렌더링이 처리될 수 있도록 
2. GPU에서 사용할 데이터를 준비하는 것은 CPU의 몫 
...
크롬의 하드웨어 가속 
렌더링 메커니즘
웹페이지의 렌더링
크롬의 렌더링 
1. 웹 페이지는 파싱을 통해 DOM 트리로 해석되어 메모리에 적재 
2. DOM 트리를 렌더링 트리로 생성 후 각 노드들을 개별적인 이미지로 생성 
3. 트리 구조 및 스타일에 따라 이미지를 배치 및 ...
레이어 모델 
레이어(Layer)? 
웹페이지를 렌더링하기 위해 필요한 이미지 단위의 요소 
● 각 레이어는 최종적으로 표현될 이미지를 생성하는 단위 
● 생성된 이미지는 텍스쳐로서 GPU에 업로드 
● 레이어들을 배치...
컴포지트(Composite)
이슈: Reflow 
● Reflow = Layout = Layouting 
o DOM 노드가 가지는 레이아웃 정보(Geometry)가 변경되 
면 레이아웃은 재배치를 위한 계산이 필요 
Header 
DIV 
Foot...
이슈. Reflow로 발생할 수 있는 일 
Node Node 
Node 
Node 
Node#A 
Node 
Node#A 
{ 
border: 30px; 
} 
Invalidate Invalidate 
Invalidat...
이슈: Repaint 
● Repaint = Redraw 
o 레이아웃 내 컨텐츠가 변경 시 텍스쳐를 새로 생성 필요 
CPU 
데이터 
GPU 
2 VRAM 
1 
3 
렌더링 
이 그림 기억하십니까?
이슈: Reflow/Repaint 발생 요인 
● DOM 노드의 동적인 추가/삭제/업데이트 
● DOM 노드의 감춤/표시 
o display: none 
o visibility: hidden 
● DOM 노드의 이동, ...
크롬 DevTools: Timeline - Frame
정리: 크롬에서의 전반적인 렌더링 흐름 
1. DOM으로부터 노드들을 개별적으로 혹은 그룹 지어 레이어 단위들로 분리 
2. 레이아웃을 계산하고 각 레이어들이 그려져야 할 영역의 크기 위치 등을 계산 
a. 위치/크기 ...
렌더링 성능 최적화!
최적화에 대한 그래픽 모듈의 구현 관점 
● 네이티브 어플리케이션 관점: 
o 최대한 가벼운 렌더링 프로세스의 구성이 목적 
> 3D 혹은 2D 게임 개발의 예 
“이번 게임은 꽤 그래픽 출력이 많기 때문에 CPU와 G...
웹 페이지에서의 렌더링 최적화는... 
● 빠른 렌더링 패스를 구현하는 것이 아니다!!! 
o 렌더링 패스는 철저하게 브라우저의 영역 
o 웹 렌더링 성능 최적화는 만드는 것이 아니라 병목 구간의 발 
생 요인을 피해가...
가장 간단한 Hack: 레이어의 분리 
크롬에서 DOM 노드가 레이어로 분리되는 조건들 
1. 3D 혹은 Perspective를 표현하는 CSS transform 속성을 가진 경우 
2. 하드웨어 가속 디코딩을 사용하는...
가장 간단한 Hack: 레이어의 분리 
분리 조건 요약: 해당 DOM 노드가 주변 노드와는 별도로 렌더링되어야 빠른 경우 
예1> 투명도(Opacity): 겹쳐진 다른 이미지와 픽셀 단위의 블렌딩(Blending)되는 ...
강제적인 레이어 분리가 만능은 아니다! 
● 왜? 
o 레이어 분리는 필연적으로 텍스쳐 이미지 분리를 의미 
§ 추가적인 메모리 소모 
o 메모리는 유한하다! 
§ 메모리 공간 부족 시 기존 데이터 릴리즈 후 새로운...
하드웨어 가속으로 얻는 성능은 
절대로 공짜가 아님! :) 
모든 것에 가능성을 두고 확인!
References 
1. 브라우저는 어떻게 동작하는가. 
2. 크롬의 렌더링 가속: 레이어 모델 
3. GPU Accelarated Compositing in Chrome 
4. Scrolling Performance...
http://goo.gl/x0E3g3 
Wicked Fast 
- Performance investments 
@Chrome Dev Summit 2014
Service Worker
Offline!! App. Cache!! 
App. Cache!! 
Offline!! 
Image: ‘Mission Impossible 4’ Movie
We forgot something! 
But…what?
Mission Impossible: 
● Truely controlling offline resources 
o Application Cache? OMG! 
o Everything managed by your webbr...
‘ServiceWorker’ solves... 
● Truely controlling offline/network stack 
o Programmable cache control 
o Custom response 
● ...
Yay, 
ServiceWorker!!
Overview: Service Worker 
● Event-driven scripts 
o that run independently of web pages 
● ServiceWorker has 
o Access to ...
Sufficient response 
http://www.slideshare.net/jungkees/service-workersa
Insufficient response 
http://www.slideshare.net/jungkees/service-workersa
Bring your own cache 
http://www.slideshare.net/jungkees/service-workersa
Fallback to network 
http://www.slideshare.net/jungkees/service-workersa
What can we do with ServiceWoker? 
● Eliminating loading time 
o Developer knows what is most important resource in 
our w...
Demo from Google I/O 2014: Topeka
// ServiceWorker is ‘Installed’!!! 
this.addEventListener("install", function(e) { 
e.waitUntil( caches.create("core") // ...
this.addEventListener("fetch", function(e) { 
var request = e.request; 
if (this.scope.indexOf(request.origin) == -1) { re...
References 
1. ServiceWorker first draft published 
2. Specification 
3. Explainer 
4. Implemetation Considerations 
5. Se...
ROCK You!
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
Upcoming SlideShare
Loading in …5
×

프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기

1,754 views

Published on

Talk about H/W acc. and rendering performance of chrome, and one more short talk about ServiceWorker.

Published in: Engineering
0 Comments
26 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,754
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
15
Comments
0
Likes
26
Embeds 0
No embeds

No notes for slide

프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기

  1. 1. GDG DevFair 2014 프론트엔드 개발자를 위한 크롬 성능 인자 이해하기
  2. 2. +Changwook.Doh cwdoh.com
  3. 3. Agenda Rendering Performance ServiceWorker
  4. 4. H/W Acceleration?
  5. 5. VS
  6. 6. H/W Acceleration for Graphics
  7. 7. VS
  8. 8. S/W 렌더링과 H/W Acc. 렌더링
  9. 9. 소프트웨어 렌더링의 실행 구조
  10. 10. 소프트웨어 렌더링 성능 응용 프로그램의 실행 성능 = 주요 기능의 수행 시간 + 그래픽스 출력 시간
  11. 11. 대량의 연산이 필요한 렌더링의 경우
  12. 12. Software only
  13. 13. + GPU Acceleration 렌더링 작업 지시
  14. 14. http://www.bedbugbarrieorilliapestcontrol.ca/resources/RestChef2.jpg
  15. 15. CPU와 GPU 사이에 존재하는 이슈들
  16. 16. 이슈 1. 서로 다른 메모리 공간 “CPU와 GPU는 전혀 다른 메모리 공간을 사용” CPU Main Memory GPU Video Memory BUS 무엇을 그려야 하는지 알려주세요!
  17. 17. 이슈 2. 메모리는 한계가 있다. “처리할 모든 데이터는 메모리에, 하지만 한계가...” 코드 이미지 데이터 또 다른 코드 또 다른 데이터 Memory 새로운 데이터 ????? “더 이상 저장할 수 없으면 어떻게???”
  18. 18. 이슈 3. 데이터는 자주 변경된다. “CPU의 데이터 변경 시 GPU 메모리도 변경 필요” CPU가 변경한 이미지(메인 메모리) GPU가 알고 있는 이미지(VRAM) 디스플레이? “모르는 걸 어떻게 그려요?”
  19. 19. GPU에서 일어나는 일들
  20. 20. 간단한 3D 그래픽스 개념 & GPU의 렌더링 동작
  21. 21. Vertex & Polygon “공간 좌표(Vertex)가 모여 도형(Polygon)을...”
  22. 22. Texture & Texture Mapping “이미지(Texture)를 도형에 씌워 그리기(Mapping)”
  23. 23. 변환(Transform) “회전/확대/축소/기울임/...”
  24. 24. 20년 전의 렌더링 파이프라인 우리가 말하는 비디 오 메모리 버텍스가 모여서 폴리곤에 텍스쳐를 입혀서 디스플레이 이미지로
  25. 25. 하드웨어 가속 렌더링의 성능 최적화를 위한 첫걸음: GPU가 잘하는 것과 못하는 것의 이해
  26. 26. GPU가 잘하는 것 “GPU는 수신된 데이터로 무언가를 그리는데 적합” 1. 텍스쳐를 가지고 이미지를 빠르게 출력 가능 2. 이미 가진 텍스쳐는 다시 받지 않고 재활용 3. 회전, 확대, 축소, 기울임, 반투명 처리 등 4. 위 기능들의 동시 처리하는 것도 매우 최적화
  27. 27. 그렇다면 GPU의 동작을 방해하는 일들은?
  28. 28. 비디오 메모리로의 데이터 전송 속도 FACT> “비디오 메모리로의 데이터 전송은 느림” CPU Main Memory GPU Video Memory BUS
  29. 29. 이슈: 비디오 메모리로의 전송 속도 “데이터 전송 시간 = 데이터의 크기 / BUS 속도” ● 일반적으로 예상되는 데이터 크기: o GPU 명령 < 버텍스 < 텍스쳐 이미지
  30. 30. 더 큰 이슈: CPU 처리 시간 FACT> “GPU의 데이터는 CPU에서 생성 후 전송” CPU 데이터 GPU 2 VRAM 1 3 렌더링 예> 코드에 의해 텍스쳐로 사용될 이미지를 생성 즉, 렌더링의 관점에서 GPU에서 사용될 데이터를 새로 만들어서 이를 전송하는 과정은 하나의 과정!
  31. 31. 중간 점검: 렌더링 성능의 주요 인자 1. GPU는 회전/확대/축소/기울임/반투명 처리 등에 최적화 a. 이 범주의 기능으로 렌더링이 처리될 수 있도록 2. GPU에서 사용할 데이터를 준비하는 것은 CPU의 몫 a. CPU가 새로운 데이터를 만드는 작업은 최소화 3. CPU가 준비한 데이터는 비디오 메모리에 전송 필요 a. 데이터의 전송을 최소화할 수 있도록...
  32. 32. 크롬의 하드웨어 가속 렌더링 메커니즘
  33. 33. 웹페이지의 렌더링
  34. 34. 크롬의 렌더링 1. 웹 페이지는 파싱을 통해 DOM 트리로 해석되어 메모리에 적재 2. DOM 트리를 렌더링 트리로 생성 후 각 노드들을 개별적인 이미지로 생성 3. 트리 구조 및 스타일에 따라 이미지를 배치 및 합성하여 출력
  35. 35. 레이어 모델 레이어(Layer)? 웹페이지를 렌더링하기 위해 필요한 이미지 단위의 요소 ● 각 레이어는 최종적으로 표현될 이미지를 생성하는 단위 ● 생성된 이미지는 텍스쳐로서 GPU에 업로드 ● 레이어들을 배치/합성하여 최종적인 웹페이지 표현 NOTE! ● 레이어의 이미지는 CPU에서 생성! o 즉, 레이어에서 생성되는 이미지는 CPU 시간 소모! 4개의 레이어로 이루어진 웹 페이지의 예
  36. 36. 컴포지트(Composite)
  37. 37. 이슈: Reflow ● Reflow = Layout = Layouting o DOM 노드가 가지는 레이아웃 정보(Geometry)가 변경되 면 레이아웃은 재배치를 위한 계산이 필요 Header DIV Footer Header DIV Footer
  38. 38. 이슈. Reflow로 발생할 수 있는 일 Node Node Node Node Node#A Node Node#A { border: 30px; } Invalidate Invalidate Invalidate 1. 레이아웃의 변경이 트리를 따라 전파 (CPU) 2. 많은 경우 레이어 이미지의 갱신 필요 (CPU) 3. 레이어 이미지가 변경되면 VRAM의 텍스쳐 갱신 필요 (RAM to VRAM Bandwidth!!!) INVALIDATE!!
  39. 39. 이슈: Repaint ● Repaint = Redraw o 레이아웃 내 컨텐츠가 변경 시 텍스쳐를 새로 생성 필요 CPU 데이터 GPU 2 VRAM 1 3 렌더링 이 그림 기억하십니까?
  40. 40. 이슈: Reflow/Repaint 발생 요인 ● DOM 노드의 동적인 추가/삭제/업데이트 ● DOM 노드의 감춤/표시 o display: none o visibility: hidden ● DOM 노드의 이동, 애니메이션 ● 스타일시트의 추가 혹은 스타일 속성의 변경 o 미디어 쿼리 역시 ● 브라우저 사이즈 변경 ● 폰트 변경 ● 스크롤 ● …
  41. 41. 크롬 DevTools: Timeline - Frame
  42. 42. 정리: 크롬에서의 전반적인 렌더링 흐름 1. DOM으로부터 노드들을 개별적으로 혹은 그룹 지어 레이어 단위들로 분리 2. 레이아웃을 계산하고 각 레이어들이 그려져야 할 영역의 크기 위치 등을 계산 a. 위치/크기 정보 등을 계산하기 위한 CPU의 계산 오버헤드가 발생 3. 레이어들 각각은 렌더링을 위해 비트맵으로 출력 a. CPU에서 레이어 이미지를 생성하는 오버헤드가 발생 4. 생성된 비트맵을 GPU에 텍스쳐로 업로드 a. GPU의 비디오 메모리로 전송하는 오버헤드는 발생 5. 계산된 레이아웃으로 레이어의 텍스쳐 이미지들을 최종 스크린 이미지로 합성
  43. 43. 렌더링 성능 최적화!
  44. 44. 최적화에 대한 그래픽 모듈의 구현 관점 ● 네이티브 어플리케이션 관점: o 최대한 가벼운 렌더링 프로세스의 구성이 목적 > 3D 혹은 2D 게임 개발의 예 “이번 게임은 꽤 그래픽 출력이 많기 때문에 CPU와 GPU 사이의 병목 구간을 최소 화할 수 있도록 텍스쳐의 생성/업로드를 병목 구간 전에 미리 처리하고, 텍스쳐 캐싱 정책을 블라블라한 모델에 따라 관리하도록 모듈을 !@#!@$ 하게 작성합니다. 또한 우리 게임에서 특별하게 발생할 몇몇 상황에도 이러한 렌더링 모듈에 대한 커스 텀 구현으로 이를 회피할 방법을 찾을 수 있을 것입니다.” - A개발팀장의 커피톡
  45. 45. 웹 페이지에서의 렌더링 최적화는... ● 빠른 렌더링 패스를 구현하는 것이 아니다!!! o 렌더링 패스는 철저하게 브라우저의 영역 o 웹 렌더링 성능 최적화는 만드는 것이 아니라 병목 구간의 발 생 요인을 피해가는 것! ● 피해야 할 성능의 위험 인자 o CPU에서 텍스쳐 이미지를 생성하는 요인들 o 가급적이면 레이아웃 변경의 요인도!!
  46. 46. 가장 간단한 Hack: 레이어의 분리 크롬에서 DOM 노드가 레이어로 분리되는 조건들 1. 3D 혹은 Perspective를 표현하는 CSS transform 속성을 가진 경우 2. 하드웨어 가속 디코딩을 사용하는 <video> 엘리먼트 3. 3D 컨텍스트 혹은 하드웨어 가속 2D 컨텍스트를 가지는 <canvas> 엘리먼트 4. (플래시와 같은) 플러그인 영역 5. 투명도(opacity) 속성 혹은 transform 애니메이션의 사용 6. 가속 가능한 CSS 필터를 가진 경우 7. Compositing Layer를 하위 노드로 가진 경우 8. 낮은 z-index를 가진 형제 노드가 Compositing Layer를 가진 경우
  47. 47. 가장 간단한 Hack: 레이어의 분리 분리 조건 요약: 해당 DOM 노드가 주변 노드와는 별도로 렌더링되어야 빠른 경우 예1> 투명도(Opacity): 겹쳐진 다른 이미지와 픽셀 단위의 블렌딩(Blending)되는 경우. 하지만 애니메이션에서만 성능 이슈가 발생하므로 애니메이션일 경우만 분리 예2> 매번 표시되는 프레임이 변경되는 <video> 엘리먼트. 개발자의 Hack! translateZ(0); ● translateZ(0);는 노드의 Z축 값으로 0을 주는 무의미한 코드 ● 그러나 레이어 분리 조건의 첫번째 항목에 해당
  48. 48. 강제적인 레이어 분리가 만능은 아니다! ● 왜? o 레이어 분리는 필연적으로 텍스쳐 이미지 분리를 의미 § 추가적인 메모리 소모 o 메모리는 유한하다! § 메모리 공간 부족 시 기존 데이터 릴리즈 후 새로운 데이터의 업로드 ● 최악의 경우가 반복되면... § 레이어 분리를 통한 성능 이점을 송수신 오버헤드로 상쇄 ● 따라서, 레이어 분리는 최소화 필요!!!
  49. 49. 하드웨어 가속으로 얻는 성능은 절대로 공짜가 아님! :) 모든 것에 가능성을 두고 확인!
  50. 50. References 1. 브라우저는 어떻게 동작하는가. 2. 크롬의 렌더링 가속: 레이어 모델 3. GPU Accelarated Compositing in Chrome 4. Scrolling Performance 5. Jank Busting for Better Rendering Performance 6. CSS 페인트 타임과 페이지 렌더 가중치 7. 불필요한 페인팅 회피하기 8. 불필요한 페인팅 회피하기: Animated GIF 버전 9. 고성능 애니메이션 10. Rendering: repaint, reflow/relayout, restyle 11. How (not) to trigger a layout in WebKit
  51. 51. http://goo.gl/x0E3g3 Wicked Fast - Performance investments @Chrome Dev Summit 2014
  52. 52. Service Worker
  53. 53. Offline!! App. Cache!! App. Cache!! Offline!! Image: ‘Mission Impossible 4’ Movie
  54. 54. We forgot something! But…what?
  55. 55. Mission Impossible: ● Truely controlling offline resources o Application Cache? OMG! o Everything managed by your webbrowser! ● Plus, background processing o Remote Push Notification, Alarm, Background-update of resources, ... o Everything run on your webpage!
  56. 56. ‘ServiceWorker’ solves... ● Truely controlling offline/network stack o Programmable cache control o Custom response ● Plus, background processing o Remote Push Notification o Task Scheduler(e.g. Local Notification) o BackgroundSync o ...
  57. 57. Yay, ServiceWorker!!
  58. 58. Overview: Service Worker ● Event-driven scripts o that run independently of web pages ● ServiceWorker has o Access to domain-wide events such as network fetches o scriptable caches § The ability to respond to network requests from certain web pages via script § A way for applications to "go offline"
  59. 59. Sufficient response http://www.slideshare.net/jungkees/service-workersa
  60. 60. Insufficient response http://www.slideshare.net/jungkees/service-workersa
  61. 61. Bring your own cache http://www.slideshare.net/jungkees/service-workersa
  62. 62. Fallback to network http://www.slideshare.net/jungkees/service-workersa
  63. 63. What can we do with ServiceWoker? ● Eliminating loading time o Developer knows what is most important resource in our webpages. § We can control ‘request/response flow’ and ‘cache’ with ServiceWorker. § and Front-end developers just write their code without other libraries to control data-flow. o Your page will be loaded in an instant!!! ● Other features come and see us soon. :)
  64. 64. Demo from Google I/O 2014: Topeka
  65. 65. // ServiceWorker is ‘Installed’!!! this.addEventListener("install", function(e) { e.waitUntil( caches.create("core") // Creating Cache ‘core’! .then(function(core) { var resourceUrls = [ "", "?offline", "components/core-ajax/core-ajax.html", // ... ]; return Promise.all(resourceUrls.map(function(relativeUrl) { // Add resource to cache ‘core’ return core.add(baseUrl + relativeUrl); })); })); });
  66. 66. this.addEventListener("fetch", function(e) { var request = e.request; if (this.scope.indexOf(request.origin) == -1) { return; } // Basic read-through caching. e.respondWith( caches.match(request, "core").then( function(response) { return response; }, function() { // we didn't have it in the cache, so add it to the cache and return it return caches.get("core").then( function(core) { log("runtime caching:", request.url); // FIXME(slighltyoff): add should take/return an array return core.add(request).then( function(response) { return response; }); // ...
  67. 67. References 1. ServiceWorker first draft published 2. Specification 3. Explainer 4. Implemetation Considerations 5. Service Workers: Bring your own magic 6. Topeka Demo @Google I/O 2014 7. webapplication.kr
  68. 68. ROCK You!

×