Reflow와 Repaint의 차이를 CSS 관점에서 정확히 설명해보자

웹 페이지가 사용자에게 부드럽고 빠르게 로드되고 반응하는 것은 사용자 경험에 있어 매우 중요합니다. 이러한 웹 성능을 최적화하기 위해 개발자들이 반드시 이해해야 할 핵심 개념 중 하나가 바로 'Reflow'와 'Repaint'입니다. 이 두 가지 개념은 브라우저가 웹 페이지를 화면에 그리는 과정, 즉 렌더링 파이프라인에서 발생하는 중요한 단계이며, 이들을 제대로 이해하고 관리하는 것이 웹 페이지의 속도와 반응성을 크게 향상시킬 수 있는 지름길입니다.

이 가이드에서는 Reflow와 Repaint가 무엇인지, 왜 중요한지, 그리고 어떻게 웹 성능에 영향을 미치는지 CSS 관점에서 자세히 설명하고, 실제 웹 개발에서 적용할 수 있는 유용한 최적화 팁들을 제공할 것입니다.

웹 성능 최적화의 핵심 Reflow와 Repaint 이해하기

브라우저는 HTML, CSS, JavaScript 코드를 해석하여 최종적으로 사용자가 볼 수 있는 웹 페이지를 화면에 표시합니다. 이 과정은 여러 단계로 이루어지는데, 그중 '레이아웃(Layout)'과 '페인트(Paint)' 단계가 Reflow와 Repaint와 밀접하게 관련되어 있습니다.

간단히 말해,

• Reflow (리플로우)는 웹 페이지의 요소들이 차지하는 공간, 위치, 크기 등 레이아웃과 관련된 모든 것을 다시 계산하는 과정입니다. 이는 매우 비용이 많이 드는(느린) 작업입니다.

• Repaint (리페인트)는 레이아웃은 변하지 않지만, 요소의 색상, 배경, 그림자 등 시각적인 스타일만 변경되어 화면의 픽셀을 다시 그리는 과정입니다. Reflow보다는 비용이 적게 들지만, 여전히 성능에 영향을 미칩니다.

이 두 과정은 웹 페이지의 요소가 변경될 때마다 발생할 수 있으며, 불필요하게 자주 발생하면 웹 페이지의 반응 속도가 느려지고 버벅거리는 현상(렉)을 유발하여 사용자 경험을 저하시킵니다. 따라서 웹 개발자들은 이들의 발생 빈도를 최소화하고 효율적으로 관리하는 방법을 숙지해야 합니다.

Reflow 레이아웃 재계산의 파워

Reflow란 무엇인가요

Reflow는 '레이아웃' 또는 '리레이아웃'이라고도 불립니다. 브라우저가 웹 페이지의 DOM(Document Object Model) 트리와 CSSOM(CSS Object Model) 트리를 결합하여 렌더 트리를 생성한 후, 각 요소의 정확한 크기와 위치를 계산하는 단계입니다. 만약 페이지의 구조나 요소의 크기, 위치에 영향을 주는 변경이 발생하면, 브라우저는 이 모든 계산을 다시 수행해야 합니다.

상상해보세요. 거실에 놓인 가구들의 위치나 크기를 변경하는 것과 같습니다. 소파를 옮기면 그 주변의 다른 가구들(테이블, 의자 등)도 영향을 받아 위치를 다시 조정해야 할 수 있습니다. 이 과정이 Reflow이며, 페이지 전체 또는 페이지의 특정 부분에 걸쳐 광범위하게 발생할 수 있습니다.

Reflow를 유발하는 주요 CSS 속성

Reflow는 주로 요소의 기하학적 속성이나 레이아웃에 영향을 미치는 CSS 속성이 변경될 때 발생합니다. 대표적인 예시는 다음과 같습니다.

• width, height, min-height, max-width 등 크기 관련 속성

• margin, padding, border 등 공간 관련 속성
• position (top, left, right, bottom) 및 display, float, clear
• font-size, font-family, line-height 등 텍스트 관련 속성 (텍스트 크기 변화가 요소의 크기에 영향을 미치므로)
• overflow, text-align, vertical-align, white-space
• 브라우저 창의 크기 변경 (리사이즈)
• DOM 요소 추가, 삭제, 내용 변경
• CSS 클래스 추가/제거
• JavaScript를 통한 스타일 변경

Reflow의 성능 비용

Reflow는 렌더링 파이프라인에서 가장 비용이 많이 드는 작업 중 하나입니다. 왜냐하면 한 요소의 Reflow는 종종 그 부모, 자식, 그리고 형제 요소들에게까지 영향을 미쳐 연쇄적인 Reflow를 유발할 수 있기 때문입니다. 특히 페이지의 상단이나 전체 레이아웃에 영향을 미치는 요소의 변경은 페이지 전체의 Reflow를 유발하여 심각한 성능 저하를 초래할 수 있습니다.

Repaint 화면 다시 그리기

Repaint란 무엇인가요

Repaint는 '리드로우'라고도 불립니다. Reflow와 달리 Repaint는 요소의 레이아웃이나 기하학적 속성에는 영향을 미치지 않지만, 요소의 시각적인 스타일(색상, 배경 등)이 변경될 때 발생합니다. 브라우저는 레이아웃을 다시 계산할 필요 없이, 해당 요소의 변경된 스타일을 화면의 픽셀에 다시 그리기만 하면 됩니다.

다시 거실 가구 비유를 들어볼까요? Repaint는 가구의 위치는 그대로 두고, 소파의 커버 색깔을 바꾸거나 벽에 걸린 그림의 액자 색을 바꾸는 것과 같습니다. 위치를 옮길 필요 없이, 보이는 모습만 바꾸는 것이죠. Reflow보다는 훨씬 가벼운 작업입니다.

Repaint를 유발하는 주요 CSS 속성

Repaint는 주로 요소의 색상이나 배경, 가시성 등 시각적 표현에만 영향을 미치는 CSS 속성이 변경될 때 발생합니다.

• color, background-color, background-image

• visibility (visibility: hidden은 Repaint를 유발하지만 Reflow는 유발하지 않습니다. display: none은 둘 다 유발하지 않습니다.)
• outline, text-decoration
• box-shadow, text-shadow
• border-radius (단, 테두리가 레이아웃에 영향을 주지 않는 경우)
• opacity (경우에 따라 Repaint만 유발하거나, GPU 가속을 통해 Compositing 단계에서 처리될 수 있습니다.)

Repaint의 성능 비용

Repaint는 Reflow보다 성능 비용이 훨씬 적습니다. 레이아웃을 다시 계산하는 복잡한 과정이 생략되기 때문입니다. 하지만 여전히 화면의 픽셀을 다시 그려야 하므로, 너무 빈번하게 발생하면 성능에 영향을 줄 수 있습니다. 특히 복잡한 애니메이션에서 Repaint가 많이 발생하면 부드럽지 못한 움직임을 보일 수 있습니다.

Reflow와 Repaint의 결정적인 차이점

두 개념의 차이점을 명확히 이해하는 것은 성능 최적화 전략을 세우는 데 매우 중요합니다.

구분Reflow (Layout)Repaint (Paint)발생 원인요소의 크기, 위치, 레이아웃 등 기하학적 속성 변경요소의 색상, 배경, 가시성 등 시각적 스타일 변경 (레이아웃에 영향 없음)영향 범위해당 요소 및 주변 요소, 부모/자식 요소까지 광범위하게 영향해당 요소에만 영향성능 비용매우 높음 (레이아웃 재계산 및 픽셀 재그리기 포함)상대적으로 낮음 (픽셀 재그리기만 수행)발생 예시width, height, margin, display, font-size 변경, DOM 추가/삭제color, background-color, visibility, box-shadow 변경

성능 최적화를 위한 실용적인 팁과 전략

웹 페이지의 Reflow와 Repaint를 최소화하는 것은 웹 성능을 향상시키는 핵심입니다. 다음은 실제 개발에서 적용할 수 있는 유용한 팁과 전략입니다.

Reflow 최소화 전략

• CSS 트랜스폼(transform) 사용:
  • transform: translate(), scale(), rotate() 등은 레이아웃에 영향을 주지 않고 요소를 움직이거나 크기를 조절할 수 있습니다. 이는 브라우저의 Compositing(합성) 단계에서 처리되며, GPU 가속을 활용하여 Reflow와 Repaint 없이 부드러운 애니메이션을 구현할 수 있습니다.
  • 예시: transform: translateX(100px); 대신 left: 100px;를 사용하면 Reflow가 발생합니다.

• position: absolute 또는 fixed 활용:
  • 문서 흐름에서 벗어난(out of flow) 요소는 주변 요소에 Reflow를 유발하지 않습니다. 애니메이션을 적용하거나 위치를 자주 변경해야 하는 요소는 이 속성들을 고려해볼 수 있습니다.
  • 단, 이 요소들 자체의 크기 변경은 여전히 Reflow를 유발할 수 있습니다.

• 레이아웃 변화를 일으키는 CSS 속성 사용 자제:
  • 특히 애니메이션 시, width, height, margin, padding 등 Reflow를 유발하는 속성 대신 transform이나 opacity를 사용하는 것이 좋습니다.

• DOM 변경 최소화 및 일괄 처리:
  • JavaScript로 DOM 요소를 여러 번 추가하거나 스타일을 변경할 때, 각 변경마다 Reflow가 발생할 수 있습니다.
  • 해결책:
    1. 요소를 먼저 display: none으로 숨긴 후 변경하고, 변경이 완료되면 다시 display: block으로 보이게 합니다. (이 과정에서 2번의 Reflow 발생)
    2. document.createDocumentFragment()를 사용하여 메모리에서 DOM을 조작한 후, 한 번에 문서에 추가합니다.
    3. 요소의 스타일을 직접 변경하기보다, CSS 클래스를 추가/제거하여 한 번에 여러 스타일을 변경합니다.

• CSS will-change 속성 활용:
  • 이 속성은 브라우저에게 "이 요소의 특정 속성이 곧 변경될 것이니 미리 준비해두라"는 힌트를 제공합니다. 브라우저는 이 힌트를 바탕으로 해당 요소에 대한 최적화를 미리 수행할 수 있습니다 (예: 별도의 레이어로 분리하여 GPU 가속 준비).
  • 남용은 금물입니다. will-change를 너무 많이 사용하면 오히려 메모리 사용량이 증가하고 성능이 저하될 수 있습니다. 실제로 변경될 요소에만 신중하게 사용해야 합니다.

• 테이블 레이아웃 피하기:
  • HTML 테이블은 셀 하나만 변경되어도 전체 테이블의 레이아웃을 다시 계산해야 하는 경우가 많아 Reflow에 취약합니다. 특별한 이유가 없다면 div와 CSS Flexbox, Grid를 사용하여 레이아웃을 구성하는 것이 좋습니다.

Repaint 최소화 전략

• opacity 대신 visibility 사용 고려:
  • 요소를 단순히 숨기거나 보여주는 경우, opacity: 0은 Repaint를 유발하지만, visibility: hidden은 Reflow를 유발하지 않으며 Repaint만 유발합니다. (display: none은 둘 다 유발하지 않음)
  • 애니메이션에서는 opacity가 visibility보다 부드럽게 전환될 수 있어 선호되기도 합니다.

• GPU 가속 활용:
  • transform, opacity (특정 조건에서) 등의 속성은 브라우저가 해당 요소를 별도의 레이어로 분리하여 GPU를 사용하여 렌더링하도록 유도할 수 있습니다. 이는 Reflow/Repaint 없이 Compositing 단계에서 처리되어 성능 이점을 가져옵니다.
  • transform: translateZ(0); 또는 backface-visibility: hidden;과 같은 '꼼수'를 사용하여 레이어를 강제로 생성하는 방법도 있었지만, will-change가 더 명시적이고 권장되는 방식입니다.

일반적인 최적화 조언

• 브라우저 개발자 도구 활용:
  • 크롬 개발자 도구의 'Performance' 탭을 사용하여 웹 페이지의 렌더링 과정을 기록하고 분석하세요. Reflow (Layout)와 Repaint (Paint)가 언제, 얼마나 자주 발생하는지 시각적으로 확인할 수 있습니다. 이를 통해 성능 병목 지점을 정확히 찾아낼 수 있습니다.

• CSS 애니메이션 최적화:
  • 애니메이션은 Reflow와 Repaint를 가장 빈번하게 유발하는 요소 중 하나입니다. width, height, left, top 등 레이아웃 속성을 애니메이션 하는 대신, transform (translate, scale, rotate)과 opacity를 사용하여 부드러운 애니메이션을 만드세요.

• JavaScript에서 스타일 변경 시 주의:
  • JavaScript에서 요소의 offsetWidth, offsetHeight, scrollWidth, scrollHeight, clientTop, clientLeft, getComputedStyle() 등을 호출하면 브라우저는 항상 최신 레이아웃 정보를 제공하기 위해 강제로 Reflow를 발생시킬 수 있습니다. 이러한 속성들을 연속적으로 호출하는 것을 피하고, 필요한 경우 값을 캐싱하여 사용하세요.

흔한 오해와 사실 관계

오해 모든 CSS 속성 변경은 Reflow를 일으킨다

사실: 그렇지 않습니다. CSS 속성 중에는 레이아웃에 영향을 주지 않고 시각적인 표현만 변경하는 속성들이 많습니다. 예를 들어, color, background-color 등은 Repaint만 유발합니다. Reflow는 요소의 크기나 위치가 변경될 때 발생합니다.

오해 Repaint는 항상 Reflow보다 빠르다

사실: 대부분의 경우 Repaint가 Reflow보다 빠릅니다. 하지만 Repaint 작업이 매우 복잡하거나 넓은 영역에 걸쳐 발생한다면, Repaint도 상당한 성능 비용을 초래할 수 있습니다. 예를 들어, 페이지 전체에 걸쳐 복잡한 box-shadow 애니메이션을 적용하면 Repaint만으로도 성능 저하가 발생할 수 있습니다.

오해 GPU 가속은 만능이다

사실: GPU 가속은 렌더링 성능을 크게 향상시킬 수 있지만, 항상 최적의 해결책은 아닙니다. GPU 가속을 위해 요소를 별도의 레이어로 분리하면, 이 레이어를 생성하고 관리하는 데 메모리와 CPU 자원이 소모됩니다. 너무 많은 레이어를 생성하면 오히려 성능이 저하되거나 모바일 기기에서 배터리 소모가 증가할 수 있습니다. will-change 속성을 사용할 때도 신중해야 하는 이유입니다.

자주 묻는 질문

질문 CSS display: none과 visibility: hidden의 차이는 무엇인가요

답변:

• display: none: 해당 요소를 렌더 트리에서 완전히 제거합니다. 따라서 Reflow와 Repaint 모두 발생하지 않습니다. 요소가 차지하는 공간도 사라집니다.
• visibility: hidden: 해당 요소는 렌더 트리에 존재하며 공간을 차지하지만, 화면에 보이지 않게만 합니다. Reflow는 발생하지 않지만, Repaint는 발생합니다.

성능 관점에서는 display: none이 더 효율적이지만, 요소가 공간을 유지해야 하는 경우에는 visibility: hidden을 사용해야 합니다.

질문 will-change 속성은 언제 사용해야 하나요

답변: will-change 속성은 요소에 애니메이션이나 트랜지션이 적용되기 직전에, 브라우저에게 해당 속성이 변경될 것임을 미리 알려줄 때 사용합니다. 예를 들어, 마우스 호버 시 특정 요소의 transform 속성이 변경되는 애니메이션이 있다면, 해당 요소에 미리 will-change: transform;을 적용할 수 있습니다. 그러나 남용하면 브라우저 리소스를 불필요하게 소모할 수 있으므로, 실제로 성능 개선이 필요한 극히 일부 요소에만 신중하게 사용하는 것이 좋습니다.

질문 Reflow가 정말 그렇게 중요한가요

답변: 네, 매우 중요합니다. Reflow는 웹 페이지의 반응성과 부드러움에 직접적인 영향을 미칩니다. 특히 모바일 환경이나 저사양 기기에서는 Reflow 한 번이 사용자에게 체감되는 큰 지연을 유발할 수 있습니다. 빠른 로딩 속도와 부드러운 사용자 경험은 검색 엔진 최적화(SEO)에도 긍정적인 영향을 미치므로, Reflow 최적화는 모든 웹 개발의 필수적인 부분입니다.

전문가의 조언 비용 효율적인 웹 개발을 위한 제언

성능 최적화는 단순히 기술적인 문제뿐만 아니라, 사용자 경험과 비즈니스 성과에도 직결되는 중요한 과제입니다. Reflow와 Repaint를 이해하고 관리하는 것은 이러한 목표를 달성하기 위한 기본 중의 기본입니다.

• 측정은 필수입니다: 막연한 추측보다는 브라우저 개발자 도구를 활용하여 실제 페이지에서 Reflow와 Repaint가 어떻게 발생하는지 정확히 측정하는 것이 중요합니다. 어디서 병목 현상이 발생하는지 알아야 올바른 최적화 방향을 설정할 수 있습니다.
• 모바일 환경을 우선 고려하세요: 데스크톱에서는 Reflow가 눈에 띄지 않을 수 있지만, 리소스가 제한적인 모바일 기기에서는 작은 Reflow도 큰 성능 저하를 일으킬 수 있습니다. 항상 모바일 사용자 경험을 염두에 두고 개발하세요.
• 점진적인 개선 접근 방식: 모든 Reflow와 Repaint를 제거하는 것은 불가능하며, 때로는 과도한 최적화가 개발 복잡성을 증가시키기도 합니다. 가장 큰 성능 병목 지점부터 해결해나가며 점진적으로 개선하는 것이 현실적인 접근 방식입니다.
• CSS 속성별 영향도 숙지: 어떤 CSS 속성이 Reflow를 유발하고 어떤 속성이 Repaint만 유발하는지 정확히 이해하고 있다면, 코드를 작성할 때부터 성능을 고려한 선택을 할 수 있습니다. 이는 장기적으로 유지보수하기 쉽고 고성능인 웹 페이지를 만드는 데 큰 도움이 됩니다.