2021年5月からコアウェブバイタルがモバイル検索のランキング要因に導入されるようです。
「コアウェブバイタル」を測定するツールに「PageSpeed Insights」というGoogleのツールがあります。
このブログはモバイルのスコアが異常に低かった気がします。
たつじんｗ これはあかん…。
ということで、「PageSpeed Insights」で「コアウェブバイタル」を測定し、少しでもモバイルの表示速度を改善する方法を考えました。
「PageSpeed Insights」でコアウェブバイタルを測定
「PageSpeed Insights」でページの表示速度を診断すると、PCのスコアは81点。
90点以上あれば申し分がないと思いますが、80点台なら悪くないと思います。
モバイルのスコアは22点。
PCのスコアと比べて極端に低いです。
青いリボン？がついた３つの指標が「コアウェブバイタル」です。
このブログは「First Input Delay（FID）」だけは悪くないようですが、「Largest Contentful Paint（LCP）」、「Cumulative Layout Shift（CLS）」が極端に低いです。
そして「ウェブに関する主な指標テストに合格していません」と書かれています。
2021年5月から「コアウェブバイタル」がモバイル検索のランキング要因になります。
ランキング要因ということだけでなく、ページの読み込み時間が遅いとユーザビリティを損ないます。
「PageSpeed Insights」のモバイルのスコアがここまで低いとなると、ページの表示速度の改善が必須に思えます。
Search Consoleで見る
「Search Console」でも「ウェブに関する主な指標」でコアウェブバイタルの状態を見ることができます。
たつじんｗ 不良ばかりや…。
不良ばかりでモバイルの表示はとんでもないことになっているようです。
「Cumulative Layout Shift（CLS）」に関する不良が全てのようです。
コアウェブバイタルについて
- Largest Contentful Paint（LCP）：読み込みパフォーマンスを測定。
- First Input Delay（FID）：双方向性。
- Cumulative Layout Shift（CLS）（CLS）：視覚的な安定性を測定。
「コアウェブバイタル」はユーザーエクスペリエンスの3つの側面（読み込み時間、インタラクティブ性、視覚的安定性）を指標化したものです。
「Largest Contentful Paint（LCP）」は読み込みパフォーマンスを測定します。
最も大きなテキストまたは画像が描画されるまでにかかった時間を表します。
「First Input Delay（FID）」は最初の入力をユーザーが実行できるようになるまでの待機時間です。
「Cumulative Layout Shift（CLS）」は視覚的な安定性を測定します。
ビューポート内の視覚要素がどのくらい移動しているかを測定する指標です
たとえばページ内のボタンをクリックしようとしたら後から読み込まれた広告にボタンが下に押しやられた状況です。
「SearchConsole」の不良は全て「CLS」で視覚的安定性に問題があるようです。
「コアウェブバイタル」について詳しいことはこちら記事に書いています。
表示速度の改善必須！コアウェブバイタルがモバイルのランキング要因に
コアウェブバイタルの改善方法
「PageSpeed Insights」では表示速度のスコアだけでなく、「改善できる項目」で推奨できるプラグインを提示して改善策も提案してくれます。
ただ、小規模な個人ブログを運営しているだけの自分には難易度の高い改善策が多いです。
そこで、現在の知識でもサイトの表示速度を改善できることを考えてみました。
たつじんｗ そんな甘い考えでは大幅に改善しないと思いますが(笑)
簡単にできそうな改善策
- 画像の最適化
- 外部ソースの読み込みを極力減らす
- リソースの圧縮
- サーバーの応答時間の短縮
- 必要ないプラグインの削除
- 自動広告をOFFにする
サイトの表示速度を改善するにはリクエスト数を減らすことです。
ページを軽くすればそれだけ読み込み時間が短くなり、表示速度が速くなります。
1.画像の最適化
最も簡単で効果がありそうなのは「画像の最適化」だと思います。
ブログに使う画像は「Photoshop」で切り抜きしてから「書き出し形式」でリサイズと画像サイズを小さくしてからアップロードしています。
「Photoshop」は画像の最適化にもかなり便利ですが有料です。
フリーで画像の最適化するツールで便利なのはGoogleのウェブアプリ「Squoosh」だと思います。
「Squoosh」は切り抜きはできませんが、画像のリサイズ&圧縮ができます。
そしてスマホでも画像の最適化ができてWebPにも対応しています。
ウェブアプリなのでインストールする必要がありません。
しかもGoogleのアプリなので安心です。
画像の最適化するなら「Squoosh」がおすすめだと思います。
アップロード済みの画像
すでにアップロードして記事に使っている画像を最適化するのは大変です。
「EWWW Image Optimizer」というプラグインはアップロードしてある画像を一括で最適化してくれます。
アップロード後だけじゃなく、アップロードした時にも画像を最適化してくれるので自分で画像を最適化するのが面倒な人にもおすすめです。
2.外部ソースの読み込みを極力減らす
最初に外部の情報を読み込んでからページを表示させるので、外部ソースを読み込む要素はなるべく減らしたいところです。
「PageSpeed Insights」の「診断」の項目を見ると「第三者のコードの影響」がかなりあるようです。
「詳細」をみると「アドセンス」が物凄く重いです(笑)。
けれど「アドセンス」と「タグマネージャー」は仕方がありません。
よく見ると「Facebook」もわりと影響あるようです。
一時期「この記事が気に入ったらいいねしよう！」をブログに設置するのが流行っていました。
このブログにも導入したのですが「いいねボタン」はFacebookのサイトにあるボタンを使っています。
Facebookがわりと影響しているのはこの「いいねボタン」が原因だと思います。
ほとんど機能していませんが、SNSボタンは各記事にあるので「この記事が気に入ったらいいね」の必要性はありません。
そしてフォローボタンに変えればいいだけですが、Facebookの「いいね」は廃止されます。
そろそろ削除しようと思っていたところなので「この記事が気に入ったらいいね」はこのブログから削除することにしました。
そしてブログ開設当初にお世話になった「ブログランキング」のボタンも削除することにしました。
3．リソースの圧縮
リソースとは具体的には、「HTML」「JavaScript」「CSS」などのソースを指します。 たとえば記事の余分な改行を減らせば「HTML」ファイルが軽くなります。
また「CSS」ファイルの使わなくなったコードを削除したり、コメントアウトなどを削除することでファイルサイズが軽くなります。
ファイルのサイズが小さくなればそれだけ表示速度が速くなります。
またソースを最適化すれば読み込み速度の改善になりますが、プラグインを使わないと自分には難しいです。
ただ、以前にプラグインでCSSを最適化したらサイトの表示が崩れたのでプラグインの使用に抵抗があります。
今回は不要になったコードを削除しただけなのでそれほど効果はないと思います。
ただ、実装するのに何日もかかり、大苦戦したFacebookの「インスタント記事（Instant Articles）」を削除したのは導入の苦労を思い出すと悲しいです。
4.サーバーの応答時間の短縮
- スペックの高いサーバーにする
- ブラウザキャッシュに有効期限を設定する
スペックの高いサーバーにする
サーバーの応答時間を短くするのに最も効果があるのはスペックの高いサーバーを利用することだと思います。
50万PVを超えるようなサイトを個人で運営してれば話は違いますが、個人ブログで利用するサーバーには限度があります。
低価なレンタルサーバーを使うことを前提に考えると、ある程度の金額のサーバーならそこまでの差異はなく、特に問題ない気がします。
このブログはロリポップ！ 
の「エンタープライズプラン」を使っています。
「PageSpeed Insights」の「合格した審査」を見てみると「最初のサーバーの応答速度は問題ない速さ」になっています。
一方、こちらはロリポップの「スタンダードプラン」を使っているサイト。
体感的にこのブログより少し表示が遅いと感じていました。
やはりエンタープライズプランと異なり、「最初のサーバーの応答時間を速くしてください」と表示されています。
スタンダードプランの下の「ライトプラン」で運営しているブログも当然「最初のサーバーの応答時間を速くしてください」と表示されました。
「ハイスピードプラン」は利用していないので不明です。
けれど名前が「ハイスピード」な上に、「エンタープライズプラン」と同じくLiteSpeed版のPHP。
おそらく「エンタープライズプラン」と同じくらいの速さだと思います。
ロリポップしか利用したことないので他のサーバーのことはよくわかりません。
ロリポップ！ なら「ハイスピードプラン」か「エンタープライズプラン」では「最初のサーバーの応答速度は問題ない速さ」になると思います。
小規模なブログであまりにスペックの高いサーバーを使うと赤字になってしまいます。
ページの表示速度を考えると、予算の範囲内でできるだけスペックの高いサーバーを使うのがいいようです。
たつじんｗ このブログは赤字です(笑)
ブラウザキャッシュに有効期限を設定する
初めてそのページにアクセスする場合は、ページの表示に必要なリソースをダウンロードするので時間がかかります。
けれど2回目以降のアクセスでは、残っているキャッシュを利用してページを表示します。
サーバーから情報を取得する必要がないのでそれだけ速くページを表示できます。
「ブラウザキャッシュに有効期限を設定」することでその有効期限の間ブラウザにキャッシュを残しておくことができます。
このブログも以前ブラウザキャッシュに有効期限を設定しています。
不必要なプラグインの削除
プラグインが多すぎるとそれだけサイトに負荷がかかり、ページの表示速度が遅くなってしまいます。
だいぶ前に「プラグインは10個もいらない！」という記事を書いていました。
けれど少しずつ使用するプラグインが増えていき現在11個のプラグインを使用しています。
そこで必要性の低いプラグインを削除することにしました。
削除したプラグイン
- AddQuicktag
- List category posts
「AddQuicktag（アドクイックタグ）」は登録したタグをエディター表示させ、クリック１つで記事にタグを挿入できるのでかなり重宝していたプラグインです。
ただ、Windows10のIMEの「ユーザー辞書」に「単語登録」すればタグを簡単に呼び出せます。
プラグインを使わなくても「ユーザー辞書」に「単語登録」すればいいだけです。
そこで「AddQuicktag（アドクイックタグ）」は削除しました。
「List category posts(リストカテゴリーポスト)」はカテゴリ別一覧記事を表示させるプラグイン。
今は使っていませんが、また使う機会があると思ってプラグインを有効化したままでした。
けれど今はブロックエディターの「最新の投稿」ブロックを使えばカテゴリ別の記事一覧を表示できます。
サムネイルも表示させて画像のサイズも設定画面で簡単に変えれます。
ブロックエディターでカテゴリ別記事一覧を簡単に表示できるようになったので「List category posts(リストカテゴリーポスト)」も削除しました。
削除候補のプラグイン
- EWWW Image Optimizer
- Google XML Sitemaps
この記事の画像最適化で書いておきながら「EWWW Image Optimizer」を削除しようとしました(笑)。
このブログでは過去にアップロードした画像の一括最適化もしてるし、現在はきちんと画像最適化してからメディアをアップロードしているのでいずれ削除する予定でした。
ただ、アップデートで「Lazy Load(遅延読込み)」とサポートされているブラウザで画像を次世代の「WebP」に変換する機能が追加されました。
WordPress5.5以降「Lazy Load」はデフォルトの機能で実装されましたが、「safari」などのブラウザでは対応してないようです。
「EWWW Image Optimizer」の設定で「Lazy Load」をオンにすれば「safari」などのブラウザにも対応するそうです。
「Lazy Load」と「WebP」に変換してくれる機能が追加されたので削除できなくなりました。
「Google XML Sitemaps」はXMLサイトマップを作成してくれるプラグイン。
WordPress5.5からでは標準機能でサイトマップを作れるようになりました。
機能不足だと思いますが、カスタムすることができます。
もう少し勉強したらWordPressの標準機能のサイトマップを使うと思います。
「タグマネージャー」も「Search Console」も「自動広告」の実装も元々はプラグインを使っていませんでした。
簡単に自分でできることなので「Site Kit by Google」も削除したほうがいいのかもしれません。
けれどGoogle公式のプラグイン。
連携できるGoogleサービスが増えるかもしれないので削除はしないと思います。
自動広告をOFFにする
アドセンス自体重いんですが、「自動広告」は広告を表示させる場所を最初に探す必要があるからなのか、通常の広告よりだいぶ重いです。
「自動広告」から自分で広告を設置することに変更したらスコアが改善された人が多いようです。
ただ、「自動広告」はGoogleが今後１番力を入れていく広告のような気がします。
まだ「自動広告」は発展途上。
使っていないと成長がわからないので、「自動広告」を使い続けることにします。
ただ、「自動広告」の中で現状ユーザーエクスペリエンスを悪くしている広告だけオフにすることにしました。
オフにした広告
モバイルの「全画面広告」。
通常はこの画像のように閉じるボタンがついていますが、動画と合わさった広告でたまに閉じるボタンが表示されない不具合がある時があります。
ブラウザの「戻る」で画面を戻すしかないのですが、初見のユーザーが画面を戻した後に再び記事をクリックしてくれることは稀だと思います。
このブログはスマホ表示の場合は画面上部に「ハンバーガーメニュー」があります。
「アンカー広告」を表示させた場合に「ハンバーガーメニュー」が隠れてししまいます。
おそらくフッターにモバイルのメニューがあるから画面上部に「アンカー広告」が表示されていると思います。
ただ、記事を読んだ後にメニューを開いてまでこのブログの他の記事を読んでくれる人はほとんどいないと思います(笑)。
このブログの環境ではユーザビリティを損なうのでしばらくの間「モバイル全画面広告」と「アンカー広告」はOFFにすることにしました。
改善結果
ページ速度の表示を改善しようと奮闘した結果、スコアは20増えました。
といってもまだだいぶ低いと思います。
画像を最適化した後に画像をコピーして貼り付けたので、２度最適化した状態になって画像があまりに貧相です(笑)。
PC表示は81→83になりました。
まとめ
モバイルのスコアが劇的に良くならなかったのは残念です。
といっても「画像の最適化」と「ブラウザキャッシュの有効期限の設定」は元からやっていたことです。
- 必要ないCSSとJavascriptを削除
- プラグインを２つ削除
- Facebookの「この記事が気に入ったらいいね」とブログランキングのボタンの削除
- 自動広告の「全画面広告」と「アンカー広告」をOFF
今回やったことは本当に簡単にできることだけです。
これだけしかやっていないのにそんな簡単に表示速度が改善されるはずはありません(笑)。
ただ、これ以上の改善策となるとキャッシュ系のプラグインを使うか、上級者向けの施策になると思います。
これ以上改善することが難しかったら、「AMP」を実装することを考えたほうがいいかもしれません。
費用対効果を考えるとプラグインで簡単にAMP化することになると思いますが。
今日のたつじんｗへの一歩
たつじんｗ 今回ほとんど改善策をしていないのでモバイルのスコアは全然良くなりませんでした。
今回１番の収穫は「PageSpeed Insights」でサイトを分析するとユニバーサルアナリティクスではアクセスがカウントされてしまいます。
けれど、GA4ではカウントされないことがわかったことです。
GA4を導入しといて良かったです(笑)
