サイト速度を上げてもGoogleの順位は上がらない?Core Web VitalsのLCP・CLS・INP

Googleが、Core Web Vitalsが良好であることで検索順位が上がると明言していることで、ページの読み込み速度を上げることに躍起になっている方も多いと思います。

しかし、サイト速度(ページ速度)を上げたことによって検索順位が上がることはほとんどありません。元の速度が極端に遅かった場合に上がる可能性はありますが、それ以外の場合ではほぼ無風です。

サイト速度は早いに越したことはありませんが、それによるSEO的な加点は大きくありません。ビッグワードで上位表示しているサイトの速度を測ってもわかるように、現時点では多少遅いぐらいのサイトでは悪影響を感じません。

サイト速度の改善は検索順位を上げるために行うものではなく、ユーザビリティやコンバージョンの観点で考えるべきものです。当然サイト速度は早いほうがよいです。メインコンテンツが表示されるまでに何秒もかかるようではユーザーが離脱してしまいます。

ストレスなくページが表示され、サイト内をサクサクと進めることでユーザー体験がよくなります。サイトによって速度が落ちるボトルネックが違うため、これをすれば簡単に早くなるという施策はありません。共用サーバーによる限界もあります。

  • 速度が遅すぎるサイトは対策しましょう!
  • 速度を上げることに時間やお金をかけすぎないようにしましょう!
  • WordPressならプラグインで画像をWebpに変換すればスコアがかなり上がる可能性あり!
目次

Core Web Vitalsとは

サイト速度とSEOの話でポイントになるのが、Core Web Vitals(コアウェブバイタル)です。

Core Web Vitalsとは、ユーザー体験(UX)をより優れたものにするための指標のことです。

2024年3月からは、「LCP・CLS・INP」の3つがCore Web Vitals指標になります。

LCP(Largest Contentful Paint)ページ内で最も大きいコンテンツの読み込みにかかった時間
CLS(Cumulative Layout Shift)ページのレイアウトがどれだけ崩れたかを数値化
INP(Interaction to Next Paint)ページ内でユーザーが起こした操作に対する反応速度。入力遅延時間+処理遅延時間+表示遅延時間を計測
※2024年3月から追加
FID(First Input Delay)ユーザーが最初に入力した操作に対する反応速度。入力遅延時間のみを計測
※2024年3月で廃止

LCP・CLS・INP(FID)を良好に保つことが、ユーザー体験によいとされています。

Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標です。検索結果でのランキングを上げ、全般的に優れたユーザー エクスペリエンスを提供できるよう、サイト所有者の皆様には、Core Web Vitals を改善することを強くおすすめします。

※Google公式サイトより

Google公式サイトのCore Web Vitalsに関するページで、「検索結果でのランキングを上げ」と書かれていることで、ページ速度が検索順位に大きな影響を与えると勘違いする人が続出しているわけです。

自分のサイトを修正する必要があるのかを調べる

Google Search Consoleを見ると、サイト速度(ページエクスペリエンス)に問題があるか否かがわかります。

ページエクスペリエンスのウェブに関する主な指標が「良好」になっていれば、大きな問題はありません。速度は気にしなくてよいでしょう。

ページエクスペリエンスとは、Webページの利便性を測る指標のことです。速度に限った指標ではありませんが、速度が遅いサイトは良好なページ数が少なくなっているはずです。

「不良」や「改善が必要なページ」が多ければ修正したほうがよいでしょう。不良が多い場合には、検索順位に悪影響を与えている可能性があります。

新しい指標であるINPについても、現時点で問題のあるページがあれば表示されるようになっています。

速度計測ツールで調べる

ページ速度が気になる方は、速度計測ツールで自分のサイトをチェックしてみましょう。

Google PageSpeed Insightは最も利用されている測定ツールです。個別URLの表示速度が確認できますが、データが少ないサイトはオリジンサマリー(ドメインの平均値)が表示されます。詳しい使い方は後述します。

TREO SITE SPEEDは、過去1年間のオリジンサマリーの表示速度が確認できます。新規サイトやアクセス数が少ないサイトはデータが確認できません。

PageSpeed Compareは、個別URLの表示速度が確認できます。入力したURLをクロールするため、新規サイトやアクセス数が少ないサイトでもデータが確認できます。

Google PageSpeed Insightsで速度を測ってみる

サイトの速度を測るツールとして有名なのが、Google PageSpeed Insights(ページスピードインサイト)です。

PageSpeed Insightsの注意点
  • パフォーマンススコアは速度を表しているわけではない
  • パフォーマンススコアが高くてもGoogleの順位が上がる訳では無い
  • LCP、CLS、INPの速度を上げてもGoogleの順位が上がることはほとんどない
  • 1回計測しただけでは評価がわからないので最低3回は計測する

ウェブに関する主な指標の評価が「合格」になっていれば特に何もしなくてOKです。

これは当サイトのPageSpeed Insightsの結果です。2024年1月のサイトリニューアルして、暇つぶしで高速化しました。

右上に「このURL」ではなく「オリジン」と表示されています。

アクセス数が少ないページは、実際のユーザーデータが不足しているため、ドメイン全体のデータを平均化して評価されます。オリジンとなっている場合は、「実際のユーザーの環境で評価する」という項目で、個別URLの指標を知ることはできません。

オリジンデータの評価が合格となっていれば、サイト全体の評価として合格ラインに達しているので、安心して大丈夫です。あとは気になる記事を個別に調査していきましょう。

トップページのスコア

当サイトのリニューアル直後のトップページの結果ですが、Core Web Vitalsの指標であるLCPが2.8秒でオレンジになっていますね。

JavaScriptやCSSが原因でレンダリングが遅延していたり、ファーストビューに画像を置くとLCPの値が悪くなる事が多いです。診断結果で「最大コンテンツの描画」要素と表示されるものです。

これぐらいなら気にする必要はありませんが、画像が原因であれば比較的簡単に改善できます。

PageSpeed Insightsの結果は環境やタイミングによっても変わるので、ブラウザや時間を変えて3回ほど計測して平均を取るのがよいと思います。すぐに再計測すると前回と同じ結果が表示されるので、少し時間を空けてから試してください。

アクセスの大半はスマホなので、デスクトップ(PC)の数値は無視してもよいでしょう。

点数が高い=速度が早いというわけではありません。
また、キャッシュの利用や遅延読み込み、Webpなどの次世代フォーマットによる画像配信を行えばパフォーマンススコアを上げることは難しくありません。

Webpに変換した後のスコア

WordPressなら簡単に高速化できるのが、画像を次世代フォーマットのWebpに変換することです。

やり方については後述します。

画像をWebpに変換しただけで、LCPが2.8秒から2.0秒になりパフォーマンススコアも上がりました。

現在のトップページの点数はこんな感じです。メインビジュアルや大きめの画像をいくつか追加ましたが、LCPは変わらずスコアもほぼ同じでした。

個別記事のスコア

当記事を公開後にチェックしてみたら、LCPが4.2秒で赤くなっていました。画像が多いので仕方ありませんが、ここまでLCPの数値が悪いとパフォーマンススコアも下がります。

診断で指摘されているのは、やはり画像関係の項目が多いです。

Webpに変換した後のスコア

これが当記事をWebpに変換した後のスコアです。LCPが大幅に改善されスコアも上がりました。

SWELLの画像等のLazyload設定を「スクリプト(lazysizes.js)を使って遅延読み込みさせる」にしたら、さらにLCPが高速化しました。Total Blocking Timeが250ミリ秒ぐらいになることもありますが、これぐらいなら気にする必要はありません。

他のサイトも測ってみた(1)

当サイトと同ドメインに設置している別テーマのサイトも計測してみました。

これは下層ディレクトリに設置しているALBINOTEの結果です。本体とは別WordPress+別テーマを使っています。

始めからこれぐらいのスコアが出ているサイトは、何もする必要はありません。

Webpに変換した後のスコア

元々速かったサイトがさらに早くなりました。

他のサイトも測ってみる(2)

これは下層ディレクトリに設置しているFPマネー学の結果です。本体とは別WordPress+別テーマを使っています。

Webpに変換した後のスコア

このサイトは運営歴が10年以上で、uploads内のファイル数が10万もあったので、Webp変換に40分もかかりました。

記事内で使っている画像が少なくても、過去に大量の画像をアップロードしているサイトは、プラグインを使って変換しても時間がかかります。

PageSpeed Insightsで指摘されることが多い項目

サイトによってPageSpeed Insights診断で指摘される項目が違いますが、以下の項目で引っかかることが多いです。

  • 次世代フォーマットでの画像の配信
  • オフスクリーン画像の遅延読み込み
  • 「最大コンテンツの描画」要素
  • 過大な DOM サイズの回避
  • レンダリングを妨げるリソースの除外
  • 適切なサイズの画像
  • 第三者コードの影響を抑えてください

一つずつ修正していってもよいのですが、ある程度のところで諦めるのが肝心です。なぜなら時間や手間をかけて修正したところでユーザーの体感速度はあまり変わりませんし、検索順位も上がらないからです。

遅いサイトを普通の速さまで上げることは大事ですが、普通レベルならそれ以上を求めてもコストとリターンが合いません。私みたいに暇つぶしで速度を上げるのは構いませんが、沼る人も多いです。

次世代フォーマットでの画像の配信

「次世代フォーマットでの画像の配信」が気になって、全ての画像をJPEGからWebP・AVIFに手動変換する人もいますが、なかなか大変な作業です。画像のフォーマットは時代とともに変わります。過去にはJPEG 2000、JPEG XRなどもありましたが、普及する前に消えました。

今主流になりつつあるWebp(ウェッピー)は、2010年にGoogleが開発した次世代画像フォーマットで、画質を落とさずにJPEGよりも30%ほどファイルサイズが軽くなります。

Webpを利用するデメリットは、古いブラウザに対応していないことですが、Webpが登場してから15年ほど経った現在、Webpに対応していないブラウザを使っている人はほとんどいません。また、WordPressのプラグインで対応すれば、古いブラザには古いフォーマットの画像を表示することもできます。

WordPressを使っている人がプラグインで自動変換するのはよいですが、1つ1つの画像を自分で変換する必要がある場合は、コストとリターンが合わないのでやめた方がよいかもしれません。

Webpは「画質を落とさずにファイルサイズを小さくする」と解説される事が多いですが、Webpの圧縮率が50%だと画質が落ち、特にPNGの文字周りのにじみや色の境界などが気になるようになります。圧縮率は80%ぐらいがよいように感じます。プラグインでも変換ソフトでも画質レベルが選べるので、画質とファイルサイズを天秤にかけて適宜調整してください。

元々軽いサイズ(使っている色が少ない)PNGをWebpに変換すると、画質が落ちる上にファイルサイズが減らない(増えることもある)ことがあります。なんでもかんでもWebpにすればよいというものではありません。

プラグインでWebpに一括変換

WordPressサイトであれば「Converter for Media」などのプラグインを使って、簡単にJPEGやPNG画像をWebpやAVIFに変換することができます。※AVIFは有料

Converter for Mediaは、古いブラウザでWebpやAVIFが表示できない場合は、元の画像を表示するようになっています。

プラグインを停止すれば元の画像が表示されるようになるので、いつでも簡単にやめることができます。

Easy Watermarkといった画像に透かしを入れるプラグインと併用することもできます。

Converter for Mediaは初期設定のままでも使えます。既に挿入した画像を一括変換するときは「画像の一括最適化」から行います。

5,000個のファイルがあるuploadsが、約3分でWebpに変換できました。10万個のファイルで40分ほどです。

テーマ内の画像も変換できますが、header.phpやhome.phpなどのphpに直接貼り付けた画像は変換されません。

テーマ内の画像を変換したいときは、一般設定の対応ディレクトリーで「/themes」をONにして一括変換します。

画質の劣化が気になる人は、コンバージョン戦略で画質レベルを上げてみましょう。最も高画質の「可逆圧縮」にすることで画質は落ちませんが、ファイルサイズは大きくなります。

変換ソフトでWebpに一括変換

JPEGやPNGをWebpに変換したいときは、WebP Converterが便利です。

WordPress以外のサイトで、頻繁に変更しない画像については、Webp変換ソフトを使ってもよいかもしれません。uploadsではなくサーバーに直接アップロードしているような画像にも使えます。

使い方は簡単で、左下の項目を「JPG/PNG to Webp」にして、変換したい画像をドロップして、Convertをクリックするだけです。複数の画像をまとめて変換することができます。

オプションで変換後のファイル保存先と圧縮率が変更できます。

100%にしてもJPEGよりはWebpの方が軽くなりますが、それほどファイルサイズが減らせるわけではないので、高くても80~90%にしておくのがよいと思います。

50%でも、画質の劣化が許容範囲の画像も多いですが、明らかに劣化していて耐え難い画像もでてきます。この辺は、サイトジャンル、画像の使い所、閲覧するユーザー層などを考慮して判断しましょう。

私の環境では変更しても✕で閉じると設定が元に戻ってしまい50%から変えられませんでした。Windowsセキュリティがブロックしているようだったのですが、Webp Converterのプロセスを除外しても設定は変えられず原因は不明です。ググってもこれで困っている人は見つけられませんでした。

オンラインでWebpに一括変換

「Webp 変換 オンライン」などのワードでググれば、オンライン上にファイルをアップして変換してくれるサイトが見つかります。

Webp変換に限らず、オンライン上にファイルをアップして変換してくれるツールは、セキュリティに懸念があり好んで使いません。

数枚の画像を変換したいときなどは便利ですが、まとまった数の画像を変換したいときや、見られるとまずい画像が含まれているときはオフラインソフトで変換するのがよいでしょう。

「最大コンテンツの描画」要素

最大コンテンツの描画は、LCP(Largest Contentful Paint)のことです。

当記事であればファーストビューのテキスト部分が該当します。基本的にどのサイトでもファーストビューの要素になるはずです。

ファーストビューに大きな画像を置いている場合は、その画像が原因の場合もありますが、テキストのみの部分が要素になることもあります。

テキストが重いわけではなく、この部分を描画するまでに時間がかかっていることになります。サーバーの応答時間やJavaScript・CSSのレンダリングブロックなど色々な原因が考えられます。

画像が原因の場合は、サイズ調整、圧縮、次世代フォーマットに変換、プリロード(事前読み込み)などによって改善します。

JavaScriptやCSSが原因のことも多いです。コードを軽くしたり、非同期読み込みにしたり、読み込みを遅延させたり、CSSならインラインで読み込むことで改善できる可能性があります。

オフスクリーン画像の遅延読み込み

「オフスクリーン画像の遅延読み込み」については、WordPressなら自動的に画像の非同期読み込み「decoding="async"」が挿入されているので特に何もする必要はありません。

PageSpeed Insightsは、遅延読み込み(loading="lazy")にしろ!と言ってきますが、現在のWordPressではloading="lazy"は挿入されません。ページのHTMLソースを見るとdecoding="async"が付いているはずです。

WordPressバージョン5.5からloading=”lazy”が挿入されるようになり、バージョン6.1からdecoding="async"が挿入されるようになりました。

画像を入れたタイミングによるものなのかわかりませんが、画像によってはdecoding="async"とloading="lazy"の両方が挿入される形になっています。なお、両方書かれている画像はloading="lazy"が有効になります。

decoding="async"でもloading="lazy"でもどちらでも構わないはずなのですが、PageSpeed Insightsではloading="lazy"が評価されます。

Total Blocking Timeはあまり気にしない

画像の遅延読み込み(loading="lazy")をしないと、Total Blocking Timeの数値は悪くなりがちです。高速化の専門家が運営するサイトでもTotal Blocking Timeの数値だけ悪いケースを見かけます。

パフォーマンススコアが低くても、FCP、LCP、SIの秒数が合格ラインなら問題ありません。

逆にパフォーマンススコアが高く、Total Blocking Timeが低くても、LCPが4秒とかになっていたら気にしなくてはいけません。

非同期読み込みは、他のコンテンツの読み込みを妨げないための処理です。遅延読み込みではありませんが、速度を向上させる効果があります。

しかし、PageSpeed Insightsでは、非同期読み込みがあまり評価されません。decoding="async"が付いていても遅延読み込みさせろと言ってきます。

ファーストビュー以外の画像を全て遅延読み込みにすることで、Total Blocking Timeが下がり、パフォーマンススコアは上がります。

パフォーマンススコアを上げたいのであれば遅延読み込みにしてもよいですが、WordPressが標準で画像を非同期読み込みにしてくれているのだから、そのまま非同期読み込みにしておくのがよいと思います。

第三者コードの影響を抑えてください

ネックになりやすい「第三者コードの影響を抑えてください」については、遅延読み込みで対応するのがよいと思います。

SWELLを使っている方は、高速化のスクリプト遅延読み込みで、遅延読み込みしても大丈夫なものを記述します。

ちなみに、当サイトでは以下のような記述になっています。遅延させる秒数は3秒にしています。

twitter.com/widgets.js,
instagram.com/embed.js,
connect.facebook.net,
assets.pinterest.com,
googletagmanager.com/gtm.js,
googletagmanager.com/gtag/js,

SWELLにデフォルトで入っていた項目にGoogleタグマネージャーを追加しました。

プラグインで遅延読み込み

テーマ内に遅延読み込み用の設定がない場合は、プラグインで対応できます。

他サイトでは、Flying Scriptsを使っています。

使い方は簡単で、Include Keywordsに遅延させたいスクリプトの名前を記述するだけです。

遅延読み込みさせるということは、その間ユーザーは該当のスクリプトを読み込まないことになります。重要なスクリプトを遅延させないように注意してください。

Googleタグマネージャー(アナリティクス)を遅延させることで、サイトに訪問した瞬間に離脱するようなユーザーをカウントできなくなります。

合格ラインに達しているのであればタグマネを遅延読込する必要はないでしょう。

Googleアナリティクスの配信トリガーをウィンドウの読み込みにすることで「第三者コードの影響を抑えてください」が出なくなると解説する記事が多いのですが、ウィンドウの読み込みにしても消えませんでした。

「preconnect」「dns-prefetch」で事前読み込みさせても状態が変わらなかったので、遅延読込させました。

遅延させる前の状態はこんな感じです。GoogleタグマネージャーとMicrosoft Clarityが引っかかっています。

遅延させた後はこんな感じです。タグマネとClarityは消えました。別でmatomoというアクセス解析ツールを入れていて、これはbodyタグの最下部に貼っています。

ページ速度の改善作業はほどほどに

この記事を書いた人

竹内潤平のアバター 竹内潤平 代表取締役社長

Webマーケター/ファイナンシャルプランナー。埼玉県飯能市出身、1978年12月25日生。趣味は登山。Webライター歴23年。

SEO、HTML、CSS、WordPressが得意です。複数のサイトを自分自身で運営・管理しています。当サイトも私がテーマカスタマイズや記事の作成をしています。

個人で自動車ローンや住宅ローンを利用したことがあり、起業してからは法人で銀行融資や日本政策金融公庫の一般貸付、マル経融資でお金を借りた経験があります。

株式投資歴は20年以上で、現在は個別株投資やベンチャー投資をしつつ、NISAつみたて投資枠でオルカン、S&P500、日経225に投資しています。

FP技能士、宅地建物取引士、日商簿記検定、証券外務員、ITパスポートの資格を保有。

運営者情報

会社名 株式会社アルビノ
代表者 代表取締役社長 竹内潤平
住所 〒160-0023
東京都新宿区西新宿3-3-13 西新宿水間ビル6階
電話番号 03-6914-6178
全社テレワーク中のため、お電話を頂いても対応できない状況となっています。
お問合せ メールフォーム
設立 2014年10月20日
資本金 1000万円
事業内容 Webマーケティング支援
メディア運営
ライフプランコンサルティング
法人番号 7011101071501
本社所在地 〒176-0012
東京都練馬区豊玉北4-4-5
インボイス登録番号 T7011101071501
目次