2nd/10_Wiki/Topics/CSS Performance Optimization.md

# [[CSS Performance Optimization|CSS Performance Optimization]]

## 📌 Brief Summary
CSS 성능 최적화는 브라우저의 렌더링 경로에서 병목 현상을 유발하는 렌더링 차단 요소를 줄이고, 연산 비용이 높은 리플로우(Reflow)와 리페인트(Repaint)를 최소화하여 웹페이지의 반응성과 로딩 속도를 향상시키는 과정입니다 [1-4]. "예쁘게" 만드는 것을 넘어 "유지보수 가능하게" CSS를 설계하려면 불필요한 스타일 제거, 애니메이션의 GPU 가속 활용은 물론, [[CSS Modules|CSS Modules]]나 [[Tailwind CSS|Tailwind CSS]]처럼 런타임 오버헤드가 적은 도구를 선택하여 번들 크기와 아키텍처 성능을 동시에 관리하는 실무적 접근이 필수적입니다 [5-8].

## 📖 Core Content

*   **렌더링 차단 방지 및 파일 최적화**
    *   브라우저가 CSS를 다운로드하고 [[CSSOM(CSS Object Model)|CSSOM(CSS Object Model]]을 구축하기 전까지 페이지 렌더링이 차단됩니다 [2]. 이를 방지하기 위해 미디어 쿼리(media queries)를 활용하여 인쇄용이나 특정 화면 크기에만 필요한 스타일을 별도의 파일로 분리해야 합니다 [9, 10].
    *   사용하지 않는 CSS(Dead code)를 제거하고, 사람이 읽기 위해 추가된 공백을 지우는 압축(Minify) 작업을 거쳐 파일 크기를 줄여야 합니다 [2, 11].
    *   `rel="preload"`를 사용하면 폰트, CSS 파일, 이미지 등 핵심 자산을 조기에 다운로드하여 사용자가 화면을 빠르게 볼 수 있도록 렌더링을 최적화할 수 있습니다 [12-14].

*   **리플로우(Reflow)와 리페인트(Repaint) 최소화**
    *   가시성이나 배경색 변경과 같은 시각적 변화는 **리페인트**를 발생시키며, 너비, 높이, 마진 등 요소의 기하학적 형태나 레이아웃이 변경되면 전체 또는 일부 페이지 레이아웃을 다시 계산해야 하는 **리플로우**가 발생해 심각한 성능 저하를 초래합니다 [4, 15].
    *   리플로우 영향을 줄이려면 자바스크립트로 여러 인라인 스타일을 반복적으로 조작하지 말고, 미리 정의된 외부 클래스 하나를 조작하여 한 번의 리플로우만 발생하게 해야 합니다 [16, 17]. DOM 트리의 가장 하단(자식) 노드에서 클래스를 변경하는 것이 리플로우 범위를 최소화하는 데 효과적입니다 [18].

*   **애니메이션 성능 최적화 전략**
    *   애니메이션에 `width`, `height`, `margin` 등의 레이아웃 속성을 사용하면 지속적인 리플로우와 리페인트를 유발하여 화면이 끊기는(Janky) 현상이 발생합니다 [19]. 대신 레이아웃에 영향을 주지 않는 `transform`과 `opacity` 속성을 사용하여 브라우저의 GPU 가속(Compositing)을 활용해야 합니다 [6, 20, 21].
    *   `box-shadow`, `filter`, `border-radius`와 같이 브라우저 연산 비용이 높은 속성을 사용한 애니메이션과, 무거운 배경 이미지 및 불필요한 무한 반복 루프 애니메이션을 피해야 합니다 [21-24].
    *   자주 변경되는 요소에는 `will-change` 속성을 부여하여 브라우저가 사전에 렌더링 최적화를 준비하게 할 수 있지만, 너무 많은 요소에 남용하면 역효과가 나므로 주의가 필요합니다 [25, 26].

*   **실무적 관점: 최신 CSS 아키텍처와 성능 비교**
    *   CSS 관리 방식을 선택할 때 런타임 성능과 번들 크기를 반드시 고려해야 합니다 [7]. 런타임 [[CSS-in-JS|CSS-in-JS]](예: [[styled-components|styled-components]], Emotion) 라이브러리는 자바스크립트 실행 중 CSS를 파싱하고 주입해야 하므로 런타임 오버헤드가 발생하고 파일 크기가 커져 성능이 떨어질 수 있습니다 [27-30].
    *   반면 **Tailwind CSS**는 유틸리티 클래스를 사용하여 실제로 쓰인 스타일만 빌드에 포함시키므로 번들 크기를 극적으로 줄일 수 있으며(5~20kb), 런타임 비용이 발생하지 않습니다 [8, 31].
    *   **CSS Modules** 역시 빌드 시에 고유 클래스명을 정적으로 생성하므로 캡슐화(스코핑)를 보장하면서도 런타임 오버헤드가 없어 성능 친화적인 아키텍처를 구현할 수 있습니다 [5, 8, 32].

## 🔗 Knowledge Connections
- **Related Topics:** [[CSS 구조 설계 방식|CSS 구조 설계 방식]], BEM, CSS Modules, [[Tailwind vs 일반 CSS 비교|Tailwind vs 일반 CSS 비교]], 애니메이션 (transition / keyframes)
- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법|실무에서 CSS 관리하는 방법]], [[대규모 프론트엔드 프로젝트 아키텍처|대규모 프론트엔드 프로젝트 아키텍처]]
- **Contradictions/Notes:** 
  - CSS-in-JS는 동적인 스타일링과 개발자 편의성을 제공하지만 성능(번들 크기 및 런타임 비용)에서는 CSS Modules나 Tailwind CSS에 비해 단점이 큽니다 [8, 27-29].
  - 모바일이나 저사양 기기에서 애니메이션을 구현할 때는 시각적인 '부드러움(Smoothness)'을 고집하기보다는 CPU 자원을 아끼기 위해 의도적으로 픽셀 이동 단위를 조정하여 '속도(Speed)'를 챙기는 형태의 타협도 성능 최적화 방법으로 제안됩니다 [33].

---
*Last updated: 2026-04-26*