웹 성능 핵심개념 - 크리티컬 렌더링 패스

 

 

🖐 버벅임(Jank) 멈춰!

대부분의 기기들은 1초에 60번 화면을 업데이트한다. 이 주기를 60Hz 라고 표현하고, 초당 프레임 60 즉, 60 fps(frames per second)라고도 표현한다. 브라우저가 프레임을 60번보다 적게 가져오면 사용자는 화면이 '버벅이고 있음'을 알아채고 시각적 불편함을 느끼게 된다.

그렇다면 1초에 60개의 프레임을 준비하려면, 얼마만큼의 시간동안 한 프레임을 준비해야 하는걸까? 1000ms 를 60개로 나누면 약 16ms이다. 그렇지만 브라우저가 이런저런 잡일도 처리해야해서 실제로는 10 ~ 12ms 만에 준비해야 한다.

 

🖼 프레임은 이렇게 만들어요

나의 앱의 프레임속도를 최적화 하기 위해서는, 브라우저가 프레임을 어떻게 렌더하는지부터 이해해야 한다. 브라우저의 크리티컬 렌더링 패스(Critical Rendering Path) 라고도 부르는 이 과정은 다음과 같다.

1. 브라우저가 서버에게 GET 요청을 보낸다.
2. 서버는 HTML을 응답으로 보내준다.
3. 브라우저는 받은 HTML을 파싱해서 DOM을 구성한다.
4. CSS파일과 브라우저 에이전트를 합쳐 CSSOM을 구성한다.
5. DOM과 CSSOM을 합쳐 Render Tree를 만든다. (Recalcuates styles)
6. 레이아웃 계산한다.
7. 실제 시각적 요소를 픽셀단위로 표현한다. (페인트)
8. 레이어를 합성한다. (컴포지트)

 

참고로 렌더트리에는 시각적으로 보이는 것만 포함된다.

렌터트리에 포함되는 것	렌더트리에 포함되지 않는 것
- ::after와 같은 pesudo elemnt     - height: 0 인 태그     - position: ablsolute, left: 100% 인 태그	- head 태그     - script 태그     - display: none 인 태그

 

레이아웃 - 페인트 - 컴포지트 단계

페인트 단계의 벡터 레스터화

 

그렇다면 샘플 사이트 의 경우에, 브라우저의 레이아웃 단계에서 body 자체의 width를 수정하는 것과 body의 자손인 특정 div의 width를 수정하는 것 중 어떤 것이 더 많은 작업을 필요로 할까?

정답은 '둘 다 같은 양의 작업을 요구한다.' 이다. 어느 노드가 변경되는지 알더라도 전체 레이아웃이 어떻게 변경될지는 알 수 없다. 따라서 브라우저는 전체 페이지의 레이아웃을 다시 잡아야 한다. 즉, 브라우저는 레이아웃에 변화가 있으면 최악의 시나리오를 가정하고 기존의 레이아웃을 전부 뭉개고 전체 레이아웃을 다시 잡는다.

이 과정은 크롬 개발자도구 - [Performance] 탭에서 확인할 수 있다.

 

이런 상황을 레이아웃의 '스코프'가 전체 문서(whole document)라고 표현한다. 레이아웃 스코프를 좁게 하기 위해서 전략적으로 CSS를 작성해서 레이아웃 바운더리를 만드는 방법이 있다. 레이아웃 바운더리가 생기면 전체 문서가 reflow되지 않고 해당 scope만 reflow되기 때문에 레이아웃 비용을 크게 줄일 수 있다. (참고: Introducing 'layout boundaries')

 

⏭ 렌더링 파이프라인

브라우저가 페이지를 렌더하는 과정을 다섯 단계로 나눌 수 있다. 각 단계 중 일부는 항상 실행되며, 일부는 경우에 따라 생략되기도 한다. 

이미지 출처: https://developers.google.com/web/fundamentals/performance/rendering

1. layout 속성을 변경한 경우 

Style > Layout > Paint > Composite 

position, padding, overflow, width, top 등이 해당된다.

2. paint-only 속성만 변경한 경우

Style > Paint > Composite

shadow, color, background-image, opacity, z-index 등이 해당된다.

3. compositing-only 속성만 변경한 경우

Style > Composite

transform, orphans, cursor 등이 해당된다.

4. 사용자가 윈도우 크기를 조정한 경우 (원래 있던 flexbox의 item)

Layout > Paint > Composite

단, 미디어쿼리 등 resize가 필요한 경우는 Style 과정이 추가된다.

각 경우에 어떤 파이프라인을 거치는지 예측 또는 측정하고, 개발의도에 따라 같은 효과를 내면서도 더 적은 과정을 거치게 의도할 수도 있다. 

 

 

참고강의

Udacity: Browser Rendering Optimization by Google