Lighthouse에서 '사용하지 않는 자바스크립트 줄이기' 해결하기

'사용하지 않는 자바스크립트 줄이기' Lighthouse 경고란 무엇인가요?

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

Lighthouse는 20KiB 이상의 사용하지 않는 코드가 있는 모든 JavaScript 파일을 표시합니다. 이 경고가 표시되면 페이지가 현재 페이지 로드에 필요하지 않은 JavaScript를 다운로드하고 실행하고 있는 것입니다.

이 경고는 Lighthouse 성능 점수에 직접적인 영향을 미칩니다. 하지만 더 중요한 것은 사용하지 않는 JavaScript가 실제 사용자에게 피해를 준다는 것입니다. 2025 Web Almanac에 따르면, 모바일 페이지의 중간값은 646KB의 JavaScript를 전송하며, 그 중 251KB는 로드되는 페이지에서 사용되지 않습니다. 90백분위수에서 낭비되는 JavaScript의 양은 931KB까지 증가합니다.

한편, 2025 Web Almanac Performance 챕터에 따르면 모바일의 총 차단 시간(Total Blocking Time)은 전년 대비 58% 증가하여 중간값이 1,916ms에 달했습니다. JavaScript 페이로드(payload)는 기기가 빨라지는 것보다 더 빠르게 증가하고 있습니다. CoreDash가 모니터링하는 사이트 전반에 걸쳐, 사용하지 않는 JavaScript를 100KB 미만으로 유지하는 오리진(origin)은 93%의 확률로 INP에서 "good" 점수를 받는 반면, 400KB를 초과하는 오리진은 64%에 그쳤습니다.

사용하지 않는 JavaScript의 원인은 무엇인가요?

사용하지 않는 JavaScript에는 여러 가지 원인이 있을 수 있습니다. 가장 흔한 원인은 다음과 같습니다:

• CMS에 플러그인이 너무 많은 경우.
• 현재 웹사이트에서 더 이상 사용하지 않는 데드 코드(Dead code).
• 불필요한 검사와 분기가 있는 잘못 작성된 스크립트.
• 마케팅 팀이 태그를 추가하고 제거하는 것을 잊어버리는 등 제한 없는 태그 매니저(GTM) 접근.
• 불필요한 임포트(import): 단일 함수만 사용할 때 전체 라이브러리를 가져오는 경우.
• 모든 페이지에서 실행되지만 특정 라우트에서만 필요한 코드.
• 사용 직전에 로드할 수 있었음에도 즉시 로드되는 스크립트.

사용하지 않는 JavaScript는 Core Web Vitals에 어떤 영향을 미치나요?

사용하지 않는 JavaScript는 두 가지 측면에서 성능에 타격을 줍니다:

• 네트워크 경합(Network contention). 모든 JavaScript 파일은 다운로드되어야 합니다. 이러한 요청은 LCP 이미지, 폰트, CSS와 대역폭을 두고 경쟁합니다. 모바일 연결에서는 이러한 지연으로 인해 Largest Contentful Paint가 2.5초 임계값을 훌쩍 넘길 수 있습니다.
• 메인 스레드 차단(Main thread blocking). 브라우저는 그 많은 JavaScript를 파싱, 컴파일, 실행해야 합니다. 그러는 동안 사용자 입력에 응답하거나 페이지 렌더링을 계속할 수 없습니다. 이는 LCP와 INP 모두에 직접적인 영향을 미칩니다.

Lighthouse 점수는 Core Web Vitals 점수가 아님을 명심하세요. Core Web Vitals는 실제 사용자의 필드 데이터(CrUX)로 측정됩니다. Lighthouse는 문제를 찾는 데 도움이 되는 진단 도구이지만, 실제 성능은 방문자가 실제로 경험하는 것입니다. RUM (Real User Monitoring)을 통해 필드 성능을 확인할 수 있습니다.

사용하지 않는 JavaScript를 찾는 방법

페이지에서 사용하지 않는 JavaScript를 식별하는 방법에는 세 가지가 있습니다:

1. Lighthouse 감사 읽기

Lighthouse는 20KiB 이상의 사용하지 않는 코드가 있는 모든 JavaScript 파일을 나열합니다. 총 바이트, 사용하지 않는 바이트, 잠재적 절감 효과를 보여줍니다. 이것이 시작점입니다. 참고로 Lighthouse 13(2025년 10월)은 인사이트 기반의 감사 형식으로 변경되었지만, 사용하지 않는 JavaScript 검사는 여전히 존재합니다.

2. Chrome 커버리지(Coverage) 도구 사용

커버리지 도구는 페이지의 모든 JavaScript 및 CSS 파일에 대해 사용된 코드와 사용되지 않은 코드의 분석을 줄 단위로 제공합니다.

Ctrl+Shift+I(Mac의 경우 Cmd+Option+I)를 눌러 Chrome DevTools를 엽니다. 그런 다음 Ctrl+Shift+P를 사용하여 명령 메뉴를 열고 coverage를 입력합니다. Show Coverage를 선택한 후 새로고침 버튼을 클릭하여 계측을 시작합니다. 페이지가 로드된 후 모든 파일과 사용되지 않은 바이트의 비율을 볼 수 있습니다.

더 세분화된 결과를 얻으려면 "Per block" 커버리지 모드(패널 상단의 드롭다운)로 전환하세요. 블록 수준의 커버리지는 함수 호출 여부뿐만 아니라 함수 내의 사용되지 않는 분기까지 감지합니다.

행을 클릭하면 Sources 패널에서 해당 파일이 열립니다. 파란색 선은 사용된 코드이고 빨간색 선은 사용되지 않은 코드입니다. 이를 통해 페이지 로드 중에 실행되지 않은 함수와 분기가 정확히 무엇인지 알 수 있습니다.

3. 번들 분석하기

webpack, Rollup, Vite와 같은 번들러를 사용하는 경우 번들 분석기를 사용하여 JavaScript 파일 내부에 무엇이 있는지 시각화하세요. webpack-bundle-analyzer 및 source-map-explorer와 같은 도구는 번들의 모든 모듈에 대한 트리맵을 보여주어, 작은 기능을 위해 큰 라이브러리를 가져왔을 때 이를 명확하게 알 수 있도록 합니다.

사용하지 않는 것이 항상 불필요한 것은 아닙니다

한 페이지에서 "사용하지 않는" 스크립트가 "불필요한" 스크립트를 의미하지는 않는다는 점을 명심하세요. 결제 양식을 구동하는 스크립트는 홈페이지에서 100% 사용되지 않는 것으로 나타납니다. 그렇다고 해당 스크립트를 삭제해야 한다는 뜻은 아닙니다. 홈페이지에서 해당 스크립트를 로드하지 않아야 한다는 의미입니다.

이것이 코드 스플릿이 해결하는 문제로, 각 라우트는 실제로 필요한 JavaScript만 로드합니다. 사이트가 단일 페이지 애플리케이션(SPA)이고 많은 양의 "사용하지 않는" JavaScript가 보인다면, 해결책은 대부분 코드를 삭제하는 것이 아니라 더 나은 라우트 수준의 코드 스플릿을 적용하는 것입니다.

'사용하지 않는 자바스크립트 줄이기' 해결 방법

'사용하지 않는 자바스크립트 줄이기' 경고를 해결하려면 먼저 낭비가 발생하는 위치를 추적해야 합니다. Lighthouse는 사용하지 않는 바이트 양이 많은 스크립트를 알려줍니다. 이를 줄이는 7가지 방법은 다음과 같습니다:

1. 불필요한 플러그인 제거. WordPress와 같은 CMS를 사용하는 경우, 가장 쉬운 방법은 필요하지 않은 플러그인을 제거하거나 사소한 플러그인을 몇 줄의 코드로 대체하는 것입니다. 분석 플러그인, 소셜 공유 버튼, 채팅 위젯이 흔한 원인입니다.
2. 데드 코드 제거. 데드 코드는 현재 웹사이트에서 더 이상 사용하지 않는 코드입니다. 최소 1년에 두 번은 데드 코드 감사를 예약하세요. Knip과 같은 도구는 JavaScript 프로젝트에서 사용되지 않는 내보내기(export) 및 종속성의 감지를 자동화할 수 있습니다.
3. 번들 트리 쉐이킹(Tree shake). 트리 쉐이킹은 빌드 시 사용하지 않는 내보내기를 제거합니다. 작동하려면 CommonJS(require)가 아닌 ES 모듈 구문(import/export)이 필요합니다. package.json에 "sideEffects": false를 추가하여 번들러가 사용하지 않는 코드를 적극적으로 제거할 수 있게 하세요. 필요한 것만 임포트하세요:

   // Bad: 전체 라이브러리를 임포트 (70+ KB)
   import _ from 'lodash';
   const result = _.debounce(fn, 300);
   
   // Good: debounce만 임포트 (트리 쉐이킹 적용 시 ~1 KB)
   import { debounce } from 'lodash-es';
   const result = debounce(fn, 300);

4. 라우트 코드 스플릿(Code split). 각 페이지에 실제로 필요한 JavaScript만 로드하세요. 동적 import()를 사용하여 라우트별 또는 기능별로 번들을 분할하세요:

   // 미리 모든 것을 임포트하는 대신:
   import { validateForm } from './formValidation.js';
   
   // 사용자가 폼과 상호작용할 때만 로드하세요:
   document.querySelector('form').addEventListener('focus', async () => {
     const { validateForm } = await import('./formValidation.js');
     validateForm();
   }, { once: true });

   React에서는 컴포넌트 수준의 분할을 위해 <Suspense>와 함께 React.lazy()를 사용하세요. Next.js App Router에서는 기본적으로 React Server Components가 클라이언트에 JavaScript를 전송하지 않습니다. Vue에서는 Vue Router에서 defineAsyncComponent() 또는 동적 임포트를 사용하세요.

5. 태그 매니저 정리 및 접근 제한. 태그 매니저는 특히 마케팅 팀이 이전 태그를 제거하지 않고 새 태그를 추가할 때 사용하지 않는 코드의 일반적인 출처입니다. 정기적으로 태그 매니저 컨테이너를 감사하세요. 페이지 로드 시 실행되는 모든 태그는 리소스를 두고 경쟁하는 JavaScript를 추가합니다.
6. 불필요한 임포트 제거. React, Vue, Next.js 프로젝트에서 import 문을 확인하세요. 단 두 개의 컴포넌트만 사용하는데 전체 컴포넌트 라이브러리를 임포트하고 있지는 않나요? 네이티브 Intl API나 dayjs와 같은 2KB의 대안으로 충분할 때 moment.js(330KB)를 가져오고 있지는 않나요?
7. 중요하지 않은 스크립트 로드 지연. 양식 제출 등과 같이 스크립트가 필요하지만, 페이지 로드 중에는 필요하지 않은 경우가 있습니다. 사용자가 실제로 필요로 할 때 로드하세요. 상호작용 시에 로드되는 스크립트는 Lighthouse 감사에서 더 이상 "사용하지 않는 JavaScript"가 아닙니다. 두 로딩 전략의 차이를 이해하려면 async와 defer도 참고하세요.

완전히 해결할 수 없는 경우

때로는 사용하지 않는 JavaScript를 모두 제거할 수 없는 경우도 있습니다. 타사 스크립트, A/B 테스트 도구, 광고 네트워크는 종종 통제할 수 없는 큰 번들을 전송합니다. 그런 경우에는 그 영향을 최소화하세요:

• 가능한 한 기본 도메인에서 타사 스크립트를 자체 호스팅(Self-host)하세요. 이렇게 하면 각 외부 도메인에 대한 새로운 DNS 조회 및 TCP 연결 비용을 피할 수 있습니다.
• 핵심 리소스의 우선순위를 지정하세요. LCP 이미지와 핵심 폰트가 네트워크 대기열에서 JavaScript 다운로드 뒤에 갇히지 않도록 미리 로드(Preload)하세요.
• 가능한 많은 JavaScript를 지연시키세요. defer, async 또는 지연 로딩을 사용하여 중요하지 않은 스크립트를 중요 렌더링 경로(critical rendering path) 밖으로 이동하세요.
• 필수적이지 않은 스크립트 리소스에 fetchpriority="low"를 사용하여 브라우저에 기다릴 수 있음을 알리세요.
• 필드 데이터 모니터링. RUM (Real User Monitoring)을 사용하여 변경 사항이 단순히 Lighthouse 점수뿐만 아니라 실제 사용자의 경험을 개선했는지 확인하세요.