Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Performance and rail

537 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Performance and rail

  1. 1. Performance & RAIL 장정환 @nundefined
  2. 2. Performance https://www.flickr.com/photos/rethwill/8685622909
  3. 3. Performance? 작업을 수행했을 때 성공적으로 실행된 정도를 기준으로 작업을 바라보는 것
  4. 4. 성공적인 실행이란? 인지 반응 시간의 기대 수준을 충족시켜 사용자가 만족감을 느끼는 상태가 된 것
  5. 5. 사용자가 만족하는 기준은 무엇인가? https://www.flickr.com/photos/51029297@N00/5275403364
  6. 6. RAIL https://commons.wikimedia.org/wiki/File:Adelaide_Darwin_Railway_Line_between_Adelaide_River_and_Pine_Creek_DSC03643.jpg
  7. 7. 읽고 생각 스크롤 드래그Transition 진행 상태 표시 상태 변경 로드 클릭 페이지 이동 IDLE RESPONSE ANIMATION LOAD
  8. 8. Response 사용자의 액션 후 반응할 때까지의 응답 시간 0ms < T < 100ms 즉각 반응 100ms < T < 200ms 지연되고 있음 200ms < T < 불만족
  9. 9. Applied Sciences Group: High Performance Touch
  10. 10. 즉각적인 반응이 중요한 이유 인간의 한계 기억과 집중 인간의 욕심 http://arycarys.deviantart.com/art/Xbox-controller-white-476639117
  11. 11. Animation 16ms마다 갱신 60fps = 16.6ms/frame 스크롤 포함
  12. 12. 어느 쪽이 더 좋은 Performance? A 0.5초 동안 멈춘 후 0.5초 동안 16ms마다 화면 업데이트 B 1초 동안 32ms 마다 화면 업데이트
  13. 13. 16ms는 충분한 시간? https://www.flickr.com/photos/51029297@N00/5275403364
  14. 14. IDLE 사용자의 행동을 대기하는 시간 길 수록 좋음 프로그램 작업 < 50ms
  15. 15. LOAD 1000ms 이내에 컨텐츠를 보여줘야 함 모든 내용을 보여줄 필요는 없음
  16. 16. LOAD > 1000ms? https://www.flickr.com/photos/51029297@N00/5275403364
  17. 17. 읽고 생각 스크롤 드래그Transition 진행 상태 표시 상태 변경 로드 클릭 페이지 이동 IDLE RESPONSE ANIMATION LOAD < 100ms < 10ms < 1000ms
  18. 18. ++Performance https://www.flickr.com/photos/thatguyfromcchs08/2300190277
  19. 19. Critical Rendering Path HTML, CSS, JavaScript 코드를 받아 픽셀로 화면에 표시할 것을 요청하는 과정
  20. 20. http://helloworld.naver.com/helloworld/59361 DOM DOM 트리 Render 트리 스타일 규칙 HTML Style Sheet 표시 HTML 파서 CSS 파서 어태치먼트 배치 그리기 Critical Rendering Path
  21. 21. DOM DOM 트리 HTML HTML 파서 DevTools에 Parse HTML로 표시 DomContentLoaded 이벤트 발생 DOM 트리 생성
  22. 22. 스타일 규칙Style Sheet CSS 파서 CSS Object Model 트리 생성 DevTools에 Recalculate Styles로 표시 CSSOM 트리 생성
  23. 23. 스타일 규칙 Render 트리 DOM 트리 어태치먼트 화면에 표시되지 않는 정보는 포함되지 않음 (display: none) Render 트리 생성
  24. 24. Render 트리 배치단말의 화면 내에서의 정확한 위치, 크기를 계산 레이아웃
  25. 25. Render 트리 표시그리기Render 트리의 노드를 픽셀로 변환 페인트
  26. 26. 과정을 멈추게 하는 요소 CSS: Render Blocking - 처음 페이지 로딩할 때만 영향 - 필요한 css만 적용 (media type, media queries) JavaScript: Parser Blocking - async 추가하여 JavaScript의 실행을 지연시킴
  27. 27. Critical Rendering Path 최적화 Parser/Render Blocking 리소스 최소화 다운로드해야 할 데이터의 최소화
  28. 28. Parser/Render Blocking 리소스 최소화 불필요한 CSS/Javascript 제거 async, defer의 사용 동기적인 서버 호출 최소화 CSS import 사용 자제 Render Blocking CSS는 HTML 문서 내에 삽입
  29. 29. 다운로드할 데이터의 최소화 불필요한 이미지 제거 적절한 이미지 포맷 이미지 압축 벡터 이미지 (SVG) CSS3 알맞은 사이즈 이미지
  30. 30. JavaScript를 사용한 페이지 변경 DOM/CSSOM 변경 https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing?hl=ko
  31. 31. 렌더링 최적화 requestAnimationFrame Web Workers Selector 복잡도 낮게 Block, Element, Modifier 코딩 방식 사용 - 단일 클래스 사용 - 계층 구조는 클래스 이름에 반영 - ._list__list-item--first-child
  32. 32. 강제 동기 레이아웃의 회피 속성 값을 변경하면 강제 레이아웃 후 값을 확인 function setClassAndLog(someClass) { target.classList.add(someClass); // 강제 동기 레이아웃 발생 console.log(target.offsetHeight); } function setClassAndLog(someClass) { console.log(target.offsetHeight); target.classList.add(someClass); } 값을 먼저 읽고 스타일을 변경한다.
  33. 33. 렌더링 영역 최적화 Console > Rendering > Show paint rectangles Timeline > Paint - Paint profiler
  34. 34. 렌더링 영역 최적화 will-change (transform) 사용 // 지원 브라우저 - chrome, opera, firefox .target_element { will-change: transform; } // 미지원 브라우저 - safari, mobile safari .target_element { trasnform: translateZ(0); }
  35. 35. Input handler 최적화 스타일 변경시 requestAnimationFrame에서 시각적 속성을 확인하므로 강제 동기 레이아웃 발생 requestAnimationFrame의 콜백에서 스타일 변경
  36. 36. Summary https://commons.wikimedia.org/wiki/File:Plastic-compass.jpg
  37. 37. RAIL 사용자 중심 Response < 100ms Animation < 10ms IDLE - 가능한 길게. 작업을 한다면 50ms 이내 Load < 1000ms
  38. 38. 최적화 Critical Rendering Path 최적화 - 렌더링에 꼭 필요한 최적화된 데이터 사용 렌더링 최적화 - requestAnimationFrame/Web Workers - Selector 단순화 - 강제 동기 레이아웃 회피 - DevTools의 적극적 사용
  39. 39. 개발자 도구 실험 사용 39
  40. 40. Thank you

×