2nd/10_Wiki/Topics/Frontend_Mastery/웹 성능 최적화(Web Performance Optimization).md

웹 성능 최적화(Web Performance Optimization)

📌 Brief Summary

웹 성능 최적화는 웹 페이지가 빠르게 로드되고, 원활하게 렌더링되며, 사용자의 상호작용에 즉각적으로 반응하도록 보장하기 위한 기술과 전략을 의미한다 [1-3]. 이는 중요 렌더링 경로(Critical Rendering Path)를 관리하여 리플로우(Reflow)와 리페인트(Repaint)를 최소화하고, 브라우저가 화면을 그리는 속도와 효율성을 극대화하는 과정을 포함한다 [4-7]. 현대의 프론트엔드 환경에서는 적절한 렌더링 전략(CSR, SSR, SSG 등)의 선택, 자바스크립트 번들 크기 축소, 그리고 컴포넌트 아키텍처를 통한 렌더링 횟수 통제가 핵심적인 최적화 목표로 다루어진다 [8-11].

📖 Core Content

• 중요 렌더링 경로(Critical Rendering Path, CRP) 최적화: 브라우저는 네트워크를 통해 전달받은 HTML과 CSS를 파싱하여 DOM과 CSSOM 트리를 생성하고, 이를 결합해 렌더 트리(Render Tree)를 구축한 뒤, 요소의 위치와 크기를 계산(Layout)하고 화면의 픽셀로 변환(Paint)하는 단계를 거친다 [5, 12-14]. 초기 렌더링 시간을 줄이려면 렌더링을 차단하는 CSS나 파싱을 차단하는 자바스크립트(Render-Blocking & Parser-blocking resources)의 수를 최소화하고 다운로드 순서를 최적화해야 한다 [15-18]. 또한 DOM 트리의 노드가 많아질수록 레이아웃과 페인트 단계의 연산 비용이 증가하므로 불필요한 DOM 노드 깊이를 줄여야 한다 [19-21].

• 리플로우(Reflow) 및 리페인트(Repaint) 최소화: DOM 구조의 변경, 창 크기 조절, 요소의 크기 및 위치 변경 등은 브라우저가 기하학적 구조를 다시 계산하게 만드는 비용이 큰 리플로우(또는 레이아웃)를 유발한다 [22-25]. 시각적 스타일(색상, 그림자 등)만 변경되는 리페인트의 경우 리플로우보다는 연산량이 적지만 과도하게 발생하면 애니메이션 프레임 속도를 저하시킨다 [7, 26, 27]. 성능을 유지하기 위해서는 DOM 업데이트를 일괄 처리하고, 요소 이동 시 위치 관련 속성 대신 GPU 가속을 활용할 수 있는 transform 속성을 사용하는 것이 좋다 [7, 26, 28-30].

• React 애플리케이션의 렌더링 최적화 기법: React의 렌더링 특성상 부모의 상태가 변경되면 속성 변경 여부와 관계없이 하위 컴포넌트가 연쇄적으로 리렌더링되며 연산 비용을 낭비할 수 있다 [31, 32]. 이를 방지하기 위해 React.memo나 useMemo 등을 통한 메모이제이션, 대규모 목록에서 화면에 보이는 노드만 그리는 가상화(Virtualization), 그리고 상태 업데이트를 하나로 묶는 자동 일괄 처리(Automatic Batching)가 사용된다 [33-36]. 아울러 React 19의 동시성 렌더링 훅(useTransition, [[useDeferredValue|useDeferredValue]])을 활용하면 무거운 연산 중에도 긴급한 상호작용의 응답성을 방해하지 않고 유지할 수 있다 [37-39].

• 렌더링 전략 선택 및 하이드레이션(Hydration) 병목 관리: 애플리케이션의 성격과 요구에 따라 클라이언트 사이드 렌더링(CSR), 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 점진적 정적 재생성(ISR) 등의 방식을 전략적으로 선택해야 한다 [9, 40-42]. SSR과 SSG는 서버에서 미리 완성된 HTML을 전달하여 빠른 초기 콘텐츠 표시(FCP)와 우수한 SEO를 보장하지만, SSR의 경우 브라우저가 자바스크립트를 다운로드하고 HTML에 이벤트 핸들러를 연결하는 '하이드레이션(Hydration)' 과정이 끝날 때까지 상호작용(TTI)이 지연되거나 메인 스레드를 차단(TBT)하는 단점이 있다 [43-47].

• React Server Components (RSC)의 도입과 자동화 도구: 기존 렌더링 방식의 번들 크기 및 하이드레이션 문제를 근본적으로 해결하기 위해 컴포넌트를 서버에서만 실행하고 클라이언트에는 자바스크립트를 전송하지 않는 RSC 모델이 도입되었다 [48-51]. 이를 통해 클라이언트로 전송되는 JS 페이로드 크기를 대폭 줄이고 서버의 리소스를 직접 활용할 수 있다 [52-54]. 더 나아가 최신 React Compiler는 빌드 타임에 코드의 추상 구문 트리(AST)를 분석해 자동으로 세분화된 메모이제이션을 삽입해주어, 개발자가 수동으로 성능을 최적화해야 하는 부담을 대폭 감소시킨다 [55-58].

🔗 Knowledge Connections

• Related Topics: [[Critical Rendering Path|Critical Rendering Path]], Reflow and Repaint, React Server Components, 하이드레이션(Hydration), 동시성 렌더링([[Concurrent Rendering|Concurrent Rendering]]), [[React Compiler|React Compiler]]
• Projects/Contexts: 콘텐츠 기반의 SEO 최적화 웹사이트 및 이커머스(E-commerce) 플랫폼 (초기 화면의 빠른 렌더링과 검색엔진 최적화를 위해 SSR, SSG, ISR이 필수적으로 요구되는 맥락) [43, 59-62], 고도의 상호작용이 필요한 관리자 대시보드 및 [[SaaS|SaaS]] (초기 렌더링보다 실시간 상태 업데이트와 인터랙션 속도가 중시되어 CSR 또는 선택적 클라이언트 컴포넌트가 적합한 맥락) [63-67].
• Contradictions/Notes:
  • 수동 메모이제이션의 유용성에 대한 관점 변화: 기존 React 생태계에서는 불필요한 리렌더링을 막기 위해 useMemo나 useCallback과 같은 수동 메모이제이션이 권장되었으나, 얕은 비교 검사 자체의 오버헤드가 발생하거나 종속성 관리가 복잡해져 과도한 사용이 안티 패턴으로 지적되기도 했다 [68, 69]. 그러나 React 19의 React Compiler 등장 이후, 컴파일러가 정적 분석을 통해 최적의 위치에 자동으로 메모이제이션을 적용하게 되면서 개발자의 수동 개입 필요성이 크게 사라지는 패러다임 전환이 이루어지고 있다 [55, 58, 70-72].
  • SSR의 성능 지표 딜레마: 서버 사이드 렌더링(SSR)은 클라이언트에게 완성된 HTML을 즉시 제공하여 초기 콘텐츠 표시(FCP)와 SEO를 개선하지만, 자바스크립트를 다운로드하여 정적 요소에 상호작용을 활성화하는 하이드레이션 과정이 완료될 때까지 상호작용 시작 시간(TTI)이 크게 지연되거나 메인 스레드 차단 시간(TBT)이 증가하는 역설적인 한계가 존재한다 [43, 45, 73-75].

---

Last updated: 2026-04-25