ウェブサイトの速度を最適化したのに、Core Web Vitalsの基準を満たせないのはなぜ？

画像を圧縮し、CDNも導入した。速度テストのスコアは赤から緑に変わったのに、Search ConsoleではCore Web Vitalsが依然として「改善が必要」と表示される。海外向け独立サイトを運営する担当者にとって、このギャップは「最適化が反映されていないのでは？」という疑念につながりがちです。

必ずしもそうとは限りません。ツールが測定する読み込み速度と、海外の顧客が実際に体験する閲覧、クリック、ページの変化は、同じものではありません。ウェブサイトの速度最適化でCore Web Vitalsの基準を満たすには、まずデータの測定基準を区別し、ユーザー体験を損ねている具体的なページや操作を特定する必要があります。

まず確認：表示されているのはスコアですか、それとも実ユーザーデータですか？

PageSpeed Insightsに表示されるLighthouseのパフォーマンススコアは、特定のシミュレーション条件で実施したラボテストの結果です。一方、ページ上部に表示される実際のユーザー体験データは、主にChromeユーザーエクスペリエンスレポート（CrUX）に基づいています。用途が異なるため、スコアが高くてもCore Web Vitalsの基準を満たすとは限りません。

Core Web Vitalsでは主に3つの指標を確認します。通常、平均値ではなく、実際のアクセスデータの75パーセンタイルで判定します。

3つすべてが「良好」の基準を満たして初めて、評価に合格します。モバイルとデスクトップは分けて確認してください。現在のURLのデータが不足している場合は、ツールがサイト全体のデータを表示していないかにも注意し、サイト全体の状況を個別ページの結果と取り違えないようにしましょう。

また、CrUXは過去28日間のローリングデータを使用します。今日修正を公開しても、過去のアクセス記録は引き続き集計に含まれるため、結果がすぐに緑色に変わるわけではありません。Search Consoleにも更新の遅れがあるため、数時間おきに修正を繰り返すのではなく、傾向を確認しましょう。

指標ごとに問題を切り分け、リソースの圧縮をむやみに続けない

PageSpeed Insightsを開いて不合格の項目を確認し、Chrome DevToolsのPerformanceパネルで該当ページを記録します。トップページだけを測定しないでください。海外の顧客が実際に訪れる入口は、商品詳細ページ、カテゴリページ、広告ランディングページであることが少なくありません。

LCPが基準未達：画像は小さくなったのに、検出されるタイミングが遅い

ファーストビューの大きな画像がLCPの対象になることはよくありますが、遅延の原因はファイルサイズとは限りません。サーバーの応答が遅い、リダイレクトが多い、JavaScriptの実行後に画像が挿入されるといった原因で、ブラウザーがダウンロードを開始するまでに時間がかかることがあります。

Networkパネルで対象リソースのリクエスト開始時刻を確認し、パフォーマンス記録と照らし合わせて、待機、ダウンロード、描画にかかった時間を切り分けます。ファーストビューの重要な画像には遅延読み込みを適用しないでください。できるだけ初期HTMLからブラウザーが画像を検出できるようにし、必要に応じて取得優先度を高く設定します。リソースの検出が遅れていると確認できた場合に限り、プリロードを検討してください。過剰に設定すると帯域を奪い合うおそれがあります。

海外向けサイトでは、ターゲット市場からのテストも必要です。北京のオフィスで速く表示されても、ドイツやブラジルのモバイルユーザーも同じように速いとは限りません。CDNのキャッシュヒット率、動的ページのオリジンサーバーへのリクエスト、多言語ページへのリダイレクトで待ち時間が増えていないかを確認しましょう。

INPが基準未達：ページは開いたのに、ボタンが「反応しない」

INPは、ページの閲覧中における操作への応答性を測定する指標です。読み込みテストを一度行うだけでは判断できません。商品フィルター、仕様の切り替え、問い合わせポップアップ、ショッピングカートなどを実際に操作して確認しましょう。

クリック操作を記録し、長時間タスクがメインスレッドを占有していないか確認します。よくある原因として、一度に大量の商品を描画する処理、複雑なフォーム検証、チャットプラグインや広告トラッキング、ヒートマップのスクリプトが集中して実行されることが挙げられます。長時間タスクを分割し、不要なJavaScriptを減らすか、必須ではない機能を適切なタイミングで読み込むようにしましょう。

ラボテストのTotal Blocking Time（TBT）は原因の特定に役立ちますが、実際のINPの代わりにはなりません。マーケティング用スクリプトを削除すればよいというわけでもありません。まずスクリプトの用途と実行条件を明確にし、パフォーマンスを改善した結果、問い合わせのアトリビューションが失われることのないようにしましょう。

CLSが基準未達：ファーストビューは安定していても、スクロール中にずれる

ページを開いてから数秒間だけに注目していると、レイアウトのずれを見逃しやすくなります。遅れて表示される割引バナーやおすすめモジュール、フォントの置き換え、サイズを予約していない動画などが、閲覧中にコンテンツを押し下げることがあります。

画像、動画、埋め込みモジュールにはサイズまたはアスペクト比を設定し、非同期コンテンツ用のスペースを確保します。多言語サイトでは、長いテキスト、フォントの読み込み、ボタンの折り返しも確認してください。中国語版で安定しているテンプレートでも、ドイツ語に切り替えると安定しない場合があります。

個別ページを修正したのに、レポートに不合格ページが多数残るのはなぜ？

Search Consoleは、ユーザー体験が似ているURLをグループ化します。商品ページを1つ修正しても、同じグループのページがすべて改善されたことにはなりません。ほかのページでは古いテンプレートが使われていたり、メイン画像が大きかったり、サードパーティ製コンポーネントが追加で読み込まれていたりする場合があります。

「テンプレート×言語×デバイス」でチェックリストを作成し、各カテゴリから代表的なページを選びます。アクセスの多い入口ページと、問題が深刻なページも対象に含めましょう。海外向けマーケティングサイトでは、広告パラメーター付きのランディングページも個別に確認し、パラメーターがキャッシュに影響していないか、広告からの流入で追加スクリプトが実行されていないかを確かめます。

易営宝のように、スマートサイト構築と海外マーケティングサービスを提供するプラットフォームでは、運用担当者が画像を1枚ずつ圧縮するだけでなく、テンプレート、スクリプト、広告の流入経路をまとめて点検するのに適しています。連携時には、サイト全体のテンプレートに起因する問題と、特定のマーケティングページだけで起きる問題を明確に分けましょう。

「緑色に変わる」のを待つだけでなく、再テストで効果を確認する

修正のたびに、公開日時、対象ページ、目標指標を記録します。公開後は、まず同じ条件でラボテストを実施し、問題が解消されたかを確認します。次に、実ユーザーモニタリングで地域、デバイス、ページタイプごとの変化を観察します。アクセス数が少ない場合は、わずかなデータだけで結論を出さないでください。

関連ページ全体に修正が反映されたことを確認したら、Search Consoleで検証を開始し、ローリングデータを継続して観察します。同時に、問い合わせの送信、決済、広告コンバージョン、同意管理機能を回帰テストし、スクリプトの遅延読み込みによって業務フローが損なわれないようにしましょう。

Core Web Vitalsの基準に達しない原因は、多くの場合、「速度向上プラグインがもう1つ必要」なのではなく、測定基準、ページテンプレート、実際の利用状況が一致していないことにあります。まず不合格の指標を特定し、該当するボトルネックを修正することで、速度改善を見栄えのよいテスト画像だけで終わらせず、海外の顧客が実感できるスムーズな体験につなげられます。