新しいGoogle基準：コアWebバイタル
公開: 2020-12-012021年5月更新
SEOマーケティングでは、企業、ブログ、Webサイト、およびオンラインプラットフォームが毎日競合しています。 グーグルのリストの一番上は彼らがなりたいところです。
グーグルの無数のリストのうち、リストされたサイトの90％は決してトップページにたどり着きません。 その10％は、有料広告、知識グラフ、および約10のオーガニックリストです。 それらの間のトラフィックは不均一です。 フォローアップページの結果に到達するのは、Webユーザーの3％未満です。
これまで、SEOマーケティングのメカニズムに影響を与えた主なものは、見出し、コンテンツ、タイトルタグ、キーワード、画像の説明、内部リンク、バックリンクなどでした。品質管理、巨大なエンジンに重点を置いて、Googleは新しいものを考慮に入れます。必須。
Core Web Vitalsは、米国の技術的なSEOエージェンシーの決定的なコンポーネントになる予定です。 また、検索結果を再定義することも期待でき、再定義する傾向があります。 従来のSEOマーケティングは基本的に関連性、距離、卓越性を取り入れていますが、Core WebVitalsは価値を定着させます。
目次
- コアWebバイタルとは何ですか？
- コアWebバイタルの3つの要素
- 最大の満足のいくペイント
- 最初の入力遅延
- 累積レイアウトシフト
- コアWebバイタルメトリクス
- コアWebバイタル分析ツール
- コアWebバイタルの最適化が重要な理由
- 結論
コアWebバイタルとは何ですか？
Core Web Vitalsは、Webサイトのユーザーエクスペリエンス（UX）を決定する個別のメトリックセットです。 後者には、3つの異なるページ速度とクライアントノードの相互作用の測定値が組み込まれています。 これらの要素の累積は、ページがリストとして受け取る優先度を決定するスコアリングシステムで機能します。
コアWebバイタルの3つの要素
最大の満足のいくペイント
Largest Contentful Paint（LCP）は、ユーザーの満足度を確保するためにGoogleが作成した測定値です。 このパラメーターは、プレゼンテーションよりもパフォーマンスに重点を置いています。 ページの読み込みに時間がかかりすぎてWebサーファーが離れる場合、これは不十分であると見なされます。
ウェブページの読み込み時間と、画像タグや動画のサムネイルなどのGoogleエクスペリエンスの要素によって、LCPの評価が決まります。 CSSを含む背景画像と、段落、見出し、リストなどのテキスト要素も流暢さを監視されます。
不十分なLCPの原因
サーバーの応答時間が遅い
Webサイトのレンダリング速度は、サーバーの反応時間に依存します。 サーバーの速度が遅いほど、デバイスの画面に表示されるまでの時間が長くなります。
ここでの主な解決策は、サーバーを最適化することです。 アセットのキャッシュとHTMLキャッシュファーストの提供により、サービスプロセスが促進されます。 さらに、ユーザーを近くのCDNにルーティングすることをお勧めします。 サードパーティの接続を早期に確立することで、遅延が最小限に抑えられます。これは、モバイルレスポンシブWebサイトにとって重要です。
CSSおよびJavaScriptのレンダリングブロック。
ブラウザは、HTMLマークアップをDOMツリーに解析することでコンテンツを配信します。 パーサーが外部スタイルシートに遭遇すると、一時停止します。 スクリプトと外部スタイルシートは、ブロッキングリソース、FCP、そして最終的にはLCPの配布を遅らせます。
CSSとJavaは堅牢であり、服従、最小化、および縮小によって「多くの重み」を失う可能性があります。 Java圧縮に使用できるソフトウェアには、UglifyJS2、ClosureCompilerおよびYUICompressorが含まれます。 CSSnano、UNCSS、およびCSSOはすべて、CSSを圧縮できるメカニズムです。 これらのツールを導入することで、読み込みの最適化にかかる時間が短縮されます。
リソースの読み込み時間が短い
CSSおよびJavaScriptアクティビティの増加は悪い結果をもたらしますが、他のコンポーネントも同様に問題があることがわかります。 LCPに悪影響を与える要素は、<image>、<img>、<video>、およびテキストノードを含むブロックレベルのコンポーネントです。
ここでは、画像ファイルとテキストファイルの最適化と圧縮が役立ちます。 別のサービスワーカーを使用しながら、必要なリソースをプリロードしてアセットをキャッシュすることにより、必要な時間が短縮されます。
ユーザーエンドレンダリング
クライアント側でほとんどのレンダリングを行うサイトは、かなりの量の制御を失います。 このオプションの欠点は、大きなJavaScriptバンドルを使用すると明らかになります。 ほとんどの場合、JavaScriptがレンダリングを完了するまでコンテンツは表示されません。 LCPの評価を危険にさらします。
JavaScriptの最小化は非常に重要であり、サーバーエンドのレンダリングはユーザーエンドよりも望ましいです。 別の解決策は、ロードの最適化の時間を支援する事前レンダリングです。
最初の入力遅延
First Input Delay（FID）は、最初のユーザー操作からブラウザーが応答するまでの時間を測定します。 クライアントがサイトを離れるかどうかは重要な要素です。 遅延は通常、ブラウザのメインスレッドがビジー状態のときに発生します。
ローカルアプリによってロードされたJavaScriptファイルは、通常、FIDの問題のせいです。 ブラウザが解析と実行を試みますが、遅延が発生し、エンドデバイスで応答がなくなります。 FIDレーティングが低いと、問題のサイトまたはページが使用できないことが確認される場合があります。
FID不良の原因
JavaScript
通常、メインスレッドがビジー状態の間、ブラウザはインタラクションに応答できません。 JavaScriptを大量に実行すると、この問題が悪化し、読み込み速度に遅延が生じます。
長いタスクを分割することで、バックログを軽減できます。 さらに、JavaScriptランタイムを制限すると、応答性が向上するはずです。 Webワーカーの使用も役立ちます。 これらはすべて、インタラクションのためにWebサイトのメトリックを最適化する方法です。
累積レイアウトシフト
累積レイアウトシフト（CLS）メトリックは、Webページのデザインの安定性を測定します。 これは、クライアントとのやり取りが可能な限り自然に流れるようにするために機能します。 Webサーファーは、サイトのコンテンツを表示しているときに、中断やジャンプを経験することがよくあります。 したがって、それは集中力の崩壊につながり、貧弱な経験を生み出します。
不便は弱いデザインの結果です。 この効果は、モバイルレスポンシブWebサイトとデスクトップブラウザで優先されます。
正しいデザイン要素の欠如は、視覚的な不安定さを引き起こします。 後者は突然のレイアウトシフトを強制する傾向があり、多くの場合、ユーザーが不要なコンテンツをクリックしてしまう原因になります。 典型的な例は、ポップアップ広告のあるサイトです。
新しいデザインは、正しく構造化されていても、Webページの速度を低下させる可能性があります。 Googleのアルゴリズムは、計算プロセスを開始する前に500ミリ秒の省略を許可することで補正します。
CLSの一般的な原因
寸法のない画像
ビデオと画像の両方の幅と高さのサイズ属性を除外すると、ランキングが低くなります。 多くの人はメディアのためのスペースを予約していません、そしてこれはジャンプとシフトをもたらします。
ここでの解決策は簡単です。 常に幅と高さを含めます。 もう1つのオプションは、CSSアスペクト比ボックスです。 ウェブサイトのスペースの予約に便利です。 これは、広告をホストするサイトで特に役立ちます。
ディメンションのない広告、埋め込み、Iframe
広告はこの問題の大きな原因です。 広告ネットワークは、ウェブサイトへのトラフィックを増やす静的なバリアントとは対照的に、動的なサイズ設定を選択します。 残念ながら、これはデスクトップまたはモバイルエクスペリエンスを犠牲にします。
特定のウィジェットを使用すると、ビデオ、マップ、ソーシャルメディアコンテンツなどのアイテムをWebページに埋め込むことができます。 ここでの問題は、サイトが埋め込みの正確なサイズや構成を知らないことが多いことです。 スペースを予約しないことにより、ページが読み込まれると不安定さが明らかになります。
サイトの埋め込みまたはフォールバックに必要な空間的ニーズを事前に計算することで、CLSの危険を回避できます。 ブラウザ開発ツールは、結果の高さと幅を取得するのに便利です。 これを確立すると、ページが読み込まれるたびにiframeが予約済みのスペースに自動的に収まります。
動的に注入されたコンテンツ
古いメディアの上に新しく挿入されたアイテムも、レイアウトの変化を引き起こします。 これらの典型的な例は、召喚状のバナーです。 彼らは相互作用を妨げるだけでなく、説得するのではなくイライラさせます。
もう一度、スペースを予約します。 さらに、サイト設計者はUIスケルトンを追加できます。 後者は、画像の読み込み時にテキストが移行されないようにするプレースホルダーです。
FOIT / FOUTの原因となるWebフォント
Web書体のダウンロードとレンダリングは、Flash of Unstyled Text（FOUT）に役立ちます。 この場合、新しいスタイルがフォールバックプリントに置き換わります。
追加の結果は、新しいケースが利用可能になるまで書体を非表示にするFlash of Invisible Text（FOIT）です。
Font Loading APIは、必要なレタリングスタイルを取得するために必要な時間を短縮し、FOUTとFOITの発生を最小限に抑えるか根絶します。
コアWebバイタルメトリクス
前述のように、3つのコアWebVital要素には個別の測定値があります。 それぞれが異なる時間基準に従って採点されました。
- 良好なLCP評価は2.5秒未満です。 Googleは4歳未満のすべてに寛大さを認めますが、これはまだ改善の余地があることを意味します。
- FIDの測定単位はミリ秒であり、ユーザー入力からWebページの反応までの時間が100未満の場合、これが理想的です。 300msのメトリックは許容されますが、これは今後の問題を示唆しています。 300ミリ秒を超えると、Webリストの降格につながります。
- CLSの理想的な読み取り値はゼロです。 Googleのアルゴリズムは0.1を受け入れますが、最大許容範囲は0.25であるため、柔軟性を確保するにはマージンが小さすぎます。 ウェブサイトの管理者は、完全な完璧を目指して努力することもできます。
コアWebバイタル分析ツール
- Web Vitals For Chromeは他の拡張機能と同様であり、プライバシー上の懸念から、このオプションに慣れていない場合があります。
- ページ速度の洞察は、デスクトップとモバイルのオプションを切り替えることができるシンプルなインターフェースです。 PCとスマートデバイスの結果は、使用する分析ソフトウェアに関係なく異なります。 上記は、28日間にわたる実際のGoogleユーザーのフィールドデータを生成します。
- Chrome Dev ToolsとLighthouseの設計により、LCPとCLSを監視できます。 残念ながら、同じソフトウェアではFIDを測定できませんが、そのためにTBTがあります。
Core Web Vitalsが急増するにつれて、より多くの監視ツールが登場するようになります。
コアWebバイタルの最適化が重要な理由
Googleのコアアップデートは2021年5月に行われる予定です。これは、それ以降、通常のSEO信号ではGoogleでの上位を維持するのに十分ではないことを意味します。
これは、高品質のUXを提唱する標準の実装です。 新しい基準に準拠しているサイトは影響を受けません。 調整されていないWebページは、SEOがどれほど効果的であるにもかかわらず、効果を実感できるはずです。 Core Web Vitalsが弱いリストはランキングが下がり、準拠しているエンティティのための余地ができます。
結論
SEOマーケティングに新しい規制を設定することで、Googleは改善への道を開きます。 Core Web Vital標準が最初であり、さらに多くの標準が続くことは確実です。 これらの対策は、インターネットの新時代が他の完璧に出現しているテクノロジーと融合するためのプラットフォームを作成します。 さらに、これらのヒントを使用して、Webサイトの読み込み速度を上げることができます。