[ Frontend ] 브라우저 렌더링 순서

2025. 8. 9. 18:30Frontend

🤔공부하게 된 계기

재직중인 회사의 고객사 요청으로 운영중인 페스티벌 페이지를

새로운 버전으로 만들어 달라는 요청이 있었다.

 

소개페이지에서 동적 animation을 추가해야 하는 과업이 있었는데 이전 버전의

소개페이지에 접속하면 노트북의 펜이 미친 듯이 돌기 시작했고,

내가 직접 개발한 소개페이지는 더 많은 animation이 추가 되었음에도

불구하고 과부화 되어 펜이 돌거나 하진 않았다.

 

이러한 현상의 원인을 [ postioin, margin ] vs [ transform ] 라고 유추했다.

내가 생각한 것은 "Layout 단계에서 지속적으로 재계산 되기 때문?" 이었다.

 

🖼️브라우저 렌더링 순서

  1. Parsing: HTML → DOM Tree, CSS → CSSOM Tree
  2. Style: DOM Tree + CSSOM Tree → Render Tree 생성
  3. Layout(Reflow): Render Tree의 각 노드 위치·크기 계산
  4. Paint: 각 노드를 픽셀 정보로 변환 (Display List 생성)
  5. Composite: 레이어를 GPU로 합성하여 최종 화면 출력

 

🪄transform이 성능이 더 좋았던 이유

margin, padding, width, height, postion 등의 변경으로 animation을 구현하면

[ Parsing ~~ Composite ] 과정을 지속 반복하게 되는데 특히나 Layout단계에서

발생하는 위치의 재계산CPU의 부하를 높이기 때문에 부담스러운 작업이 된다.

 

반면 transform 속성을 활용하여 animation을 구현하게 되면

Composite단계에서 처리하게 되고, 가장 부담스러운 작업인 Layout(Reflow)

단계를 거치지 않기 때문에 압도적인 성능차이가 나게 되는 것이다.

 

결론

animation을 구현한다면 불가피한 상황이 아니라면 transform 속성을 활용하자!

 

✍🏻마치며...

"활용하는 기술에 대한 이해도를 가지자!" 라고 생각하며 개발에 임하고 있지만 막상 시간에 쫓겨 그러지 못하는 경우가 많은 것 같다. 그간 습득했던 기술지식을 기반으로 유추하고 해결하는 방식이 나쁜 것은 아니지만, 알 수 없는 무언가의 영역이 되어 지나치는 것 보다는 학습을 통해 이해도를 높이고 유추가 아닌 확신이 되어가는 것이 베스트인 것 같다.