Lighthouse '렌더링 차단 리소스 제거' 경고 해결하기

렌더링 차단 리소스를 제거하고 Core Web Vitals 개선하기

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-27

요약: '렌더링 차단 리소스 제거'

브라우저가 <head>에서 렌더링을 차단하는 CSS나 JavaScript를 만나면 모든 작업을 중단합니다. 해당 리소스의 다운로드와 실행이 끝날 때까지 화면에 픽셀이 그려지지 않습니다. Lighthouse의 '렌더링 차단 리소스 제거' 경고는 바로 이 점을 지적합니다. 즉, <head> 내부의 무언가가 첫 번째 페인트를 지연시키고 있다는 뜻입니다.

렌더링 차단 리소스를 제거하거나 지연시켜 이 Lighthouse 경고를 해결하세요. 2025 Web Almanac에 따르면 모바일 페이지의 단 15%만이 이 감사를 통과합니다. 이는 웹의 85%가 불필요한 렌더링 지연을 겪고 있다는 것을 의미합니다.

'렌더링 차단 리소스 제거' 문제 해결 방법 알아보기

Lighthouse의 '렌더링 차단 리소스 제거' 경고란 무엇인가요?

마지막 검토: Arjen Karel, 2026년 3월

Lighthouse의 렌더링 차단 리소스 제거 경고를 유발하는 원인은 무엇일까요? Lighthouse는 다음 중 하나에 해당하는 페이지를 지적합니다.

  • 지연되지 않은 head 내의 script 태그.
    페이지의 head에 있는 스크립트는 defer 또는 async 속성이 없으면 기본적으로 렌더링을 차단합니다.
  • 기기 미디어와 일치하는 연결된 스타일시트.
    <link rel="stylesheet">는 비활성화되지 않고 브라우저의 미디어와 일치할 경우 페이지의 렌더링을 차단합니다. 예를 들어 <link rel="stylesheet" media="print">는 화면 기기에서 렌더링을 차단하지 않습니다.

렌더링 차단 리소스가 너무 많으면 First Contentful Paint (FCP)Largest Contentful Paint (LCP)에 직접적인 영향을 미칠 가능성이 큽니다. Vodafone은 렌더링 차단 JavaScript를 줄여 LCP를 31% 개선했으며, 이는 매출 8% 증가로 이어졌습니다.

Web Performance Calendar에 따르면 웹사이트의 67.7%가 렌더링을 차단하는 서드파티 리소스를 하나 이상 로드합니다. Google Fonts 하나만으로도 580만 개 이상의 사이트에서 렌더링 차단 요청을 유발합니다.

'렌더링 차단 리소스'의 원인은 무엇인가요?

렌더링 차단 리소스는 항상 페이지의 head에 있는 스타일시트와 JavaScript입니다. 즉, 이는 CMS, 웹 개발자 또는 플러그인에 의해서만 추가될 수 있습니다. 렌더링 차단 리소스의 출처를 찾을 때는 다음 위치를 확인해 보세요.

  • 템플릿. 웹사이트의 템플릿은 가장 먼저 살펴봐야 할 곳입니다. <head> 코드가 있는 위치를 찾아 하드코딩된 스타일과 스크립트가 있는지 확인하세요.
  • CMS. 때로는 CMS 자체가 제대로 작동하기 위해 일부 스크립트(예: jQuery)를 요구하기도 합니다.
  • 플러그인. 플러그인은 페이지에 스타일과 스크립트를 주입하는 것으로 악명이 높습니다. 플러그인이 한 페이지에서만 사용되는 경우에도 모든 페이지에서 해당 리소스를 로드하는 경우가 많습니다.

스크립트 수준의 데이터가 포함된 가장 최신 버전인 2024 Web Almanac의 JavaScript 장에 따르면, 87%의 페이지가 최소 하나 이상의 스크립트에 async를 사용하고 있지만 실제 개별 스크립트 태그에 이를 적용한 비율은 49%에 불과했습니다. 그리고 단 13%의 스크립트만이 defer를 사용합니다. 웹상의 대부분의 스크립트는 여전히 두 속성 중 어느 것도 없이 로드되며, 이는 렌더링을 차단함을 의미합니다.

'렌더링 차단 리소스 제거' 문제 해결 방법

렌더링 차단 리소스를 해결하려면 해당 리소스가 더 이상 렌더링을 차단하지 않도록 해야 합니다. 가장 좋은 해결책은 리소스를 완전히 제거하는 것입니다. <head>에 여전히 남아 있는 오래되고 사용하지 않는 스크립트와 스타일시트는 생각보다 흔합니다. 제거할 수 없다면 지연시키세요.

JavaScript 지연시키기

JavaScript는 스크립트 태그에 defer 또는 async 속성을 추가하여 지연시킬 수 있습니다.

<!-- deferred: 병렬로 다운로드되며, HTML 파싱 후 순서대로 실행됩니다. -->
<script defer src="script.js"></script>

<!-- async: 병렬로 다운로드되며, 준비되는 즉시 실행됩니다. (순서 무관) -->
<script async src="script.js"></script>

대부분의 스크립트에는 실행 순서를 유지하는 defer가 더 안전한 선택입니다. 분석 스크립트와 같이 완전히 독립적인 스크립트에는 async를 사용하세요. ES 모듈(<script type="module">)을 사용하는 경우 지연 동작이 자동으로 적용됩니다. 모듈 스크립트는 렌더링을 차단하지 않습니다.

JavaScript 타이밍을 제어하는 모든 방법에 대한 포괄적인 가이드는 JavaScript를 지연시키는 16가지 방법을 참조하세요. async와 defer가 Core Web Vitals에 어떻게 다르게 영향을 미치는지 이해하고 싶다면 관련된 전용 문서도 마련되어 있습니다.

스타일시트 지연시키기

스타일시트를 지연시키는 것은 스크립트를 지연시키는 것보다 까다롭습니다. 스타일시트가 지연되면 페이지는 처음에 해당 스타일 없이 렌더링되고, 로드가 완료된 후 브라우저가 스타일을 적용합니다. 이로 인해 화면 깜빡임과 레이아웃 이동이 발생합니다. 따라서 지연된 스타일시트는 인라인 중요 CSS와 함께 사용해야 합니다.

1단계: 중요 CSS를 인라인으로 삽입하세요. 중요 CSS는 페이지의 표시되는 부분을 렌더링하는 데 필요한 최소한의 스타일 집합입니다. 이를 <head><style> 태그에 직접 인라인으로 삽입하세요. 이렇게 하면 외부 파일을 기다리지 않고 스크롤 없이 볼 수 있는 콘텐츠를 페인트하는 데 필요한 모든 것을 브라우저에 제공할 수 있습니다. 중요 CSS를 수동으로 추출하는 것은 번거로운 작업입니다. 당사의 중요 CSS 생성기를 사용하여 이를 자동화할 수 있습니다.

<style>/* 여기에 중요 CSS 삽입 */</style>

2단계: 나머지는 낮은 우선순위로 로드하세요. 중요하지 않은 스타일시트의 경우 fetchpriority="low"를 추가하여 이 리소스가 중요한 콘텐츠와 경쟁해서는 안 된다는 것을 브라우저에 알립니다.

<link rel="stylesheet"
      href="styles.css"
      fetchpriority="low">

오래된 문서에서는 로드 시 media="all"로 전환되는 media="print" 편법을 권장하는 것을 볼 수 있습니다. 이 방법은 추천하지 않습니다. 이 방식은 의도하지 않은 목적으로 media 속성을 남용하며, 깨지기 쉬운 onload 핸들러에 의존하고, 해당 핸들러가 실패하면 스타일이 전혀 적용되지 않습니다. fetchpriority="low"를 사용하는 것이 올바르고 의미론적인 접근 방식입니다. 트릭 없이 사용자의 의도를 브라우저에 정확하게 전달합니다.

현재 페이지에서 전혀 필요하지 않은 스타일시트(예: 특정 페이지 유형에서만 사용되는 스타일)의 경우, 가장 깔끔한 해결책은 해당 페이지에서 사용하지 않는 CSS를 완전히 제거하는 것입니다.

렌더링 차단 리소스의 영향 줄이기

때로는 렌더링 차단 리소스를 제거할 수 없는 경우가 있습니다. 템플릿에 접근할 수 없거나 CMS에서 특정 스크립트를 요구할 수 있습니다. 영향을 줄일 수 있는 몇 가지 방법이 있습니다.

  • 스타일과 스크립트를 축소하고 압축하세요.
    작은 리소스는 큰 리소스보다 로드 성능에 미치는 영향이 적습니다. 서버에서 gzip 또는 brotli 압축이 활성화되어 있는지 확인하세요.
  • 중요 요청 체이닝을 피하세요.
    렌더링을 차단하는 스타일시트가 @import를 통해 다른 스타일시트를 로드하면 요청 체인이 생성됩니다. 두 번째 파일은 첫 번째 파일이 완전히 로드되고 파싱될 때까지 다운로드를 시작할 수 없습니다. 대신 개별 <link> 태그를 사용하여 두 파일이 병렬로 다운로드되도록 하세요.
  • 페이지별로 리소스를 언로드하세요.
    한 페이지에서 리소스를 제거할 수 없다고 해서 모든 페이지에서 필요하다는 의미는 아닙니다. WordPress 플러그인은 플러그인이 일부 페이지에서만 활성화된 경우에도 모든 페이지에 스크립트와 스타일을 추가하는 경향이 있습니다.
  • 중요한 것의 우선순위를 정하세요.
    리소스 우선순위 지정을 사용하여 중요한 리소스가 먼저 로드되고 중요하지 않은 리소스가 대역폭을 두고 경쟁하지 않도록 하세요.

CoreDash 모니터링 데이터에 따르면 렌더링 차단 리소스를 모두 제거한 사이트는 FCP가 평균 420ms 향상되었습니다.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

CoreDash는 제가 직접 쓰려고 만들었습니다.

1KB 미만, EU 호스팅, 쿠키 동의 배너 없음. 이제 MCP까지 지원합니다.

CoreDash 무료 체험
Lighthouse '렌더링 차단 리소스 제거' 경고 해결하기Core Web Vitals Lighthouse '렌더링 차단 리소스 제거' 경고 해결하기