"Core Web Vitals 90점+"라는 목표는 추상적이라 막막합니다. 워드프레스 사이트에서 가장 자주 느려지는 원인은 LCP(Largest Contentful Paint)이고, LCP의 90%는 4가지 패턴에서 나옵니다. 이 4가지를 효과 순서대로 정리합니다.
워드프레스 LCP가 느려지는 4가지 빈도순 원인
- Hero 이미지 비최적화 — 가장 큰 효과. 메인 비주얼이 압축 안 된 4MB PNG인 경우.
- 웹폰트 차단 렌더링 — Google Fonts 또는 무거운 한글 폰트가 본문 페인트를 지연.
- 플러그인·테마의 무거운 CSS/JS — Elementor 같은 빌더가 본문에 200KB CSS 주입.
- 호스팅·캐싱 부재 — TTFB가 1초 넘는 호스팅, 캐싱 플러그인 미설정.
실무에서 본 평균 분포는 위 순서가 그대로 영향력 순서입니다. 1번을 잡으면 보통 1~1.5초 단축, 2~4번은 각 0.3~0.7초 정도 단축합니다.
작업 1 — Hero 이미지 처리 (가장 큰 효과)
워드프레스 사이트의 첫 화면 메인 이미지가 LCP 요소인 경우가 압도적으로 많습니다. 다음 순서로 처리합니다.
- 이미지를 WebP로 변환 (PNG/JPG 대비 30~50% 절감)
- 실제 표시 크기로 리사이즈 (1920×1080을 1200×675로)
<img>에fetchpriority="high"속성 추가 (Chrome 우선 로딩)- preload 링크 추가:
<link rel="preload" as="image" href="..."> - 모바일/데스크탑 분기 (srcset)
이 5가지만 처리하면 LCP가 4초→2초대로 떨어지는 경우가 흔합니다.
작업 2 — 웹폰트 로딩 최적화
한글 폰트는 영문보다 파일 크기가 5~10배 큽니다. Pretendard, Noto Sans KR을 그대로 로드하면 LCP를 0.5초 이상 잡아먹는 경우가 많습니다.
font-display: swap적용 (폰트 로딩 동안 시스템 폰트로 표시)- 사용하지 않는 weight 제거 (보통 400, 600, 800만 있으면 충분)
- Subset 사용 (필요한 글자 범위만 로드)
- 중요 폰트는 preload
작업 3 — 플러그인·테마 CSS/JS 정리
Elementor, WPBakery 같은 페이지 빌더는 사용하지 않는 CSS도 모든 페이지에 로드합니다. 다음 도구로 점검할 수 있습니다.
Chrome DevTools → Coverage 탭에서 "사용되지 않는 CSS" 비율 확인. 60% 이상이면 플러그인 정리가 필요합니다.
실무 권장: WP Asset CleanUp, Perfmatters 같은 도구로 페이지별 불필요한 스크립트 차단. 단, 일부 페이지에서 필요한 것을 차단하지 않도록 주의.
작업 4 — 호스팅·캐싱 점검
TTFB(Time To First Byte)가 1초 넘으면 LCP 90점은 거의 불가능합니다. 호스팅 측정 방법:
- WebPageTest에서 측정 (실제 환경)
- TTFB가 800ms 넘으면 호스팅 변경 또는 캐싱 강화 필요
- WP Rocket, LiteSpeed Cache 같은 캐싱 플러그인 점검
- Cloudflare CDN 무료 플랜으로도 TTFB 절반 가능
측정 — PageSpeed Insights와 실측의 차이
PageSpeed Insights 점수만 보면 안 됩니다. "Lab Data"(실험실 측정)와 "Field Data"(실제 사용자 데이터)가 다를 수 있습니다. 구글이 랭킹에 쓰는 건 Field Data입니다.
점검 순서: (1) 서치콘솔의 "Core Web Vitals" 리포트, (2) PageSpeed의 "Origin Summary", (3) CrUX Report. 이 3가지가 일치하면 진짜 개선된 것이고, Lab만 좋아졌다면 사용자 환경에서는 여전히 느릴 수 있습니다.