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を良好に保つことが、ユーザー体験によいとされています。
Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標です。検索結果でのランキングを上げ、全般的に優れたユーザー エクスペリエンスを提供できるよう、サイト所有者の皆様には、Core Web Vitals を改善することを強くおすすめします。
※Google公式サイトより
Google公式サイトのCore Web Vitalsに関するページで、「検索結果でのランキングを上げ」と書かれていることで、ページ速度が検索順位に大きな影響を与えると勘違いする人が続出しているわけです。
自分のサイトを修正する必要があるのかを調べる
Google Search Consoleを見ると、サイト速度（ページエクスペリエンス）に問題があるか否かがわかります。
ページエクスペリエンスのウェブに関する主な指標が「良好」になっていれば、大きな問題はありません。速度は気にしなくてよいでしょう。
ページエクスペリエンスとは、Webページの利便性を測る指標のことです。速度に限った指標ではありませんが、速度が遅いサイトは良好なページ数が少なくなっているはずです。
「不良」や「改善が必要なページ」が多ければ修正したほうがよいでしょう。不良が多い場合には、検索順位に悪影響を与えている可能性があります。
ウェブに関する主な指標のモバイルで、「問題ありません」と表示されていればサイトの状態は悪くありません。
速度計測ツールで調べる
ページ速度が気になる方は、速度計測ツールで自分のサイトをチェックしてみましょう。
Google PageSpeed Insightは最も利用されている測定ツールです。個別URLの表示速度が確認できますが、データが少ないサイトはオリジンサマリー（ドメインの平均値）が表示されます。詳しい使い方は後述します。
TREO SITE SPEEDは、過去1年間のオリジンサマリーの表示速度が確認できます。新規サイトやアクセス数が少ないサイトはデータが確認できません。
PageSpeed Compareは、個別URLの表示速度が確認できます。入力したURLをクロールするため、新規サイトやアクセス数が少ないサイトでもデータが確認できます。
Google PageSpeed Insightsで速度を測ってみる
サイトの速度を測るツールとして有名なのが、Google PageSpeed Insights（ページスピードインサイト）です。
- パフォーマンススコアは速度を表しているわけではない
- パフォーマンススコアが高くてもGoogleの順位が上がる訳では無い
- LCP、CLS、INPの速度を上げてもGoogleの順位が上がることはほとんどない
- 1回計測しただけでは評価がわからないので最低3回は計測する
これは当サイトのPageSpeed Insightsの結果です。2024年1月のサイトリニューアルして、暇つぶしで高速化しました。
右上に「このURL」ではなく「オリジン」と表示されています。
アクセス数が少ないページは、実際のユーザーデータが不足しているため、ドメイン全体のデータを平均化して評価されます。オリジンとなっている場合は、「実際のユーザーの環境で評価する」という項目で、個別URLの指標を知ることはできません。
オリジンデータの評価が合格となっていれば、サイト全体の評価として合格ラインに達しているので、安心して大丈夫です。あとは気になる記事を個別に調査していきましょう。
トップページのスコア
当サイトのリニューアル直後のトップページの結果ですが、Core Web Vitalsの指標であるLCPが2.8秒でオレンジになっていますね。
JavaScriptやCSSが原因でレンダリングが遅延していたり、ファーストビューに画像を置くとLCPの値が悪くなる事が多いです。診断結果で「最大コンテンツの描画」要素と表示されるものです。
これぐらいなら気にする必要はありませんが、画像が原因であれば比較的簡単に改善できます。
PageSpeed Insightsの結果は環境やタイミングによっても変わるので、ブラウザや時間を変えて3回ほど計測して平均を取るのがよいと思います。すぐに再計測すると前回と同じ結果が表示されるので、少し時間を空けてから試してください。
アクセスの大半はスマホなので、デスクトップ（PC）の数値は無視してもよいでしょう。
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のプラグインで対応すれば、古いブラザには古いフォーマットの画像を表示することもできます。
プラグインで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の数値だけ悪いケースを見かけます。
逆にパフォーマンススコアが高く、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に遅延させたいスクリプトの名前を記述するだけです。
reCAPTCHAを遅延読み込みさせると、コンタクトフォームなどで正常な動きをしないことがあるので注意してください。reCAPTCHAは、使用するページのみで動作するように設定しましょう。
Googleタグマネージャー（アナリティクス）を遅延させることで、サイトに訪問した瞬間に離脱するようなユーザーをカウントできなくなります。
合格ラインに達しているのであればタグマネを遅延読込する必要はないでしょう。
Googleアナリティクスの配信トリガーをウィンドウの読み込みにすることで「第三者コードの影響を抑えてください」が出なくなると解説する記事が多いのですが、ウィンドウの読み込みにしても消えませんでした。
「preconnect」「dns-prefetch」で事前読み込みさせても状態が変わらなかったので、遅延読込させました。
遅延させる前の状態はこんな感じです。GoogleタグマネージャーとMicrosoft Clarityが引っかかっています。
遅延させた後はこんな感じです。タグマネとClarityは消えました。別でmatomoというアクセス解析ツールを入れていて、これはbodyタグの最下部に貼っています。
