얼마 전 사이드 프로젝트로 만든 포트폴리오 사이트를 처음 PageSpeed Insights로 돌려봤을 때의 충격이 아직도 생생하다. 성능 점수가 단 47점이었다. 틀린 코드 하나 없이 잘 만들었다고 생각했는데, 실제 사용자에게는 느리고 불편한 사이트였던 것이다. 그 경험이 웹 성능 최적화에 제대로 파고드는 계기가 됐다.
이 글에서는 Lighthouse가 무엇인지부터 시작해서, 2026년 현재 반드시 알아야 할 Core Web Vitals 변화와 점수를 90점 이상으로 끌어올리는 실전 방법을 단계별로 정리한다.
Lighthouse란 무엇이고 왜 중요한가?
Lighthouse는 Google이 만든 오픈소스 웹 감사 도구다. Chrome 브라우저의 DevTools에 기본 내장되어 있으며, 성능(Performance), 접근성(Accessibility), 권장사항(Best Practices), SEO 네 영역을 0~100점으로 평가한다.
Lighthouse 성능 점수는 Google의 Core Web Vitals 지표와 직접 연결된다. Core Web Vitals는 2021년부터 Google 검색 순위에 공식 반영된 지표로, 페이지의 로딩 속도·상호작용 응답성·시각적 안정성을 수치로 측정한다.
그런데 2026년 현재, Lighthouse 점수의 의미가 이전보다 훨씬 커졌다. **Google의 2026년 3월 코어 업데이트(4월 8일 완료)**는 Core Web Vitals를 페이지 단위가 아니라 도메인 전체 수준으로 평가하도록 기준을 바꿨다. 쉽게 말해, 블로그의 메인 글 몇 개만 빠르다고 안심할 수 없다. 느린 글이 사이트 전체 순위를 끌어내린다. 업계 분석에 따르면 전체 URL의 25% 이상이 “Poor” 또는 “Needs Improvement”에 해당하면 사이트 전반의 순위 하락으로 이어질 수 있다.
핵심 측정 방법: Chrome에서 F12(개발자 도구) → Lighthouse 탭 → “Analyze page load” 클릭. 또는 PageSpeed Insights에서 URL을 입력하면 실제 사용자 데이터(CrUX)와 함께 확인할 수 있다.
2026년 Core Web Vitals, 무엇이 달라졌나?
Core Web Vitals는 세 가지 핵심 지표로 구성된다.
| 지표 | 측정 내용 | Good 기준 | Lighthouse 비중 |
|---|---|---|---|
| LCP (Largest Contentful Paint) | 가장 큰 콘텐츠 요소가 화면에 그려지는 시간 | 2.5초 이내 | 25% |
| INP (Interaction to Next Paint) | 클릭·탭·키 입력 후 화면 반응 시간 | 200ms 이내 | 10% |
| CLS (Cumulative Layout Shift) | 로딩 중 콘텐츠가 예고 없이 이동하는 정도 | 0.1 이하 | 15% |
2026년 3월 업데이트에서 가장 주목할 변화는 세 가지다.
첫째, LCP·INP·CLS의 순위 반영 가중치가 동등하게 조정됐다. 이전에는 LCP가 사실상 가장 중요한 지표로 취급됐지만, 이제는 INP 점수가 나빠도 LCP만큼 순위에 타격을 준다. 사이트 상호작용 최적화를 미뤄왔다면 지금이 바로 점검할 시기다.
둘째, Lighthouse 점수와 실제 순위 반영 지표는 다르다는 점을 반드시 이해해야 한다. Google 검색 순위에 영향을 주는 것은 Lighthouse의 시뮬레이션 값이 아니라 실제 사용자 데이터인 CrUX(Chrome User Experience Report) 필드 데이터다. Lighthouse 점수 100점을 받아도 Search Console의 Core Web Vitals 보고서에서 “Poor”가 뜰 수 있다. 진단은 Lighthouse로, 최종 판단은 Google Search Console로 해야 하는 이유가 여기 있다.
셋째, INP가 가장 많은 사이트가 실패하는 지표가 됐다. 2026년 기준 전 세계 사이트의 43%가 여전히 INP 200ms 기준을 충족하지 못하고 있다. 특히 워드프레스 사이트는 플러그인이 늘어날수록 JavaScript 실행 부담이 커져 INP가 떨어지기 쉽다.
LCP 점수를 빠르게 높이는 방법은?
LCP의 주범은 대부분 이미지다. 아래 방법을 순서대로 적용하면 LCP를 효과적으로 단축할 수 있다.
1. 이미지를 WebP 또는 AVIF 포맷으로 변환한다
WebP는 PNG·JPEG 대비 동일 화질에서 파일 크기를 평균 25~35% 줄인다. AVIF는 WebP보다 더 뛰어난 압축률을 보이지만 2026년 7월에야 “Widely Available” 상태가 될 예정이므로, 지금은 WebP를 기본으로 적용하는 것이 안전하다. 워드프레스 환경에서는 Imagify 또는 ShortPixel 플러그인이 업로드 시 자동으로 WebP 변환을 처리해준다.
2. Hero 이미지를 preload로 미리 로드한다
페이지 상단의 메인 이미지는 브라우저가 HTML을 파싱하기 전에 미리 내려받도록 설정하면 LCP를 크게 줄일 수 있다.
html
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high">fetchpriority="high" 속성은 브라우저에게 이 리소스를 최우선으로 가져오라고 명시적으로 알려준다. 2026년 현재 Chrome·Firefox·Safari 최신 버전 모두 지원한다.
3. <img> 태그에 width와 height를 반드시 명시한다
브라우저가 이미지 로드 전에 공간을 미리 확보하므로 CLS도 함께 개선된다. 이 두 속성 하나를 빠뜨리는 것이 CLS 점수 하락의 가장 흔한 원인 중 하나다.
4. 서버 응답 속도(TTFB)를 개선한다
TTFB가 0.8초를 초과하면 LCP에 직접적인 영향을 준다. 워드프레스라면 WP Rocket 같은 캐싱 플러그인을 설치하고 CDN을 적용해 정적 자산의 전송 거리를 줄인다. 공유 호스팅을 사용 중이라면 VPS로의 업그레이드가 가장 근본적인 TTFB 개선책이다.
CLS와 INP는 어떻게 개선할 수 있을까?
CLS 개선
레이아웃 이동의 가장 흔한 원인은 크기가 지정되지 않은 이미지와 뒤늦게 로드되는 광고다. 모든 이미지·비디오 요소에 width, height를 명시하고, 광고 슬롯에는 최소 높이를 미리 지정한다.
css
/* 이미지 비율 유지 + CLS 방지 */
img {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}Google Fonts 사용 시 font-display: swap 설정도 CLS에 영향을 준다. 폰트 로드 전에 레이아웃 이동이 생기지 않도록 폴백 폰트를 명시적으로 지정하고, 가능하면 폰트를 자체 호스팅하는 것이 가장 안정적이다.
INP 개선
INP의 주원인은 메인 스레드를 오래 점유하는 무거운 JavaScript다. 해결 방법은 세 가지다.
- 불필요한 서드파티 스크립트(채팅 위젯, 마케팅 툴 등)를 제거하거나 지연 로드한다.
<script>태그에defer또는async속성을 추가해 초기 렌더 차단을 방지한다.- 무거운 이벤트 핸들러 로직은
requestIdleCallback으로 분리해 유휴 시간에 처리한다.
참고로 Lighthouse는 INP를 직접 측정하지 못한다. INP는 실제 사용자 인터랙션이 있어야만 측정되는 순수 필드 지표이기 때문이다. Lighthouse의 TBT(Total Blocking Time)가 INP와 가장 높은 상관관계를 보이므로, TBT를 줄이는 방향으로 최적화하면 실제 INP도 함께 개선된다.
Lighthouse 점수를 추가로 올리는 전략에는 무엇이 있을까?
렌더 블로킹 리소스 제거
CSS·JS 파일이 초기 렌더를 막는다면, Critical CSS만 인라인으로 포함하고 나머지는 비동기 로드한다. 워드프레스에서는 WP Rocket의 “Delay JavaScript Execution” 기능으로 손쉽게 적용할 수 있다.
번들 최적화
Vite나 webpack 같은 번들러의 Tree-shaking으로 실제 사용하는 코드만 번들에 포함시킨다. 번들 크기를 줄이면 TBT가 줄어 성능 점수에 직접 반영된다. Vite는 esbuild 기반으로 빌드 속도와 번들 최적화를 동시에 제공한다. (→ Vite vs Webpack 2026: 속도 차이가 얼마나 날까?)
서드파티 스크립트 감사
Google Analytics, 광고 태그, 소셜 위젯 등 서드파티 스크립트는 INP와 LCP 두 지표 모두를 악화시킨다. 실제로 내 블로그에서 WordPress 소셜 공유 플러그인 하나를 제거했을 때 INP가 380ms에서 210ms로 떨어졌다. 분기마다 서드파티 스크립트를 감사하고 가치가 낮은 것은 제거하는 습관이 필요하다.
코드 품질과 Best Practices 점수
TypeScript를 도입하면 타입 오류 기반의 런타임 예외를 사전에 차단하여 페이지 오류율을 낮추고 Best Practices 점수에도 긍정적인 영향을 준다. (→ TypeScript를 도입하면 정말 버그가 줄어들까?)
Lighthouse 점수를 정확하게 측정하려면 어떻게 해야 할까?
로컬 DevTools 측정값은 실제 사용자 환경과 다를 수 있다. Lighthouse는 시뮬레이션된 단일 기기, 단일 네트워크 환경에서 테스트하기 때문이다. 더 신뢰도 높은 데이터를 얻으려면 다음 두 가지를 병행한다.
- PageSpeed Insights: 실제 사용자 데이터(CrUX)와 Lighthouse 측정값을 함께 제공한다. 모바일·데스크톱을 구분해 보여주므로 모바일 성능을 별도로 확인할 수 있다.
- Google Search Console Core Web Vitals 보고서: 내 사이트를 방문한 실제 사용자의 28일 누적 데이터를 기반으로 문제 URL을 분류해준다. Google 순위 반영 기준이 바로 이 데이터다.
Lighthouse 점수는 측정할 때마다 소폭 변동한다. 단일 측정값보다 3~5회 측정 후 평균값을 기준으로 삼는 것이 좋다. 또한 개선 작업 후 Search Console에 반영되기까지 약 28일의 시간이 필요하다. 점수를 올리고 순위가 바로 오르지 않아도 조급해할 필요가 없다.
css
/* 이미지 비율 유지 + CLS 방지 */
img {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}INP 개선
INP의 주원인은 메인 스레드를 오래 점유하는 무거운 JavaScript다. 해결 방법은 세 가지다.
- 불필요한 서드파티 스크립트(채팅 위젯, 마케팅 툴 등)를 제거하거나 지연 로드한다.
<script>태그에defer또는async속성을 추가해 초기 렌더 차단을 방지한다.- 무거운 이벤트 핸들러 로직은
requestIdleCallback으로 분리해 유휴 시간에 처리한다.
Lighthouse 점수를 추가로 올리는 전략에는 무엇이 있을까?
렌더 블로킹 리소스 제거
CSS·JS 파일이 초기 렌더를 막는다면, Critical CSS만 인라인으로 포함하고 나머지는 비동기 로드한다. 워드프레스에서는 WP Rocket의 “Delay JavaScript Execution” 기능으로 손쉽게 적용할 수 있다.
번들 최적화
Vite나 webpack 같은 번들러의 Tree-shaking으로 실제 사용하는 코드만 번들에 포함시킨다. 번들 크기를 줄이면 TBT(Total Blocking Time)가 줄어 성능 점수에 직접 반영된다. Vite는 esbuild 기반으로 빌드 속도와 번들 최적화를 동시에 제공한다. (→ Vite vs Webpack 2026: 속도 차이가 얼마나 날까?)
코드 품질 관리
TypeScript를 도입하면 타입 오류 기반의 런타임 예외를 사전에 차단하여 페이지 오류율을 낮추고 Best Practices 점수에도 긍정적인 영향을 준다. (→ TypeScript를 도입하면 정말 버그가 줄어들까?)
폰트 최적화
Google Fonts를 사용한다면 font-display: swap을 적용해 폰트 로드 중 텍스트가 보이지 않는 FOIT 현상을 방지한다.
Lighthouse 점수를 정확하게 측정하려면 어떻게 해야 할까?
로컬 DevTools 측정값은 실제 사용자 환경과 다를 수 있다. 더 신뢰도 높은 데이터를 얻으려면 다음 두 가지를 병행한다.
- PageSpeed Insights: 실제 사용자 데이터(CrUX)와 Lighthouse 측정값을 함께 제공한다. 측정 환경을 표준화해 비교가 용이하다.
- Google Search Console Core Web Vitals 보고서: 내 사이트를 방문한 실제 사용자의 28일 누적 데이터를 기반으로 문제 URL을 분류해준다.
또한 Lighthouse 점수는 측정할 때마다 소폭 변동한다. 단일 측정값보다 3~5회 측정 후 평균값을 기준으로 삼자. 워드프레스 운영자라면 Google Search Console의 Core Web Vitals 보고서를 최소 월 1회 확인하는 습관을 들이는 것이 좋다.
자주 묻는 질문 (FAQ)
Q. Lighthouse 점수 몇 점이면 충분한가요?
Google은 90~100점을 “Good”, 50~89점을 “Needs Improvement”, 49점 이하를 “Poor”로 분류한다. SEO와 광고 수익화를 목표로 한다면 성능과 SEO 두 영역 모두 90점 이상을 목표로 하되, 점수 자체보다 실제 Core Web Vitals 지표(LCP 2.5초 이내, INP 200ms 이내, CLS 0.1 이하)가 “Good” 범위에 들어오는지가 더 중요하다. 2026년 3월 업데이트 이후에는 특히 사이트 전체 URL의 Core Web Vitals 상태를 함께 관리해야 한다.
Q. 워드프레스에서 Lighthouse 점수를 빠르게 올리는 플러그인 조합은 무엇인가요?
효과가 높은 조합은 세 가지다. 첫째, WP Rocket(캐싱 + JS 지연 로드 + 미니파이)은 설치만으로 성능 점수가 10~20점 오르는 경우가 많다. 둘째, Imagify 또는 ShortPixel로 이미지를 WebP로 자동 변환·압축한다. 셋째, Cloudflare 무료 플랜 또는 BunnyCDN을 적용해 정적 자산 전송 거리를 줄인다. 유료 플러그인이 부담스럽다면 Autoptimize(CSS/JS 최적화)와 Smush(이미지 압축) 무료 플러그인으로 시작해도 의미 있는 점수 향상이 가능하다. 단, 평균 워드프레스 사이트의 Lighthouse 점수는 기본 상태에서 40~70점 수준이므로, 테마와 플러그인 수를 최소화하는 것이 장기적으로 가장 효과적인 전략이다.
Q. Lighthouse 점수를 올렸는데도 실제 사이트가 느린 이유는 무엇인가요?
Lighthouse 점수는 제어된 환경에서의 단일 시뮬레이션 결과다. Google이 검색 순위에 반영하는 것은 이 점수가 아니라 실제 사용자 방문 데이터인 CrUX 필드 데이터다. 따라서 Lighthouse에서 90점을 받았더라도 Search Console의 Core Web Vitals 보고서에서 “Needs Improvement”가 뜰 수 있다. 진단과 수정은 Lighthouse로, 최종 검증은 Search Console로 하는 것이 올바른 워크플로다. 또한 TTFB가 0.8초 이상이라면 프론트엔드 최적화만으로는 한계가 있으므로 호스팅 환경 개선을 병행해야 한다.
마치며
Lighthouse 최적화는 한 번에 끝나는 작업이 아니다. 특히 2026년 3월 업데이트 이후로는 사이트 전체 URL의 성능을 균일하게 관리하는 것이 더 중요해졌다. 시작점은 단순하다. 이미지 WebP 변환과 캐싱 플러그인 적용을 먼저 하고, 이후 서드파티 스크립트 감사, CLS·INP 순서로 개선하면 단계적으로 90점 이상을 달성할 수 있다.
개선 후에는 반드시 Google Search Console에서 실제 사용자 데이터를 확인하자. Lighthouse 점수와 체감 성능이 일치하는지 검증하는 것이 최적화의 마지막 단계다.
프론트엔드 빌드 환경을 함께 개선하고 싶다면 번들 사이즈 줄이기: 프론트엔드 빌드 최적화 실전 가이드도 참고해보자.
