Core Web Vitals: 맞춤 코드가 100점을 받고 WordPress는 60점을 넘기 어려운 이유

손으로 짠 사이트가 Core Web Vitals를 통과하는 반면 빌더 사이트는 한 점을 두고 다투는 데에는 구조적인 이유가 있습니다. 깔끔한 코드는 지표를 무너뜨리는 군더더기를 애초에 지고 있지 않기 때문입니다. Core Web Vitals는 Google이 확인한 순위 요소이며, 여기 대부분의 개발자가 입 밖에 내지 않는 사실이 있습니다. 여러분이 고른 플랫폼이, 무엇을 최적화하기도 전에 기준 점수의 약 80%를 결정합니다. 맞춤형 PHP는 최소한의 노력으로 100점에 도달할 수 있지만, WordPress는 캐시 플러그인을 얹어도 흔히 40~60점대에 머뭅니다. 저는 둘 다 만들고 최적화해 봤으니 이것은 이론이 아닙니다. 실제 수치, 실제 코드, 실제 고객 성과와 함께 그 이유를 정확히 보여드리겠습니다.

Core Web Vitals 통과의 비즈니스 사례

코드에 들어가기 전에 영향을 이해하세요. Google 데이터에 따르면:

• Core Web Vitals를 통과하는 사이트는 사용자 이탈이 24% 감소합니다.
• LCP 0.5초 개선은 전환율을 12–15% 증가시킬 수 있습니다(Google 사례 연구).
• 페이지 경험은 이제 두 페이지의 관련성이 비슷할 때 승부 결정 요소입니다.

플랫폼 선택은 개발자의 편의성만이 아닙니다 – 수익과 순위의 직접적인 동인입니다.

실제 숫자: 맞춤 PHP vs WordPress (동일 서버)

동일한 호스팅(Hostinger VPS, 2 vCPU, 2GB RAM, NVMe 스토리지)에서 통제된 테스트를 실행했습니다. 두 웹사이트:

• 사이트 A: 맞춤 PHP/HTML, 프레임워크 없음, 최소 CSS/JS, 수동 최적화.
• 사이트 B: 새로운 WordPress 6.7 + Astra 테마 + 5가지 필수 플러그인(Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

847KB의 JavaScript가 문제입니다. WordPress는 jQuery, 블록 편집기, 플러그인 스크립트 및 테마 자산을 – 사용하지 않더라도 – 로드합니다. Google의 Lighthouse는 이 모든 것을 측정하며, 모든 킬로바이트는 LCP와 INP에 추가됩니다.

Core Web Vitals 설명 (2026년 임계값)

Google은 페이지 경험이 모바일과 데스크톱 모두에서 순위 신호임을 확인했습니다. 2026년 임계값은 다음과 같습니다:

• LCP (Largest Contentful Paint) – 로딩 속도 측정. 좋음: 2.5초 미만.
• INP (Interaction to Next Paint) – 응답성 측정. 좋음: 200ms 미만(2024년 FID 대체).
• CLS (Cumulative Layout Shift) – 시각적 안정성 측정. 좋음: 0.1 미만.
• TTFB (Time To First Byte) – 서버 응답. 좋음: 600ms 미만(비공식적이지만 Google이 사용).

이러한 지표를 통과하지 못한 사이트는 더 빠른 경쟁자 아래로 밀려납니다 – 더 많은 백링크가 있더라도 마찬가지입니다.

맞춤 PHP가 완벽한 100을 달성하는 방법 (실제 코드 + 에지 기술)

다음은 Lighthouse 점수 100을 보장하기 위해 모든 맞춤 빌드에서 수행하는 정확한 작업입니다.

1. 중요한 자산 사전 로드

브라우저가 HTML을 구문 분석하기 전에 무엇이 가장 중요한지 알려줍니다.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. 접힌 부분 위 CSS 인라인(FCP 절반으로 줄이기)

표시 영역에 필요한 스타일만 추출합니다. Chrome의 Coverage 탭을 사용하여 사용하지 않는 CSS를 찾습니다.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. srcset 및 WebP로 반응형 이미지 제공

대부분의 사이트는 데스크톱 크기 이미지를 모바일에 제공합니다 – 이는 LCP에 큰 불이익입니다. `srcset`을 사용하여 적절한 크기의 이미지를 제공합니다.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. 서버 응답 최적화(TTFB)

OPcache가 활성화된 PHP‑FPM, GZIP 압축 및 데이터베이스 인덱싱을 사용합니다. WordPress `wp_query` 오버헤드가 없으면 쿼리가 150ms가 아닌 5–15ms 만에 반환됩니다. 추가 조정:

• Keep‑Alive 및 HTTP/2 활성화.
• CDN(Cloudflare 또는 Bunny.net)을 사용하여 정적 자산 캐싱.
• 필요한 경우 데이터베이스를 별도 서버로 이동하거나 Redis를 객체 캐싱에 사용.

5. 레이아웃 이동 제거(CLS = 0.01)

모든 이미지, 비디오 및 광고 슬롯에는 명시적인 `width` 및 `height` 속성이 제공됩니다. `font-display: swap`으로 글꼴 공간을 예약합니다.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. 중요하지 않은 JavaScript 지연

모든 외부 스크립트에 `defer` 또는 `async`를 사용하고 분석을 사용자 상호 작용 후에 로드하도록 이동합니다.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. 접힌 부분 아래 이미지에 `loading="lazy"` 사용

초기에 보이지 않는 이미지는 지연 로드해야 합니다. 이는 대역폭을 절약하고 LCP를 가속화합니다.

WordPress가 이러한 숫자를 쉽게 따라잡을 수 없는 이유

• 모든 플러그인은 종종 `async` 또는 `defer` 없이 자체 CSS/JS를 추가합니다. "최적화된" 플러그인도 오버헤드를 추가합니다.
• 블록 편집기는 단순한 페이지를 사용하는 경우에도 500KB 이상의 JavaScript를 로드합니다. 이는 사용하지 않는 코드 0.5MB입니다.
• 캐싱 플러그인은 도움이 되지만 근본적인 비대함을 제거할 수는 없습니다 – 이미 비대한 출력을 캐싱할 뿐입니다.
• 타사 테마는 전체 프레임워크(Bootstrap, Tailwind)를 번들로 제공합니다 – 렌더링을 계속 차단하는 90%의 사용하지 않는 CSS입니다.

일시적으로 Lighthouse에서 90점을 받더라도 플러그인 업데이트나 새 테마로 인해 하룻밤 사이에 45점으로 떨어질 수 있습니다. 맞춤 PHP를 사용하면 성능은 결정적입니다 – 변경하지 않는 한 변하지 않습니다.

두 가지 실제 클라이언트 변환 사례

사례 연구 1: WooCommerce 보석 가게 → 맞춤 PHP

보석 가게의 WooCommerce 사이트는 Lighthouse에서 43점(모바일)을 받았습니다. 12개의 활성 플러그인, 비대한 테마, 4.2초의 로드 시간. Stripe Checkout이 있는 맞춤 PHP 스토어로 마이그레이션한 후:

• Lighthouse 점수: 43 → 98.
• 모바일 로드 시간: 4.2초 → 0.9초.
• 전환율: 1.8% → 3.4% (+89%).
• 평균 주문 가치 22% 증가(더 빠른 체크아웃이 업셀을 장려).

사례 연구 2: 500개 이상 페이지의 부동산 사이트

부동산 중개업체의 WordPress 사이트는 페이지 로드 시간 3.5초, CLS 0.28(나쁨)이었습니다. 경량 템플릿, 인라인 중요 CSS, 사전 로드된 히어로 이미지를 사용하여 프런트엔드를 맞춤 PHP 사이트로 재구축했습니다.

• LCP: 3.1초 → 0.9초.
• CLS: 0.28 → 0.02.
• 이탈률이 58%에서 37%로 감소.
• 문의 양식 제출이 60일 이내에 41% 증가.

페이지 빌더의 숨겨진 비용: Wix, Squarespace, Shopify

WordPress만이 아닙니다. 모든 드래그 앤 드롭 플랫폼은 기본값이 좋지 않아 어려움을 겪습니다:

• Wix/Squarespace: 인라인 스타일이 여기저기, 거대한 DOM 크기, 중요 CSS 제어 불가. Lighthouse 모바일 평균 점수: 30–50.
• Shopify: Wix보다 낫지만 테마는 무거운 JavaScript와 외부 글꼴을 로드합니다. 평균 점수: 60–75.
• Webflow: 최적화 가능하지만 전문 지식이 필요하며 손으로 작성한 PHP에 비해 여전히 비대한 코드를 출력합니다.

브라우저에 도달하는 모든 바이트를 완전히 제어할 수 있는 것은 맞춤 PHP뿐입니다.

시작하는 방법 (개발자가 아닌 경우에도)

모든 것을 처음부터 작성할 필요는 없습니다. 저는 각 웹사이트를 수동으로 구축하므로 100% 맞춤형 코드베이스를 얻을 수 있습니다. 결과: 스크린샷을 찍어 신뢰 신호로 사용할 수 있는 Lighthouse 점수입니다. 정적 사이트 생성기(Hugo, Eleventy)로 시작한 다음 동적 기능을 위해 나중에 PHP를 추가할 수도 있습니다.

행동 계획: 오늘 사이트를 100점으로 만들기

1. PageSpeed Insights(모바일)에서 현재 사이트 테스트. LCP, INP, CLS를 기록하세요.
2. 쉬운 문제 해결: 이미지 압축, 캐싱 활성화, 사용하지 않는 플러그인 제거.
3. 70점 미만이면 플랫폼 마이그레이션을 고려하세요. 맞춤 PHP 사이트의 ROI는 더 높은 전환율과 낮은 호스팅 비용으로 6~12개월 내에 회수되는 경우가 많습니다.
4. 또는 저를 고용하세요. 100점을 받는 맞춤 PHP 사이트를 구축해 드립니다 – 보장합니다.

최종 요약: 플랫폼 선택이 승부의 80%이다

모든 사이트를 최적화할 수 있지만 맞춤 PHP로 시작하면 엄청난 선발 이점을 얻을 수 있습니다. WordPress는 자체 아키텍처와 끊임없이 싸워야 합니다. Wix와 Squarespace는 느린 템플릿에 가둡니다. 맞춤 PHP는 완전한 제어권을 제공합니다. 숫자가 말해줍니다.

기본적으로 Lighthouse 96–100점을 받고 페이지 빌더를 능가하는 웹사이트를 원한다면 이야기합시다.

모든 테스트 데이터는 Lighthouse 12.0(모바일 시뮬레이션)을 사용하여 Hostinger VPS(2 vCPU, 2GB RAM)에서 수집되었습니다. 결과는 콘텐츠 및 호스팅에 따라 다를 수 있습니다.