ビジネスの意思決定者だけでなくデベロッパー以外のユーザーも、Core Web Vitals をどのように改善できるかをご覧ください。
はじめに
ウェブサイトのユーザー エクスペリエンスは、ビジネスの成果に直接影響することがわかっています。ウェブサイトの読み込みとユーザーへの応答が速くなるような優れたエクスペリエンスを提供すると、多くの場合、エンゲージメントとコンバージョンの増加につながります。Core Web Vitals は、ウェブサイトのユーザー エクスペリエンスを定量化して改善の余地がある領域を特定する取り組みです。
ただし、Core Web Vitals のドキュメントの多くは、技術的な理解を深め、コードを完全に管理できるウェブ デベロッパーを対象としています。多くのウェブサイトは、WordPress、Shopify、Wix などの「サイトビルダー」プラットフォームや、他の同様のソリューションを使用して、デベロッパー以外によって作成されており、多くの場合、ウェブ開発チームは存在しません。
専任のチームやウェブ デベロッパーが存在する場合でも、ウェブ パフォーマンスを担うのはそれらのチームだけではありません。ビジネスの意思決定者は、ウェブサイトやデザインの決定から、ウェブサイトへのトラフィック増加に向けた広告戦略の策定まで、ウェブサイトのパフォーマンスに大きな影響を与えています。このような判断は、多くの場合、ウェブサイトのパフォーマンスに大きな影響を与えます。
このガイドは、ウェブ開発に関する深い技術的知識がなくても、サイトの作成者と所有者がユーザー エクスペリエンスを最大限に理解し、改善できるように、関連情報を提供することを目的としています。
また、パフォーマンスの問題の多くは、デベロッパーが技術的な修正を実装する必要があります。デベロッパー向けのガイドがこうした取り組みに役立ちます。これは包括的なガイドではなく、ビジネス上の意思決定者向けの Core Web Vitals イニシアチブの入門編であり、ページ パフォーマンスの低下につながる、開発上以外の一般的な根本原因を想定しています。さらに前進するには、ウェブ デベロッパーが関与する必要があるでしょう。
Core Web Vitals とは
Core Web Vitals は、ページのユーザー エクスペリエンス、特にユーザーが感じるページ速度を測定するように設計された 3 つの指標のセットです。それぞれに 3 文字の略語が使われています。
- Largest Contentful Paint（LCP）は、読み込みのパフォーマンスを測定します。これは、ページの読み込みを開始してから、そのページの最も目立つコンテンツが表示されるまでにかかる時間（秒）です。
- Cumulative Layout Shift（CLS）は、ページの視覚的な安定性（読み込み中にコンテンツがどの程度移動するか）を測定します。
- Interaction to Next Paint（INP）（2024 年 3 月 12 日に FID を正式に代替）は、ページの応答性（クリック、タップ、キーボード操作に対するページの反応の速さ）を測定します。
各指標は、ユーザー エクスペリエンスのさまざまな側面を測定します。また、各指標の推奨しきい値も定められており、ユーザー エクスペリエンスが「良好」と見なされ、それを超えると「低い」と見なされます。これらのしきい値の間は、ページは改善が必要の範囲内であるとみなされます。なお、これらの指標については数値が小さいほど効果的です。
Core Web Vitals はどのように測定されますか？
Core Web Vitals はウェブサイトの実際のユーザーによって測定されるため、ユーザーによって結果は異なります。「Google が考えること」や「googlebot が考えること」ではなく、お客様のウェブサイトの実際のユーザーが経験したことです。
ユーザーによっては、デバイスやネットワークがより高速になります。一部のデバイスでは、低速のデバイスやネットワークの速度が使用されます。サイト上でよりシンプルで高速なページにアクセスするユーザーもいれば、より複雑で動作の遅いページにアクセスするユーザーもいます。これらのユーザー エクスペリエンスの結果が集計され、ウェブサイト全体の総合的な測定値が導き出されます。
Google は、オプトインした Chrome ユーザーのデータを Chrome ユーザー エクスペリエンス レポート（CrUX）で利用できるようにしています。このレポートは、PageSpeed Insights や Google Search Console などの多くの Google ツールにフィードされます。
CrUX は人気の高い何百万ものウェブサイトで使用できますが、すべてのウェブサイトが CrUX に対応しているわけではありません。その他のリアル ユーザー モニタリング（RUM）ツールでも、サイトのこれらの指標を収集できます。
サイトの Core Web Vitals を確認するにはどうすればよいですか？
Core Web Vitals の指標を表示するツールは、Google やサードパーティによって多数提供されています。この投稿では、サイトの Core Web Vitals をすばやく確認できる 2 つのツールをご紹介します。Core Web Vitals に対処するためのワークフローなど、その他の Google ツールについて詳しくは、Core Web Vitals と Google のツールのワークフローに関する投稿をご覧ください。
統合 RUM ソリューションがプラットフォームで提供されている場合は、サイトのページに関する詳細な情報を確認したり、特定のページにドリルダウンしたりユーザーをセグメント化したりして、問題の把握と特定に役立てることができます。
PageSpeed Insights
設定なしで簡単に確認したい場合は、PageSpeed Insights（PSI）を使用できます。URL を入力して [Analyze]をクリックしますサイトが CrUX に含まれている場合は、すぐに「実際のユーザーが体験している状況を確認する」セクションが表示されます。
これは、過去 28 日間に Chrome ユーザーがウェブサイトをどのように利用しているかを示します。上部には 3 つのウェブに関する主な指標が表示され、その下に他の補足指標（保留中の INP 指標を含む）が表示されます。ページ上部に表示される「合格/不合格」の評価でカウントされるのは Core Web Vitals のみですが、他の指標は Core Web Vitals の問題のトラブルシューティングに役立つことがあります（次のセクションで説明します）。
このセクションの上部にあるボタンを使用して、モバイル表示とパソコン表示を切り替えることができます。[この URL] と [元の] のすべてのデータを切り替えるには、右上の切り替えボタン（両方のデータが存在する場合）を使用します。
これらの数値は、サイトのパフォーマンス、改善の余地がある指標、デバイスの種類について、広範な指標として役立ちます。
Google Search Console
Google Search Console（GSC）はサイト所有者専用であるため、使用するにはサイト所有者の登録と確認が必要です。このページには、Google 検索がサイトをどのように認識しているかの詳細が表示されます。
PageSpeed Insights とは異なり、GSC には、Google 検索が認識しているサイト上のすべてのページが一覧表示され、Core Web Vitals のすべての詳細情報が表示されます。
ページは URL グループに収集されるため、特定のカテゴリのページ（商品の詳細ページ、ブログページなど）にウェブに関する主な指標の問題があるかどうかを簡単に確認できます。これらは通常、同様のテクノロジーやテンプレートに基づいて構築されているため、これらのページで問題に共通の原因が存在する可能性があります。
サイト作成者向けの Core Web Vitals に関する一般的な問題
パフォーマンスの問題の多くは、デベロッパーが技術的な修正を実装する必要があります。デベロッパー向けのガイドが、その修正に役立ちます。このセクションでは、これらの指標を改善するためにビジネスの意思決定者が支援できる、デベロッパー以外のよくある問題について説明します。
「デベロッパー以外」とは、サイトの実際のコーディング方法を制御できないサイトビルダー プラットフォームを使用している方、サイトのデザインに関する決定や予算の優先順位付けを行う可能性があるビジネスの意思決定者を指します。
Largest Contentful Paint（LCP）に関する問題
LCP はウェブページの読み込み速度を測定することを目的としています。具体的には、リンクをクリックしてから最大のコンテンツ（通常はバナー画像や見出し）がブラウザに表示されるまでの時間を測定しています。
優れたページ エクスペリエンスを得るには、リンクがクリックされてから 2.5 秒以内にそのコンテンツが表示されるようにする必要があります。4 秒以上かかる場合は、エクスペリエンスが低いと見なされます。
次のセクションでは、LCP に影響を与える、ビジネスの意思決定者が影響を与える可能性のある一般的な問題について説明します。
ページの読み込み開始の遅延
ページ自体の読み込み時間を改善することについてよく考えていますが、開始する前に遅延が生じることもよくあります。ウェブサイトが数秒間ダウンロードされていなくても、2.5 秒の良好しきい値を下回る LCP は不可能です。
最初のバイトまでの時間（TTFB）は、ウェブページの最初の部分をダウンロードするのにかかる時間です。PageSpeed Insights で、大きい TTFB 診断指標が赤色または黄色で表示されている場合は、これが重要な対処法であり、LCP に直接影響が及ぶはずです。
視聴者を理解する
TTFB の問題では、対象ユーザーを理解することが重要です。ウェブサイトが 1 つの国でホストされていても、世界中のユーザーにサービスを提供する場合、ウェブサイトのユーザーとウェブサーバー間の地理的な距離がページの TTFB の決定要因になります。コンテンツ配信ネットワーク（CDN）を使用すると、サイトのコピーを世界中にキャッシュ保存できるため、ユーザーの近くで利用することができます。多くのホスティング プロバイダがサービスの一部として CDN を提供しており、CDN は自動的に処理されます。自分のサイトがホストされている場所について確認してください。一部のプラットフォームでは、有料階層が高いほど CDN ロケーションが増加し、さまざまな階層のサービスが提供されます。グローバル ビジネスは、このようなケースでは上位層を検討する必要があります。
リダイレクトの回数を減らす
TTFB が遅くなるもう 1 つの一般的な原因はリダイレクトです。広告キャンペーンの実施やメール配信の際は、リダイレクトの数をなるべく抑えるために、複数の短縮リンクを使用したり、リダイレクトの必要がある URL を指定したりしないでください。たとえば、www.example.com/blog にリダイレクトする必要があるキャンペーンで example.com/blog を使用し、その後 https://www.example.com/blog にリダイレクトすると、ページの TTFB に時間がかかります。マーケティング キャンペーンでは、リダイレクトの回数をできる限り少なくします。
広告キャンペーンが適切なオーディエンスをターゲットにしていることを確認する
また、広告キャンペーンでターゲット オーディエンスを効果的にターゲティングしていることを確認します。地球の裏側にいるユーザー（でも商品を提供できないユーザー）から多くの新しいトラフィックを獲得すると、広告費用の無駄使いが発生し、ウェブサイトのパフォーマンスにも悪影響を及ぼします。
URL パラメータがウェブのパフォーマンスに影響する可能性がある
UTM パラメータなどの URL パラメータは、マーケティング キャンペーンでよく使用されます。これを行うと、毎回同じページが提供されているとしても、各 URL が固有のページのように見えるため、インフラストラクチャのキャッシュ効率が低下する可能性があります。UTM パラメータを使用している場合は、CDN プロバイダまたはインフラストラクチャ チームに連絡して、キャッシュ インフラストラクチャでこれらの URL パラメータが無視されるようにして、すでにキャッシュされているページをキャンペーンで活用できるようにします。
メディアはパフォーマンスのためにコストがかかることがある
ページに対するメディアの影響を考慮します。通常、画像や動画などのメディアはサイズが非常に大きいため、ダウンロードにはテキストより時間がかかります。これにより、残りのページの読み込み速度も低下する可能性があります。LCP 要素がテキストではなくメディアの場合、これは特に重要です。LCP 要素はウェブページの約 80% に表示される画像であるため、メディアがサイトに与える影響を考慮することが重要です。
同時に、メディア アセットは、テキスト中心のサイトよりも魅力的で、リッチな視覚的エクスペリエンスをもたらします。したがって、メディアを削除できる選択肢はほとんどありませんが、メディアの費用を認識し、費用を減らす方法を知っておくと、パフォーマンスの問題を最小限に抑えることができます。
カルーセルを使わない
複数の画像で構成されるカルーセルは、適切に実装されていないと複数の画像を同時にダウンロードすることが必要になるため、ページの全体的な読み込み時間に影響する可能性があります。また、カルーセルは、広く利用されているにもかかわらず、優れたユーザー エクスペリエンスを提供しないことが多いため、サイトで使用する前に慎重に検討してください。
ウェブ用に最適化された画像を使用する
メディア アセットのサイズです。ウェブ上の多くの画像が、高い解像度で配信されています。メディア パートナーやデザイン エージェンシーから提供されることが多いフルサイズの印刷品質の画像ではなく、ウェブ用に最適化された画像を提供するようにしてください。TinyJPG などのサービスを使用すると、画像をアップロードする前に画像から不要なデータをすばやく削除できます。多くのウェブ プラットフォームでは、アップロード時に画像を自動的に最適化しようとしますが、ユーザーのデバイスで画像が表示されるサイズがわからないため、最初はサイズが小さい画像を用意すると、大幅な成果向上が見込めます。
動画については特に注意を払う
動画を使用するときは特に考慮します。動画は、ウェブサイトがダウンロードして表示する最大規模のコンテンツであり、したがって最も時間のかかるコンテンツであるため、使いすぎないようにします。ウェブページの最上部には使用せず、ページの下部には保存してください。これにより、安価なコンテンツもすばやく読み込めるようになり、ユーザーの読み込みエクスペリエンスが向上し、LCP への影響もありません。
A/B テスト
多くの企業は、A/B テストを実施して、ウェブサイトに対する変更をテストしています。その実装方法が、LCP に大きな影響を与える可能性があります。
多くの A/B テスト ソリューションでは、テストでの変更が適用されるまで、ウェブサイトが最初にユーザーに表示されるタイミングが遅れます。これにより、元のバージョンのウェブサイトは表示されなくなりますが、代わりにウェブサイトがユーザーに表示されるのが遅くなります。この遅延を回避するため、他のソリューションはサーバーサイドで適用されます。A/B テストがどのように実施され、こうした遅延の影響を受けるかについて、時間をかけて把握してください。また、可能であれば、サーバーサイドの A/B テスト ソリューションの使用も検討してください。
A/B テストでは、新しい変更をリリースする前に貴重なフィードバックを得ることができますが、ページ パフォーマンスのコストは、それらがもたらす潜在的な利点と比較検討する必要があります。
インフラストラクチャに関係なく、A/B テストを実行するすべてのユーザーは、常に次のベスト プラクティスを念頭に置く必要があります。
- A/B テストツールの使用対象を、テストの対象となるページのみに制限します。ほとんどのページで A/B テストが常時実施されていない可能性がある場合に、すべてのページを遅らせないようにします。
- A/B テストを一部のユーザーに制限して、大多数のユーザーに影響が及ばないようにします。
- A/B テストは、確実な結果を得るために必要な最小限の時間に限定する。A/B テストの実行時間が長いほど、ユーザーのページ パフォーマンスが低下する時間が長くなります。
- 何よりも重要な点は、不要になった A/B Testing テストを削除することです。
Cumulative Layout Shift（CLS）の問題
CLS は、ページの視覚的な安定性（コンテンツが読み込まれた後にページのコンテンツがどの程度変化するか）を測定します。これは、ユーザーがウェブページを読み始めたものの、コンテンツや広告スロットが増えるにつれてその位置がわからなくなった場合、気が散る可能性があります。また、ページのレイアウトが大きく移動した場合、ユーザーが意図せずに間違ったコンテンツをクリックしてしまう可能性もあります。後で読み込まれる動的コンテンツは特に注意してください。また、最初のページ コンテンツの一部が移動される可能性があります。
コンテンツのシフト量とシフト量を計算する数式を使用して測定されます。0.1 以下の値を「良好」、0.25 を超える値を「不良」とみなす、単位なしの比率で表されます。
次のセクションでは、ビジネスの意思決定者が影響を与える可能性がある CLS に影響する一般的な問題について説明します。
ページを下にスクロールしたときに画像がどのように読み込まれるか確認する
多くのテンプレートでは、最初のページ読み込み時に画面上に表示される画像により多くのリソースを割り当てるために、ページの下方に画像が読み込まれないようにしています。ユーザーが下にスクロールすると、画像が読み込まれます。この画像読み込み方法を「遅延読み込み」といいます。
ページ テンプレートでは、遅延読み込みされる画像用のスペースを確保して、画像が読み込まれる前にユーザーが非常に速くスクロールしても、その周囲のコンテンツが移動しないようにする必要があります。お使いのテンプレートやプラットフォームが対応していない場合は、この機能に対応したものに切り替えることをご検討ください。
コンテンツの途中に表示される広告に注意する
コンテンツの途中に挿入された広告は、読み込みに少し時間がかかる場合が多く、前のセクションで説明した画像よりも時間がかかるため、コンテンツが押し下げられることがあります。このリスクを軽減するために、メインページ コンテンツの横に配置するのが一般的なパターンです。実際にこれを実現する方法は、使用するプラットフォームや、サイトの構築に使用しているテンプレートによって異なります。
ページの上部に動的コンテンツを追加しない
ページの読み込み後にアラートやバナー（Cookie バナーやスペシャル オファーなど）を追加しないようにします。代わりに、メイン コンテンツの上にアラートやバナーを重ねて表示するよう選択すると、ページ コンテンツの移動を防ぐことができます。前のセクションと同様に、ここでのオプションはページで使用されているプラットフォームとテンプレートによって異なります。
Interaction to Next Paint（INP）に関する問題
INP はページの応答性を測定します。応答性とは、ページがクリック、タップ、キーボード入力などの操作にすばやく反応するかどうかを評価するものです。ユーザー入力にすぐに反応しないページは、動作が遅く感じられ、ユーザーに不満を抱かせる可能性があります。
INP は、ページのライフサイクル中に、対象となるすべてのインタラクション全体を測定し、最も低いインタラクションをレポートします。INP の良好しきい値は 200 ミリ秒、低しきい値は 500 ミリ秒です。INP は FID を強化したもので、応答性の測定に優れています。そのため、INP は応答性を測定するための Core Web Vitals として FID に取って代わられました。
応答性の指標、特に INP は、最適化が難しい指標です。これらの指標が「低い」しきい値に含まれる場合、通常はウェブページが過度に操作しようとしたためにインタラクションが遅延するためです。したがって、ここでの主な解決策は、不要なコードを削除して軽量なページを作成することです。
次のセクションでは、ビジネスの意思決定者が影響を与える可能性がある INP に影響する一般的な問題について説明します。
春の大掃除をしましょう！
サイトに追加されたプラグインとウィジェットを確認し、不要になったプラグインやウィジェットを削除します。プラグインを追加して試してみることは簡単ですが、役に立たなかったプラグインを削除してしまうこともよくあります。これはインタラクションが遅くなる原因の 1 つですが、他の多くの方法と比べて最適化は比較的簡単です。
同様に、マーケティング キャンペーンでタグ マネージャーを使用している場合は、古いキャンペーンを必ず削除してください。配信されなくなったとしても、期限切れのマーケティング キャンペーンのコードは、各ページでダウンロードしてコンパイルする必要があり、最初のページ読み込み時のユーザー操作が遅くなる可能性があります。
高価なウィジェットやプラグインを使用しない
計算量の多いウィジェットやプラグインは、見た目は良いものの、ユーザー エクスペリエンスは向上しますか、それとも悪化しますか？PageSpeed Insights の「パフォーマンスの問題の診断」/「Lighthouse（Lighthouse）」レポートは、ウェブサイトのパフォーマンスに大きく影響している JavaScript の特定に役立ちます。
ウィジェットは、必要なページのみに制限するのが理想的です。お問い合わせページに Google マップの埋め込みのみを使用する場合は、応答性の問題を引き起こす可能性のあるすべてのページに読み込む必要はありません。
広告の数を考慮する（特にモバイルで）
多くのビジネスにとって広告は優れた収益化戦略ですが、多くの場合、複雑で大量のリソースが必要です。広告が多いほどリソースを大量に消費するため、ページの読み込み速度が低下する可能性があります。これは特にモバイル デバイスに当てはまります。こうしたモバイル デバイスでは、デスクトップ デバイスやノートパソコンほど処理能力に優れたメモリが少ないことがよくあります。
収益化とパフォーマンスのバランスを重要視します。一方、ユーザー エクスペリエンスが悪かったために離脱するタイミングが早まっている場合、増加した広告よりも収益が増加している可能性があります。
過度なページサイズを避ける
大規模で複雑なページを表示するには、より多くの処理時間が必要です。たとえば、1,000 種類の商品を含む商品ギャラリーの場合、ユーザーのブラウザ ウィンドウに表示されるまでに時間がかかります。この時間を短縮するために、ページをページ分けするタイミングを検討してください。
さらにサポートが必要な場合
この投稿では、ビジネス オーナーがパフォーマンスに影響を与える可能性がある一般的な考慮事項を紹介します。他にも、ウェブ デベロッパーに相談して、ウェブサイトのパフォーマンスを改善する方法について詳しく見てもらうことが必要になる場合もあります。
プラットフォーム固有の情報
ほとんどのプラットフォームはウェブ パフォーマンスを非常に重視しており、その改善方法についてプラットフォームごとに専用のアドバイスを提供している場合があります。また、このプラットフォームの利用の一環として、専任のウェブ パフォーマンス チームからサイトの改善方法についてアドバイスを受けることもできます。
また、Lighthouse では、スタックパック機能を使用してプラットフォーム固有の情報が表示されるため、サポート対象プラットフォームのユーザーに適切なアドバイスを提供することができます。
プラットフォームは時間の経過とともに継続的に改善され、現在、その多くはパフォーマンスと Core Web Vitals に注力しています。プラットフォーム デベロッパーが行った最新の改良点を活用できるよう、プラットフォームを最新の状態に保ちましょう。
これは、プラットフォーム アップデートを含め、プラットフォーム プロバイダがプラットフォームを自動的に管理するホスト型プラットフォームを使用している場合に最も簡単な方法です。プラットフォームを自社でホストしている場合（たとえば、ローカルの WordPress を独自のサーバーにインストールする）、プラットフォームを定期的に更新することで、デベロッパーが実装したプラットフォームの改善による恩恵を受けることができます。この維持を優先するか、管理を行うサービスを選択する必要があります。
ウェブ デベロッパーの利用
ウェブ パフォーマンスの専門知識を持つウェブ デベロッパーは、ビジネス オーナーよりも多くの問題に対処できる可能性が高いと言えます。初期段階または定期的な変更のためにウェブ デベロッパーに依頼している場合や、専任の開発チームがある場合、連携するデベロッパー（理想的には、ウェブ パフォーマンスの専門知識を持つ人）を見つける必要がある場合があります。
上記の提案ではウェブサイトのパフォーマンスの問題に対処するには不十分な場合は、デベロッパーに相談してください。しかし、前述の例から、ビジネス上の優先事項と開発の意思決定のバランスを取りながら、ウェブサイトに適したソリューションにすることが重要であることもわかるはずです。
ウェブ パフォーマンスは、1 回限りの作業であることはめったにありません。ウェブサイトのパフォーマンスを良好に保つには、多くの場合、ウェブサイトの改善後に掲載順位が下がることを防ぐため、定期的なモニタリングとメンテナンスが必要になります。
おわりに
ウェブサイトは顧客との接点となることが多いため、顧客体験を提供することは重要です。これは、お客様のビジネスの第一印象を獲得する初回訪問者だけでなく、リピーターやリピーターにも当てはまります。これらのユーザーには、できるだけシームレスな体験を提供し、好ましくない印象を残すような不満がないことが理想的です。Core Web Vitals は、Google がサイトに検討することを推奨しているユーザー エクスペリエンスの指標の一つです。ウェブがもたらすさまざまな可能性の中、ユーザーがあなたのサイトにイライラすると、他のウェブサイトも簡単に試してしまいます。
それと同時に、Core Web Vitals はウェブサイトの指標の一つにすぎません。企業はウェブサイトにどの程度投資するか、その投資からどのような利益が得られるかを自分で決める必要があります。
謝辞
サムネイル画像（作成者: Carlos Muza、出典: Unsplash）