ビジネスの意思決定者やデベロッパー以外の方が 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）: クリック、タップ、キーボード操作に対してページがどれだけ迅速に応答するか。
各指標は、ユーザー エクスペリエンスの異なる側面を測定します。Google は、各指標の推奨しきい値も提供しています。下限しきい値を下回るユーザー エクスペリエンスは「良好」と見なされ、上限しきい値を上回るユーザー エクスペリエンスは「不良」と見なされます。これらのしきい値の間にあるページは、改善が必要な範囲にあると見なされます。これらの指標では、数値が低いほど優れていることに注意してください。
Core Web Vitals はどのように測定されますか？
Core Web Vitals は、ウェブサイトの実際のユーザーによって測定されます。結果はユーザーごとに異なります。これらは「Google の見解」でも「Googlebot の見解」でもなく、ウェブサイトの実際のユーザーが体験したことです。
一部のユーザーは、より高速なデバイスとより高速なネットワークを使用しています。一部のユーザーは、低速のデバイスや低速のネットワークを使用しています。サイトのシンプルで読み込みが速いページにアクセスするユーザーもいれば、複雑で読み込みが遅いページにアクセスするユーザーもいます。これらのユーザー エクスペリエンスの結果がすべて集計され、ウェブサイト全体の総合的な測定結果が得られます。
Google は、オプトインした Chrome ユーザーのデータを Chrome ユーザー エクスペリエンス レポート（CrUX）で提供しています。このレポートは、PageSpeed Insights や Google Search Console などの多くの Google ツールにフィードされます。
CrUX は、数百万の人気ウェブサイトで利用できますが、すべてのウェブサイトが CrUX に含まれているわけではありません。他のリアルユーザー モニタリング（RUM）ツールでも、サイトのこれらの指標を収集できます。
サイトの Core Web Vitals を確認するにはどうすればよいですか？
Google やサードパーティが提供する、Core Web Vitals の指標を表示するツールは数多くあります。この記事では、サイトの Core Web Vitals をすばやく確認できる 2 つのツールを紹介します。その他の Google ツール（Core Web Vitals の改善に使用するワークフローなど）について詳しくは、Google ツールを使用した Core Web Vitals ワークフローの投稿をご覧ください。
プラットフォームに統合 RUM ソリューションが用意されている場合は、サイトのページに関するより詳細な情報を提供したり、特定のページをドリルダウンしたり、ユーザーをセグメント化したりして、問題の把握と特定に役立てることができます。
PageSpeed Insights
設定不要のクイックビューには、PageSpeed Insights（PSI）を使用できます。URL を入力して [分析] をクリックします。サイトが CrUX に含まれている場合は、[Discover what your real users are experiencing] セクションがすぐに表示されます。
これは、過去 28 日間に実際の Chrome ユーザーがウェブサイトをどのように利用したかを示しています。上部に 3 つの Core Web Vitals が表示され、その下に他のサポート指標（保留中の 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 の問題があるかどうかを確認できます。これらのページは通常、同様のテクノロジーやテンプレートに基づいて構築されているため、これらのページの問題には共通の原因がある可能性があります。
サイト作成ツールに関する Core Web Vitals の一般的な問題
パフォーマンスの問題の多くは、デベロッパーが技術的な修正を実装する必要があります。デベロッパー向けのガイドは、デベロッパーがその修正を行う際に役立ちます。このセクションでは、ビジネス上の意思決定者がこれらの指標を改善するために役立つ、デベロッパー以外の一般的な問題について説明します。
「デベロッパー以外」とは、サイトビルダー プラットフォームを使用しているため、サイトの実際のコーディング方法を制御できないユーザーや、サイトのデザインを決定したり、予算の優先順位付けを支援したりするビジネス上の意思決定者を指します。
Largest Contentful Paint（LCP）に関する問題
LCP は、リンクがクリックされてから、最も大きなコンテンツ（通常はバナー画像または見出し）がブラウザに表示されるまでの時間を測定することで、ウェブページの読み込み速度を測定することを目的としています。
ウェブページのページ エクスペリエンスが良好と判断されるためには、リンクがクリックされてから 2.5 秒以内にそのコンテンツが表示されるようにする必要があります。4 秒以上かかる場合は、エクスペリエンスが低いと見なされます。
ビジネスの意思決定者が影響を与えることができる、LCP に影響する一般的な問題の一部を次のセクションで説明します。
ページの読み込み開始の遅延
ページ自体の読み込み時間の改善に注目しがちですが、読み込みが開始される前に遅延が発生していることがよくあります。ウェブサイトのダウンロードに数秒かかる場合、LCP を 2.5 秒未満の良好なしきい値にすることは不可能です。
Time to First Byte（TTFB）は、ウェブページの最初の部分がダウンロードされるまでにかかる時間です。PageSpeed Insights で TTFB の診断指標が赤またはオレンジで表示されている場合は、その問題に対処することが重要であり、LCP に直接的な影響を及ぼす可能性があります。
視聴者を理解する
TTFB の問題については、オーディエンスを理解することが重要です。1 つの国でホストしているウェブサイトから世界中のユーザーにサービスを提供する場合、ウェブサイトのユーザーとウェブサーバーの地理的な近さが、ページの TTFB の要因になります。コンテンツ配信ネットワーク（CDN）を使用すると、サイトのコピーを世界中にキャッシュできるため、ユーザーの近くに配置できます。多くのホスティング プロバイダは、サービスの一部として CDN を提供しており、この処理を自動的に行います。サイトがホストされている場所がこれに該当するかどうかを確認してください。一部のプラットフォームでは、有料の上位ティアでより多くの CDN ロケーションを利用できる、さまざまなティアのサービスを提供しています。グローバル企業は、このような場合に上位のティアを検討する必要があります。
リダイレクトの回数を減らす
リダイレクトも、TTFB が遅くなる一般的な原因です。広告キャンペーンを実施したり、メールを送信したりする場合は、複数の短縮 URL を使用しないようにしたり、リダイレクトが必要な 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 テストを削除することです。
Cumulative Layout Shift（CLS）に関する問題
CLS は、ページの視覚的な安定性（コンテンツの読み込み時にページのコンテンツがどの程度移動するか）を測定します。ユーザーがウェブページを読み始めた後に、コンテンツや広告スロットが挿入されて読み進めていた場所を見失うと、ユーザーの気が散る可能性があります。また、ページのレイアウトが過度にずれると、ユーザーが意図せず間違ったコンテンツをクリックしてしまうこともあります。後から読み込まれる動的コンテンツは、最初のページ コンテンツの一部を移動させる可能性があるため、細心の注意を払ってください。
これは、数式を使用して測定され、コンテンツがどの程度、どのくらい移動したかが計算されます。単位のない分数で表され、値が 0.1 以下であれば良好、0.25 以上であれば不良と見なされます。
ビジネス上の意思決定者が影響を与えることができる、CLS に影響する一般的な問題の一部を次のセクションで説明します。
ページをスクロールしたときに画像がどのように読み込まれるかを確認する
多くのテンプレートでは、ページの下部にある画像の読み込みを回避して、最初のページ読み込み時に画面に表示される画像により多くのリソースを割り当てています。ユーザーが下にスクロールすると、画像が読み込まれます。この画像読み込み手法は、遅延読み込みと呼ばれます。
ページ テンプレートでは、遅延読み込みされる画像用のスペースを確保する必要があります。これにより、画像が読み込まれる前にユーザーが非常に速くスクロールしても、その周囲のコンテンツが移動することはありません。テンプレートやプラットフォームがこの処理を行わない場合は、この処理を行うものに切り替えることを検討してください。
コンテンツの途中に広告を配置する場合は注意する
コンテンツの途中に挿入された広告は、コンテンツを押し下げるリスクがあります。広告の読み込みには、前のセクションで説明した画像よりも時間がかかることが多いためです。メインページのコンテンツの横に配置することは、このリスクを軽減する一般的なパターンです。実際にこれを実現する方法は、特定のプラットフォームと、サイトの構築に使用するテンプレートによって異なります。
ページの上部に動的コンテンツを追加しない
ページ読み込み後に、ページの上部にアラートやバナー（Cookie バナーや特別オファーなど）を追加しないようにします。代わりに、メイン コンテンツの上にアラートやバナーを重ねて表示するようにすれば、ページ コンテンツがずれることはありません。前のセクションと同様に、ここでのオプションは、ページに使用されているプラットフォームとテンプレートによって異なります。
Interaction to Next Paint（INP）に関する問題
INP は、ページの応答性を測定する指標です。クリック、タップ、キーボード入力などの操作にページが迅速に応答するかどうかを評価します。ユーザー入力にすばやく応答しないページは、動作が遅く感じられ、ユーザーに不満を与える可能性があります。
INP は、ページのライフサイクル中に発生したすべての対象となるインタラクションを測定し、最も悪いインタラクションを報告します。INP の良好のしきい値は 200 ミリ秒、不良のしきい値は 500 ミリ秒です。
応答性の指標（特に INP）は、最適化が難しい指標です。これらの指標が不十分のしきい値にある場合、通常は、ウェブページが過剰な処理を行おうとしてインタラクションが遅延していることが原因です。そのため、主な解決策は、不要なコードを削除してページを軽量化することです。
INP に影響する一般的な問題のうち、ビジネス上の意思決定者が影響を及ぼすことができるものについて、次のセクションで説明します。
春の大掃除をしましょう。
サイトに追加されているプラグインとウィジェットを確認し、使用されていないものは削除します。プラグインを追加して試すのは簡単ですが、役に立たなかった場合に後で削除するのを忘れてしまうことがよくあります。これは、インタラクションが遅くなる原因の一つですが、他の多くの最適化よりも比較的簡単です。
同様に、マーケティング キャンペーンにタグ マネージャーを使用している場合は、古いキャンペーンが削除されていることを確認します。期限切れのマーケティング キャンペーンのコードは、実行されなくなったとしても、各ページでダウンロードしてコンパイルする必要があります。そのため、最初のページ読み込み時にユーザー インタラクションが遅くなる可能性があります。
高価なウィジェットやプラグインを避ける
計算コストの高いウィジェットやプラグインは、見た目は良くても、ユーザー エクスペリエンスを向上させるどころか、実際には悪化させている可能性があります。PageSpeed Insights の [パフォーマンスの問題を診断する] レポートは Lighthouse によって提供されており、ウェブサイトのパフォーマンスに顕著な影響を与えている JavaScript を特定するのに役立ちます。
ウィジェットは、必要なページにのみ配置することをおすすめします。たとえば、Google マップの埋め込みを「お問い合わせ」ページでのみ使用している場合、すべてのページで読み込む必要はありません。すべてのページで読み込むと、応答性の問題が発生する可能性があります。
広告の数を考慮する（特にモバイルの場合）
広告は多くのビジネスにとって優れた収益化戦略ですが、複雑でリソースを大量に消費することがよくあります。広告の数が多いほど、リソースの消費量が増え、Page Speed に影響する可能性があります。これは、処理能力メモリがデスクトップやノートパソコンほど大きくないことが多いモバイル デバイスに特に当てはまります。
収益化とパフォーマンスのバランスを検討します。ユーザー エクスペリエンスの低下が原因でユーザーが早期に離脱している場合、広告を追加したことで得られる収益よりも、失う収益の方が多くなる可能性があります。
過度なページサイズを避ける
大規模で複雑なページは、表示に時間がかかります。たとえば、1,000 種類の商品を掲載した商品ギャラリーがある場合、ユーザーのブラウザ ウィンドウに表示されるまでに時間がかかります。この時間を短縮するために、ページをページ分けするタイミングを検討してください。
さらにサポートが必要な場合はどうすればよいですか？
この投稿では、パフォーマンスに影響する可能性がある、ビジネス オーナーが考慮すべき一般的な事項をいくつか紹介します。これ以外にも、ウェブサイトのパフォーマンスを改善するためにできることについて、ウェブ デベロッパーに相談してさらに分析情報を得る必要があるかもしれません。
プラットフォーム固有の情報
ほとんどのプラットフォームはウェブ パフォーマンスを重視しており、パフォーマンスを改善するためのプラットフォーム固有のアドバイスを提供している場合があります。また、そのプラットフォームを使用する一環として、ウェブ パフォーマンスの専門チームにアクセスできる場合もあります。このチームは、サイトの改善方法についてさらにアドバイスを提供してくれます。
Lighthouse は、Stack Pack 機能を使用してプラットフォーム固有の情報も表示します。これにより、サポートされているプラットフォームのユーザーに適切なアドバイスを提供できます。
プラットフォームは時間の経過とともに継続的に改善されており、現在、多くのプラットフォームがパフォーマンスと Core Web Vitals に注力しています。プラットフォームを最新の状態に保ち、プラットフォーム デベロッパーによる最新の改善を活用できるようにしてください。
これは、プラットフォーム プロバイダがプラットフォームの更新を含むプラットフォームの管理を自動的に行うホスト型プラットフォームを使用している場合に最も簡単です。プラットフォームを自分でホストしている場合（たとえば、独自のサーバーにローカルの WordPress をインストールしている場合）、プラットフォームが定期的に更新されるようにすることで、プラットフォームのデベロッパーが実装した改善をサイトに反映できます。企業は、このメンテナンスを優先するか、メンテナンスを管理してくれるサービスを選択する必要があります。
ウェブ デベロッパーに依頼する
ウェブ パフォーマンスの専門知識を持つウェブ デベロッパーは、ビジネス オーナーよりも多くの問題に対処できる可能性があります。サイトの初期構築や定期的な変更のためにすでにウェブ デベロッパーを雇っている場合や、専任の開発チームがいる場合、またはデベロッパー（ウェブ パフォーマンスの専門知識を持つデベロッパーが理想的）を探す必要がある場合があります。
ここで紹介した提案だけでは、ウェブサイトのパフォーマンスの問題を解決するのに十分でない場合は、デベロッパーに相談してください。ただし、前述の例からもわかるように、デベロッパーと協力して、ビジネスの優先事項と開発上の決定のバランスを取りながら、ウェブサイトに適したソリューションを見つけることが重要です。
ウェブ パフォーマンスは、1 回限りの作業になることはほとんどありません。ウェブサイトのパフォーマンスを良好に保つには、改善後にウェブサイトが後退しないように、定期的なモニタリングとメンテナンスが必要になることがよくあります。
まとめ
ウェブサイトは多くの場合、ビジネスと顧客の最初の接点となるため、顧客にとって素晴らしい体験となるようにする必要があります。これは、ビジネスの第一印象を得る新規ユーザーだけでなく、リピーターやロイヤル カスタマーにも当てはまります。これらのユーザーには、可能な限りシームレスなエクスペリエンスを提供し、不満を感じさせないようにすることが理想的です。Core Web Vitals は、Google がサイトに考慮することを推奨しているユーザー エクスペリエンスの指標の 1 つです。ウェブにはさまざまなサイトがあるため、ユーザーはサイトに不満を感じると、他のウェブサイトを試すことができます（そして実際に試すでしょう）。
同時に、Core Web Vitals はウェブサイトの 1 つの指標にすぎません。ウェブサイトにどれだけの投資を行い、その投資に対してどのようなリターンが得られるかを判断するのは、ビジネス オーナー自身です。