transform 으로 리플로우 잡기 - 웹 성능 최적화

houndhollis·2024년 11월 5일

프론트엔드 면접 단골 질문, 여러분은 대답 하실 수 있을까요?

브라우저가 어떻게 렌더링 되는지 아시나요? ㅎㅎ

거의 웬만한 프론트엔드 개발자들은 대답을 잘 할 것입니다.

오늘은 Transform 으로 레이아웃 단계를 잡아 볼려고 합니다.

reflow , repaint

리플로우는 웹 페이지에서 요소의 레이아웃이나 위치, 크기와 같은 속성이 변경될 때, 브라우저가 레이아웃을 다시 계산하고, 렌더 트리를 새로 구성하는 과정입니다. 리플로우는 DOM 구조의 스타일이 변경되면 발생하며, reflow가 발생하면 그 하위 요소들에도 영향을 미칠 수 있습니다.

CPU 연산을 많이 요구합니다 복잡한 레이아웃 일 수록 비용이 많이 듭니다.

리페인트는 요소의 색상이나 배경 등 시각적인 스타일이 변경될 때 발생하는 과정입니다. 화면에 요소를 다시 그리는 과정이 필요하며, 리페인트는 리플로우보다 상대적으로 비용이 적게 든다는 점이 있습니다.

GPU 연산입니다.

결론

리플로우는 레이아웃과 관련된 속성이 변경될 때 발생하며, 부모 요소의 변화가 자식 요소까지 영향을 미치기 때문에 비용이 많이 듭니다.
리페인트는 시각적 스타일의 변경만을 처리하며, 레이아웃이나 위치 변화 없이 화면에 요소를 다시 그리는 작업만 수행하기 때문에 리플로우 보다 성능에 미치는 영향이 적습니다.

프레임 드롭

리플로우가 자주 발생하면 성능 저하로 인해 프레임 드롭이 발생합니다. 여기서 프레임 드롭이란, 보통 모든 브라우저들은 60프레임을 맞춰서 보여줄려고 합니다.

-> 60프레임이란 1초에 60개의 프레임을 본다고 생각하면 편합니다.

하지만 짧은 시간동안 많은 리플로우가 일어나 많은 단계를 거치려다 보니깐 브라우져가 일부 화면을 생략해서 Jank(화면이 매끄럽지 않게 끊기는 현상 , 프레임 드롭)현상이 발생하는 것입니다.

그러면 어떻게 리플로우를 방지?

간단한 예시를 하나 가져왔습니다.

남은 스크롤이 얼마나 남은지 보여주는 Scrol bar가 있습니다.

개발자 도구의 요소탭을 확인해보면

보통은 width를 잡고 채워주는 식으로 개발을 진행할 듯 합니다.
물론 저도 그랬습니다 🤣

하지만 우리는 바로 위에서 학습했습니다.
width 처럼 DOM의 변화를 주면 리플로우가 일어난다는 것입니다. 확인해보겠습니다

Performance

퍼포먼스 탭을 이용하여 Recode 한 모습입니다. 아래 부분에 스크롤이 움직일때,
Layout 단계가 보이시나요? 리플로우가 발생하는 모습입니다.

전체 영역의 Call tree 를 봐도 Layout 단계를 확인할 수 있습니다.

개선 코드

저는 width 대신, Transform 으로 css를 변경할려고 합니다.

<div className="sticky top-0 bg-black z-10">
        <h1 className="text-white font-bold text-2xl">Transform 최적화</h1>
        <div
          style={{ transform: `scaleX(${percent / 100})` }}
          className="absolute top-[40px] left-0 w-full rounded origin-left transition-transform h-[3px] bg-white will-change-transform"
        />
      </div>
... 생략