コアウェブバイタル（アドセンス）のためにあなたのウェブサイトを最適化する方法

CoreWebVitalsを改善するための競争は簡単なものではありません。 あなたがあなたのウェブサイトを収益化するためにグーグルAdSenseのような広告プログラムに頼るならば、それはより難しくなります。

Google AdSenseを実行しているWebサイトは、GoogleAdSenseがインストールされていない同じWebサイトよりもコアWebバイタルテストに失敗する可能性が10倍高くなります。 これは主に、GoogleAdSenseがウェブサイトに追加するサードパーティのリクエストとアセットの数によるものです。 これらの資産のほとんどは、最適化されておらず、大きく、ユーザーフレンドリーではありません。

AdSenseと広告プラットフォーム以外で、最適化されていない画像、JavaScript、CSSが特に多くある場合は、CoreWebVitalsテストに失敗する可能性が非常に高くなります。

Core Web Vitalsテストに合格し、検索エンジンランキングの可能性を高めるのに苦労している場合は、この記事で実用的な解決策を見つけることができます。

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

Core Web Vitalsは、Google Lighthouseを利用した指標であり、サイトが優れたページエクスペリエンスをどのように提供しているかを判断します。 テストの実行には多くのメトリックがありますが、最も重要なメトリックは、最大コンテンツペイント（LCP）、最初の入力遅延（FID）、および累積レイアウトシフト（CLS）です。

Googleは発表しました 2021年XNUMX月以降、これらの指標は、検索結果でのWebページの位置を決定するために使用されるランキングシグナルの一部になります。

要約すると、Core Web Vitalsは、Webマスターにとっての恐怖ではなく、Webサイトのページエクスペリエンスを向上させる手段であると言えます。

最大のContentful Paint（LCP）：LCPは、ウェブページ上の最大の表示画像またはテキストブロックの読み込みにかかる時間を測定します。 表示されている最大のテキストまたは画像の読み込みが速い場合、残りの画像とテキストの読み込みが速いと認識されます。 通過するのに必要なロード時間は 2.5秒.

最初の入力遅延（FID）：FIDはWebページの双方向性を測定します。 これは、ユーザーがサイトをクリックした後、ブラウザーがイベントハンドラーの処理を開始するのにかかる時間によって決まります。 これは広くあなたのウェブサイトの第一印象と呼ばれています。 通過するのに必要な時間は 100ミリ秒.

累積レイアウトシフト（CLS）：CLSは、Webページで発生するレイアウトシフトを測定します。 Webページが読み込まれ、突然何かが表示または非表示になり、ページが大きくなったり小さくなったりするように調整する必要がある場合、そのシフトが測定されます。 それはユーザーエクスペリエンスにとってひどいものであり、私は同意します。 合格する必要のあるスコアは 0.1.

コアWebバイタルのためにあなたのウェブサイトを最適化する方法

次の手順に従って、Webサイトを最適化します。

1.高速ウェブホストから始めます

応答時間がひどいWebホストがある場合、ここにリストする他のすべてのものは、望ましい結果をもたらさない可能性があります。 サーバーがリクエストに応答する速度が速いほど、優れています。

最初のバイトまでの時間（TTFB）が速いWebホストが重要なのはなぜですか？ TTFBは重要ではないと主張する人もいますが、問題はありません。 それが他のすべての基盤です。 インターネットが遅い都市にユーザーがいる場合、Webホストがどれだけ速く応答できるかがすべてを意味します。 主に超高速インターネットを使用する都市のユーザーがいる場合は、どのWebホストでもパフォーマンスが向上します。

Webホストが3Gではなく2Gまたは4Gにどのように応答するかをテストしてみてください。 多くのユーザーが3Gまたは2Gを介して接続している場合、それはCoreWebVitalsスコアに加算されるためです。 したがって、ミリ秒ごとにカウントされます。 FIDで100msを取得することと101msを取得することの違いは、100msでは合格しますが、101msでは失敗することです。 したがって、1ミリ秒は問題ではないと誰かが言った場合、その人は間違っている可能性があります。

選ぶとき ウェブホスト、常にデータセンターをWebサイトユーザーの大多数に近づけるようにしてください。 あなたはあなたの分析を見ることによって彼らの場所を見つけることができます。 ほとんどのユーザーはどこから来ましたか？ それらに近いデータセンターを選択してください。 近いほど良い。

ウェブホストを変更した後、コアウェブバイタルのウェブサイトのフィールドデータに大きな変化があることに個人的に気づきました。 私は他に何もしませんでした。

あなたが高速のウェブホストを探しているなら、誠実さのないアフィリエイトによって純粋に推進されているたくさんの推奨事項がそこにあります。 WordPressを実行していて、余裕がある場合は、強くお勧めします キンスタ。 WordPressに最適です。 もっと安いものが必要な場合、またはWordPressを使用していない場合は 曇り とても効果的です。

2.軽量で速度が最適化されたテーマを使用する

このヒントは、非コーダーにとって、さらには時間のかからないコーダーにとっても非常に役立ちます。 特に、オプションが非常に多いWordPressを使用している場合は、軽量で速度が最適化されたテーマを使用するようにしてください。

テーマはウェブサイトのスケルトンのようなものなので、スケルトンが壊れると本体が壊れてしまいます。 それだけです。

テーマで探す必要のあるベストプラクティスの長いリストがあります。 最も一般的な悪い習慣のいくつかは、JQueryに過度に依存しており、不要なときにCSS / JSをロードしすぎたり、テーマのサイズが大きくなったりします。 あなたはいつでも次のようなツールを使うことができます 黄色い実験室、デモをテストします。

WordPressを使用している場合は、 最速のWordPressテーマ.

3。 画像を最適化する

画像はかっこいいです。 彼らはコンテンツをとても魅力的にします。 ただし、最適化されていない場合は、負担になる可能性があります。 3 MBのような大きな画像があると、速度に間違いなく影響します。 また、スクロールする前にサイトにアクセスしたときにこれらの画像が表示されている場合は、LCPメトリックに確実に影響します。

真実は、最適化されていない画像がページのサイズに追加されるということです。 ページサイズが大きいほど、読み込みに時間がかかります。

私は個人的に、アップロードする前にすべての画像を最適化することを好みます。 画像の最適化に外部サービスを使用していません。 ただし、WordPressまたは同様のCMSを使用している場合は、画像を自動的に最適化するためのプラグインとソリューションがあります。 使用するものに関係なく、クラウドソリューションもあります。

4.背景画像のサイズを削除または縮小します

背景画像は通常非常に大きいです。 また、意味のあるコンテンツが表示される前に最初にロードする必要があるため、ロード時間が遅くなる可能性があります。

背景画像を完全に削除して、より高速なWebサイトを作成できます。 それらが非常に重要な場合は、可能な限り最小のサイズに最適化するか、画像の代わりにパターンを使用することを検討してください。

5.ブラウザのキャッシュを使用する

忠実な読者がたくさんいる場合は、ブラウザのキャッシュを検討する必要があります。 ユーザーが初めてWebサイトにアクセスすると、ブラウザはそのWebサイトをキャッシュします。 XNUMX回おきにアクセスすると、すぐに読み込まれます。 これにより、XNUMX回目の訪問以降のFIDとLCPを大幅に改善できます。

WordPressユーザーの場合、ほとんどのキャッシュプラグインがこれを実現するのに役立ちます。

6. JavaScriptを縮小し、未使用のJavaScriptを延期します

JavaScriptは素晴らしいものですが、多くの場合、レンダリングがブロックされます。 これは、ロード時間、そして最終的にはFIDに影響を与える可能性があることを意味します。

ファイルサイズを小さくするために空白とコメントを削除してJavaScriptを縮小してみてください。 また、重要ではないJavaScriptを延期するようにしてください。 これにより、FIDが向上するはずです。

WordPressユーザーの場合、次のようなプラグインがあります Autoptimize、WP Rocket、およびこれを実行できるその他の機能。

7.AdSenseサイズ属性を設定します

ウェブサイトでAdSenseを実行していて、CLSに苦労している場合は、これですべての問題を解決できます。 それは私のためになりました、そしてそれはあなたのためにすべきです。

ユーザーがアクセスしたときに表示されるヘッダーの近くに広告ユニットがある場合、XNUMXつの問題は、広告がすぐに読み込まれない可能性があることです。 ページが既にロードされた後にロードされる場合があり、ロードされると、レイアウトにシフトが生じます。 これはレスポンシブ広告ユニットでは非常に一般的です。 そのため、CLSメトリックを渡すことは不可能です。

これを処理する最良の方法は、AdSenseコードを少し編集することです。 心配ありません、それは非常に合法です。 広告のサイズ属性、特に高さを指定するだけです。 これを行うと、広告が読み込まれるたびにレイアウトのずれに気付くことはなくなります。

以下は、ブログのヘッダーのすぐ下で使用したレスポンシブ広告ユニットの例です。 サイト運営者IDと広告スロットをXXXXXXに置き換えました。 height属性（min-height：300px）を追加したことに気づきました。 私がそれをした瞬間、すべてのCLSの問題は永遠になくなりました。

<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Header ad -->
<ins class="adsbygoogle"
     style="display:block; min-height: 300px"
     data-ad-client="ca-pub-xxxxxxxxxxxxxx"
     data-ad-slot="xxxxxxxxxx"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
     (adsbygoogle = window.adsbygoogle || []).push({});
</script>

これは、ページでそのサイズを予約することです。 したがって、広告が表示されるたびに、サイズをすでに設定しているため、レイアウトの変更はありません。

8.画像やその他のメディアのサイズ属性を設定します

広告の場合と同様に、画像やその他のメディアは、ウェブサイトに読み込まれるときにレイアウトがずれる可能性があります。 何かを読んでいるだけで、画像が読み込まれ、突然レイアウトがずれたり、読んでいたものが見えなくなったり、他の何かが表示されたり、誤って他の何かをクリックしたりする場合があります。

メディアファイルにsize属性を設定することで、これらすべてを回避できます。 あなたのCLSメトリックは、あなたがやったことに満足するでしょう。

9.画像の遅延読み込み。

PageSpeedInsightに関するアドバイスを見たことがあるかもしれません。 画面外の画像を延期する。 単純に意味するのは、画像を遅延ロードすることです。

遅延読み込みは、ページサイズを縮小し、ユーザーがアクセスしたときのページの読み込み時間を短縮します。 これはCWVメトリックに適しています。

これは特にLCPの改善に役立ちます。

10.重要なCSSを縮小して生成することにより、CSSを最適化します

CSSは、Webサイトの見栄えを良くするものですが、大きなCSSファイルは、ユーザーへのページのレンダリングを遅らせるため、大きな問題になる可能性があります。

ユーザーがWebサイトにアクセスすると、ブラウザーは通常の動作で、Webページヘッダーで参照されているすべてのCSSをロード、解析、および実行するまで、ユーザーへのWebページのレンダリングを遅らせます。 大きなCSSファイルがある場合、これは大きな問題になる可能性があります。 それはあなたのサイトを遅くします。

重要なCSSは、ページの読み込みに必要なCSSのみを読み込むことで役立ちます。 CSSの残りの部分は非同期でロードできます。

また、空白やコメントを削除してファイルサイズを小さくすることで、CSSを縮小することもできます。

あなたもすることができます 未使用のCSSを削除する。 使用しているサービスが使用されていないCSSをプッシュしている場合は、それらを削除しても安全です。

WordPressを使用している場合は、WP Rocket、LiteSpeed Cache、FlyingPressなどのプラグインがこれを実現するのに役立ちます。

11.AdSenseスマートローディングを実装する

この方法は、AdSenseがウェブサイトの速度を低下させる責任がある場合、すべての課題をほぼ完全に排除できます。

これはスマートな方法でAdSenseをロードすることについてです。 ユーザーがスクロールやクリックなどのアクションを実行するまで、AdSenseは読み込まれません。 これにより、読み込み時間とAdSenseの影響を受けるコアウェブバイタルが大幅に改善されます。

これを行うのに役立つWordPressプラグインはたくさんありますが、WPRocketやFlyingScriptsがその一例です。 私の知る限り、この方法はGoogleAdSenseポリシーに違反していません。

Note: この方法は、知覚される速度とページスコアを向上させるのに役立ちますが、AdSenseの収益に影響を与える可能性があります。 実験を行って、それが価値があるかどうかを確認することをお勧めします

12.可能であれば、システムスタックフォントを使用します

フォントは、どのWebサイトでも読み込み時間を長くします。 また、画像のないWebページの場合、テキストブロックがLCP評価の原因となる可能性があります。 この場合、LCPスコアはフォントに直接影響されます。

GoogleFontとFontAwesomeは引き続き改善されていますが、システムスタックフォントを使用すると大幅に改善されます。 デバイスによってはそれほど空想的ではありませんが。

13. CDNを使用する

世界のさまざまな地域からのユーザーがいる場合は、CDNを使用すると、速度を向上させ、間接的にCoreWebVitalsメトリックを向上させることができます。

簡単な説明のCDNは、Webサイトのコピーを多数作成し、世界のさまざまな地域のさまざまなPoint of Presence（POP）に保存します。 誰かがあなたのウェブサイトを要求すると、それは最も近い場所からあなたのウェブサイトを提供します。

たとえば、サイトが米国でホストされていて、英国からの訪問者がいる場合、米国からサイトを取得する代わりに、CDNは英国からサイトにサービスを提供します。 その効果は短納期になります。 スピード。

あなたはチェックアウトすることができます 最高のCDN そこに。

14.DNSプリフェッチを設定します

Webサイトの配信をCDNなどの外部サービスに依存している場合は、次のことを行う必要があります。 DNSプリフェッチを設定する DNSルックアップによる遅延を最小限に抑えるため。

DNSプリフェッチは、呼び出される前にDNSをプリフェッチします。 最終的に呼び出されたときに瞬時に読み込まれるようにします。

15.サードパーティのスクリプトを最適化する

サイトで使用しているサービスの一部が、サイトの速度を低下させる可能性のあるサードパーティのスクリプトを追加していないことを確認してください。

ソリューションをサードパーティのリクエストに置き換えて、サイトの速度を低下させることができます。

別のサードパーティのスクリプトであるGoogleAdSenseに関しては、できることはほとんどありません。 ベストプラクティスは、3ページに最大XNUMXつの広告を統合して使用することです。 収入は少なくなりますが、読み込み時間が長くなるため、一致するコンテンツは避けてください。

16.スクロールしなければ見えない位置からAdSenseを削除します

このアドバイスは実験に基づいています。 LCPを除くすべての指標が検索コンソールレポートで適切である場合は、最初に画像とフォントが最適化されていることを確認してください。 それらが最適化されていて、それでもLCPに失敗している場合は、AdSenseが原因である可能性があります。

余裕があれば、AdSenseをXNUMXか月間上から削除して、問題が解決するかどうかを確認します。

削除したくない場合は、手動で、またはFlyingScriptsなどのプラグインを使用して遅延させることができます。

17.AMPに切り替えます

AMPは、AcceleratedMobilePagesを意味します。 AMPの考え方は、ウェブページを最適化してモバイルでの読み込みを高速化することです。 そしてもちろん、AMP オープンソース プロジェクトはGoogleによって開始されました。

AMPは元々、モバイルページの速度を上げることを目的としていましたが、デスクトップページの速度を上げることもできます。

AMPページは、モバイルページやデスクトップページよりも一貫して高速であり、私たちの観察によれば、100％を超えることもあります。

ウェブサイトの唯一の現金化戦略がGoogleAdSenseである場合は、すべてのウェブサイトをAMPに切り替えることを検討してください。 私が所有するブログでは、AMPページのAdSenseがモバイルやデスクトップよりも変換されることがあることに個人的に気づきました。

結論

コアWebバイタルは、GoogleだけでなくユーザーのWebサイトを改善するのに役立ちます。 ラボデータのテストスコアは良好ですが、フィールドデータのスコアは不良であることが非常に一般的です。

これは、ユーザーの構成によるものです。 ほとんどのユーザーがインターネットの速度が遅い場所から来ている場合は、最適化はうまくいっていても、フィールドデータで失敗している可能性があります。