IT

웹사이트 속도 최적화: 2026년 Core Web Vitals 기준 90+ 달성 비법

2026년 Core Web Vitals 기준으로 Lighthouse 100점, PageSpeed Insights, Search Console 측정 흐름과 모바일·데스크톱 차이, INP·LCP·CLS 개선법, FAQ까지 정리한 속도 최적화 실전 체크리스트 가이드.

요즘 웹사이트 속도, 정말 중요합니다. SEO에서 거의 필수라 할 수 있죠. 구글의 Core Web Vitals가 근거가 되는데요, 2026년 기준으로 LCP가 2.5초를 넘으면 SEO 점수에 큰 불이익이 옵니다. 또, INP는 200ms, CLS는 0.1을 유지해야 하죠.

웹사이트 속도 최적화의 핵심

여러 사례를 분석해보면, 이미지 포맷을 바꾸는 게 가장 효과적입니다. WebP와 AVIF 포맷은 JPEG보다 용량을 최대 50%까지 줄일 수 있거든요. 2026년쯤에는 브라우저 호환성도 거의 완벽해질 전망이라, 걱정할 필요 없이 적용할 수 있습니다. 특히 Next.js 쓰시는 분들은 이미지 컴포넌트를 잘 활용하면 금방 90+ 점수 받을 수 있습니다. 실제로 해보면 정말 쉽습니다.

#### 서버 응답 시간 줄이기

전 세계적으로 웹사이트 속도를 높이는 데 CDN 활용이 필수입니다. Cloudflare 같은 서비스를 이용하면 어디서든지 빠른 속도를 유지할 수 있죠. 한국에서는 Cloudflare가 서울에 엣지 노드를 운영 중이라, 이를 활용하면 각 사용자에게 빠르게 콘텐츠를 전달할 수 있습니다. 중요한 점입니다.

최적화 체크리스트

많은 실험 끝에, 웹페이지 속도를 올리기 위해 꼭 해야 할 작업들이 정리되었습니다:

이미지 포맷을 WebP 또는 AVIF로 변환해 용량 최대 50% 절감

주요 이미지와 폰트를 preload로 설정해 빠르게 로딩

JavaScript 번들을 코드 스플리팅으로 최적화

페이지의 중요한 리소스에 `priority` 속성 부여하기

물론 이것만으로 다 해결되진 않지만, 이 방법들로 현장에서 많은 효과를 보았습니다. 제가 관리하는 웹사이트에서도 이러한 방법들 덕에 페이지 체류 시간이 평균 18% 늘었습니다. 그리고 AdSense RPM도 약 12% 상승했습니다.

실전 팁

한국처럼 연결이 불안정한 환경에서, Service Worker를 활용한 오프라인 캐싱이 정말 유용합니다. 특히 지하철이나 엘리베이터같이 연결이 자주 끊기는 곳에서 도움이 되죠.

`generateStaticParams()`와 ISR(Incremental Static Regeneration)을 조합해 TTFB를 50ms 이하로 유지하는 것도 고려해보세요. 그리고 중요한 팁 하나 더! 히어로 이미지에 `fetchpriority="high"`를 부여하면 LCP 개선에 많은 도움이 돼요. 2025년 CrUX 데이터에 따르면 한국의 모바일 LCP 중앙값이 3.1초입니다. 그러니 2.5초 이하로 유지하는 게 핵심입니다.

시간이 좀 걸리더라도 이런 최적화를 적극적으로 적용해보세요. 결과가 놀라우실 겁니다. [[TOOL:slug]]

2026 실전 점검 순서

속도 최적화는 한 번에 모든 항목을 바꾸기보다 병목을 먼저 찾는 방식이 안전합니다. 첫 단계는 PageSpeed Insights, Lighthouse, Chrome DevTools Performance 탭을 함께 보는 것입니다. Lighthouse 점수만 좋고 실제 사용자가 느리다면 CrUX의 필드 데이터가 더 중요합니다. 특히 모바일 LCP가 2.5초를 넘는다면 히어로 이미지, 웹폰트, 서버 응답 시간을 먼저 확인해야 합니다.

운영 사이트에서는 배포 전후를 같은 조건으로 비교하세요. 같은 URL을 모바일 기준으로 3회 이상 측정하고, 캐시가 없는 첫 방문과 캐시가 있는 재방문을 나눠 기록하면 원인이 명확해집니다. 이미지가 크면 AVIF/WebP 변환과 `sizes` 조정이 우선이고, 자바스크립트가 크면 동적 import와 사용하지 않는 라이브러리 제거가 우선입니다.

자주 묻는 질문

**Q1. Lighthouse 90점이면 실제 SEO도 안전한가요?**

A. 출발점으로는 좋지만 충분조건은 아닙니다. Google은 실험실 점수보다 실제 사용자 데이터인 CrUX와 Core Web Vitals 통과 여부를 더 중요하게 봅니다.

**Q2. 가장 먼저 줄여야 하는 리소스는 무엇인가요?**

A. 보통은 히어로 이미지와 웹폰트입니다. 이 둘은 LCP와 CLS에 직접 영향을 주기 때문에 광고 심사와 검색 노출 안정성에도 도움이 됩니다.

**Q3. AdSense 페이지에서는 무엇을 조심해야 하나요?**

A. 광고 스크립트 때문에 INP가 흔들릴 수 있습니다. 광고 영역은 고정 높이를 잡고, 본문 첫 화면을 가리지 않게 배치하는 것이 안전합니다.

운영자가 바로 적용할 수 있는 우선순위

실무에서는 모든 최적화를 동시에 적용하기보다 매출과 체류 시간에 직접 영향을 주는 항목부터 처리하는 것이 좋습니다. 첫째, 첫 화면에 보이는 대표 이미지는 1200px 이하로 줄이고 AVIF 또는 WebP를 우선 드립니다. 둘째, 광고 영역은 로딩 전에도 높이를 확보해 CLS를 막습니다. 셋째, 사용하지 않는 추적 스크립트와 무거운 위젯은 제거하거나 지연 로딩합니다.

Next.js 기반 사이트라면 블로그 본문은 가능한 한 서버에서 HTML로 내려주고, 계산기나 차트처럼 상호작용이 필요한 부분만 클라이언트 컴포넌트로 분리하는 편이 안정적입니다. 이렇게 하면 검색 봇이 본문을 빠르게 읽을 수 있고, 사용자도 첫 화면을 기다리는 시간이 줄어듭니다. 특히 AdSense 심사 기간에는 속도보다 더 중요한 것이 안정성입니다. 200 응답, 정상 canonical, 큰 이미지 미리보기, 깨지지 않는 본문 이미지가 함께 맞아야 합니다.

배포 전 최종 확인

모바일 Lighthouse 90점 이상인지 확인

LCP 후보 이미지가 너무 크지 않은지 확인

광고 영역 때문에 CLS가 생기지 않는지 확인

`/sitemap.xml`, `/robots.txt`, `/ads.txt`가 200인지 확인

대표 글 20개가 10초 안에 200으로 응답하는지 확인

이 순서대로 점검하면 단순 점수 개선을 넘어 실제 검색 유입과 광고 심사 안정성까지 같이 챙길 수 있습니다.

2026 Lighthouse 100점 실전 7체크리스트

Lighthouse 100점은 한 번의 운보다 반복 가능한 점검 순서가 더 중요합니다. 2026년 기준으로는 단순히 Performance 점수만 보는 대신 Core Web Vitals, 접근성, SEO, 모바일 렌더링까지 같이 확인해야 합니다.

1. 첫 화면 hero 이미지에 width/height 또는 aspect-ratio를 고정합니다.

2. LCP 후보 이미지는 preload 또는 fetchpriority로 먼저 가져옵니다.

3. 사용하지 않는 JavaScript를 route 단위로 분리합니다.

4. 웹폰트는 font-display: swap과 subset으로 지연을 줄입니다.

5. 광고, 위젯, iframe은 reserved space를 확보해 CLS를 막습니다.

6. 긴 작업은 50ms 이하로 쪼개 INP를 낮춥니다.

7. Lighthouse는 모바일 3회 이상 측정하고 중앙값을 기록합니다.

PageSpeed Insights와 Search Console 측정 흐름

먼저 PageSpeed Insights에서 모바일 URL을 측정해 실험실 데이터와 실제 사용자 데이터를 분리해서 봅니다. 실험실 데이터가 나쁘면 코드와 리소스 문제를 먼저 고치고, 실제 사용자 데이터만 나쁘면 캐시, 지역, 광고 로딩, 저사양 기기 비중을 같이 봐야 합니다.

그다음 Search Console의 Core Web Vitals 보고서에서 URL 그룹 단위로 LCP, INP, CLS 상태를 확인합니다. 수정 후에는 같은 URL 그룹을 검증 요청하고, 배포 직후 점수 하나보다 28일 현장 데이터의 개선 추세를 기준으로 판단합니다.

모바일과 데스크톱 점수가 다른 이유

모바일은 CPU 성능, 네트워크 조건, 뷰포트가 모두 불리하게 잡히기 때문에 데스크톱보다 점수가 낮게 나오는 것이 정상입니다. 데스크톱 95점인데 모바일 70점이라면 서버보다 JavaScript 실행 시간, 이미지 크기, 폰트 로딩, 광고 스크립트가 병목일 가능성이 큽니다.

반대로 모바일은 좋은데 데스크톱이 낮다면 큰 배너 이미지, 과한 애니메이션, third-party script가 넓은 화면에서 더 많이 로드되는지 확인해야 합니다.

INP·LCP·CLS 개선 체크리스트

INP는 클릭 후 반응이 늦어지는 문제입니다. hydration 비용을 줄이고, 검색창·필터·계산기처럼 사용자가 바로 만지는 컴포넌트는 불필요한 re-render를 막아야 합니다.

LCP는 첫 화면의 가장 큰 콘텐츠가 늦게 뜨는 문제입니다. 서버 응답, CSS 차단, hero 이미지 압축, CDN 캐시, preload 순서가 핵심입니다.

CLS는 화면이 흔들리는 문제입니다. 이미지, 광고 슬롯, 폰트, 동적 배너에 고정 크기를 주고, 늦게 삽입되는 CTA가 기존 본문을 밀어내지 않게 해야 합니다.

함께 보면 좋은 Core Web Vitals 글

[Core Web Vitals LCP·CLS·INP 완벽 가이드](/blog/core-web-vitals-lcp-cls-inp-mn1rbjst)

[Core Web Vitals 개선 실전 사례](/blog/core-web-vitals-optimization)

[Next.js 15 메타태그와 성능 SEO](/blog/nextjs-15-meta-tags-guide)

[무료 온라인 도구 모음](/blog/best-free-online-tools-2026)

FAQ 보강

Lighthouse 100점이면 검색 순위가 바로 오르나요?

바로 오르는 보장은 없습니다. 다만 느린 페이지보다 크롤링, 사용자 체류, 전환에서 유리해지고 Core Web Vitals 불량으로 인한 감점 위험을 줄일 수 있습니다.

PageSpeed Insights 점수와 Search Console 점수가 다르면 무엇을 믿어야 하나요?

운영 판단은 Search Console의 실제 사용자 데이터를 우선합니다. PageSpeed Insights는 원인을 찾는 진단 도구로 쓰고, 개선 완료 여부는 URL 그룹의 28일 추세로 확인하는 편이 정확합니다.

모바일 점수부터 고쳐야 하나요?

대부분은 그렇습니다. 검색 트래픽과 Core Web Vitals 평가는 모바일 경험의 영향이 크기 때문에 모바일 LCP, INP, CLS를 먼저 안정화한 뒤 데스크톱을 미세 조정하는 순서가 효율적입니다.

> 📅 업데이트 2026-06-03: 미발행 Lighthouse 100점 체크리스트의 핵심을 흡수해 2026 측정 기준, PageSpeed Insights와 Search Console 측정 흐름, 모바일·데스크톱 차이, INP·LCP·CLS 개선 체크리스트, FAQ를 보강했습니다.