Googleの2021年5月の更新：Core WebVitalsの詳細

公開: 2021-07-19

更新：デジタルマーケティングの世界は絶えず変化していますが、心配しないでください。私たちはその上にいます。 グーグルは、次のアルゴリズムについて彼らの考えを変えました。

ここで私たちのアップデートで最近の変更を読んでください、しかしこのブログも読んでください。

2021年5月、Googleは検索ランキングアルゴリズムの一部を形成するCore Web Vitals（CWV）メトリックを導入します。 これがあなたが知る必要があることであり、その前にすべきことです…

高速サイトが重要であることは誰もが知っています。 ユーザーエクスペリエンスが向上し、コンバージョン率が向上し、モバイルフレンドリーなどの他のページエクスペリエンス指標とともに、Googleでのモバイル検索ランキングがすでに考慮されています。

しかし、Googleはそれだけではありません。 2020年5月に、彼らはCore Web Vitalsについて私たちに話し、2020年11月10日に、Core WebVitalsが全体的なランキングアルゴリズムの検索シグナルとして組み込まれることを発表しました。

さらに、「優れたページエクスペリエンスを持つ検索結果のページを強調表示する視覚的なインジケーターをテストする」ことを計画しています。 そのため、CWVの最適化によってランキングが上がる可能性が高まるだけでなく、検索エンジンの結果ページからのクリック率が上がる可能性もあります。

これらの新しいCWV指標でフラグが立てられた潜在的な問題を監査して修正するために今すぐ行動することで、この変更が2021年に発効したときに、Googleのランキングが上がる可能性が高くなります。

しかし、最初に、要約…

要約：コアWebバイタルとは何ですか？

Core Web Vitalsは、サイト全体の速度スコアに含まれる3つの新しいページエクスペリエンスメトリックのセットです。 これらの指標は、GoogleのPageSpeedInsightsツールのPSIおよび他の場所でのLighthousePerformanceモニタリングですでに重要な役割を果たしています。

新しいCWVメトリックは、次のもので構成されます。 コアWebVitals3xメトリクス

最大のコンテンツフルペイント（LCP）

これは、fold要素の上の最大のものがユーザーにレンダリングされるまでにかかる時間です。 これは、全体的な速度スコアメカニズムの25％を占めるため、モバイルで最大のアイテムの配信を2.5秒以下に合理化することが非常に重要です。

サーバーの応答性、レンダリングブロッキングスクリプトとスタイル、CSS、フォント、画像の複雑さなど、多くの要因がLCPの向上に貢献しています。

最初の入力遅延（FID）

これは双方向性を測定します。 タップやクリックなどのユーザー入力に対するページの応答性。 ブラウザが最初の入力に応答する目標速度は100ms以下である必要があります。

ブラウザがページの読み込み中に大量のJavaScriptを解析または実行している場合、これによりCPUが拘束されるか、「メインスレッド」がブロックされ、デバイスの入力に対する応答が低下します。 高いFIDは通常、複雑なJavaScriptの指標です。 これは、単一のスクリプトまたは関数、あるいは多数のスクリプトである可能性があります。

対話性までの時間と合計ブロッキング時間の既存のPSIメトリックは、FIDに関連しており、全体の速度スコアのなんと35％を占めています。

累積レイアウトシフト（CLS）

これは、折り目の上のコンテンツの視覚的な安定性の尺度です。 全体的な速度スコアの5％しか含まれていませんが、全体像を検討する価値はあります。 CLSが高いと、ページの読み込み中にビジュアルレイアウトが1つ以上変更されたことを示すことがよくあります。たとえば、バナーが読み込まれると、ページのコンテンツが下に移動します。

スピードスコアの内訳

次の図は、全体的な速度スコアの内訳と、これらの新しいCWVメトリックがGPSIスコアで果たす役割の大きさを示しています。

灯台スコア更新からのソースデータ

非CWVメトリックも、First Content Paint（FCP）、Time to Interactive（TTI）、Total Blocking Time（TBT）を含む全体的なスコアを形成しますが、3つのCWVメトリックに焦点を合わせると、他のメトリックに直接影響します。 高速LCPは、たとえば高速FCPなしでは不可能であり、高いFIDスコアはTBTとTTIの影響を直接受けます。

最大のコンテンツフルペイント最適化のヒント

LCPメトリックは、多数の個別の要因で構成されており、高いFCPの影響を直接受けます。 FCPに不良のフラグが付けられている場合は、ここから開始することをお勧めします。 ネットワーク接続、サーバーの応答性、最初のバイトまでの時間TTFB、レンダリングブロックファイルなど、すべてがFCP値に影響します。 これらのより一般的なページ速度の推奨事項の詳細については、以下のLCP固有のヒントに加えて、このテーマに関するページ速度の電子書籍を確認してください。

LCP値がFCPよりもはるかに高い場合は、この最大の要素の表示をより効率化する方法を検討する必要があります。

最大の要素を決定する

おそらく最初にやりたいことは、最大の要素が何であるかを判断することです。 最大の要素は、さまざまなブレークポイントで変化する可能性のあるピクセル領域に基づいているため、視覚的なスキャンで必ずしも適切な要素が識別されるとは限りません。

PSIでは、[診断]セクションに[最大のコンテンツフルペイント要素]パネルがあります。 または、以下に示すように、Chromeのパフォーマンスモニタリングツールのインジケーターにカーソルを合わせると、LCPを表示できます。 LCP最大要素診断

上記の例のHallamサイトでは、パフォーマンスモニターにLCPがメインの「ThriveOnline」の見出しとして表示されます。 理想的には、LCPはこの例のようにFCPの直後に続く必要があり、2つの間にギャップがある場合は、その理由を理解する必要があります。

フォントは最適化されていますか？

fold要素の上の最大のものがタイポグラフィである場合、フォントの配信が可能な限り合理化されていることを確認する必要があります。 これも：

  1. CSS font-display：swap;を使用します。 フォントファイルのロード中にすぐにフォントが表示されるようにします。 Google FontsとAdobeのTypekitの両方に、フォントの「display」パラメータを設定する機能があります。
  2. サードパーティのフォントに対してクロスドメインリクエストを行う代わりに、サーバー上で.woffおよび.woff2フォントファイルをローカルでホストしてみてください。 Google Fontsはかなり高速で、Typekitフォントは低速で、一部のサードパーティフォントファウンドリは信頼性が低い可能性があります。
  3. フォントファイルをプリロードすると便利です。 ローカルでホストされているフォントは、多くの場合、Webサイトのメインスタイルシートに含まれていますが、このスタイルシートをダウンロードして解析してから、その中のフォントに追加の要求を行う必要があります。 プリロードは、CSSが解析されるのを待たずに、フォントのダウンロードをより早く開始するようにブラウザーに指示します。
  4. サードパーティのフォントファウンドリには、preconnectとdns-prefetchを使用します。 これらのディレクティブは、フォントに対して要求が行われる前に、サードパーティドメイン間のDNS、TLS、およびTCP接続を確立するのに役立ちます。
  5. 折りたたみ式ディスプレイの上に必要なタイポグラフィ用のフォントファイルのみを含めてください。 Font Awesomeなどのアイコンライブラリのフォントアセットは非常に重いことで有名ですが、これら（および対応するアイコンライブラリCSS）へのリクエストは通常​​、延期して<head>要素の後に読み込むことができます。
  6. メインサイトのスタイルシート内のフォントファイルに対してクロスドメインリクエストを行わないでください。これは、接続性とサードパーティドメインの追加のルックアップに依存しているためです。
  7. Webセーフフォントを検討してください。 これらは、美学の点で非常に制限される可能性がありますが、フォントファイルへの要求を必要としません。

画像は最適化されていますか？

多くの場合、折り畳み要素の上で最大のものは画像であり、画像を最適化するために非常に重要です。 以下は一般的には良い習慣ですが、LCP要素にとって特に重要です。

  1. 正しい画像ファイルタイプを使用してください。 JPG画像は写真に、SVGはベクターグラフィックスとアイコンに、PNGはより複雑な非写真画像に、透明性が必要な場合に使用する必要があります。
  2. JPG画像が保存されるか、約50〜60％の品質で出力されることを確認してください。 このレベルでは、品質に認識できるほどの損失はないはずです。 また、画像からメタデータが削除されていることを確認してください。
  3. tinypng.comなどの圧縮プラグインまたはサービスは、画像を自動的かつ一括で最適化し、不要なメタデータを取り除くことができます。
  4. 画像は、表示する領域に合わせて適切なサイズにする必要があります。モバイルで高品質のデスクトップ画像を出力しないでください。
  5. 画像は、レスポンシブ画像の「srcset」属性を持つ標準の<img>タグを使用して出力する必要があります。
  6. 折り畳みまたは画面外の画像の下では、loading =” lazy”属性を使用する必要があります。
  7. さらに優れた圧縮率を得るには、次世代の.web画像ファイル形式を使用してください。 これにより、簡単に30％節約でき、多くの場合、はるかに高くなります。
  8. 折りたたまれた画像の上に最大のものをプリロードして、他の、潜在的に重要度の低いコンテンツよりも早くダウンロードを開始することを検討してください。

レンダリングブロックファイルを減らす

<head> </ head>要素にロードされたJavaScriptまたはCSSファイルは、ページのレンダリングを開始する前にこれらのファイルをダウンロードする必要があるため、レンダリングブロックと見なされます。 これは、FCPとLCPの両方の指標に大きな影響を与える可能性があります。 ヘッド内のレンダリングブロックファイルは、ページの折り畳み表示の上にある最初のファイルにとって重要な場合にのみ使用する必要があります。

<head>内の未使用のファイルを削除する、フッターに重要でないファイルをロードする、または複数のファイルをより少ないファイルに結合することで、レンダリングをブロックするアセットの量を減らすことができます。

LCPの表示にJavaScriptを使用しないでください

CWV以前は、これは大したことではありませんでした。 JavaScriptは、フェードテキストやヒーローカルーセルなど、折り畳み要素の上をアニメーション化または表示するために使用されるのが一般的であり、多くの場合、速度スコアにほとんどまたはまったく影響を与えません。

最大の要素の表示がJavaScriptに依存している場合、要素が表示される前にJavaScriptをダウンロード、解析、実行する必要があるため、多くの場合、長い遅延が発生する可能性があります。 JavaScriptファイルは通常（そして非常に正しく）<head>要素の後にロードされるため、「レンダリングブロック」されませんが、これは、LCPのレンダリングを効果的にブロックできることを意味します。

以下の例を見てください（ロゴがぼやけており、見出しが変更されています）。これは、PSIのスコアが高いサイトからのものです。 LCP（メインの見出しテキスト）は、テキストがフェードインする前にダウンロード、解析、および実行するJavaScript（黄色の帯で表される）の要件によって引き起こされるFCPから数秒離れています。

テキストのフェード自体も問題になる可能性があり、最大の要素の表示が遅れる原因になります。

このようなJavaScript技術は、全体的な速度スコアをすぐに25％低下させる可能性があるため、最大の要素の読み込みを妨げたり防止したりするために使用しないでください。

ウィンドウロード時にスクリプトを実行する

フォールドコンテンツの上にクリティカルを表示するためにJavaScriptが必要になることはめったにありません（必須ではありません）が、一般的な問題は、DOMの準備が整うとすぐに関数がトリガーされる可能性があることです。 人気のあるjQueryフレームワークでは、これは「ready」イベントを介して行われます。 Google Tag Managerは、準備ができたときに関数または「タグ」をトリガーすることもできます。

メインページのコンテンツが読み込まれた後、ウィンドウの読み込みイベントでコンテンツを重要に表示するために必要のないすべてのJavaScriptをトリガーして、折り畳み上のコンテンツとLCP要素のレンダリングとの潜在的な干渉を防ぐことを検討してください。

LCPを切り替えます

画像がどれほど最適化され、合理化されていても、ほとんどの場合、誤植要素と比較して、ダウンロードと表示に時間がかかります。 画像のLCPスコアを高速化することは完全に可能ですが、最大の画像要素を縮小して最大のテキスト要素よりも小さくすることで、代わりにテキストをLCPに使用できるようになる場合があります。

LCPがテキスト要素に切り替えられた以下の例に示すように、設計で許可されている場合、これはスコアに大きな違いをもたらす可能性があります。 LCPスイッチエレメント

最初の入力遅延最適化のヒント

前に述べたように、FIDはユーザー入力に対するページの応答性を測定します。 これは、インタラクティブTTIまでの時間と合計ブロッキング時間TBTを組み合わせたもので、全体の速度スコアの最大35％を占める可能性があります。

これらのメトリックは、主に、ページの読み込み中にスクリプトが解析および実行されることによって影響を受けます。 CPUのメインスレッドをブロックし、特にローエンドのスマートフォンデバイスの場合、デバイスの応答性に影響を与える可能性があります。

PSIに表示される「ラボデータ」はFIDを直接測定しないことに注意することが重要です。 これは、シミュレートするのが難しい、ユーザーによるタップまたはクリックからの測定のインタラクティブな性質によるものです。 代わりに、「フィールドデータ」によって収集されます。 ChromeユーザーエクスペリエンスレポートCrUXに基づいて、28日間にわたって実際のユーザーから収集された測定値。

そのため、FIDを直接最適化するのは少し難しいです。何かを変更して、さらにデータが収集されるまで28日待つことができないためです。 したがって、ラボデータのTTIおよびTBTメトリックを代わりに使用する必要があります。これらのメトリックの低い時間は、低いFIDに相関するためです。

では、これらのメトリックを最適化するにはどうすればよいでしょうか。

JavaScriptを監査する

JavaScriptにはさまざまな形とサイズがあり、単一のビデオ埋め込み、チャットウィジェット、ReCaptchaスクリプト、またはHubSpot統合が、高いFID、TTI、およびTBTメトリックの背後にある唯一の原因であることは珍しくありません。

Page Speed Insightsの診断パネルは、開始するのに適した場所です。 「メインスレッドの作業を最小限に抑える」のセクションでは、JavaScriptが占める実行時間を示し、「JavaScriptの実行時間を短縮する」セクションでは、解析時間と実行時間が長いファイルを示し、「サードパーティの影響を減らす」を示します。 code 'は、影響の大きいサードパーティのスクリプトを強調表示してグループ化します。

以下のスクリーンショットは、インタラクティブ時間の測定基準が15秒で、いくつかの重いスクリプトがあるサイトを示しています。 多くのスクリプトは、HubSpotやVimeoなどのサードパーティからのものです。

Google PageSpeedInsightsのサードパーティスクリプトの影響

これらのスクリプトがページの読み込みにどのように影響するかをより深く分析および視覚化するために、Chromeのパフォーマンスモニターツールは、起動されるスクリプトと関数、これらのスクリプトの相対的な影響、およびページの読み込みのどの時点でこれらをドリルダウンするための優れた方法です。長いスクリプトが実行されています。

以下の例は同じサイトのものであり、黄色、ピンク、オレンジのバーで表されたJavaScriptを示しています。バーが長いほど、実行時間の長いタスクを示しています。 これらの長いタスクをクリックすると、強調表示されたスクリプトが上記のPSIで強調表示された大きなスクリプトと相関していることがわかります。

パフォーマンスモニターの例
パフォーマンスモニターで大量のJavaScriptを示すスクリーンショット

どのスクリプトがパフォーマンスに影響を与えているかをよりよく理解したら、以下に概説するように、それらの影響を最小限に抑えるために使用できるいくつかの手法があります。

スクリプトを非同期でロードする

JavaScriptはデフォルトで順番に実行されます。 他のスクリプトのロードに依存しないスクリプトがある場合、これらのスクリプトは、他のスクリプトの解析と実行をブロックしないように、「async」属性を使用してロードする必要があります。

JavaScriptを条件付きでロードする

多くのサイトでよく見られる問題は、重いスクリプトがグローバルに読み込まれるか、不要なときにページに読み込まれることです。 たとえば、フォーム送信時のスパムを阻止するためにReCaptchaを使用する必要がある場合は、フォームのあるページにのみスクリプトをロードするようにしてください。

JavaScriptバンドルを合理化する

jQuery UIやBootstrapなどのJavaScriptライブラリは、追加のJavaScript機能を提供するためによく使用されます。 バンドルを使用する場合は、不要なJavaScriptがダウンロードおよび解析されるのを防ぐために、バンドル内に関連する機能のみを含めるようにしてください。

必要に応じて遅延読み込みスクリプト

JavaScriptが必要なページにのみロードされる場合でも、スクリプト自体は必ずしもページのロードまたはウィンドウのロードイベント中に解析および実行する必要はありません。 実際に必要な場合にのみJavaScriptをロードすると、TTI、TBT、およびFIDのメトリックに大きな違いが生じる可能性があります。 ここではいくつかの例を示します。

  1. YouTubeやVimeoなどのビデオ埋め込みは、通常、影響が大きくなります。 代わりに、ビデオサムネイルをクリックするときにのみ、これらのスクリプトをロードすることを検討してください。
  2. HubSpotなどのサードパーティフォームの統合は集中的に行われる可能性があります。 フォームがモーダルまたはページの下部に表示される場合は、ページの読み込みではなく、スクロールまたはモーダルのアクティブ化時に必要なスクリプトを読み込むか挿入することを検討してください。
  3. ライブチャットウィジェットは、全体的な速度スコアに最大35％影響を与える可能性があります。 ライブチャットウィジェットを、グローバルな「ライブチャット」CTAをサポートする専用の連絡先ページに移動するか、「チャット」ボタンがクリックされたときにのみライブチャットスクリプトを挿入することを検討してください。
  4. 埋め込まれたiFrameベースのコンテンツに 'loading =” lazy”属性を追加すると役立ちますが、これは新しいブラウザ機能であり、使用するiFrameの埋め込みに応じてテストする必要があります。

ビジネスインテリジェンスツールを評価する

HotjarなどのツールやVWOなどのA / Bテストソフトウェアを使用してユーザーの行動を分析することは、ビジネスインテリジェンスにとって非常に重要であり、多くの場合、その利点がサイトの速度への影響を上回ります。

そうは言っても、データが分析される頻度に応じて、これらのツールを24時間年中無休で実行することの重要性を評価することは依然として価値があります。 たとえば、アクティブなテストが実行されていない場合、A / Bテストをオフにする必要があります。十分なデータが収集および処理された後、Hotjarなどの動作分析ツールが非アクティブ化される場合があります。

累積レイアウトシフト最適化のヒント

累積レイアウトシフト（CLS）は、全体的な速度スコアの5％しか占めない場合がありますが、それでも、特にページの読み込み時に大量のシフト要素がユーザーに不快感を与える可能性があるため、全体像の重要な部分です。

CLS要素を決定する

どの要素がコンテンツのシフトを引き起こしているのかが明らかな場合もありますが、以下に示すように、PSIの[レイアウトシフト]パネルでこれを確認することは常に価値があります。

レイアウトシフト診断

CLSメトリックは0.1未満である必要がありますが、上記の例では、これを400％以上超えており、スコアが5％低下します。 これが地球規模の問題である場合、それはすべてのページで5％です。

シフトする要素は、影響の順に識別して対処する必要があり、折り目の上下の要素が含まれる場合があります。 以下に、レイアウトシフトの最も一般的な原因と解決策のいくつかを強調しました。

アニメーションに気をつけろ

ユーザーがページを下にスクロールするときに、画像、テキスト、またはコンテンツのパネルをフェードインまたはスライドさせるなど、特定のアニメーション手法を使用してコンテンツがユーザーに表示される方法を変更することは非常に一般的です。 これらは見た目に美しいかもしれませんが（誰に尋ねるかによって異なります）、これらの手法がページの読み込み中にコンテンツをシフトしないことが重要です。

コンテンツを非表示にしてからユーザーにフェードする必要がある場合は、コンテナのサイズまたはページの合計の高さが、コンテンツが読み込まれるときに変更されないようにしてください。コンテンツは、表示ではなくCSSの可視性ルールを使用して（必要に応じて）非表示にできます。 これにより、必要なスペースの基本的な量が保持されます。

画像のサイズを指定する

<img>タグに幅と高さの属性が設定されていない場合、またはCSSを使用して画像のサイズや比率を設定していない場合、ブラウザは、必要なピクセル領域を決定する前に、まず画像をダウンロードする必要があります。これにより、画像が読み込まれるときに、画像の下にレンダリングされるコンテンツがシフトする可能性があります。

画像をダウンロードする前に、画像の幅と高さを指定したり、CSS内で画像（または親コンテナ）のサイズや比率を設定したりすると、ブラウザは画像を表示する必要のある領域を認識し、潜在的なレイアウトを回避できます。シフト。

バナー

広告、Cookieのローバー、またはバナーに重要な情報を表示するために使用されるその他の情報は、おそらくCLSが高い原因の最も一般的な原因の1つです。

バナーコンテンツは外部データソースから、または同じサイトからJavaScriptを介して読み込まれるのが一般的です。つまり、コンテンツが読み込まれるまでバナーコンテナのサイズを計算できない場合があります。 これが発生すると、バナーコンテンツが読み込まれ、ユーザーに表示されると、バナーの下のコンテンツが下にシフトします。

これにはいくつかの解決策があります。

  1. ブラウザがプレースホルダーを効果的にレンダリングできるように、CSSでバナーまたはバナーコンテナの最小の高さを設定します。 ただし、コンテンツの量が動的で不明な場合、これは問題になる可能性があります。
  2. 絶対に、または画面の上部または下部にバナーの位置を固定します。 閉じたり閉じたりできるバナーの場合、固定要素は他の要素の配置に影響を与えないため、これは適切な考慮事項です。
  3. 可能であれば、バナーコンテンツのサーバー側のレンダリングを確認してください。つまり、コンテンツとバナーのサイズは、ユーザーに届く前に事前に読み込むことができます。

概要

上で強調したテクニックのいくつかが、Googleの新しいCore WebVitalsに関するパフォーマンスの問題の診断とトラブルシューティングに役立つことを願っています。 Hallamでの過去数か月間、速度監査と開発チームによる直接的な改善の両方の観点から、多くのクライアントがWebサイトのパフォーマンスを改善するのを支援してきました。

この記事が役に立った場合は、WebサイトのパフォーマンスeBookもチェックしてください。この電子書籍では、Webサイトを構築または管理する人が恩恵を受けることができる、ページ速度に関するより一般的な推奨事項について詳しく説明しています。