페이지 속도·Core Web Vitals 개선 가이드 — LCP·INP·CLS 기준과 해결 순서

페이지 속도는 구글의 Core Web Vitals 세 지표로 평가합니다. 실제 방문자의 75% 이상이 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하를 경험하면 「좋음」입니다. 개선은 서버 응답(TTFB)을 먼저 확인한 뒤 캐시 → 이미지 → 자바스크립트 → 폰트 순서로 진행하면 적은 노력으로 큰 효과를 얻습니다.

Core Web Vitals 합격 기준은 얼마인가요?

INP는 2024년 3월 FID를 대체했습니다. TTFB(서버 첫 응답, 0.8초 이하 권장)와 FCP(첫 콘텐츠 표시, 1.8초 이하 권장)는 원인을 찾는 보조 지표입니다. 구글은 Core Web Vitals를 페이지 경험 신호로 쓰지만 관련성이 더 우선한다고 밝힙니다. 속도는 순위를 뒤집는 요소라기보다 이탈과 전환을 좌우하는 기본기입니다.

Lighthouse 점수와 실사용자 데이터(CrUX)는 무엇이 다른가요?

PageSpeed Insights에는 두 종류의 데이터가 함께 나옵니다.

구글이 평가에 쓰는 것은 실사용자 데이터이고, Lighthouse 성능 점수(0~100)는 진단용 숫자입니다. 방문자가 적은 사이트는 CrUX가 「데이터 없음」으로 나오는데, 이때는 Lighthouse의 LCP·TBT·CLS를 기준 안으로 맞추면 됩니다. 목표는 점수 100이 아니라 세 지표를 「좋음」 구간에 넣는 것입니다.

TTFB가 느리면 무엇부터 확인하나요?

TTFB는 요청 후 서버의 첫 바이트가 도착하기까지의 시간으로, LCP의 출발점입니다. 서버가 1.5초 늦게 응답하면 이미지를 아무리 줄여도 LCP 2.5초를 맞추기 어렵습니다.

• 서버 위치: 방문자 대부분이 한국인데 서버가 미국·유럽에 있으면 왕복 거리만으로 수백 ms가 더해집니다.
• 페이지 캐시: 워드프레스·그누보드처럼 요청마다 PHP와 DB를 거치는 사이트는 페이지 캐시만 켜도 크게 빨라집니다.
• 쿼리·플러그인: 쓰지 않는 플러그인을 지우고, 느린 DB 쿼리에 인덱스를 추가합니다.
• 런타임 설정: PHP OPcache를 켜고 HTTP/2 이상으로 서비스합니다.

무엇부터 고쳐야 하나요? 캐시 → 이미지 → JS → 폰트

1. 캐시: 한 번 받은 파일은 다시 받지 않게

CSS·JS·이미지·폰트처럼 잘 바뀌지 않는 파일은 Cache-Control로 1년 동안 저장하게 합니다. 수정할 때 파일명의 버전(app.3f9a1c.css, ?v=20260928)이 바뀌도록 빌드하면 긴 캐시에도 새 파일이 바로 반영됩니다. HTML은 짧게 캐시하거나 매번 확인하게 둡니다.

2. 이미지: LCP 요소부터

대부분의 페이지에서 LCP 요소는 첫 화면의 대표 이미지입니다. 대표 이미지는 먼저 불러오고, 스크롤해야 보이는 이미지만 지연 로딩합니다.

<!-- 첫 화면 대표 이미지: 지연 로딩 금지, 우선순위 높임 -->
<img src="/img/hero.webp" width="1200" height="600" fetchpriority="high" alt="강남역 필라테스 스튜디오 내부">

<!-- 아래쪽 이미지: 지연 로딩 -->
<img src="/img/review-1.webp" width="600" height="400" loading="lazy" alt="회원 수업 후기 사진">

• 대표 이미지에 loading="lazy"를 붙이면 LCP가 오히려 늦어집니다.
• WebP나 AVIF로 바꾸고, 화면 크기에 맞는 해상도를 srcset으로 제공합니다.
• width·height를 지정하면 이미지 자리가 미리 잡혀 CLS가 줄어듭니다. 자세한 방법은 이미지 최적화 가이드에 있습니다.

3. 자바스크립트: 적게, 늦게, 잘게

INP와 TBT를 나쁘게 만드는 주범은 메인 스레드를 오래 붙잡는 자바스크립트입니다.

• 첫 화면에 필요 없는 스크립트에는 defer를 붙여 HTML 해석을 막지 않게 합니다.
• 채팅 위젯, 중복된 광고 픽셀, 쓰지 않는 분석 태그를 정리합니다. 태그 관리자에 쌓인 태그도 주기적으로 점검합니다.
• 50ms를 넘는 긴 작업(Long Task)은 잘게 나눠 사용자 입력이 바로 처리되게 합니다.

4. 폰트: 한글 웹폰트는 서브셋으로

한글은 현대 음절만 11,172자라서 전체 글자를 담은 폰트는 파일이 메가바이트 단위로 커집니다. 자주 쓰는 2,350자(KS X 1001) 서브셋이나 unicode-range로 나눈 동적 서브셋을 woff2로 쓰고, 폰트가 늦게 와도 글자가 먼저 보이도록 font-display를 지정합니다.

@font-face {
  font-family: "Pretendard";
  src: url("/fonts/pretendard-subset.woff2") format("woff2");
  font-weight: 400;
  font-display: swap;
}

Nginx·Cloudflare 설정 팁

# http 블록: 텍스트 압축 (text/html은 기본 포함)
gzip on;
gzip_vary on;
gzip_types text/css application/javascript application/json image/svg+xml;

server {
    listen 443 ssl;
    http2 on;   # nginx 1.25.1 미만은 listen 443 ssl http2;

    # 파일명에 버전이 붙는 정적 파일은 1년 캐시
    location ~* \.(css|js|woff2|webp|avif|jpg|png|svg)$ {
        add_header Cache-Control "public, max-age=31536000, immutable";
    }
}

Brotli는 gzip보다 압축률이 좋지만 Nginx에 ngx_brotli 모듈을 따로 설치해야 합니다. Cloudflare를 쓴다면 다음을 확인하세요.

• 정적 파일은 기본으로 캐시되지만 HTML은 캐시하지 않습니다. 소개형 사이트는 Cache Rules로 HTML도 캐시할 수 있지만 로그인·장바구니·관리자 경로는 반드시 제외합니다.
• Auto Minify 기능은 2024년에 종료되었으므로 압축(minify)은 빌드 단계에서 처리합니다.
• Rocket Loader는 스크립트 실행 순서를 바꿔 오류를 낼 수 있으니 켠 뒤 주요 기능을 꼭 확인합니다.
• 국내 통신망에서는 무료 요금제 트래픽이 해외 거점으로 연결되는 경우가 있으므로, 적용 전후 TTFB를 서울에서 비교 측정합니다.

서버·캐시·CDN 설정은 전자책 PART 5. 기술적 SEO에서 더 자세히 다룹니다.

SEO Check에서는 이렇게 점검합니다

무료 SEO 진단은 서울에서 측정한 응답을 기준으로 다음을 확인합니다.

• TTFB: 0.8초 이하면 통과, 0.2초 안팎이면 이상적인 수준
• HTML 크기와 압축: gzip 또는 Brotli 적용 여부
• HTTP/2: HTTP/2 이상으로 응답하는지
• 이미지: width·height 지정(CLS 예방)과 지연 로딩 사용 여부

해외에서 접속하는 구글봇과 AI 크롤러 기준의 속도는 8개 지역에서 따로 측정합니다. 읽는 법과 개선 순서는 글로벌 접속 속도 가이드에 있습니다.

정밀진단 리포트는 Lighthouse 모바일 측정으로 성능 점수, LCP, TBT(200ms 이하), CLS(0.1 이하), FCP, 전체 전송 용량과 개선 기회 목록을 제공합니다. 모바일 환경 전반은 모바일 최적화 가이드를 함께 보세요.

• 서울 기준 TTFB가 0.8초 이하다
• 대표 이미지에 lazy가 없고 fetchpriority="high"를 지정했다
• 모든 이미지에 width·height가 있다
• 불필요한 외부 스크립트를 지웠고 나머지는 defer로 불러온다
• 한글 웹폰트는 서브셋 woff2와 font-display를 쓴다
• 정적 파일은 1년 캐시하고 파일명으로 버전을 관리한다
• 서치 콘솔 코어 웹 바이탈 보고서에서 모바일이 「좋음」이다