コアウェブバイタルの計測と対策～PageSpeed Insightsで WordPressサイトを 「良好」にする方法～

皆さんこんにちは、taneCREATIVEの「ちほうタイガー」です。　
2021年12月上旬にこの記事を改訂しています。

まだまだ新型コロナ禍が続いている現状ですが、Googleが2021年6月よりページエクスペリエンス（Page Experience）シグナルを導入し、その主要なシグナルであるコアウェブバイタル（Core Web Vitals）を順次Google検索のランキングシグナルとして組み込んだことで、当社へのWebコンサルティングないしWordPressの高速化に関するご相談が増加していると感じています。

そこで、本稿では主にWeb制作会社に勤務されている方や企業のWeb担当者の方を対象として、最も事例として多いWordPressで構築されたWebサイトを例にして、PageSpeed Insightsを使ってコアウェブバイタルの点数を改善する手法について解説してみたいと思います。

Googleは、2021年6月16日から8月31日にかけて、モバイル検索を対象にページエクスペリエンス（PX）アップデートを実施しました。

これは数百あるとされる検索アルゴリズム用シグナルのうち、「ページエクスペリエンス」に関する部分のアップデートで、既存の検索アルゴリズム用シグナル（モバイルフレンドリー、HTTPセキュリティ、煩わしいインタースティシャルに関するガイドライン）に「ウェブに関する主な指標（コアウェブバイタル）」という新しい観点を組み合わせたものになります。

今回のアップデートはモバイル検索を対象に行われましたが、今後PC検索への反映も予定されています（PC検索のページエクスペリエンスアップデートは2022年2月に開始し、3月に完了するとGoogleから発表されています）。

Googleは、この新しいページエクスペリエンスシグナル導入により検索順位が大幅に変わるわけではなく、「同様の品質とコンテンツを含むページが複数ある場合、ページエクスペリエンスが優れているページは、そうでないページよりも検索パフォーマンスが高くなる可能性がある」という控えめな表現に留めています。この為、検索アルゴリズムでは引き続き関連性とコンテンツの質が重要視されることに変わりはないでしょう。

しかし、当社で保守をさせていただいている260サイト程度のデータを検証すると、モバイルユーザーの割合が高く、良好URL率が高いWebサイトでは、6月頃から一気に合計表示回数、ユーザー数が増えてきている例が観測されています。

反対に、良好URL率が低い一部Webサイトでは、この良好URL合計表示回数が減少している事例も観測されています。

2021年6月は複数の大きなアップデート等があったことから当社でも原因の切り分けを完璧にできているわけではありませんが、コアウェブバイタルの改善はテクニカルSEOにおける重要対策と捉えることにしています。

それでは、今回導入されたコアウェブバイタルについて、改めて見ていきましょう。

ユーザーエクスペリエンスの品質を測定するためのGoogleの取り組みであるウェブバイタル。その核となるのがコアウェブバイタルであり、以下3つの指標で測定することができます。

LCP（Largest Contentful Paint） … ページの表示速度を表す指標

FID（First Input Delay）………………クリック等への反応速度を表す指標

CLS（Cumulative Layout Shift）……ページの視覚的な安定性を表す指標

コアウェブバイタルは、Chromeユーザーエクスペリエンスレポート（ChromeUXレポート）で測定されます。
これはWebサイトの実際のユーザーデータを28日分集計し、その値をそれぞれのウェブバイタル指標ごとに「良好」「改善が必要」「不良」の判定へ振り分けたものです。

コアウェブバイタルの判定基準は以下の通りです。

LCP … 主要コンテンツの表示速度が2.5秒以下なら良好、4.0秒を超えると不良

FID … 最初のクリックなどへの反応速度が0.1秒以下なら良好、0.3秒を超えると不良

CLS … 視覚的なずれの値が0.1以内なら良好、0.25を超えると不良

コアウェブバイタル改善の手順と必要なツールもGoogleは準備してくれています。すなわち、① Search Consoleの「ウェブに関する主な指標」レポートを利用して、サイト全体について改善点の余地があるかどうかをチェックした上で、② PageSpeed InsightsとLighthouseを利用して、具体的な問題の発見と修正を実施します。

Search Console の「ウェブに関する主な指標」レポートの見方についてはインターネット上に多くの解説がありますので、本稿ではPageSpeed Insightsによる改善点の把握と対処の仕方をご紹介いたします。

PageSpeed Insightsの使い方は非常に簡単です。同サイトに計測したいページのURLを入力して分析をクリックすると、しばらくしてから分析結果が表示されます。

これまでは、最初に「総合得点」が表示され、その下には「フィールドデータ・Origin Summary」「ラボデータ」「監査項目」と続いていました。
しかしながら、総合得点は実際にはラボデータで評価されていること等、若干ユーザーに伝わりにくいところもあったかと思います。

2021年11月のPageSpeed InsightsのUI変更では、これらの情報が整理されています。

まず、旧UIでは「モバイル」「パソコン」という分け方でしたが、新UIでは「携帯電話」「デスクトップ」とタブの表記が変わりました。

次に、「実際のユーザーの環境で評価する」という欄の、「このURL」タブに旧UIでのフィールドデータが、「オリジン」タブにOrigin Summaryがまとめられました。
この欄では、過去28日間の実際のデータに基づいた「ウェブに関する主な指標の評価（コアウェブバイタル）」とFCP（First Contentful Paint、ユーザーにページの視覚的レスポンスが表示されるまでの時間）に関する評価を確認することができます。

また、「パフォーマンスの問題を診断する」という欄に、旧UIでの「総合得点」「ラボデータ」「監査項目」がまとめられました。
この欄では、旧ラボデータと、それに基づいたパフォーマンススコア（旧総合得点）、その根拠となる監査結果並びに改善提案を確認することができます。

このように、ラボデータは重要なデータですが、Search Consoleで確認できる良好URL率を向上させるためには、コアウェブバイタルを中心に改善できればよいことから、必ずしもPageSpeed Insightsのパフォーマンススコアで100点を取ることにこだわる必要はないことも付記しておきます。

とはいえ、左記のように、コアウェブバイタルであるLCPが25%、CLSが15％、そしてFIDの代替であるTBTが30%と他の指標よりも比重が大きいことから、コアウェブバイタルを中心に改善を実施すれば、結果的にPageSpeed Insightsのパフォーマンススコアは上昇することになります。

また、指標の下には0.1秒ごとの画面キャプチャーが左から順に10枚並んでおり、Webページが何秒で表示されているか、視覚的なずれ（CLS）は無いかを確認することができます。

LCPに関連する監査項目が15項目、FIDの代替であるTBTが9項目、CLSが3項目と、LCPに関しての監査項目が大半であることが確認できます。
※追記：監査項目 No.37, No.38を追加しました（2021年12月）

② テキストの圧縮

テキストを圧縮します。できればBrotli圧縮、難しければGZIP圧縮をかけます。

htaccessが置けるサーバー構成であれば、mod_deflateを使ったhtaccess記述を加えることで簡単にGZIP圧縮をかけることができます。

③ Webフォントを使用しない or サブセット化する

日本語のWebフォントの利用は、デザイン性などでWebサイトのUXを高めますが、一方でファイルサイズが大きく読み込み時間がかかるいとうデメリットを有します。この為、当社のコーポレートサイトではWebフォントを利用しないことで速度低下を防いでいます。

デザイン面でWebフォントを利用したい場合には、使用しないフォントデータを削除（サブセット化）することで、日本語Webフォントデータを軽量化することができます。

ここまでは実例を元に、最もハードルの高いLCP改善の手法について触れてきました。ここからは残る2つのコアウェブバイタルの改善策についても、簡単に触れたいと思います。

コアウェブバイタルの2つ目、CLS（Cumulative Layout Shift）は、Webページで起きるレイアウトのずれを計測します。

例えば、Webサイト内のあるボタンを押そうとした瞬間にレイアウトがずれて違うボタンをクリックしてしまい、望まない処理が行われてしまう、ということがあればユーザー体験を損ねることになりかねません。悪意のあるWebサイトの場合は、意図的にレイアウトをずらして望まない決済処理をさせるなどの仕掛けも組めてしまいます。

実際には悪意の有無はデータから測定困難ですので、レイアウトがずれないページに高評価を与える仕組みが組まれたものと推察されています。

CLSへの対策は、LCPよりもシンプルです。
もちろん当社が把握していない例外はあるかと思いますが、原則としてCLSに関連する３つの監査項目をクリアすればCLSの不良判定は免れます。

特にWordPressで構築されたWebサイトに関してはCLSの問題は起こりにくいので、その点も付記していきたいと思います。

残る一つのコアウェブバイタル、FID（First Input Delay）は、ユーザーが最初にボタンをクリック・タップするなどの操作を行ってから、ブラウザがその操作に応じて実際にイベントハンドラーの処理を開始するまでの時間を計測した指標です。　しかしながら、ユーザーがクリック・タップなどの操作を行ってから

ブラウザが実際に処理を行うまでの時間については、通常の処理であればユーザーを100ミリ秒以上待たせるようなことはまず考えにくく、入力遅延の多くは、メインスレッドにおいてはJavaScriptファイル等の解析と実行が混み合っており、ブラウザがビジー状態になっていて、ユーザーの操作に対応できない時間がある場合に起こります。

この為、FCP（First Contentful Paint、ユーザーにページの視覚的レスポンスが表示されるまでの時間）とTTI（Time to Interactive、ユーザーが操作可能になるまでの時間)の間の時間の合計であり、メインスレッドがブロックされることで、入力の応答性が妨げられる時間を計測した指標であるTBT（Total Blocking Time、合計ブロック時間）の把握と改善が、FIDの改善に役にたつことになります。

PageSpeed Insightsの監査項目では、TBTに関連する9項目を確認することができます。

TBTの改善方法は、メインスレッドにおいてはJavaScriptファイル等の解析と実行が混み合わないようにすることですので、基本的には前述したレンダリングの高速化を実施することで改善を目指せます。

また、「過大なDOMサイズの回避」項目で監査が失敗になる条件は以下の通りです。

・合計で1,500を超えるノードがある。　　

・深さが32ノードを超える。

・60を超える子ノードを持つ親ノードがある。

DOMのノードは要素のことを指しますので、htmlのタグ一つ一つとイメージすると分かり易いでしょう。
htmlのタグ数を多くしすぎないこと、階層を深くしすぎないこと、一つのタグ内に子要素を設けすぎないことをマークアップの時に意識することが、TBTやFID対策として有効と言えるでしょう。
既存サイトの場合でも、スライダーの表示数（隠れているが、見えない要素の数）等を減らすことでノードを減らすことができます。

ここまでコアウェブバイタル改善の手法についてご紹介させていただきましたが、今後もパソコン検索へのコアウェブバイタル導入に伴い、ウェブバイタル指標の見直し等が起こることは予想されます。

刻々と変わっていく情報を網羅的にキャッチアップし、対策を実施し続けることで最高水準のコアウェブバイタルを保つことは容易なことではありません。
また、今回ご紹介した手法もあくまで当社サイトを元にした改善手法にすぎないため、Webサイト毎に改善策があり、それぞれ入念な検証が必要となります。

Webサイト制作は、単価が安く、日々時間に追われまくっている業界のため、全ての案件で完璧なコアウェブバイタル対応を実践できるわけはないのです（心の叫び！）。

皆さんのWebサイト制作・保守を担当されているWeb制作会社さんに対しても、可能な範囲で勉強と努力をされていても期待通りの総合点数を出せないことが十分にありうることをご理解いただき、優しいご対応をしていただけますと幸いです。