Web Performance

당황하지 않고 Lighthouse 보고서를 읽는 법

성능 감사에서 무엇이 중요한지, 무엇은 안전하게 무시해도 되는지 이해하기 위한 실용 가이드

The Wux Webtools Team The Wux Webtools Team 10 읽기 최소 시간 AI 지원, 인간 검토
Stylized lighthouse beam illuminating a clear path through fog, representing clarity in performance diagnostics
목차
  1. 첫 번째 원칙: 점수는 사이트 그 자체가 아닙니다
  2. 먼저 읽어야 할 것: Core Web Vitals
  3. Opportunities와 Diagnostics: 차이를 이해하기
  4. 보통 무시해도 되는 감사 항목
  5. 모든 것이 빨간색일 때 해야 할 일
  6. Lab data와 field data: 현실 확인
  7. Lighthouse를 다시 실행해야 할 때
  8. Lighthouse 결과를 실제 조치로 이어주는 도구들
  9. 핵심 요점
  10. FAQ
  11. Sources

첫 번째 원칙: 점수는 사이트 그 자체가 아닙니다

처음 Lighthouse 보고서를 열면 숫자와 색상으로 구분된 박스, 들어본 적 없는 항목에 대한 경고가 벽처럼 쏟아집니다. 자연스러운 반응은 당황입니다. 점수는 빨간색이고, 실패한 감사 항목은 열일곱 개나 됩니다. 분명 사이트가 망가진 걸까요?

대개는 그렇지 않습니다. Lighthouse는 성적표가 아니라 진단 도구입니다. 점수는 실험실 조건에서 실행한 합성 벤치마크입니다. 흔히 제한된 연결 환경에서 2017년의 중급형 휴대폰을 시뮬레이션합니다. 이는 해당 특정 시나리오에서 사이트가 어떻게 동작하는지를 알려줄 뿐, 실제 사용자가 현장에서 어떻게 경험하는지를 말해주지는 않습니다.

이 점이 중요한 이유는 대부분의 팀이 점수에 집착하다가 맥락을 놓치기 때문입니다. 실시간 데이터를 다루는 복잡한 웹 앱이라면 65점도 괜찮을 수 있습니다. 반대로 잘못된 것을 최적화했다면 95점이어도 경험은 좋지 않을 수 있습니다. 점수는 조사의 출발점이지 성공 지표가 아닙니다.

먼저 읽어야 할 것: Core Web Vitals

전체 성능 점수는 건너뛰세요. Metrics 섹션으로 내려가 Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Interaction to Next Paint (INP) 세 가지 숫자를 확인하세요. 이것이 Core Web Vitals이며, Google이 순위 신호로 사용하는 유일한 성능 지표입니다.

  • LCP는 가장 큰 가시 요소가 렌더링되는 데 걸리는 시간을 측정합니다. 목표: 2.5초 미만. 4초를 넘는다면 사용자는 의미 있는 콘텐츠를 보기까지 너무 오래 기다리고 있는 것입니다.
  • CLS는 시각적 안정성, 즉 페이지가 로드되는 동안 얼마나 흔들리는지를 측정합니다. 목표: 0.1 미만. 0.25를 넘는다면 버튼이 이동해 사용자가 의도치 않게 잘못된 항목을 클릭하고 있을 수 있습니다.
  • INP는 반응성, 즉 페이지가 클릭, 탭, 키 입력에 얼마나 빠르게 반응하는지를 측정합니다. 목표: 200ms 미만. 500ms를 넘으면 사이트가 굼뜨게 느껴집니다.

이 세 지표는 실제 사용자의 불편함과 관련이 있습니다. 다른 것을 걱정하기 전에 먼저 이것들을 수정하세요.

Opportunities와 Diagnostics: 차이를 이해하기

Lighthouse는 결과를 Opportunities와 Diagnostics라는 두 범주로 나눕니다. Opportunities는 예상 시간 절감 효과를 기준으로 정렬됩니다. Diagnostics는 추가 맥락입니다. 문제가 될 수도 있고, 아닐 수도 있는 항목들입니다.

Opportunities부터 시작하세요. Lighthouse가 "렌더링 차단 리소스 제거"로 1.2초를 절약할 수 있다고 말한다면, 이는 분명한 개선 기회입니다. "사용하지 않는 JavaScript 줄이기"로 0.1초를 절약할 수 있다고 한다면, 리팩터링할 가치가 크지 않을 가능성이 높습니다.

Diagnostics는 더 까다롭습니다. "과도한 DOM 크기 피하기"는 나쁘게 들리지만, CLS가 양호하고 INP가 빠르다면 큰 DOM이 실제로 누구에게도 피해를 주지 않을 수 있습니다. Diagnostics는 단서이지 명령이 아닙니다. 실제 지표와 맞닿아 있는 항목을 조사하세요.

보통 무시해도 되는 감사 항목

일부 Lighthouse 경고는 오래된 잔재이거나 지나치게 공격적입니다. 불필요한 불안을 가장 많이 만드는 항목은 다음과 같습니다.

  • "스크롤 성능 개선을 위해 passive listener를 사용하지 않음" — 이는 대개 큰 차이를 만들지 않는 마이크로 최적화입니다. 스크롤이 버벅인다는 증거가 없다면 건너뛰세요.
  • "이미지 요소에 명시적인 width와 height가 없음" — CLS에는 중요하지만, 이미지가 레이아웃 이동을 일으키는 경우에만 그렇습니다. CLS가 이미 좋다면 감사 항목을 만족시키기 위해 리팩터링하지 않아도 됩니다.
  • "차세대 형식으로 이미지 제공" — 맞습니다. WebP와 AVIF는 더 작습니다. 하지만 이미지가 이미 최적화되어 있고 LCP가 빠르다면, 이는 위기가 아니라 있으면 좋은 개선 사항입니다.
  • "거대한 네트워크 페이로드 피하기" — Lighthouse는 1.6 MB를 넘는 모든 것을 표시합니다. 하지만 빠르게 로드되는 2 MB 페이지가 렌더링을 막는 500 KB 페이지보다 낫습니다. 전체 용량뿐 아니라 바이트가 어떻게 전달되는지에 집중하세요.

모든 것이 빨간색일 때 해야 할 일

Lighthouse 점수가 50 미만이고 대부분의 감사 항목이 실패한다면, 대개 다음 세 가지 근본 원인 중 하나를 다루고 있을 가능성이 높습니다.

  1. 최적화되지 않은 폰트. Web font는 여전히 대부분의 사이트에서 가장 쉬운 성능 개선 지점입니다. 실제로는 두 굵기만 쓰는데 여섯 가지 font weight를 로드하고 있지는 않은지, WOFF2 대신 WOFF 파일을 배포하고 있지는 않은지 확인하세요.
  2. 렌더링을 차단하는 CSS와 JavaScript. First Contentful Paint (FCP)가 3초를 넘는다면 브라우저가 화면을 그리지 못하게 막는 무언가가 있습니다. 큰 CSS 파일이나 <head> 안의 동기 스크립트를 찾아보세요.
  3. 너무 큰 이미지. LCP 요소가 이미지이고 그 크기가 4 MB라면, 그것이 문제입니다. 압축하고, 접힌 영역 아래 이미지는 lazy-load하며, 반응형 이미지 문법을 사용하세요.

이 중 하나를 수정한 뒤 Lighthouse를 다시 실행하세요. 종종 20~30점이 오르는 것을 볼 수 있습니다. 그런 다음 다음 항목을 처리하면 됩니다.

Lab data와 field data: 현실 확인

Lighthouse는 실험실에서 실행됩니다. 느린 연결과 느린 기기를 시뮬레이션하지만, 사람들이 어떻게 스크롤하는지, 무엇을 클릭하는지, 불안정한 Wi-Fi에 연결되어 있는지 같은 실제 사용자 행동은 시뮬레이션할 수 없습니다.

현실을 확인하려면 Lighthouse 결과를 Chrome User Experience Report (CrUX)의 field data와 비교하세요. CrUX는 지난 28일 동안 실제 Chrome 사용자가 사이트를 어떻게 경험했는지 보여줍니다. Lighthouse는 LCP가 4초라고 말하지만 CrUX는 2초를 보여준다면 CrUX를 신뢰하세요. 둘 다 나쁘다면 실제 문제가 있는 것입니다.

CrUX 데이터는 PageSpeed Insights(Lighthouse의 웹 버전)나 Google Search Console의 "Core Web Vitals"에서 확인할 수 있습니다. 불일치가 있다면 이유를 조사하세요. 실제 사용자가 더 빠른 네트워크를 사용하고 있을 수도 있습니다. Lighthouse가 최적화되지 않은 개발 빌드를 테스트하고 있을 수도 있습니다.

Lighthouse를 다시 실행해야 할 때

Lighthouse에는 노이즈가 있습니다. 같은 페이지에서 연속으로 세 번 실행해도 세 가지 다른 점수가 나옵니다. 성능은 변동성이 있기 때문입니다. 백그라운드 프로세스, 네트워크 지터, 브라우저 휴리스틱이 모두 결과에 영향을 줍니다.

안정적인 기준선을 얻으려면 모든 확장 프로그램을 비활성화한 incognito mode에서 Lighthouse를 실행하거나, 더 일관된 결과를 위해 --preset=desktop 플래그와 함께 CLI를 사용하세요. 세 번 실행하고 점수의 평균을 내세요. 큰 변동(10점 초과)이 보인다면 다른 문제가 있는 것입니다. 서버가 느리거나, 페이지가 매번 다른 리소스를 로드하고 있을 수 있습니다.

중요한 변경 후에는 매번 Lighthouse를 다시 실행하세요. 새 폰트 전략을 배포했나요? LCP를 확인하세요. 이미지를 lazy-load했나요? CLS를 확인하세요. 타사 스크립트를 추가했나요? INP를 확인하세요. 성능은 한 번 고치고 끝나는 일이 아니라, 지켜야 하는 예산입니다.

Lighthouse 결과를 실제 조치로 이어주는 도구들

Lighthouse는 무엇이 느린지 알려줍니다. 하지만 항상 어떻게 고쳐야 하는지 알려주지는 않습니다. 이를 위해서는 추가 도구가 필요합니다.

  • WebPageTest는 페이지가 로드되는 과정을 프레임별 filmstrip 뷰로 보여줍니다. LCP와 CLS 문제를 진단하는 데 필수적입니다.
  • Chrome DevTools Performance panel은 어떤 JavaScript가 main thread를 막고 있는지 정확히 보여줍니다. 나쁜 INP 점수의 원인을 찾는 데 사용하세요.
  • 이미지 압축 도구를 사용하면 브라우저에서 직접 이미지를 최적화할 수 있습니다. 타사 서비스에 업로드하는 것보다 더 빠르고 더 비공개적입니다. 이미지를 기기 밖으로 내보내지 않기 때문에 클라이언트 측 이미지 처리는 개인정보 보호 측면의 이점이 있습니다.

Lighthouse는 출발점입니다. 이 도구들은 일을 마무리하도록 도와줍니다.

핵심 요점

  • Lighthouse 점수는 실험실 벤치마크이지, 실제 사용자 경험을 측정한 값이 아닙니다. 당황하기 전에 CrUX의 field data와 비교하세요.
  • Core Web Vitals (LCP, CLS, INP)에 먼저 집중하세요. 이는 사용자 불편과 SEO 영향에 관련된 지표입니다.
  • 예상 시간 절감 효과를 기준으로 Opportunities의 우선순위를 정하세요. 실제 성능 문제와 맞지 않는 Diagnostics는 무시하세요.
  • passive listener나 차세대 이미지 형식 같은 일부 감사 항목은 마이크로 최적화입니다. 큰 것부터 먼저 고치세요.
  • Lighthouse를 세 번 실행하고 결과의 평균을 내세요. 성능은 변동성이 있으며, 한 번의 실행만으로는 오해할 수 있습니다.

FAQ

Q: Lighthouse 점수가 실행할 때마다 바뀌는 이유는 무엇인가요?
A: Lighthouse는 네트워크 속도, CPU 부하, 브라우저 휴리스틱 등 변동 조건에서 성능을 측정하며, 이 모든 요소가 결과에 영향을 줍니다. 더 안정적인 기준선을 위해 incognito mode에서 세 번 실행하고 점수의 평균을 내세요.

Q: 모바일과 데스크톱 중 무엇을 먼저 최적화해야 하나요?
A: 모바일입니다. 대부분의 웹 트래픽이 모바일이고 모바일 기기가 더 느리기 때문에 Lighthouse는 기본적으로 모바일 시뮬레이션을 사용합니다. 모바일 점수가 좋다면 데스크톱 점수도 대체로 괜찮습니다.

Q: Lighthouse 점수는 95인데 사이트가 여전히 느리게 느껴집니다. 무엇이 문제인가요?
A: Lighthouse는 페이지 로드를 측정하지, 로드 이후의 상호작용성을 측정하는 것은 아닙니다. INP 점수를 확인하고 Chrome DevTools Performance panel을 사용해 사용자가 클릭하거나 스크롤할 때 무슨 일이 일어나는지 프로파일링하세요. Lighthouse가 잡아내지 못하는 JavaScript 문제가 있을 수 있습니다.

Q: 완벽한 100점이 필요한가요?
A: 아니요. 90점 이상이면 훌륭합니다. 100점을 좇다 보면 사용자에게 중요하지 않은 것을 최적화하게 되는 경우가 많습니다. LCP, CLS, INP 같은 실제 지표에 집중하고 점수 자체는 무시하세요.

Q: 타사 스크립트를 많이 사용해도 Lighthouse를 신뢰할 수 있나요?
A: Lighthouse는 타사 스크립트를 문제로 표시하지만, 필요한 것과 불필요한 것을 항상 구분할 수 있는 것은 아닙니다. "거대한 네트워크 페이로드 피하기"와 "JavaScript 실행 시간 줄이기" 감사 항목을 사용해 가장 큰 문제를 일으키는 항목을 식별한 다음, 유지할 가치가 있는지 결정하세요.

Sources

Flowchart for reading a Lighthouse report: ignore score first, check LCP CLS INP, review Opportunities by time savings, then use Diagnostics as context
InfographicHow to triage a Lighthouse report — A simple order of operations turns a scary report into a short prioritized checklist
Two-column comparison of Lighthouse items to prioritize versus warnings that can often wait, with examples and numeric thresholds
InfographicLighthouse signals: fix now vs usually ignore — Not every red warning deserves engineering time
Side-by-side diagram comparing Lighthouse lab data and CrUX field data, including 28-day real-user window and example LCP mismatch
InfographicLab data vs field data at a glance — Use lab data to diagnose and field data to confirm what users really feel

자주 묻는 질문

Lighthouse 점수가 실행할 때마다 바뀌는 이유는 무엇인가요?
Lighthouse는 네트워크 속도, CPU 부하, 브라우저 휴리스틱 등 변동 조건에서 성능을 측정하며, 이 모든 요소가 결과에 영향을 줍니다. 더 안정적인 기준선을 위해 incognito mode에서 세 번 실행하고 점수의 평균을 내세요.
모바일과 데스크톱 중 무엇을 먼저 최적화해야 하나요?
모바일입니다. 대부분의 웹 트래픽이 모바일이고 모바일 기기가 더 느리기 때문에 Lighthouse는 기본적으로 모바일 시뮬레이션을 사용합니다. 모바일 점수가 좋다면 데스크톱 점수도 대체로 괜찮습니다.
Lighthouse 점수는 95인데 사이트가 여전히 느리게 느껴집니다. 무엇이 문제인가요?
Lighthouse는 페이지 로드를 측정하지, 로드 이후의 상호작용성을 측정하는 것은 아닙니다. INP 점수를 확인하고 Chrome DevTools Performance panel을 사용해 사용자가 클릭하거나 스크롤할 때 무슨 일이 일어나는지 프로파일링하세요. Lighthouse가 잡아내지 못하는 JavaScript 문제가 있을 수 있습니다.
완벽한 100점이 필요한가요?
아니요. 90점 이상이면 훌륭합니다. 100점을 좇다 보면 사용자에게 중요하지 않은 것을 최적화하게 되는 경우가 많습니다. LCP, CLS, INP 같은 실제 지표에 집중하고 점수 자체는 무시하세요.
타사 스크립트를 많이 사용해도 Lighthouse를 신뢰할 수 있나요?
Lighthouse는 타사 스크립트를 문제로 표시하지만, 필요한 것과 불필요한 것을 항상 구분할 수 있는 것은 아닙니다. "거대한 네트워크 페이로드 피하기"와 "JavaScript 실행 시간 줄이기" 감사 항목을 사용해 가장 큰 문제를 일으키는 항목을 식별한 다음, 유지할 가치가 있는지 결정하세요.

출처 및 추가 읽기

  1. Lighthouse performance scoring — Google Developers
  2. Core Web Vitals — web.dev
  3. Chrome User Experience Report — Google Developers
  4. WebPageTest Documentation — WebPageTest.org
#lighthouse #core-web-vitals #beginners #performance #web-performance
저자에 대하여
The Wux Webtools Team

마지막 업데이트:

계속 읽기