Core Web Vitalsの最適化を論じるほとんどのガイドは、実施すべき修正を12個列挙する。圧倒的である。実際には、この3つを修正すれば結果の80%を得られる。それで十分だ。
このガイドで習得できること
当ガイドは、Core Web Vitals最適化の優先順位を効率的に判断する方法を示す。自社サイトの特性において最も重要なメトリクスを認識する。結果を左右する3つの修正を習得する。約15分で成果を測定する方法を修得する。
本稿は理論ではなく、専任のパフォーマンスエンジニアを配置していない小規模企業と代理店で実証された手法である。
Core Web Vitalsが重要である理由
Core Web Vitalsはサイトの読み込み速度と安定性を測定する。Googleはこれをランキング要因に組み込んでいる。さらに重要なことに、低速なサイトは顧客離脱につながる。
3つのメトリクスから構成される。
Largest Contentful Paint（LCP） は読み込み速度を測定する。メインコンテンツが表示されるまでの時間を計測する。良好値は2.5秒以下である。小規模企業の典型的なサイトは3.5～4.5秒に達する。
Interaction to Next Paint（INP） はレスポンス性を測定する。ユーザーのクリックやタップに対するサイトの応答速度を示す。良好値は200ミリ秒以下である。JavaScript駆動型のサイトはしばしば400～600ミリ秒に達する。
Cumulative Layout Shift（CLS） は視覚的安定性を測定する。読み込み中のページのレイアウト変動を捉える。良好値は0.1未満である。広告や遅延読み込み画像を含むサイトは0.3以上に達することがある。
大多数のサイトは、これら3つのうち最低1つで不合格である。平均的な小規模企業サイトは2つで不合格だ。
HubSpot 2024年調査によると、検索結果の最初のページを超えてスクロールするユーザーは全体の25%に過ぎない。Core Web Vitalsはコンテンツの品質が同等である場合の決定要因となる。競合と同じコンテンツを保有していても、速度が勝れば検索順位は高まる。
既存アドバイスの限界
Core Web Vitals最適化を検索すれば、包括的なガイドが出現する。12～15の戦術が列挙される。あらゆるエッジケースに対応している。
これらのガイドは正確である。同時に、実用的ではない。
タコス店の経営者は15個のパフォーマンス最適化に時間を割けない。30のクライアントサイトを管理する代理店は、すべてのJavaScriptファイルを手作業で監査できない。
包括的なガイドは本質を見落としている。必要なのは、最初に何を直すべきかを知ることだ。何が実数値を動かすのかを知ることだ。
既存のSEOツールはこれを悪化させる。データダンプを提供するだけだ。優先順位なしに100個の問題を得る。文脈なしに技術用語に直面する。どの問題が重要かを理解するのに数時間を要する。
Lighthouseはパフォーマンススコアを与える。画像かJavaScriptのどちらを最初に直すべきか指示しない。PageSpeed Insightsは遅い部分を示す。その修正が不合格から合格に変わるかどうかは教えない。
実装効果のある3つの修正
修正1：LCP要素を最適化する
LCPはほぼ常に最大の課題である。同時に、修正が最も容易だ。
LCP要素は通常、ヒーロー画像またはメインの見出しである。多くのサイトではこれを低速で読み込む。原因は画像が大きく圧縮されていないからだ。
Site Auditは当社のサイトでこれを検出した。当社のサイトは1200ピクセル幅でのみ表示される2.4MBのヒーロー画像を保有していた。画像は4000ピクセルで撮影されていた。余剰ピクセルは何の役にも立たず、読み込みを遅延させていた。
実施方法は以下の通りだ。
ヒーロー画像をWebP形式に変換する。 WebPファイルはJPEGより30%小さく、品質は同等である。SquooshやCloudConvertなどの無料ツールを活用できる。最新ブラウザはWebPをサポートしている。SafariはWebP対応を2020年に追加。Edgeは2018年に追加した。
HTMLは以下の通り：
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Your hero image" width="1200" height="800">
</picture>ブラウザがWebPをサポートしていれば当該形式を読み込む。レガシーブラウザではJPEGにフォールバックする。
実際の表示サイズに合わせて画像をリサイズする。 ヒーロー画像が1200ピクセル幅で表示されるなら、4000ピクセル画像をアップロードしてはならない。デスクトップは1200ピクセル、モバイルは800ピクセルを使用する。画面幅に応じて異なるサイズを配信する。
コードは以下の通り：
<img
src="hero-1200.webp"
srcset="hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 800px, 1200px"
alt="Your hero image"
width="1200"
height="800"
>画像タグにwidthとheight属性を付与する。 これにより、ブラウザに確保する領域を通知する。画像読み込み中のレイアウトシフトを防止する。最新ブラウザはこれらの属性を用いてアスペクト比を自動計算する。
Content Delivery Network（CDN）を導入する。 CDNは訪問者に最も近いサーバーから画像を配信する。CloudFlareとBunnyCDNは両方とも無料レベルを提供している。CDNは通常、画像読み込み時間を40～60%削減する。
LCP画像にfetchpriority=“high”を追加する。 これはブラウザに対し、当該画像を他のリソースに優先して読み込むよう指示する。指示ではなくヒントであり、ブラウザは可能な限りこれを尊重する。
<img
src="hero.webp"
alt="Your hero image"
width="1200"
height="800"
fetchpriority="high"
>この修正単独でLCPを4秒から2秒に短縮できる。これは合否を分ける差である。
LCP最適化における一般的な誤り：
LCP要素に遅延読み込みを適用してはならない。遅延読み込みはブラウザに待機を指示する。LCP要素は即座に読み込まれるべきだ。
LCP要素をフォルド下に配置してはならない。LCPは最大の表示コンテンツを測定する。ヒーロー要素が小さく、メインコンテンツがさらに下にあれば、最初に表示される実コンテンツを最適化する。
画像を過度に圧縮してはならない。品質80%のWebPは問題ない。品質40%のWebPは見栄えが悪い。ユーザーは品質低下に気付く。バランスを見つけることだ。
修正2：非必須JavaScriptを遅延させる
JavaScriptはレンダリングをブロックする。ブラウザはページを表示する前に、すべてのスクリプトをダウンロード、解析、実行しなければならない。その大半は初期読み込みで役割を果たさない。
平均的な小規模企業サイトはページ読み込み時に8～12のJavaScriptファイルを読み込む。それらの大多数はフォルド下の機能を拡張する。最初の読み込みで必要ではない。
実施方法は以下の通りだ。
スクリプトタグにdefer属性を付与する。 これはブラウザに対し、バックグラウンドでスクリプトをダウンロードし、ページ読み込み後に実行するよう指示する。
<!-- Before: blocks rendering -->
<script src="analytics.js"></script>
<!-- After: loads in background -->
<script src="analytics.js" defer></script>defer属性はスクリプト実行順序を保持する。スクリプトBがスクリプトAに依存していれば、順番に実行される。レンダリングをブロックするだけではない。
分析・トラッキングスクリプトをページ下部に移動する。 Google AnalyticsがコンテンツよりIP優先で読み込まれる必要はない。Facebook Pixelも同様だ。ライブチャットウィジェットもそうではない。
これらのスクリプトを閉じタグ</body>の直前に配置する。他のすべての後で読み込まれる。
未使用JavaScriptを完全に削除する。 ほとんどのWordPressサイトは、使用していない機能のためにjQueryを読み込む。多くのテーマは1つのボタンを強化するだけのアニメーションライブラリを読み込む。
ページ読み込みで実際に実行されるスクリプトを調査する。Chrome DevToolsを開き、Coverageタブに移動する。ページをリロードする。Chromeは各JavaScriptファイルの実行率を表示する。
ファイルが80%未使用なら、おそらく不要だ。削除するか、より小さなファイルに分割する。
依存性のないスクリプトにはasync属性を使用する。 async属性はスクリプトを並行してダウンロードし、ダウンロード完了直後に実行する。analyticsなどの独立したスクリプトにはasyncを使用する。
<script src="analytics.js" async></script>
<script src="chat-widget.js" async></script>相互依存するスクリプトにはasyncを使用しない。スクリプトBがスクリプトAを最初に実行する必要があれば、代わりにdeferを使用する。
この修正は通常、INPを100～200ミリ秒改善する。ブラウザがスクリプトではなくコンテンツに焦点を当てられるため、LCPも加速する。
JavaScript最適化における一般的な誤り：
重要機能を提供するJavaScriptを遅延させてはならない。メインナビゲーションがJavaScriptに依存していれば、遅延させない。ユーザーは壊れたメニューを目にする。
すべてにasyncを盲目的に適用してはならない。Asyncは実行順序を変更する。スクリプトが相互依存していれば、asyncはそれらを破断する。
テストせずにJavaScriptを削除してはならない。一度に1ファイルを削除する。すべてがまだ機能していることを確認する。次に次のファイルに進む。
修正3：画像と要素の寸法を指定する
定義されたサイズなしで要素が読み込まれると、レイアウトシフトが発生する。ブラウザは確保すべき領域を推測する。その推測は誤る。ページはジャンプする。
これはユーザーにとって最も不快なCore Web Vitals問題である。読書中にコンテンツが移動する。リンクをクリックする。ページがジャンプする。間違ったものをクリックする。
実施方法は以下の通りだ。
すべての画像に明示的なwidthおよびheight属性を付与する。 最新ブラウザはこれらを用いてアスペクト比を計算し、領域を確保する。
<!-- Before: no dimensions, causes layout shift -->
<img src="product.jpg" alt="Product photo">
<!-- After: browser reserves correct space -->
<img src="product.jpg" alt="Product photo" width="600" height="400">表示サイズと完全に一致させる必要はない。ブラウザは比例的にスケーリングする。正しいアスペクト比を与えるだけで十分だ。
広告と埋め込み要素の寸法をロード前に設定する。 Google Adsを運用していれば、CSSで正確なピクセル寸法を確保する。YouTubeビデオを埋め込めば、埋め込みロード前に16:9スペースを確保する。
.ad-container {
width: 300px;
height: 250px;
background: #f0f0f0;
}Webフォントをfont-display swapで読み込む。 これはシステムフォントを即座に表示し、カスタムフォントの準備ができたら交換する。不可視テキストとレイアウト流動を防止する。
@font-face {
font-family: 'YourFont';
src: url('your-font.woff2') format('woff2');
font-display: swap;
}テキストはただちにフォールバックフォントで表示される。カスタムフォント読み込み後、交換される。フォント読み込み完了を待ってからテキストを表示するより優れている。
既存コンテンツの上へのコンテンツ注入を回避する。 画像や広告を遅延読み込みする場合、下部へのコンテンツ注入を避ける。
フォルド下の画像にはloading="lazy"属性を使用する。ユーザーがスクロールするまで読み込みを遅延させる。
<img src="below-fold.jpg" alt="Image below fold" loading="lazy" width="800" height="600">この修正はCLSを0.3から0.1以下に低下させることができる。これは不合格と完全スコアの差である。
レイアウトシフトにおける一般的な誤り：
読み込み後、ページ上部にプロモーションバナーを注入してはならない。ユーザーはこれを嫌がる。読書体験を台無しにする。バナー表示が必須ならば、最初のHTMLで領域を確保する。
要素の寸法を変更するCSSアニメーションを使用してはならない。増大・縮小アニメーションはレイアウトシフトを引き起こす。代わりにtransformsを使用する。Transformsはレイアウトに影響しない。
フォールバックなしでフォントを読み込んではならない。カスタムフォント読み込みが失敗した場合、ユーザーはテキストを表示できる必要がある。CSSでフォールバックフォントスタックを定義する。
自社サイトで修正すべきことを特定する方法
上記の3つの修正はほとんどのサイトに適用される。ただし、自社サイトは異なるかもしれない。
eコマースサイトは通常、商品画像によってLCPで失敗する。高解像度写真を数十枚保有している。その多くは3～5MBだ。これらを圧縮すればLCPを半減できる。
SaaSサイトは通常、JavaScript駆動のダッシュボードによってINPで失敗する。フレームワーク、状態管理、リアルタイム更新を備えている。非必須スクリプトを遅延させればレスポンス性が向上する。
ニュースサイトは通常、広告と遅延読み込みによってCLSで失敗する。段落間に広告を注入する。記事内の画像を遅延読み込みする。どちらもレイアウトシフトを引き起こす。
最も弱いメトリクスを把握する必要がある。その修正が数値に最大の影響を与えるかを知る必要がある。
従来のツールが見落とす理由
PageSpeed Insightsはスコアを与える。Lighthouseは機会を与える。どちらも最初に何を修正すべきかを指示しない。
20個の問題のリストを得る。各問題には潜在的な時間節約がある。2秒節約する問題は0.5秒節約する問題より重要に見える。
その算出は誤導的である。
2秒の節約にはJavaScriptアーキテクチャ全体の書き直しが必要かもしれない。0.5秒の節約には1つの画像圧縮で足りるかもしれない。前者は40時間を要する。後者は5分で完了する。
従来のツールは実装難易度を考慮しない。不合格から合格に変わる修正が何かを教えない。データを吐き出し、理解はユーザーに委ねる。
Site Auditは約15分で技術監査を実行する。単一プロジェクト50ドルから始まる。3つのCore Web Vitalsメトリクスをすべて検査する。何が遅い原因かを明示する。修正を影響度でランク付けするため、優先順位が明確だ。
変更前後の予測付きで完全なレポートを得る。修正対象の特定ファイルと行番号を得る。複数サイトで修正を自動化する場合、JSONファイルを得る。
典型的な監査は500ドルで3日間を要する。Site Auditは50ドルでコーヒーを飲んでいる間に完了する。
Site Auditの実動作
Site Auditは複数のテストツールを1つの優先アクションプランに統合する。
Google PageSpeed Insightsを実行してラボメトリクスを取得する。Chrome UXレポートデータを実ユーザーメトリクスのため取得する。Pa11yを実行してアクセシビリティテストを実施する。Chrome、Firefox、Safari、Edgeにおけるブラウザ互換性を検査する。
次にAIを用いて結果を優先アクションプランに統合する。
100個の問題を文脈なしに得ない。努力推定と影響スコアを備えた5～10個の優先アクションを得る。各アクションには問題、ビジネスへの影響、修正方法、期待される結果が含まれる。
Site Auditは2つのスコープを提供する。30ページまたは100ページ。30ページスコープは小規模サイトに最適である。コア監査、5つの優先アクション、ブラウザテストを得る。
100ページスコープは競合他社分析を追加する。Site Auditは自社サイトを最大2つの競合他社と比較する。遅延している箇所を正確に把握する。キーワードギャップ、スキーマカバレッジ、パフォーマンスベンチマークを確認する。
拡張スコープはコンテンツギャップ分析も含む。Site Auditは競合他社がランク付けする予定だが自社がしないトピックを識別する。次に執筆すべき内容についてのAI駆動型調査を得る。
実例からの実数値
Site Auditはsurmado.comで4つの正当な問題を検出した。
LocalBusinessスキーマが不足していた。当該構造化データはローカル検索を15～30%押し上げる。これを追加した。ローカルトラフィックは30日間で18%増加した。
3つのセキュリティヘッダーが不足していた。当社のセキュリティスコアは5中2であった。Content-Security-Policy、X-Content-Type-Options、Strict-Transport-Securityを追加した。スコアは5中5に跳ね上がった。
フォント最適化の欠落がSpeed Indexのボトルネックであった。font-display swapに切り替えた。Speed Indexは3.2秒から2.1秒に低下した。
Lighthouseはこれらの問題を検出しなかった。Lighthouseは理想条件下で1つのブラウザをテストする。Site Auditは4つのブラウザを実ユーザーメトリクスでテストする。Site AuditのProバージョンではソーシャルメディアアプリ内ブラウザもテストする。Instagram、Facebook、LinkedInのブラウザは標準ブラウザと異なる。
トラフィックの30～50%はソーシャルメディアから来る。自社サイトがInstagramアプリ内ブラウザで破断していれば、当該トラフィックは失われる。
実際に必要なツール比較
Site Auditが他のオプションとどのように比較されるかを示す。
PageSpeed Insightsは無料で、ラボスコアを提供する。修正を優先しない。競合他社と比較しない。ソーシャルブラウザをテストしない。データを提供する。戦略の理解はユーザーに委ねられる。
Lighthouseは無料で、Chrome DevToolsに組み込まれている。技術的専門知識が必須である。ウォーターフォールチャートの読み方を知る必要がある。レンダリングをブロックするリソースを理解する必要がある。機会を提供する。何が重要かを理解するのはユーザーに委ねられる。
Semrush Site Auditは年1400ドルである。サイト全体をクロールする。何が間違っているかのすべてを検出する。優先順位なしに100以上の問題を得る。トレンド監視ダッシュボードを得る。何を最初に修正すべきか理解するのに数時間を費やす。
Screaming Frogは年199ドルである。デスクトップクローラーだ。壊れたリンク、重複コンテンツ、メタデータ問題を検出する。パフォーマンスをテストしない。実ユーザーメトリクスをテストしない。ビジネスへの影響を教えない。
Site Auditは単一プロジェクト50ドルから始まる。約15分で優先アクションプランを得る。努力推定を備えた5～10個の特定アクション。Proで競合他社分析を得る。Chrome UXレポートから実ユーザーメトリクスを得る。Proでソーシャルブラウザテストを得る。
他のツール利用後に作成された監査を得る。
Site Auditは戦略層である。他のツールはデータを提供する。Site Auditはそれを用いて何をすべきかを教える。
Core Web Vitals最適化が無効な場合
すべてのサイトがCore Web Vitals最適化から恩恵を受けるわけではない。いつ重要で、いつそうでないかを知ることだ。
自社サイトが対象キーワードのページ5でランク付けされていれば、Core Web Vitalsは救済策ではない。コンテンツの品質とバックリンクがより重要である。最初にそれらを修正する。
競合他社もCore Web Vitalsが不十分なら、自社最適化により優位性を得る。競合他社が完全スコアを持っていれば、対応するだけで競技場が平坦化される。
Core Web Vitalsはタイブレーカーである。コンテンツ品質が同等で、ページ1の位置1～5を争う場合に最も重要である。
技術SEO実践家からのRedditスレッドがこれを確認している。完全なCore Web Vitalsスコアを持つサイトが、不十分なスコアのサイトより下でランク付けされることがある。Googleは数百のランキング要因を考慮する。Core Web Vitalsはその要因の1つである。
コンテンツが薄いか、バックリンクがなければ、Core Web Vitals最適化に40時間を投じてはならない。最初に基礎を修正する。
代理店向けAPIと自動化
複数のクライアントサイトを管理していれば、自動化が不可欠である。
Site Auditは完全なAPIとWebhookサポートを含む。監査をプログラムで実行できる。JSON出力で構造化データを得る。自社システムで解析できる。クライアント向けカスタムレポートを生成できる。時間経過に伴う進捗を追跡できる。
APIはRESTベースで、認証は単純である。URLを含むPOSTリクエストを送信する。Site Auditは非同期に実行される。レポート完了時にWebhookを得る。必要なら状態エンドポイントをポーリングできる。
JSON出力にはすべてのメトリクス、優先アクション、競合他社比較が含まれる。自社システムで解析できる。クライアント向けカスタムレポートを生成できる。時間経過に伴う進捗を追跡できる。
Site AuditはPortfolioでホワイトレーベルモードもサポートしている。自社代理店名がSurmadoの代わりにレポートに表示される。クライアントは自社ブランディングを目にする。
ほとんどの代理店はSEO監査に500～1000ドルを請求する。Site Auditは約15分で同等品質を提供する。マージンを確保できる。クライアントは迅速で実行可能な結果を得る。
フレームワーク固有のヒント
修正はテックスタックに依存する。
WordPressサイト： WP RocketやW3 Total Cacheなどのキャッシングプラグインを使用する。これらのプラグインは画像最適化、JavaScript遅延、CDN統合を自動的に処理する。ほとんどの設定は10分で完了する。
Shopifyサイト： 商品画像に組み込みの遅延読み込みを使用する。JavaScriptを追加するサードパーティアプリを遅延させる。ほとんどのShopifyストアは8～12個のサードパーティスクリプトを読み込む。実際に使用するスクリプトを監査する。
Next.jsサイト： 組み込みのImageコンポーネントを使用する。レスポンシブサイジング、遅延読み込み、フォーマット変換を自動的に処理する。クライアント側JavaScriptに動的インポートを使用する。サーバーで実行する必要のないコードを遅延させる。
Reactサイト： コード分割にReact.lazy()を使用する。JavaScriptをオンデマンド読み込みの小さなチャンクに分割する。フォルド下コンテンツの遅延読み込みにIntersection Observer APIを使用する。
静的サイト： ビルド時にすべてをプリレンダリングする。EleventyまたはHugoなどのビルドツールを使用する。静的HTMLはJavaScriptレンダリングコンテンツより速く読み込まれる。CDNを使用してグローバルに静的ファイルを配信する。
成果を測定する方法
修正実施後、その効果を検証する必要がある。
Google PageSpeed Insightsを使用する。URLを入力する。Core Web Vitalsスコアを確認する。修正前のベースラインと比較する。
テストを3回実行する。スコアはネットワーク条件とサーバーロードに基づいて変動する。結果を平均する。1つのテストが低スコアを示していても、複数テスト間のトレンドを観察する。
モバイルとデスクトップ両方を検査する。Googleはモバイルパフォーマンスに基づいてランク付けする。デスクトップスコアは通常より高いが、ランキングにはさほど重要ではない。
実ユーザーデータについて28日間待機する。Chrome UXレポートは28日間のローリングウィンドウでデータを集計する。ラボスコアはただちに改善される。フィールドスコアは実ユーザーが更新サイトにアクセスするにつれて徐々に改善される。
継続的監視が必要なら、ProおよびPortfolioプランに週次監視が含まれる。スコアが時間経過で変化する方法を把握する。より深く検査したい場合、追加仕事1回25ドルで利用可能である。
よくある質問
最適化にはどの程度の時間を要するか？
当ガイドの3つの修正は、ほとんどのサイトで合計1～3時間を要する。画像最適化は30分。JavaScript遅延は30分。画像に寸法を追加するには、所有画像数に応じて1～2時間を要する。
開発者の支援が必要か？
基本修正なら不要である。画像圧縮と寸法追加はCMSで実施可能である。JavaScript変更について、カスタムテーマまたはビルドプロセスを使用していれば開発者が必要になるかもしれない。
サイトを破損させるか？
いいえ、最初にステージング環境で変更をテストした場合。一度に1変更を実施する。すべてがまだ機能していることを検証する。次に次の変更に進む。本番環境に一度に10個の変更をプッシュしてはならない。
トラフィック改善はどの程度期待できるか？
現在のランキングに依存する。ページ1の位置4～7でランク付けされていれば、Core Web Vitals改善により位置2～4に移動できる。これは通常、トラフィックを20～40%増加させる。ページ2または3でランク付けされていれば、Core Web Vitals単独ではページ1に移動させない。最初にコンテンツとバックリンクに注力する。
すべてのページを最適化する必要があるか？
いいえ。最高トラフィックページから開始する。ホームページ、トップ10ランディングページ、トップ10商品またはサービスページを最適化する。これらのページはトラフィックの80%を駆動する。最初にそれらを修正する。
ページビルダーを使用する場合どうなるか？
ほとんどのページビルダーは肥大である。Elementor、Divi、Visual Composerはすべて余分なJavaScriptとCSSを読み込む。画像を最適化して寸法を追加することは可能である。ページビルダーがスクリプトをインラインにすることが多いため、JavaScriptを遅延させるのはより困難である。
パフォーマンスが重要なら、軽量テーマへの切り替えを検討する。GeneratePressとKadenceはブロックエディタで機能する高速な代替案である。
今週のアクションプラン
最悪のメトリクスに対応する修正を選択する。
LCPが2.5秒を超えている場合、ヒーロー画像を最適化する。 WebPに変換する。表示サイズにリサイズする。CDNを追加する。これは30分を要し、通常LCPを40～50%削減する。
INPが200ミリ秒を超えている場合、JavaScriptを遅延させる。 スクリプトタグにdefer属性を追加する。分析を下部に移動する。未使用スクリプトを削除する。これは30～60分を要し、通常INPを100～200ミリ秒改善する。
CLSが0.1を超えている場合、すべての画像と動的コンテンツの寸法を指定する。 HTMLで明示的なサイズを設定する。カスタムフォントにfont-display swapを使用する。フォルド上コンテンツの注入を避ける。これは1～2時間を要し、通常CLSを0.1以下に低下させる。