Core Web Vitals：カスタムコードが100を獲得し、WordPressが60を超えることが少ない理由

手書きのサイトが Core Web Vitals に合格する一方で、ビルダー製サイトが1点を巡って苦闘するのには構造的な理由があります。きれいなコードは、指標を壊す無駄な重量を抱え込まないのです。Core Web Vitals は Google が認めたランキング要因であり、ここに大半の開発者が口にしない事実があります。選んだプラットフォームが、最適化を始める前の段階で基準スコアの約80%を決めてしまうのです。カスタム PHP は最小限の労力で100点に届きますが、WordPress はキャッシュプラグインを入れても40〜60点にとどまりがちです。私はその両方を構築し最適化してきたので、これは机上の空論ではありません。実際の数値、実際のコード、実際のクライアント成果とともに、その理由を正確にお見せします。

Core Web Vitalsを通過するビジネスケース

コードに入る前に、影響を理解してください。Googleのデータが示すこと：

• Core Web Vitalsを通過するサイトはユーザー離脱が24％減少します。
• LCPの0.5秒改善はコンバージョンを12～15％増加させる可能性があります（Googleケーススタディ）。
• ページ体験は現在、2つのページの関連性が類似している場合のタイブレーカーです。

プラットフォームの選択は開発者の利便性だけの問題ではありません – 収益とランキングの直接的なドライバーです。

生の数値：カスタムPHP vs WordPress（同じサーバー）

同一ホスティング（Hostinger VPS、2 vCPU、2GB RAM、NVMeストレージ）で管理テストを実行しました。2つのウェブサイト：

• サイト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） – 応答性を測定。良好：200ミリ秒未満（2024年にFIDを置き換え）。
• CLS（Cumulative Layout Shift） – 視覚的安定性を測定。良好：0.1未満。
• TTFB（Time To First Byte） – サーバー応答。良好：600ミリ秒未満（非公式だが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のカバレッジタブを使用して未使用の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`オーバーヘッドがないため、クエリは150ミリ秒ではなく5～15ミリ秒で戻ります。追加の調整：

• 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を読み込みます。それは半分のメガバイトの未使用コードです。
• キャッシュプラグインは役立ちますが、根底にある肥大化を除去することはできません – すでに肥大化した出力をキャッシュするだけです。
• サードパーティのテーマはフレームワーク全体（Bootstrap、Tailwind）をバンドルしています – レンダリングをブロックし続ける未使用CSSが90％です。

一時的にLighthouseで90を獲得しても、プラグインの更新や新しいテーマによって一晩で45に落ちる可能性があります。カスタムPHPでは、パフォーマンスは決定的です – 変更しない限り変わりません。

2つの実際のクライアント変革

ケーススタディ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）で収集されました。結果はコンテンツとホスティングによって異なる場合があります。