- SERVICE
- WORKS
- ABOUT US
- NEWS & COLUMN
- RECRUIT
本記事は「WEBプロダクション年鑑(2022)」に特集として掲載されたものを、出版元である株式会社アルファ企画様の承諾を頂いてコラムとして公開しているものになります。 |
皆さんこんにちは、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での「総合得点」「ラボデータ」「監査項目」がまとめられました。
この欄では、旧ラボデータと、それに基づいたパフォーマンススコア(旧総合得点)、その根拠となる監査結果並びに改善提案を確認することができます。
それでは「実際のユーザーの環境で評価する」欄から見ていきましょう。
「このURL」(旧UIでのフィールドデータ)タブの情報は、過去28日間の収集期間内に実際のさまざまな端末やネットワークの条件におけるユーザーから匿名で送られたパフォーマンスデータです。
このフィールドデータは、【分析対象とした1ページ】に対する、コアウェブバイタルの【3つの指標全て(LCP、FID、CLS)】において、データが十分に蓄積されていると掲出されます。
しかしながら、1ページだけで十分なデータが蓄積されるサイトは限定されますし、FIDはユーザーが閲覧しただけでは計測されず、何らかのアクションをしてはじめて計測されるデータである為、データが蓄積されにくいという特性を有しています。
そういった理由によるかは定かではありませんが、2021年6月頃より、【サイト全体】のデータについて、【最低限2つの指標(LCP、CLS)】において、データが十分に蓄積されていれば、「オリジン」(旧UIのOrigin Summary)として、サイト全体のLCP、CLS、FIDとFCP(First Contentful Paint、ユーザーにページの視覚的レスポンスが表示されるまでの時間)データが表示されるようになった模様です。
当社のコーポレートサイトのトップページを例にすると、「このURL」欄にはデータが十分に蓄積されておらず、「データが見つかりません。」と掲出されます。
しかしながら、サイト全体のデータとしては、FIDのデータが不足しているものの、LCPとCLSについてデータが十分に蓄積されているようで、「オリジン」欄にはLCPとCLS、FCPの計測結果が表示されており、LCPとCLSの2項目でコアウェブバイタルが判定されています。
「パフォーマンスの問題を診断する」欄で使用されるデータは、旧UIでラボデータと呼ばれていたデータであり、その名の通りラボ(研究室)で計測するデータです。
【分析対象とした1ページ】を対象として、固定されたネットワーク条件で1台の端末でページ読み込みをシミュレートしたデータであり、計測時の瞬間的なデータであるため、計測ごとに値が異なってきます。
パフォーマンススコア(旧「総合得点」)を確認できる他、コアウェブバイタルのうちLCPとCLSを計測でき、FIDについては相関性を有する指標であるTBT(Total Blocking Time)で計測することができます(詳細は「6.FIDの改善方法」で記載します)。
また、このデータはLighthouseという、ウェブサイト・アプリの品質向上を目的とした計測ツールで測定されており、「計算ツールはこちら」からPageSpeed Insightsのパフォーマンススコアを算出するための計算を確認することもできます。
PageSpeed Insightsでの得点向上を狙いたい場合は、これら指標の測定数値と比重を参考にすると、効果的な得点向上を狙うことができます。
得点比重はLighthouse Scoring Calculatorのバージョンにより変化していきますが、2021年12月時点、バージョン8+の比重は以下の図の通りです。
このように、ラボデータは重要なデータですが、Search Consoleで確認できる良好URL率を向上させるためには、コアウェブバイタルを中心に改善できればよいことから、必ずしもPageSpeed Insightsのパフォーマンススコアで100点を取ることにこだわる必要はないことも付記しておきます。
とはいえ、左記のように、コアウェブバイタルであるLCPが25%、CLSが15%、そしてFIDの代替であるTBTが30%と他の指標よりも比重が大きいことから、コアウェブバイタルを中心に改善を実施すれば、結果的にPageSpeed Insightsのパフォーマンススコアは上昇することになります。
また、指標の下には0.1秒ごとの画面キャプチャーが左から順に10枚並んでおり、Webページが何秒で表示されているか、視覚的なずれ(CLS)は無いかを確認することができます。
ここまでのデータは、対象ページやデータ取得期間、あるいは指標に違いはあるものの、サイトの現状とその評価を表すものでした。
これに対して、「パフォーマンスの問題を診断する」欄の下部に掲出されている「改善できる項目」「診断」「合格した監査」(ここではこれらをまとめて「監査項目」と呼びます)は、改善のための提案・ヒントになります。
こちらもラボデータと同様Lighthouseで監査されており、パフォーマンス監査に基づいた項目の内、ページの読み込み時間を短縮できる可能性のある項目が「改善できる項目」欄に、Webサイトのパフォーマンスに関する詳細項目が「診断」欄に掲出されます。
どちらも影響が大きいと推定される順に羅列されており、左側のアイコンと色で重要度が示される他、合格値が計測されると「合格した監査」に振り分けられるようになっています。
ここで指摘されている項目について、地道な対処を行うことでラボデータ・総合得点は向上していきます。
一方で、「改善できる項目」と「診断」の全てを「合格した監査」にすることは現実的ではありませんし、必要であるとも考えていません。
重要度が高く、実現可能な監査項目から順に改善を施していくとよいでしょう。
また、「次に関連する監査を表示」という欄からはFCPとコアウェブバイタルに関連する項目を絞り込むことができますので改善の順序を策定するのに便利です。
監査項目とコアウェブバイタルとの関連をまとめたものが下の表になります。
No. | 監査項目 | 関連する指標 |
---|---|---|
1 |
適切なサイズの画像 |
- |
2 |
レンダリングを妨げるリソースの除外 |
LCP |
3 |
オフスクリーン画像の遅延読み込み |
- |
4 |
CSS の最小化 |
LCP |
5 |
JavaScriptの最小化 |
LCP |
6 |
使用していないCSSを削除してください |
LCP |
7 |
効率的な画像フォーマット |
- |
8 |
次世代フォーマットでの画像の配信 |
- |
9 |
テキスト圧縮の有効化 |
LCP |
10 |
必須のドメインへの事前接続 |
LCP |
11 |
最初のサーバー応答時間は問題ない速さです[合格] |
LCP |
12 |
複数のページリダイレクトの回避 |
LCP |
13 |
キーリクエストのプリロード |
LCP |
14 |
アニメーション コンテンツでの動画フォーマットの使用 |
LCP |
15 |
第三者の使用の最小化・第三者コードの影響を抑えてください |
TBT |
16 |
合成されていないアニメーションは使用しないでください |
CLS |
17 |
ファサードでのサードパーティリソースの遅延読み込み |
TBT |
18 |
過大なネットワークペイロードの回避 |
LCP |
19 |
静的なアセットと効率的なキャッシュポリシーの配信 |
- |
20 |
過大なDOMサイズの回避 |
TBT |
21 |
クリティカルリクエストチェーンを回避してください |
LCP |
22 |
JavaScriptの実行にかかる時間 |
TBT |
23 |
メインスレッド処理の最小化 |
TBT |
24 |
ウェブフォント読み込み中の全テキストの表示 |
LCP |
25 |
リクエスト数を少なく、転送サイズを小さく維持してください |
- |
26 |
「最大コンテンツの描画」要素 |
LCP |
27 |
JavaScriptバンドル内の重複モジュールを削除する |
TBT |
28 |
使用していないJavaScriptの削除 |
- |
29 |
Largest Contentful Paintの画像のプリロード |
LCP |
30 |
スクロールパフォーマンスを高める受動的なリスナーが使用されています[合格] |
- |
31 |
レイアウトが大きく変わらないようにする |
CLS |
32 |
メインスレッドでタスクが長時間実行されないようにしてください |
TBT |
33 |
document.write() は使用されていません[合格] |
- |
34 |
カスタム速度の記録と計測 |
- |
35 |
画像要素でwidthとheightが明示的に指定されている[合格] |
CLS |
36 |
最新ブラウザに従来の JavaScript を配信しないようにしてください |
TBT |
37 |
widthまたはinitial-scaleを指定した<meta name="viewport">タグがあります |
TBT |
38 |
First Contentful Paint(3G) |
- |
LCPに関連する監査項目が15項目、FIDの代替であるTBTが9項目、CLSが3項目と、LCPに関しての監査項目が大半であることが確認できます。
※追記:監査項目 No.37, No.38を追加しました(2021年12月)
それではここから、特にWordPressで構築されたWebサイトへ対象を絞り、コアウェブバイタル改善のための具体的な手法を紹介いたします。
今回WordPressに絞る理由は大きく2つです。一つはWordPressがシェア率ナンバーワンのCMSであること。もう一つは、WordPressはユーザーがアクセスしてからリアルタイムでWebページを生成する動的なCMSであるため、バックエンドの処理に時間がかかる傾向にあることです。
実際に、コアウェブバイタルがGoogle検索のランキング要因に組み込まれることが公表されて以来、WordPressサイトの高速化に関するご相談が増加しており、リソースの関係でWebコンサルティングとしては対応が困難になってきたため、エンジニアによるサービスとしてパッケージ化をして対応しています。
このようにWordPressで構築されたWebサイトは、静的なWebサイトよりも表示速度が遅くなる傾向にあることから、コアウェブバイタルのうち表示速度の指標であるLCPの問題が発生しやすい傾向にあるといえます。
それでは、LCP(Largest Contentful Paint)について、改めて説明いたします。
LCPは、ページが読み込まれてからページ内の最大のコンテンツ(画像または文字)が表示されるまでの速度を計測したものです。Webサイトのデザインにもよりますが、多くのケースではメインビジュアル画像の表示速度を指すことになるかと思います。
その為、そもそもページ内の最大画像をそこまで大きな画像にしなければ、更に言えばメインビジュアル画像を無くせば、LCPは自ずと向上します。大抵のWebサイトでプライバシーポリシーなどテキストだけのページでLCP点数が高いのはそのためです。
しかしデザインやコンテンツ内容の兼ね合いで大きな画像を手放せない場合は、地道にLCP低下の原因をつぶしていく必要があります。
LCPを改善する方法として、バックエンドの高速化、ネットワークの高速化、レンダリングの高速化の順に対策を説明していきます。
バックエンドを高速化する手法は多岐に渡りますが、最もお薦めの手法はWordPressをヘッドレスCMS化してしまい、静的サイトジェネレータなどの技術で静的にページを生成しておく手法です。
更に可能であれば公開側はCDNだけにしておけば、表示速度だけでなくセキュリティー対策、サーバーのコストダウン、耐障害性、アクセス耐性面でも優れた構成になります。
当社のコーポレートサイトも、WordPressは非公開領域のAmazon EC2に格納されていますが、同じく非公開領域にあるAmazon S3にWebサイト内の全ページを静的ファイル化した上で、公開領域にあるAmazon CloudFront(CDN)に転写する手法で、バックエンドの高速化兼セキュリティー対策を実施しています。
この手法はECサイト等のように厳密なリアルタイム性が求められるWebサイト・Webシステムには向きませんし、後述の「ネットワークの高速化」に便利なhtaccessが使えない等、デメリットも存在しますが、当社の保有するナレッジの範囲内では最も費用対効果に優れたバックエンドの高速化対策であると考えています。
なお、この構成以外の高速化対策については、「WordPressの高速化対策」のページをご覧ください。
次に、Webページに使用される要素の読み込み時間を短縮していきます。
どんなWebサイトでも、表示される要素の大半はテキストと画像が占めています。これら一つ一つの要素を軽量化することで読み込み時間が短縮されることは比較的イメージがし易いかと思います。
当社のコーポレートサイトでは、大きく分けて以下の3つの対応を実施しています。
① 画像の軽量化
画像の軽量を実施します。画像はデータ容量が大きいので、軽量化に取り組むことで速度改善に大きな効果が得られます。
❶ WordPressプラグイン「EWWW Image Optimizer」で画像サイズの縮小・圧縮・WebP生成・遅延読込をまとめて行う
画像データを最適な大きさに縮小し、圧縮をかけ、データ形式を「WebP」に変換することで、本来の半分ほどのサイズまで軽量化することが可能です。
また、これは「レンダリングの高速化」対策になりますが、同プラグインで画像データの遅延読込設定(ページロード時に、最初の画面で表示されない画像の読み込みを後回しにする設定)をかけることができます。
「EWWW Image Optimizer」プラグインには遅延読込の除外設定もあるので、メインビジュアルを除外するなど細かい設定も可能です。
❷ サイズの大きな画像データはimgタグにsrcset属性を設定し、パソコンとモバイルで画像を出し分ける
例えば、画面いっぱいにメインビジュアルを表示する場合、パソコン表示とモバイル機器の表示では必要な画像サイズは異なります。
そのため最適な画像サイズを複数用意して、srcset属性で表示させる画像の出力を切り替えます。srcset属性はユーザー閲覧環境それぞれの画面サイズ大きさで表示させたい画像を用意し、ブラウザに提案するための属性です。
ブラウザが最適な画像を選択するので、Retinaディスプレイなど高解像度のディスプレイにも対応が可能です。
以下の記載例では大中小の画像を用意しています。
例) <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w" sizes="100vw" width=”small.jpgの横サイズ” height=”small.jpgの縦サイズ” alt="メインビジュアル" /> |
② テキストの圧縮
テキストを圧縮します。できればBrotli圧縮、難しければGZIP圧縮をかけます。
htaccessが置けるサーバー構成であれば、mod_deflateを使ったhtaccess記述を加えることで簡単にGZIP圧縮をかけることができます。
③ Webフォントを使用しない or サブセット化する
日本語のWebフォントの利用は、デザイン性などでWebサイトのUXを高めますが、一方でファイルサイズが大きく読み込み時間がかかるいとうデメリットを有します。この為、当社のコーポレートサイトではWebフォントを利用しないことで速度低下を防いでいます。
デザイン面でWebフォントを利用したい場合には、使用しないフォントデータを削除(サブセット化)することで、日本語Webフォントデータを軽量化することができます。
最後にレンダリングの高速化に挑戦していきます。
レンダリングとは、ブラウザがHTMLなどのファイルを画面イメージに変換し表示させる処理のことをいいます。
ブラウザが採用しているレンダリングエンジンによって若干のフローは異なりますが、基本的には次のような処理手順になります(※Webkitの用語で説明します)。
❶ HTMLパーサーがHTMLを解析してDOMツリーを構築
❷ CSSパーサーがCSSを解析してCSSOMツリーを構築、DOMツリーと関連付けを行ってレンダーツリーを構築
❸ レンダーツリーに基づいて要素をレイアウト
❹ レイアウトを描画
❶❷が画面イメージの設計書作成フェーズになります。
基本的に❶❷の設計書フェーズが完了しないとブラウザは❸❹の描画フェーズに進まない為、DOMとCSSOMの構築に必須となるHTML、CSS、JavaScriptが監査項目No.2の「レンダリングを妨げるリソース」になります。
また、設計書に不要な指示が書いてあったり、外部読み込み指示が多くある場合には、なかなか❸❹の描画フェーズに移れません。
このように、レンダリングの高速化においては、如何にして0.1秒でも早く描画フェーズに進めるように改善するかが重要になります。
当社のコーポレートサイトでは、大きく分けて以下の3つの対応を実施しています。
① レンダリングを妨げるリソースの使用は必要最小限度にする
CSS、JavaScriptは、なるべくそのページで使用するものだけを読み込むようにします。
jQueryなどのJavaScriptのライブラリを使用する場合、実際に必要なプログラムはライブラリ内の一部だけですので、それ以外のプログラムは本来的には不要なレンダリングを妨げるリソースとなります。
当社のコーポレートサイトでは、例えばグローバルナビゲーションの部分をCSSのみで実装するなどしてjQuery自体を外してあり、その上でどうしてもJavaScriptが必要なページにだけ個別に処理を書き込むことで、不要なレンダリングを妨げるリソースが無いようにしています。
② その他の外部読み込みを必要最小限にする
前述のレンダリングを妨げるリソース以外にも、Webフォントやアイコンなど外部から読み込む要素があると、描画フェーズに進む前にそれらを読み込む時間がかかってしまいます。
当社のコーポレートサイトでは、Webフォントを使用せず、アイコンを全てSVG画像に変換することで、CSS、JavaScript以外の外部読み込み要素を必要最小限にしています。
③ 最初に開く画面(ファーストビュー)とその周辺の描画フェーズを先に実施する
最初に開く画面(ファーストビュー)とその周辺以外(オフスクリーン)で使用するリソース・要素の読み込みを後回しにして、まずはファーストビューの描画フェーズを実行することで表示速度を早めることができます。
画像についてはLazy Loadによって、オフスクリーン画像の遅延読込設定をします。
JavaScriptにはdefer属性で遅延読込設定を、CSSにはrel属性をpreloadにすることで非同期読込設定をかけます。非同期読み込み設定は、描画前の読み込みとは別(非同期)で読み込むようにする設定ですので、遅延読込に近い効果を発揮します。
とはいえ、既存サイトのCSSにおいてファーストビューとオフスクリーンを切り離すのはかなりの手間ですので、当社のコーポレートサイトの改修ではそこまでは実施していません。可能ならば最初の構築の段階で、ファーストビューとオフスクリーンを切り離すのが望ましいと思います。
もし切り離せる場合は、切り離したCSSをminify化したうえでインライン記述を行うと、さらに読み込み速度を向上させることができます。
ここまでは実例を元に、最もハードルの高いLCP改善の手法について触れてきました。ここからは残る2つのコアウェブバイタルの改善策についても、簡単に触れたいと思います。
コアウェブバイタルの2つ目、CLS(Cumulative Layout Shift)は、Webページで起きるレイアウトのずれを計測します。
例えば、Webサイト内のあるボタンを押そうとした瞬間にレイアウトがずれて違うボタンをクリックしてしまい、望まない処理が行われてしまう、ということがあればユーザー体験を損ねることになりかねません。悪意のあるWebサイトの場合は、意図的にレイアウトをずらして望まない決済処理をさせるなどの仕掛けも組めてしまいます。
実際には悪意の有無はデータから測定困難ですので、レイアウトがずれないページに高評価を与える仕組みが組まれたものと推察されています。
CLSへの対策は、LCPよりもシンプルです。
もちろん当社が把握していない例外はあるかと思いますが、原則としてCLSに関連する3つの監査項目をクリアすればCLSの不良判定は免れます。
特にWordPressで構築されたWebサイトに関してはCLSの問題は起こりにくいので、その点も付記していきたいと思います。
監査項目No.16の内容です。
この監査項目については、当社の方でも実際に不合格となった事例を見たことがなく、よくわかっていない状態なのですが、理論上は異なるサイズのアニメーションをブラウザ上で重ね合わせたり順に表示したりすれば、レイアウトがずれることはイメージできますので、それは避けるようにという意味ではないかと推察しております。
しかしながら、アニメーションを合成せずに使用することは実務上ほぼ考えにくい為、この監査項目については特に問題にならないのではないかと考えております。
監査項目No.31の内容です。
レイアウトが変わると判定されるケースで当社が把握しているものは、ユーザーの操作によらずにバナーやボタンが動くケース(JavaScriptでスクロールに追随するバナー・ボタンなどを設置している等)や、スライダーで大量の画像の読み込みに時間がかかってしまいレイアウトが動くケース、Webフォントの読み込みに時間がかかってしまいレイアウトが動くケース、Lazy Loadでの代替画像と遅延読み込みされた画像のサイズが異なる場合等があります。
対応策としては、スクロール追随型のバナーやボタンを使用しないようにする、スライダーは使用しないか最初から表示領域を確保する、Webフォントは極力使用しない、WordPress標準搭載のNative Lazyloadを利用するなどがあり、当社のコーポレートサイトでもこれらの対応でレイアウトが大きく変わらないようにしています。
監査項目No.35の内容です。
画像や動画にwidthやheightが指定されていないと、実際に読み込まれるまで画像のサイズがブラウザで判別されないため、これらを指定しておくことでレイアウトのずれを防止します。
また、CSSでアニメーションを行う際はtransformプロパティを使用し、width, heightやleft, topなどの値自体を変更しないようにします。
なお、WordPressで構築されたWebサイトであれば、原則として画像や動画にwidth, heightの値が自動で組み込まれますので、この監査項目が不合格になった場合には、静的にコーディングしてあるか、あるいはサードパーティー製のテーマやプラグインで特殊な処理がされているか等をチェックするとよいでしょう。
残る一つのコアウェブバイタル、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制作会社さんに対しても、可能な範囲で勉強と努力をされていても期待通りの総合点数を出せないことが十分にありうることをご理解いただき、優しいご対応をしていただけますと幸いです。
taneCREATIVEに所属する謎のトラ。