docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links

10_Wiki/Topics/Frontend_Mastery/CSS Performance Optimization.md

@@ -1,12 +1,12 @@
-# [[CSS Performance Optimization]]
+# [[CSS Performance Optimization|CSS Performance Optimization]]
 
-## 📌[[ brief]] Summary
-CSS 성능 최적화는 브라우저의 렌더링 경로에서 병목 현상을 유발하는 렌더링 차단 요소를 줄이고, 연산 비용이 높은 리플로우(Reflow)와 리페인트(Repaint)를 최소화하여 웹페이지의 반응성과 로딩 속도를 향상시키는 과정입니다 [1-4]. "예쁘게" 만드는 것을 넘어 "유지보수 가능하게" CSS를 설계하려면 불필요한 스타일 제거, 애니메이션의 GPU 가속 활용은 물론, [[CSS Modules]]나 [[Tailwind CSS]]처럼 런타임 오버헤드가 적은 도구를 선택하여 번들 크기와 아키텍처 성능을 동시에 관리하는 실무적 접근이 필수적입니다 [5-8].
+## 📌 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)]]을 구축하기 전까지 페이지 렌더링이 차단됩니다 [2]. 이를 방지하기 위해 미디어 쿼리(media queries)를 활용하여 인쇄용이나 특정 화면 크기에만 필요한 스타일을 별도의 파일로 분리해야 합니다 [9, 10].
+    *   브라우저가 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].
 
@@ -20,13 +20,13 @@ CSS 성능 최적화는 브라우저의 렌더링 경로에서 병목 현상을
     *   자주 변경되는 요소에는 `will-change` 속성을 부여하여 브라우저가 사전에 렌더링 최적화를 준비하게 할 수 있지만, 너무 많은 요소에 남용하면 역효과가 나므로 주의가 필요합니다 [25, 26].
 
 *   **실무적 관점: 최신 CSS 아키텍처와 성능 비교**
-    *   CSS 관리 방식을 선택할 때 런타임 성능과 번들 크기를 반드시 고려해야 합니다 [7]. 런타임 [[CSS-in-JS]](예: [[styled-components]], Emotion) 라이브러리는 자바스크립트 실행 중 CSS를 파싱하고 주입해야 하므로 런타임 오버헤드가 발생하고 파일 크기가 커져 성능이 떨어질 수 있습니다 [27-30].
+    *   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 구조 설계 방식]], [[BEM]], [[CSS Modules]], [[Tailwind vs 일반 CSS 비교]], 애니메이션 (transition / keyframes)
-- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법]], [[대규모 프론트엔드 프로젝트 아키텍처]]
+- **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].