Lighthouse에서 "Avoid Chaining Critical Requests" 해결하기
요약: "Avoid Chaining Critical Requests"
크리티컬 요청(Critical requests)은 브라우저가 높은 우선순위로 가져오는 네트워크 요청입니다.
페이지나 스크립트로 인해 여러 리소스가 차례대로 높은 우선순위로 다운로드되는 경우, 이를 크리티컬 요청 체인이라고 부릅니다.
브라우저는 이러한 크리티컬 리소스가 모두 다운로드될 때까지 페이지의 렌더링 및 페인팅을 (완전히) 시작하지 않습니다. 따라서 어떤 크리티컬 리소스든 페이지의 첫 렌더링을 차단할 수 있습니다. 크리티컬 요청 체인이 커질수록 First Contentful Paint 및 Largest Contentful Paint가 더 많이 지연됩니다.
최종 검토: Arjen Karel, 2026년 3월
다운로드 우선순위 결정 방식
크리티컬 요청은 초기 페이지 로드 중에 높은 우선순위로 다운로드되는 리소스입니다. 이 우선순위는 어떻게 결정될까요?
다운로드 우선순위는 브라우저 자체에 의해 결정됩니다. 브라우저는 일련의 규칙을 따라 각 애셋의 우선순위를 결정합니다. 어떤 요소가 궁극적으로 가장 높은 우선순위를 받는지는 페이지 구조에 따라 달라집니다. 브라우저가 페이지의 첫 렌더링에 필요하다고 판단하는 요소에 가장 높은 우선순위가 부여됩니다.
처음에 브라우저는 어떤 요소가 가장 중요한지 합리적으로 추측합니다. 일반적으로 다운로드 우선순위는 다음과 같이 작동합니다: HTML이 항상 가장 높은 우선순위를 가지며, 그 다음으로 스타일시트, 동기식 JavaScript, 글꼴, AJAX 요청, 페이지 상단의 이미지, 페이지 하단의 이미지, 그리고 비동기식 JavaScript 순입니다.
fetchpriority 속성을 사용하여 이러한 우선순위를 재정의할 수 있습니다. fetchpriority="high"를 설정하면 리소스가 일반적으로 예상하는 것보다 더 중요하다고 브라우저에 알립니다. fetchpriority="low"를 설정하면 반대 효과가 발생합니다. 이 속성은 현재 93%의 브라우저 지원율을 보입니다. 전체 가이드는 Resource Prioritization and the Core Web Vitals를 참조하세요.
페이지에서 어떤 리소스에 높은 우선순위가 부여되었는지 확인할 수 있습니다. Ctrl+Shift+J를 눌러 DevTools를 엽니다. Network 탭으로 이동하여 열 이름을 마우스 오른쪽 버튼으로 클릭하고 'Priority'를 선택하세요.
크리티컬 요청 체인이 페이지 로드 시간에 미치는 영향
페이지를 로드할 때 브라우저는 "디스플레이 차단(display blocking)" 모드로 시작합니다. 이 모드에서는 가장 중요한 리소스가 높은 우선순위로 다운로드됩니다. 이것들이 크리티컬 리소스입니다.
브라우저는 모든 크리티컬 리소스가 다운로드될 때까지 페이지 렌더링을 (완전히) 시작하지 않습니다. 따라서 어떤 크리티컬 리소스든 페이지의 첫 렌더링을 차단할 수 있습니다.
페이지에 크리티컬 리소스가 적을수록 브라우저가 첫 번째 콘텐츠를 화면에 표시하기 위해 수행해야 할 작업이 줄어들며, CPU 및 기타 리소스에 대한 경쟁도 줄어듭니다.
2025 Web Almanac에 따르면, 모바일 페이지의 15%만이 렌더링 차단 리소스 감사를 통과합니다. 이는 웹의 85%가 여전히 해결해야 할 크리티컬 체인 문제를 가지고 있음을 의미합니다. 이것이 모바일 오리진의 55%만이 First Contentful Paint에서 "good" 점수를 받는 주된 이유 중 하나입니다. CoreDash가 모니터링하는 사이트 전반에 걸쳐, 크리티컬 체인 요청이 3개 미만인 오리진의 중간 FCP는 1.2초인 반면, 8개 이상인 오리진은 2.4초입니다.
참고: 2025년 10월 출시된 Lighthouse 13부터 이 감사는 "Network Dependency Tree" 인사이트로 이름이 변경되었습니다. 개념은 동일합니다: Lighthouse는 우선순위가 높은 네트워크 요청의 체인을 분석하고 너무 깊을 때 경고를 표시합니다.
Lighthouse에서 "Avoid Chaining Critical Requests" 해결하기
세 가지 방법으로 크리티컬 요청의 영향을 줄일 수 있습니다:
- 크리티컬 리소스의 수를 줄입니다. 제거하거나 지연시켜 크리티컬 리소스를 비 크리티컬 리소스로 변환하세요.
- 크리티컬 바이트 수를 줄입니다. 크리티컬 경로 리소스의 크기를 줄이면 다운로드 속도가 빨라집니다. Gzip 또는 Brotli 압축, JavaScript 트리 쉐이킹(tree shaking), 이미지 최적화 및 글꼴 서브세팅(font subsetting)이 모두 도움이 됩니다.
- 크리티컬 경로의 다운로드 순서를 개선합니다. 사전 로드(preloading)와 같은 리소스 힌트를 사용하여 리소스 탐색을 건너뛰고 크리티컬 리소스가 가능한 한 빨리 다운로드되도록 보장하세요. HTTP 103 Early Hints를 사용하여 HTML이 도착하기도 전에 리소스 사전 로드를 시작하세요.
어떤 옵션이 가장 좋은지는 리소스의 파일 유형에 따라 다릅니다:
1. HTML
HTML 자체는 항상 가장 높은 우선순위로 다운로드됩니다. 페이지는 항상 크리티컬 요청 체인의 일부입니다. 이것이 최적화 시 페이지 자체를 가장 먼저 고려해야 하는 이유입니다.
콘텐츠의 지연 로드: Google 자체와 같은 많은 대형 사이트는 크리티컬 요청 체인을 줄이기 위해 이 기술을 사용합니다. 예를 들어 검색 결과 페이지에서 당장 필요하지 않은 콘텐츠의 일부는 나중에 AJAX 요청을 통해 로드됩니다.
최소화(Minify): 작을수록 항상 빠릅니다. HTML 축소를 사용하여 페이지에서 주석, 공백 및 빈 줄을 제거하세요.
압축(Compression): Brotli 또는 Gzip으로 HTML을 압축하세요. Brotli는 일반적으로 Gzip보다 15~20% 더 나은 압축률을 달성합니다.
2. 스타일시트(Stylesheets)
페이지의 헤드에 있는 스타일시트는 항상 중요합니다. 스타일이 없으면 브라우저는 페이지가 어떤 모습일지 알 수 없습니다. 따라서 스타일시트는 크리티컬 요청 체인의 표준 부분입니다.
크리티컬 CSS: CSS 체인을 끊는 가장 효과적인 방법은 <head>의 <style> 태그 내에 크리티컬 CSS를 직접 인라인으로 삽입하는 것입니다. 이는 렌더링을 차단하는 네트워크 요청을 완전히 제거합니다. NodeJS 도구 또는 Critical CSS Generator를 통해 크리티컬 CSS를 생성할 수 있습니다. 크리티컬 CSS는 인라인으로 배치하고 나머지는 더 낮은 우선순위로 로드하세요:
<link rel="preload"
href="css.css"
type="text/css"
as="style"
onload="this.onload=null;this.rel='stylesheet';"/> 이제 페이지에 이상한 일이 일어나는지 지켜보세요. 처음에는 스타일이 없는 페이지가 표시되고, CSS를 로드한 후에야 스타일링이 적용됩니다. 모든 콘텐츠가 스타일이 없는 상태에서 스타일이 적용된 상태로 번쩍일 것입니다. 이것이 크리티컬 CSS가 필요한 이유입니다: 페이지의 보이는 부분에 대한 CSS 규칙이 인라인 처리되므로 페이지가 즉시 올바르게 표시되고, 나머지 CSS는 렌더링을 차단하지 않고 로드됩니다.
CSS @import 체인 피하기: CSS 파일이 @import를 사용하여 다른 CSS 파일을 로드하는 경우, 브라우저가 파일 B가 필요하다는 것을 발견하기도 전에 파일 A를 다운로드해야 하는 체인이 생성됩니다. @import 문을 별도의 <link> 태그로 바꾸거나 빌드 시점에 파일들을 병합(concatenate)하세요. 이는 불필요하게 깊은 크리티컬 체인을 유발하는 가장 흔한 원인 중 하나입니다.
미디어 쿼리(Media queries): 디바이스에 필요한 스타일만 로드하세요. 방문자가 모바일 기기를 사용 중이라면 데스크톱이나 인쇄용 스타일을 다운로드할 필요가 없습니다. 일치하지 않는 기기에서는 스타일시트가 차단되지 않도록 media 속성을 사용하세요:
<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)"> 브라우저는 media 속성이 현재 기기와 일치하는 스타일시트만 높은 우선순위로 다운로드합니다. 일치하지 않는 스타일시트는 낮은 우선순위로 다운로드되며 렌더링을 차단하지 않습니다.
최소화(Minify): 사용하지 않는 CSS를 제거하세요. 많은 사이트가 Bootstrap과 같은 CSS 라이브러리를 사용합니다. 이러한 라이브러리는 종종 과도하게 완전하며 모든 스타일 선언이 사용되지는 않습니다. CSS 전처리기(Sass 등)를 통해 이러한 라이브러리를 편집하여 사용하지 않는 스타일 그룹을 제거하세요. 전처리기는 또한 모든 공백과 줄 바꿈을 제거하여 CSS를 최소화합니다. 'remove unused CSS' 해결 방법도 참조하세요.
압축(Compression): Brotli 또는 Gzip 압축으로 스타일시트를 압축하세요.
3. JavaScript
페이지 헤드에 있는 JavaScript 파일은 기본적으로 높은 우선순위로 다운로드되며, 다운로드되고 실행되는 동안 페이지 렌더링을 차단합니다. 따라서 JavaScript는 크리티컬 요청 체인의 표준 부분입니다.
Defer 및 Async: async 또는 defer 속성을 통해 JavaScript 파일을 비동기적으로 로드하여 우선순위를 조정하세요. Async 스크립트는 더 낮은 우선순위로 병렬 다운로드됩니다. Deferred 스크립트 역시 병렬로 다운로드되며 HTML 파싱이 완료될 때까지 실행이 지연됩니다. 전체 비교를 보려면 async vs defer 및 이들이 Core Web Vitals에 미치는 영향을 참조하세요.
// 로드 및 실행을 차단함
<script src="normalscript.js"></script>
// async는 로드 중에는 차단하지 않지만, 실행 중에는 차단함
<script src="asyncscript.js"></script>
// defer는 로드 또는 실행 중에 차단하지 않음
<script src="deferscript.js"></script>
JavaScript를 지연시키는 더 많은 기술을 알아보려면 JavaScript를 지연시키거나 예약하는 16가지 방법을 참조하세요. 지연시킬 수 없는 미사용 JavaScript가 있는 경우 사용하지 않는 JavaScript를 줄이는 방법을 참조하세요.
코드 분할 및 사전 로드(Code splitting and preloading): 페이지에서 JavaScript를 비동기적으로 로드할 수 없는 경우, JavaScript를 여러 파일로 분할하세요. 페이지 로드 중 크리티컬한 부분을 작은 파일에 배치하고 사전 로드(preload)하세요. 비 크리티컬 JavaScript는 다른 파일에 배치하고 deferred 또는 async로 로드되도록 하세요.
최소화(Minify): JavaScript minifier를 통해 바이트 수를 줄이세요. webpack, Rollup 및 Vite와 같은 최신 번들러는 내부적으로 terser를 사용하여 JavaScript를 분석하고 가능한 한 작게 만듭니다.
압축(Compression): Gzip 또는 Brotli를 통해 JavaScript를 압축하여 바이트 수를 줄이세요.
4. 웹 폰트(Web fonts)
웹 폰트는 일반적으로 크리티컬 요청 체인의 마지막 파일입니다. 이는 웹 폰트가 탐색에 의존하기 때문입니다. 브라우저가 해당 폰트가 필요하다는 것을 발견할 때만 로드됩니다. 이를 위해 브라우저는 먼저 HTML을 분석하고 스타일시트에서 어떤 글꼴이 사용되는지 찾아야 합니다.
사전 로드(Preloading): 폰트를 사용할 것을 알고 있다면 이 폰트를 사전 로드(preload)하는 것이 더 빠릅니다. 그러면 폰트가 가능한 한 일찍 다운로드되어 크리티컬 요청 체인에 미치는 영향을 최소화합니다. 페이지 헤드의 가능한 한 앞부분에 다음 코드를 추가하여 폰트를 사전 로드하세요:
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin> 폰트 전략(Font strategy): 폰트를 더 빨리 로드하는 다른 많은 방법이 있습니다. Google Fonts 자체 호스팅 방법 및 웹 폰트 로드 중에 텍스트가 계속 표시되도록 보장하는 방법을 참조하세요.
- 항상 자체 호스팅(self-hosted) 웹 폰트를 사용하고, Google Fonts와 같이 원격으로 호스팅되는 폰트는 사용하지 마세요.
- 폰트 서브세팅(font subsetting)으로 폰트 크기를 조정하세요.
- 비 크리티컬 폰트는 FontFace API를 통해 로드하세요.
- 초기 렌더링이 폰트에 의해 차단되지 않도록
font-display: swap을 사용하세요. - 폰트 합성(font synthesis)을 통해 브라우저가 자체적으로 폰트 변형(variants)을 생성하도록 허용하세요.
5. 이미지(Images)
페이지 로드 중 눈에 보이는 뷰포트에 나타나는 이미지 역시 높은 우선순위가 부여될 수 있으며 크리티컬 경로를 방해할 수 있습니다. 웹사이트의 보이는 부분에 이미지가 항상 표시된다고 확신할 경우 이 이미지를 사전 로드(preload)하세요. fetchpriority="high"를 추가하여 브라우저에 이것이 페이지에서 가장 중요한 이미지임을 알리세요:
<link rel="preload" as="image" href="important-image.webp"> 즉시 표시되지 않는 모든 이미지의 경우, 이 이미지들을 지연 로드(lazy load)하세요. 이미지가 표시되기 직전까지 로딩을 지연시키려면 loading="lazy"를 사용하세요:
<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="..."> 6. AJAX 요청
AJAX 요청에는 항상 높은 우선순위가 할당됩니다. 따라서 페이지가 렌더링을 마칠 때까지 AJAX 요청을 연기하세요. 페이지가 "load" 이벤트를 보낼 때까지 기다리세요:
window.addEventListener('load', (event)=>{
console.log('AJAX 요청을 하기에 좋은 시점입니다');
}); AJAX 요청을 연기할 수 없는 경우, 리소스를 사전 로드하여 브라우저에서 더 빨리 사용할 수 있도록 만들 수 있습니다.
7. Iframes
Iframe은 보통 높은 우선순위로 다운로드됩니다. Iframe은 실제로 페이지 안의 페이지이기 때문에, iframe은 페이지 로드 시간에 상당한 지연을 초래할 수 있습니다. Iframe이 필요로 하는 리소스 역시 높은 우선순위로 다운로드되어 자체적인 크리티컬 요청 체인을 형성할 수 있습니다. 따라서 iframe 사용은 Core Web Vitals에 큰 영향을 미칠 수 있습니다.
loading="lazy" 속성을 통해 iframe 로딩을 지연시킬 수 있습니다. 이는 로딩 중 iframe이 즉시 보이지 않을 때 종종 큰 차이를 만듭니다. 타이밍을 더 잘 제어하려면 JavaScript를 통해 iframe을 주입하여 크리티컬 요청 체인에 포함되지 않도록 하세요. 이 기술의 예시는 PageSpeed를 떨어뜨리지 않고 Google Maps를 포함하는 방법 및 완벽한 Core Web Vitals로 YouTube를 포함하는 방법을 참조하세요.
개선 사항 확인하기
크리티컬 체인을 최적화한 후 Real User Monitoring을 통해 개선 사항을 확인하세요. FCP와 LCP가 모두 개선될 것입니다. Lighthouse와 같은 랩 도구(Lab tools)는 즉각적인 피드백을 주지만, Core Web Vitals에 중요한 것은 실제 사용자의 필드 데이터(field data)입니다.
