Google IO Extended 2015 Seoul This slide is about the RAIL that is a performance model for web applications by Google Chrome Team.

1. Performance & RAIL
장정환 @nundefined

2. Performance
https://www.flickr.com/photos/rethwill/8685622909

3. Performance?
작업을 수행했을 때
성공적으로 실행된 정도를 기준으로
작업을 바라보는 것

4. 성공적인 실행이란?
인지 반응 시간의 기대 수준을 충족시켜
사용자가 만족감을 느끼는 상태가 된 것

5. 사용자가 만족하는 기준은 무엇인가?
https://www.flickr.com/photos/51029297@N00/5275403364

6. RAIL
https://commons.wikimedia.org/wiki/File:Adelaide_Darwin_Railway_Line_between_Adelaide_River_and_Pine_Creek_DSC03643.jpg

7. 읽고 생각
스크롤 드래그Transition
진행 상태 표시 상태 변경
로드
클릭
페이지 이동
IDLE
RESPONSE
ANIMATION
LOAD

8. Response
사용자의 액션 후 반응할 때까지의 응답 시간
0ms < T < 100ms 즉각 반응
100ms < T < 200ms 지연되고 있음
200ms < T < 불만족

9. Applied Sciences Group: High Performance Touch

10. 즉각적인 반응이 중요한 이유
인간의 한계
기억과 집중
인간의 욕심
http://arycarys.deviantart.com/art/Xbox-controller-white-476639117

11. Animation
16ms마다 갱신
60fps = 16.6ms/frame
스크롤 포함

12. 어느 쪽이 더 좋은 Performance?
A
0.5초 동안 멈춘 후
0.5초 동안
16ms마다
화면 업데이트
B
1초 동안
32ms 마다
화면 업데이트

13. 16ms는 충분한 시간?
https://www.flickr.com/photos/51029297@N00/5275403364

14. IDLE
사용자의 행동을 대기하는 시간
길 수록 좋음
프로그램 작업 < 50ms

15. LOAD
1000ms 이내에 컨텐츠를 보여줘야 함
모든 내용을 보여줄 필요는 없음

16. LOAD > 1000ms?
https://www.flickr.com/photos/51029297@N00/5275403364

17. 읽고 생각
스크롤 드래그Transition
진행 상태 표시 상태 변경
로드
클릭
페이지 이동
IDLE
RESPONSE
ANIMATION
LOAD
< 100ms
< 10ms
< 1000ms

18. ++Performance
https://www.flickr.com/photos/thatguyfromcchs08/2300190277

19. Critical Rendering Path
HTML, CSS, JavaScript 코드를 받아
픽셀로 화면에 표시할 것을 요청하는 과정

20. http://helloworld.naver.com/helloworld/59361
DOM
DOM
트리
Render
트리
스타일
규칙
HTML
Style
Sheet
표시
HTML
파서
CSS
파서
어태치먼트
배치
그리기
Critical Rendering Path

21. DOM
DOM
트리
HTML HTML
파서
DevTools에 Parse HTML로 표시
DomContentLoaded 이벤트 발생
DOM 트리 생성

22. 스타일
규칙Style
Sheet
CSS
파서
CSS Object Model 트리 생성
DevTools에 Recalculate Styles로 표시
CSSOM 트리 생성

23. 스타일
규칙
Render
트리
DOM
트리
어태치먼트
화면에 표시되지 않는 정보는 포함되지 않음
(display: none)
Render 트리 생성

24. Render
트리
배치단말의 화면 내에서의
정확한 위치, 크기를 계산
레이아웃

25. Render
트리
표시그리기Render 트리의 노드를 픽셀로 변환
페인트

26. 과정을 멈추게 하는 요소
CSS: Render Blocking
- 처음 페이지 로딩할 때만 영향
- 필요한 css만 적용 (media type, media queries)
JavaScript: Parser Blocking
- async 추가하여 JavaScript의 실행을 지연시킴

27. Critical Rendering Path 최적화
Parser/Render Blocking 리소스 최소화
다운로드해야 할 데이터의 최소화

28. Parser/Render Blocking 리소스 최소화
불필요한 CSS/Javascript 제거
async, defer의 사용
동기적인 서버 호출 최소화
CSS import 사용 자제
Render Blocking CSS는 HTML 문서 내에 삽입

29. 다운로드할 데이터의 최소화
불필요한 이미지 제거
적절한 이미지 포맷
이미지 압축
벡터 이미지 (SVG)
CSS3
알맞은 사이즈 이미지

30. JavaScript를 사용한 페이지 변경
DOM/CSSOM
변경
https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing?hl=ko

31. 렌더링 최적화
requestAnimationFrame
Web Workers
Selector 복잡도 낮게
Block, Element, Modifier 코딩 방식 사용
- 단일 클래스 사용
- 계층 구조는 클래스 이름에 반영
- ._list__list-item--first-child

32. 강제 동기 레이아웃의 회피
속성 값을 변경하면
강제 레이아웃 후
값을 확인
function setClassAndLog(someClass) {
target.classList.add(someClass);
// 강제 동기 레이아웃 발생
console.log(target.offsetHeight);
}
function setClassAndLog(someClass) {
console.log(target.offsetHeight);
target.classList.add(someClass);
}
값을 먼저 읽고 스타일을 변경한다.

33. 렌더링 영역 최적화
Console > Rendering > Show paint rectangles
Timeline > Paint - Paint profiler

34. 렌더링 영역 최적화
will-change (transform) 사용
// 지원 브라우저 - chrome, opera, firefox
.target_element {
will-change: transform;
}
// 미지원 브라우저 - safari, mobile safari
.target_element {
trasnform: translateZ(0);
}

35. Input handler 최적화
스타일 변경시 requestAnimationFrame에서 시각적
속성을 확인하므로 강제 동기 레이아웃 발생
requestAnimationFrame의 콜백에서 스타일 변경

36. Summary
https://commons.wikimedia.org/wiki/File:Plastic-compass.jpg

37. RAIL
사용자 중심
Response < 100ms
Animation < 10ms
IDLE - 가능한 길게. 작업을 한다면 50ms 이내
Load < 1000ms

38. 최적화
Critical Rendering Path 최적화
- 렌더링에 꼭 필요한 최적화된 데이터 사용
렌더링 최적화
- requestAnimationFrame/Web Workers
- Selector 단순화
- 강제 동기 레이아웃 회피
- DevTools의 적극적 사용

39. 개발자 도구 실험 사용
39

40. Thank you