워드프레스용 Core Web Vitals: 최적화 가이드 (2026)

워드프레스와 Core Web Vitals: 현재 상황

워드프레스에는 성능 문제가 있습니다. Core Web Vitals Technology Report(CrUX 데이터 기반)에 따르면, 워드프레스는 모바일 Core Web Vitals 통과율에서 지속적으로 Shopify, Wix, Squarespace에 뒤처져 있습니다. 2025년 말 기준으로 모바일의 워드프레스 사이트 중 약 44%만이 세 가지 Core Web Vitals를 모두 통과했습니다. 약 65%인 Shopify와 60% 이상인 Wix와 비교해 보십시오.

이것은 워드프레스가 본질적으로 느리기 때문이 아닙니다. 워드프레스 코어는 가볍습니다. 문제는 그 위에 추가되는 것들입니다. 무거운 테마, 비대한 페이지 빌더, 각기 자체 JavaScript와 CSS를 주입하는 수십 개의 플러그인, 최적화되지 않은 이미지, 그리고 서버 응답 시간이 느린 저렴한 공유 호스팅이 원인입니다.

좋은 소식은 워드프레스가 코드, 호스팅, 최적화 전략에 대한 완전한 제어권을 제공하기 때문에 숙련된 최적화가 가장 큰 차이를 만들어내는 플랫폼이라는 점입니다. 제가 작업하는 사이트들은 정기적으로 모든 페이지에서 Core Web Vitals를 통과합니다. 핵심은 어떤 워드프레스의 특정 요소가 각 지표에 영향을 미치는지 이해하고 체계적으로 해결하는 것입니다.

숫자로 보는 워드프레스 Core Web Vitals

CrUX Technology Report와 HTTP Archive는 주요 CMS의 CWV 통과율을 추적합니다. 2025년 말 기준 워드프레스의 위치는 다음과 같습니다.

출처: HTTP Archive의 CrUX Technology Report, 2025년 6월. SearchEngineJournal 분석의 INP 순위.

이 데이터에서 얻을 수 있는 핵심 인사이트는 워드프레스의 문제가 INP(85.9% 통과, 평균보다 약간 낮음)가 아니라는 점입니다. 워드프레스의 문제는 느린 TTFB로 인한 LCP입니다. 인프라 수준에서 TTFB가 처리되는 Shopify와 같은 완전 호스팅 플랫폼과 비교할 때, CrUX 데이터에 따르면 워드프레스 사이트의 32%만이 우수한 TTFB를 가지고 있습니다. 이는 플랫폼 문제가 아니라 호스팅 품질 문제입니다.

CoreDash가 모니터링하는 워드프레스 사이트 전반에 걸쳐 패턴은 일관됩니다. 최적화 전, 모바일 LCP의 중앙값은 3.5~4.5초 사이입니다. 이 가이드에서 설명한 호스팅, 캐싱 및 이미지 최적화를 구현한 후 중앙값은 1.6~2.1초로 떨어집니다. 가장 큰 영향을 미치는 단일 변경 사항은 거의 항상 페이지 캐싱이 없는 공유 호스팅에서 서버 수준 캐싱 및 CDN이 있는 매니지드 호스팅으로 업그레이드하는 것이며, 이것만으로도 일반적으로 800ms 이상의 TTFB를 200ms 미만으로 줄일 수 있습니다.

워드프레스가 Core Web Vitals에서 어려움을 겪는 이유

수정 사항을 살펴보기 전에 워드프레스 사이트가 Core Web Vitals를 통과하지 못하게 만드는 5가지 근본 원인을 이해해야 합니다. 제가 컨설팅 업무에서 보는 모든 문제는 다음 중 하나(또는 그 이상)로 귀결됩니다.

1. 페이지 빌더 팽창

Elementor, Divi, WPBakery와 같은 페이지 빌더는 모든 페이지에 엄청난 양의 추가 HTML, CSS, JavaScript를 더합니다. Elementor만 해도 워드프레스 설치에 압축되지 않은 코드를 21MB 이상 추가할 수 있습니다. 각 위젯, 애니메이션, 스타일링 옵션은 DOM 크기와 렌더링 차단 리소스의 양을 증가시킵니다.

그 결과 수백 개의 불필요한 <div> 래퍼 요소가 있는 비대한 페이지, 위젯 사용 여부에 관계없이 모든 페이지에 로드되는 다중 CSS 파일, 그리고 페이지 로드 중 메인 스레드를 차단하는 JavaScript가 생성됩니다. 이는 LCP(더 많은 렌더링 차단 리소스), INP(메인 스레드를 놓고 경쟁하는 더 많은 JavaScript) 및 CLS(빌더 CSS가 로드됨에 따른 레이아웃 재계산)에 직접적인 악영향을 미칩니다.

Gutenberg(기본 워드프레스 블록 편집기)는 더 작은 DOM 공간을 차지하는 훨씬 깔끔한 HTML을 생성합니다. 새로운 워드프레스 사이트를 구축하는 경우 무거운 페이지 빌더 대신 GeneratePress, Astra, Kadence와 같은 가벼운 테마와 함께 Gutenberg를 고려해 보십시오.

2. 플러그인 과부하

평균적인 워드프레스 사이트에는 20~30개의 활성 플러그인이 있습니다. 각 플러그인은 해당 플러그인이 사용되지 않는 페이지에도 자체 CSS 및 JavaScript를 주입할 수 있습니다. 홈페이지에 스크립트를 로드하는 문의 양식 플러그인. 블로그 게시물에 로드되는 WooCommerce 스크립트. 한 페이지에서만 사용하는데도 모든 곳에서 로드되는 슬라이더 플러그인 등이 그 예입니다.

저는 사용하지 않는 플러그인 스크립트를 제거하여 전체 JavaScript를 40% 이상 줄인 워드프레스 사이트를 감사한 적이 있습니다. 해결책이 반드시 플러그인을 완전히 제거하는 것은 아닙니다. 핵심은 조건부 로드입니다. 즉, 각 플러그인의 애셋이 실제로 필요한 페이지에서만 로드되도록 하는 것입니다. Perfmatters 및 Asset CleanUp과 같은 플러그인을 사용하면 로드할 스크립트 및 스타일을 페이지별로 제어할 수 있습니다.

3. 최적화되지 않은 이미지

워드프레스는 기본적으로 이미지 최적화를 강제하지 않습니다. 콘텐츠 편집자는 카메라에서 직접 3000x2000 픽셀 사진을 업로드하며, 테마가 800픽셀 너비로만 표시하는 경우에도 워드프레스는 이를 전체 해상도로 제공합니다. 대부분의 워드프레스 페이지에서 LCP 요소는 이미지이며, 최적화되지 않은 히어로 이미지는 LCP 실패의 가장 흔한 단일 원인입니다.

워드프레스 5.8 이상에서는 기본 WebP 지원이 추가되었고 워드프레스 5.5 이상에서는 기본 지연 로딩이 추가되었지만 이러한 기능에는 적절한 구성이 필요합니다. 많은 테마와 플러그인이 이를 재정의하거나 자체적인(종종 더 안 좋은) 버전을 구현합니다. 완전한 전략은 Core Web Vitals를 위한 이미지 최적화 가이드를 참조하십시오.

4. 느린 호스팅 및 서버 응답

서버의 Time to First Byte(TTFB)는 LCP의 하한선을 설정합니다. 응답하는 데 800ms가 걸리는 서버는 아무리 프론트엔드 최적화를 하더라도 보상할 수 없습니다. 수백 개의 사이트가 단일 서버를 공유하는 저렴한 공유 호스팅은 워드프레스 사이트에서 좋지 않은 TTFB의 가장 흔한 원인입니다.

워드프레스는 모든 페이지 요청마다 PHP를 실행하고 MySQL 데이터베이스를 쿼리하는 동적 CMS입니다(캐싱이 구성되지 않은 경우). 페이지 캐싱이 없으면 워드프레스는 정적 사이트보다 본질적으로 느립니다. 적절한 캐싱과 고품질 호스트를 사용하면 TTFB를 200ms 미만으로 줄일 수 있습니다. 그렇지 않으면 500ms에서 1500ms가 일반적입니다. 자세한 내용은 Time to First Byte 최적화 가이드에서 알아보십시오.

5. 폰트 로딩 문제

많은 워드프레스 테마는 Google 서버에서 Google Fonts를 로드하는데, 이는 폰트 다운로드를 시작하기 전에 DNS 조회 및 외부 도메인에 대한 연결을 요구합니다. 이는 텍스트 렌더링을 지연시키고(텍스트 기반 LCP 요소의 LCP 손상), 웹 폰트가 교체되어 fallback 폰트를 대체할 때 스타일이 적용되지 않은 텍스트가 번쩍이는 현상(FOUT)을 일으켜 CLS를 유발할 수 있습니다.

해결 방법: 폰트를 직접 호스팅(self-host)하고 레이아웃 변경을 최소화하기 위해 적절하게 일치하는 fallback 폰트와 함께 font-display: swap 또는 font-display: optional을 사용하십시오.

워드프레스에서 LCP 수정하기

Largest Contentful Paint는 주요 콘텐츠가 얼마나 빨리 표시되는지 측정합니다. 워드프레스에서 LCP 실패는 거의 항상 이미지, 렌더링 차단 리소스 또는 느린 서버 응답으로 인해 발생합니다. LCP 수정을 위한 우선순위는 다음과 같습니다.

LCP 요소 식별

PageSpeed Insights를 통해 페이지를 실행하고 "진단" 섹션에서 "Largest Contentful Paint 요소"를 찾아보십시오. 대부분의 워드프레스 페이지에서 이는 히어로 이미지, 특성 이미지 또는 첫 번째 큰 텍스트 블록입니다. LCP 요소가 무엇인지 아는 것은 최적화 전략을 결정합니다.

LCP 이미지 사전 로드(Preload)

LCP 요소가 이미지인 경우 테마의 <head>에 preload 힌트를 추가합니다. 워드프레스에서는 테마의 functions.php를 통해 이를 추가할 수 있습니다.

또한 LCP 이미지의 <img> 태그에 직접 fetchpriority="high"를 추가하십시오. 워드프레스 6.3 이상에서는 첫 번째 콘텐츠 이미지에 대해 이 작업을 자동으로 수행하지만, 테마에서 제대로 작동하는지 확인하십시오. 전체 전략은 LCP 이미지를 사전 로드하는 방법을 참조하십시오.

렌더링 차단 리소스 제거

워드프레스 테마와 플러그인은 종종 렌더링을 차단하는 <head>에 CSS와 JavaScript를 대기시킵니다(enqueue). 성능 플러그인을 사용하여 중요하지 않은 JavaScript를 연기(defer)하고 중요하지 않은 CSS를 비동기적으로 로드하십시오. 가장 효과적인 옵션은 다음과 같습니다.

• WP Rocket: 사용자 상호작용 전까지 JavaScript 실행 지연, critical CSS 자동 생성
• FlyingPress: 유사한 연기 및 critical CSS 기능을 갖춘 가벼운 대안
• Perfmatters: 세분화된 페이지별 스크립트 관리, 사용하지 않는 기능 비활성화
• 자체 WP Core Web Vitals 플러그인: LCP 감지 및 고급 이미지 타이밍 기능이 포함되어 CWV 최적화를 위해 특별히 설계됨

수동 제어의 경우 JavaScript를 연기하는 14가지 방법 및 critical CSS 생성 및 사용 방법을 참조하십시오.

페이지 캐싱 활성화

페이지 캐싱은 각 페이지의 완전히 렌더링된 HTML을 저장하므로 방문할 때마다 워드프레스가 PHP를 실행하고 데이터베이스를 쿼리할 필요가 없습니다. 이는 TTFB를 획기적으로 줄여 LCP를 직접적으로 개선합니다. 대부분의 고품질 매니지드 워드프레스 호스트(Kinsta, SiteGround, WP Engine, Cloudways)는 서버 수준 캐싱을 포함합니다. 귀하의 호스트에 포함되어 있지 않다면 캐싱 플러그인을 설치하십시오.

또한 방문자와 가까운 엣지(edge) 위치에서 캐시된 페이지를 제공하도록 CDN을 구성하십시오. 성능을 위한 Cloudflare 구성 방법을 참조하십시오.

워드프레스에서 INP 수정하기

Interaction to Next Paint는 사이트가 클릭, 탭 및 키 누름에 얼마나 빠르게 반응하는지 측정합니다. 워드프레스 사이트는 메인 스레드의 과도한 JavaScript 때문에 INP에 실패합니다. 가장 큰 원인은 다음과 같습니다.

플러그인 JavaScript 문제

설치된 모든 플러그인은 페이지가 로드될 때마다 실행되는 JavaScript를 추가할 수 있습니다. 방문자가 기능과 상호작용하지 않더라도 해당 기능의 JavaScript는 여전히 메인 스레드 시간을 놓고 경쟁합니다. 방문자가 버튼을 클릭할 때, 메인 스레드가 여유로워질 때까지 브라우저는 응답할 수 없습니다.

플러그인을 가차 없이 감사하십시오. 모든 플러그인에 대해 '이것이 이 페이지 유형에 로드되어야 하는가?'라고 질문해 보십시오. Chrome DevTools Coverage 탭을 사용하여 각 페이지에서 얼마나 많은 JavaScript가 사용되지 않는지 확인하십시오. 그런 다음 스크립트 관리자 플러그인을 사용하여 필요하지 않은 페이지에서 특정 스크립트를 비활성화하십시오.

WooCommerce 스크립트 관리

WooCommerce는 워드프레스에서 INP 문제에 가장 크게 기여하는 요소 중 하나입니다. 기본적으로 WooCommerce는 커머스 기능이 없는 블로그 게시물과 정적 페이지를 포함한 모든 페이지에 자체 JavaScript와 CSS를 로드합니다. Disable WooCommerce Bloat 또는 Perfmatters와 같은 플러그인을 사용하여 상점이 아닌 페이지에서 WooCommerce 애셋이 로드되는 것을 방지하십시오.

서드파티 스크립트 연기(Defer) 및 지연(Delay)

Google Analytics, Facebook Pixel, Google Tag Manager, 채팅 위젯 및 마케팅 도구는 모두 메인 스레드를 차단하는 JavaScript를 추가합니다. 가장 효과적인 전략은 첫 번째 사용자 상호작용(스크롤, 클릭 또는 키 누름)이 발생할 때까지 이러한 스크립트를 지연(delay)시키는 것입니다. 이렇게 하면 서드파티 스크립트가 초기 페이지 반응성에 전혀 영향을 미치지 않습니다.

WP Rocket의 "Delay JavaScript Execution" 기능은 이 작업을 자동으로 수행합니다. JavaScript 연기하기 가이드를 참조하여 수동으로 구현할 수도 있습니다.

워드프레스에서 CLS 수정하기

Cumulative Layout Shift는 예상치 못한 콘텐츠 이동을 측정합니다. 워드프레스 사이트는 누락된 이미지 크기, 폰트 교체, 동적으로 주입된 콘텐츠로 인해 CLS에 실패합니다.

이미지 크기 설정

모든 <img> 태그에는 명시적인 width 및 height 속성이 필요하므로 브라우저가 이미지를 로드하기 전에 올바른 공간을 예약할 수 있습니다. 워드프레스는 버전 5.5부터 이를 자동으로 추가해왔지만, 많은 테마가 이 동작을 재정의하거나 크기를 생략한 사용자 지정 이미지 마크업을 사용합니다. 테마의 이미지 템플릿을 확인하고 크기가 존재하는지 확인하십시오.

광고 및 동적 콘텐츠를 위한 공간 예약

페이지가 로드된 후 콘텐츠를 주입하는 광고 슬롯, 쿠키 동의 배너, 이메일 가입 팝업, 알림 표시줄은 워드프레스 사이트에서 CLS를 유발하는 가장 일반적인 원인입니다. CSS min-height 선언을 사용하여 이러한 요소에 대한 명시적인 공간을 예약하여 요소가 나타날 때 주변 콘텐츠가 이동하지 않도록 하십시오.

폰트 관련 레이아웃 변경 수정

웹 폰트가 로드되어 fallback 폰트를 교체할 때 텍스트가 다시 흐르고 주변 요소가 이동할 수 있습니다. 해결책은 두 가지입니다. 폰트를 직접 호스팅(self-host)하여(외부 DNS 조회를 제거함) CSS를 font-display: optional을 사용하도록 구성하거나, CSS size-adjust 속성을 사용하여 세심하게 일치시킨 fallback을 사용하는 것입니다. 이렇게 하면 웹 폰트가 늦게 로드되더라도 텍스트가 이동하지 않습니다. 전체 가이드는 CLS 최적화 가이드를 참조하십시오.

워드프레스 호스팅과 Core Web Vitals

호스팅 제공업체는 워드프레스 사이트의 성능 상한선을 설정합니다. 주요 호스팅 유형이 Core Web Vitals에 미치는 영향은 다음과 같습니다.

TTFB가 지속적으로 400ms 이상인 경우 아무리 프론트엔드 최적화를 하더라도 우수한 LCP를 얻을 수 없습니다. 호스팅을 먼저 업그레이드하십시오. SiteGround, Kinsta, Cloudways와 같은 매니지드 워드프레스 호스트는 TTFB를 획기적으로 줄여주는 서버 수준 캐싱, PHP 8.x 및 CDN 통합을 제공합니다.

CrUX 데이터는 이것이 워드프레스의 가장 큰 문제임을 확인해 줍니다. 인프라가 관리되는 Shopify 및 Wix와 같은 완전 호스팅 플랫폼과 비교할 때 워드프레스 사이트의 32%만이 우수한 TTFB를 가지고 있습니다. CoreDash 필드 데이터도 동일한 패턴을 보여줍니다. 공유 호스팅 환경의 워드프레스 사이트는 평균 900ms에서 1400ms의 p75 TTFB를 갖습니다. 동일한 사이트가 서버 수준 캐싱을 갖춘 매니지드 호스팅으로 이동하면 120ms에서 250ms로 떨어집니다. 이 단일 변경만으로도 다른 최적화 없이 종종 LCP가 "나쁨"에서 "좋음"으로 이동합니다.

페이지 빌더: 성능 비교

페이지 빌더 선택(또는 사용하지 않음)은 워드프레스의 Core Web Vitals에 영향을 미치는 가장 큰 단일 아키텍처 결정입니다. 제가 감사 과정에서 지속적으로 관찰한 내용은 다음과 같습니다.

이미 Elementor나 Divi를 사용 중이고 마이그레이션할 수 없는 경우, 해당 빌더의 "Optimized DOM Output" 및 "Optimized Asset Loading" 기능을 활성화하고, 사용하지 않는 위젯과 애니메이션을 제거하며, WP Rocket과 같은 캐싱 플러그인을 사용하여 추가 오버헤드를 보완하십시오.

워드프레스 사이트의 CoreDash 필드 데이터도 같은 이야기를 합니다. Gutenberg 및 가벼운 테마로 구축된 사이트는 일관되게 2.0초 미만의 모바일 LCP 중앙값을 달성합니다. 최적화 이전의 Elementor 사이트는 일반적으로 3.8에서 5.2초 사이의 모바일 LCP 중앙값을 보이며, 이 차이는 거의 전적으로 추가적인 렌더링 차단 CSS 및 JavaScript에 기인합니다. 최적화 후(critical CSS, 지연된(deferred) JS, 감소된 DOM) Elementor 사이트는 2.0에서 2.8초에 도달할 수 있지만 플러그인 및 빌더 업데이트로 인해 종종 다시 비대해지기 때문에 지속적인 유지 보수가 필요합니다.

워드프레스 Core Web Vitals 최적화 체크리스트

다음은 제가 Core Web Vitals를 위해 워드프레스 사이트를 최적화할 때 사용하는 체계적인 접근 방식입니다. 이 순서대로 작업하십시오.

인프라 (가장 먼저 수행)

• 서버 수준 캐싱 및 PHP 8.x를 지원하는 매니지드 워드프레스 호스팅으로 업그레이드
• CDN 구성 (Cloudflare 설정 가이드)
• 페이지 캐싱 활성화 (서버 수준 또는 WP Rocket / LiteSpeed Cache를 통해)
• GZIP 또는 Brotli 압축 활성화

테마 및 빌더

• 가능한 경우 가벼운 테마(GeneratePress, Astra, Kadence)로 전환
• 페이지 빌더를 사용하는 경우 최적화된 DOM 출력 및 애셋 로딩 활성화
• 사용하지 않는 테마 기능, 위젯 및 애니메이션 제거
• 워드프레스 코어, 테마 및 모든 플러그인을 최신 버전으로 업데이트

이미지

• fetchpriority="high"를 사용하여 LCP 이미지 사전 로드(Preload)
• ShortPixel, Imagify 또는 Smush를 사용하여 이미지를 WebP 또는 AVIF로 변환
• 적절한 srcset 및 sizes 속성으로 반응형 이미지 제공
• 모든 <img> 태그에 명시적인 width 및 height 추가
• 스크롤 없이 볼 수 있는(above the fold) 이미지는 지연 로딩(lazy load)하지 마십시오. (LCP가 손상됨)

JavaScript 및 CSS

• 중요하지 않은 JavaScript 연기(Defer)
• 사용자 상호작용 전까지 서드파티 스크립 지연(Delay)
• critical CSS 생성 및 인라인 처리
• Perfmatters 또는 Asset CleanUp을 사용하여 페이지별로 사용하지 않는 플러그인 스크립트 제거
• 상점이 아닌 페이지에서 WooCommerce 애셋 비활성화

폰트

• Google Fonts 직접 호스팅(Self host)
• 중요한 폰트 파일 사전 로드(Preload)
• font-display: swap 또는 optional 사용
• 최대 2개의 폰트 패밀리로 제한

모니터링

• 지속적으로 필드 데이터를 추적하기 위해 CoreDash Real User Monitoring 설정
• 매주 Google Search Console Core Web Vitals 보고서 모니터링
• 모든 테마 업데이트, 플러그인 변경 또는 콘텐츠 업데이트 후 다시 테스트

모든 최적화 영역을 다루는 완전한 크로스 플랫폼 체크리스트는 Ultimate Core Web Vitals 체크리스트를 참조하십시오.

워드프레스에서 Core Web Vitals 측정

워드프레스에는 기본 Core Web Vitals 보고 기능이 없습니다. 성능을 측정하려면 외부 도구가 필요합니다.

• Google Search Console: 실제 CrUX 필드 데이터를 기반으로 전체 사이트에서 어떤 페이지가 통과하고 실패하는지 보여줍니다. "경험(Experience)" 아래에 있는 "Core Web Vitals" 보고서를 확인하십시오.
• PageSpeed Insights: 필드 데이터(CrUX) 및 랩 데이터(Lighthouse)로 개별 URL을 테스트합니다. 이를 사용하여 특정 페이지를 진단하십시오.
• CoreDash: 페이지, 기기, 국가 및 개별 요소별로 분석된 실시간 필드 데이터를 제공하는 Real User Monitoring(RUM)입니다. 28일 단위의 CrUX 데이터 창과 달리 CoreDash는 변경 사항의 즉각적인 영향을 보여줍니다.
• Chrome DevTools: 성능(Performance) 패널을 사용하여 INP를 차단하는 긴 작업을 식별하고 Coverage 탭을 사용하여 사용하지 않는 JavaScript 및 CSS를 찾으십시오.

이러한 도구에 대한 완전한 비교는 측정 도구 비교 표가 포함된 Core Web Vitals 개요를 참조하십시오.

워드프레스 Core Web Vitals의 흔한 실수

수백 개의 워드프레스 사이트를 감사한 제 경험에 따르면 가장 자주 볼 수 있는 실수는 다음과 같습니다.

• LCP 이미지 지연 로딩. 워드프레스는 기본적으로 이미지에 loading="lazy"를 추가합니다. 히어로 이미지가 LCP 요소인 경우 이를 지연 로딩(lazy loading)하면 로드가 지연됩니다. LCP 이미지가 지연 로딩에서 제외되고 fetchpriority="high"를 갖는지 확인하십시오.
• 너무 많은 최적화 플러그인. WP Rocket, Autoptimize, LiteSpeed Cache 및 W3 Total Cache를 동시에 설치하면 충돌이 발생합니다. 하나의 캐싱/최적화 플러그인을 선택하고 적절하게 구성하십시오.
• 필드 데이터 무시. Lighthouse 점수가 95점이라고 해서 Core Web Vitals를 통과한다는 의미는 아닙니다. Google은 실제 방문자의 필드 데이터를 사용합니다. 실제 기기를 사용하는 실제 방문자는 완전히 다른 경험을 할 수 있습니다. 항상 Search Console을 확인하거나 RUM을 사용하십시오.
• 업데이트 후 테스트 안 함. 테마 또는 플러그인 업데이트가 소리 없이 Core Web Vitals를 퇴보시킬 수 있습니다. 초기 최적화 후뿐만 아니라 지속적으로 모니터링하십시오.