Google Lighthouseは間違いなく、マーケティング担当者・エンジニア・ブロガーに共通するサイト最適化に対する優れたツールです。この認識は共有されているのですが、これに対する意識は大きく分けて2つにはっきりと分かれます。
一方では、これを意識して、100点を目指す人もいれば、最初から諦めて無視している人もいます。これはどちらも正しい選択ではあります。2020年末までは・・・
Google Lighthouseは実測値の計測ツールではありません。LighthouseはGoogleが定めた指標に基づいたページ評価にすぎません。そのため、「Lighthouseの点数が低いからページの読み込み速度が遅い」というのは必ずしも正解ではないのです。
しかし、情勢は変わってきており、Googleは2021年からこのLighthouseの指標(=コアウェブバイタル)を検索結果のランキングの要素に含めることを2020年5月28日に発表しています。
これを踏まえ、Google Lighthouseへの対応は必須の物となりつつあります。しかし、実際に計測ツールを使って現状を測定しても、点数を除く各項目について理解するのは難しいかもしれません。そこで、この記事ではLighthouseを使った改善項目の解説と、対応策を提示したいと思います。
ちなみに、Lighthouseで100点を取る意味はありません。なぜなら、Google Analyticsなど、自分の管轄外のスクリプトが原因で、100点を取ることは実用的ではないからです。目指すなら、70点から90点が理想的です。
Google Lighthouseの基本
Google Lighthouseについてご存知ない方のために紹介しますと、これはGoogleが開発したWEBページの評価ツールです。Chromeの拡張機能としても提供されていますし、Chromeの開発者ツール上にもツールとして用意されています。
このツールのサイト版も用意されており、Measureという名前で公開されています。[View Report]を押すと、上の画像の様なLighthouseのデータが表示されるので、同じ物と思って良いでしょう。
ページ単位で計測を行うことができ、Performance以外の項目もあることがわかります。これらの情報から高速化に関する部分だけを取得して表示するのがGoogle Page Speed Insightになります。
同じページを計測すると、結果も大体同じになります。
これらのいずれの方法を使って計測しても構いません。基礎となっているのはLighthouseであり、Google Page Speed InsightとMeasureはこれらをベースにしたツールと考えてください。
Lighthouseの推奨事項にしたがって高速化を行う
Lighthouseの点数を上げるためには推奨事項を理解して、自分のできる範囲で対応を考える必要があります。本稿では、この推奨事項を深く理解することに焦点をあてます。
残念ながら、Lighthouseは日本語対応していないので、これから紹介するキャプチャは全てGoogle Page Speed Insightの物にしています。
レンダリングを妨げるリソースの除外
最も一般的な推奨事項の1つが、[レンダリングを妨げるリソースの除外]です。
ページが表示される際、デフォルトでは全てのJavaScriptとCSSは同期的に処理されます。つまり、HTMLを上から読み込む際に、JavaScirpとCSSファイルが見つかる度に処理を一時中断しているわけです。この状態は好ましくありません。この様なスクリプトを[レンダリングを妨げるリソース]と呼びます。
この問題を解決する方法として、Googleは下記の2つを推奨しています。
- JavaScriptやCSSが多くない場合は、全てのコードをインラインで記述することで回避できます。ただ、残念ながら、WordPressは自分でコントロールできない第三者のコードをたくさん読み込むケースをまず回避できないので、これは難しいです。
- 読み込みを遅らせます。(非同期読み込み または 遅延読み込み) JavaScriptとCSSそれぞれに対して、HTML読み込み後に実行する様に指定することが可能です。
非同期読み込みの方法に関しては下記記事も役に立つことでしょう。
クリティカルなリクエストの深さの最小化
クリティカルなリクエストの深さは、名前が小難しいですが、平たく言えば、「ページが読み込まれる前に読み込まれているリソースを表示」してくれる項目です。私のサイトの場合、下記の様な結果になりました。
ただ、私のサイトは既にLighthouse対策を行っているのでほとんど出ません。普通はもっとたくさん出ます。
この画像はGoogleの公式解説ページの画像を引用した物です。ここから分かるのは、遅延読み込みを検討すべきファイルがたくさんあり、特に[/scripts/main.js]は中でさらに別のファイルを読み込んでいることです。
これはよくありませんので、私のサイトの様にリクエストの数とサイズを最小限に抑えたいところです。
この問題は直接対応する物ではなく、以下の推奨事項をクリアすることで、改善に向かいます。
- レンダリングを妨げるリソースの除外
- オフスクリーン画像の遅延読み込み
- CSSとJavaScriptの最小化
一般的にはページのファーストビュー内のリソースは全て同期的にし、それ以外の部分に関わるリソースは全て遅延させるのが最適解です。
リクエスト数を少なく、転送サイズを小さく維持する
当たり前のことですが、読み込むリソースが多いほど、ページの読み込みに時間がかかります。
具体的にどこまで減らせば良いのかという基準はありません。なので、それぞれのリソースの種類を確認し、不必要なファイルが読み込まれていないかを逐一確認するという地道な作業が必要です。
その他に、各リソース値の上限を決めておくことも1つの手段として挙げられます。ただし、これは企業向けであり、ルール作りも必要なため、運用面で不必要なコストが発生するかもしれません。Googleはパフォーマンスバジェット（注釈：パフォーマンスについての指標の上限）を推奨しており、作成方法を紹介しています。
参考までに私のサイトはLighthouseの評価が90点近く出ますが、その場合のリソース転送サイズの合計は500 ~ 600 KiB程度です。
CSSの最小化
CSSの最小化とは、不要な文字、スペース、重複を排除してファイルを圧縮するプロセスです。CSSファイルのサイズが小さくなり、読み込み速度が向上するため、Googleはこの方法を推奨しています。
WordPressのプラグインを使ってこの作業を行うことになるとは思いますが、必要な実作業とその仕組みを知っておくことは大事です。
- コメント・スペース・改行を削除する
- CSSの詳細度を浅くする
CSSの詳細度を浅くする
//処理が多い
ul li {
}
//処理が少ない
li {
}このコードの様に、詳細度深くすれば、自分のCSSを確実に適用し、他のCSSコードを上書きすることも簡単です。しかし、その分コード量が多くなってしますのも事実です。そのため、高速化を考える場合、できるだけ簡素なCSSコードを使い回し、CSSの量を減らすことが重要です。詳細度が浅いと、CSSの解析時間も少なくなりますので、この面でも高速化が期待できます。
JavaScriptの最小化
同様にJavaScriptファイルも縮小が必要です。
CSSの詳細度の様な作業はできませんが、コメント・改行・スペースの削除は可能です。
使用していないCSSを削除
WordPressはその性質上、第三者のCSSを読み込みますが、全てのリソースが全てのページで使われているわけではありません。
実際に使用されるCSSは1割くらいだったりします。
そのため、Googleは使用していないCSSを削除することを推奨しています。
WordPressをお使いの場合はプラグインを見直しましょう。有効化中のプラグインの中で実際に使用されていないファイルを特定し、その読み込みを取り消すことも、地道な作業になりますが、有効な対応策です。ちなみに、Chrome DevToolsなどのツールを使用して、最適化が必要な使われていないCSSを見つけることもできます。
メインスレッド処理の最小化
「メインスレッド」とは、ページ上で読み込まれたコードを元にビジュアル(みなさんが実際にみるページ)のレイアウトを作成する作業のことを指します。HTML・CSS・JavaScriptを解析・実行を行い、ユーザーの動作(ボタンを押したなど)も扱います。
そのため、メインスレッドの処理が完了するまでは、ユーザーのリクエストをページが受け取ることができません。よって、メインスレッドの作業に時間がかかりすぎると必然的にページの読み込み速度も遅くなります。
これは、直接対応する物ではなく、他のほとんどの推奨項目を改善し、適切なサーバーを選ぶことで改善されます。
適切なサーバーの定義ですが、実はメインスレッドをGoogleが求める様な秒数で出すためには数千円のコスト帯では無理です。CPU 6コア・メモリ 16GBくらいが必要になります。そうなると月額1万は超えます。
JavaScriptの実行にかかる時間の低減
JavaScriptの実行は、メインスレッドの中で最も影響が大きくなります。Lighthouseはこの項目に影響を与えるファイルが列挙するため、それほど重要ではないモジュールが原因となっていた場合には、そのファイルを削除するなどの対応が取れます。
IDEA HACK では、既にこの施策に取組済みですが、上の画像から分かる通り、AMP広告のファイルがまだ引っかかっています。とはいえ、止めるわけには行かないので、放置しています。この様に、ソースが何を行っているかを理解していると、リソースの整理を効率的に進められます。
最初のサーバー応答時間を速くしてください
「最初のサーバー応答時間を速くしてください」というのは、TTBTにかかる時間を短くすることを意味します。[Time to First Byte」（TTFB）]とは、リクエストを行った後、ブラウザがサーバーから最初の1バイトを受信するまでにかかる時間です。これはページの最終的な読み込み速度とは異なります。TTFBを短くできると、サイトの読み込み速度を向上させることができます。
TTBTは最初の1バイト受信するまでの時間なので、普通に考えれば<html>の<が最初の1バイトになります。つまり、この項目においては、CSSとJavaScriptは関係がありません。*読み込んでませんからね
というわけで、ここはサーバーのスペックが大きな影響を与えます。IDEA HACKの場合も、この項目は警告が出ており、サーバーのスペックを上げる様推奨されています。しかし、総合得点は90点ほどを確保し、かつコスト見合いの観点から、この項目の改善は見送っております。
適切なサイズの画像
画像などのメディアファイルは、サイトの読み込みにに大きな影響を及ぼす可能性があります。これを適切なサイズにすることで読み込み時間を短縮できます。単純に無駄に大きい画像の読み込みはサイトの読み込みを遅くします。当たり前の話ですね。
この問題を修正するには、適切なサイズで画像をアップロードするか、「レスポンシブ画像」を使用します。
srcset属性をimgタグに適用することで、複数のサイズの画像を登録しておいて、デバイスのサイズ別に実際に読み込む画像の出し分けを行うことが可能になります。
<img srcset="image-800w.jpg 880w,
image-480w.jpg 480w,
image-320w.jpg 320w"
sizes="(max-width: 320px) 280px,
(max-width: 480px) 440px,
800px"
src="image-800w.jpg">上記の様にメディアクエリを用いて画像ファイルを登録することで、ブラウザに「このサイズまではこの画像」と指示を与えることが可能です。
WordPressのルールに基づいて記事を書いていれば、レスポンシブ画像は自動的に適用されるので、この項目は最初からクリアしているはずです。
オフスクリーン画像の遅延読み込み
「オフスクリーン画像を遅延読み込み」は、ページの上で画像が表示されるまではその画像の読み込みを停止させておき、ページがスクロールされて、その画像が画面内に入ってきそうなタイミングで画像の読み込みを行うことで、ページ読み込み時の処理を減らすことを意味します。
WordPress 5.5で、画像の遅延読み込み機能がコアに実装され、自動で適用される様になりましたので、この推奨項目は自動でクリアできるはずです。
ただし、WordPress 5.5で実装された遅延読み込みは、ブラウザの最新技術を使っている関係でサポートブラウザはまだ少ないです。そのため、コアの遅延読み込みを無効化して、プラグインを使って実装する人もいます。
効率的な画像フォーマット
画像はサイトの読み込みに大きな影響を与えます。ページのリソースの大半は画像だからです。この項目を達成するためには画像の「圧縮」が必要です。
画像の圧縮を自動化するプラグインもありますし、プラグインを入れたくない場合でもツールを使えば可能です。また、GIFの使用を止めるべきです。GoogleはGIFを使うくらいならMP4を使って動画を埋め込む方がまだパフォーマンスへの影響が少ないとしています。
次世代フォーマットでの画像の配信
JPEG 2000、JPEG XR、WebPなどの「次世代フォーマットでの画像の配信」が推奨されています。その中でもGoogleが開発元のWebPが主流になりつつあり、WebP対応とも言えます。
WebPはサポートブラウザがまだ十分ではないため、現行の画像フォーマットと併用が必要になり、出しわけも必要になります。また、現行と次世代のフォーマットを別々に用意する必要もあるため、画像フォルダを圧迫しますが、それでも対応すべき項目です。imagifyなどのプラグインを検討してください。
アニメーション コンテンツでの動画フォーマットの使用
GIFを使っているサイトをたまに見かけますが、作成に時間がかかる割にGoogleには嫌われています。「GIF = 動く画像」と言われる様に、GIFは視覚的なコンテンツを効果的に届ける形式です。
だけど・・・重いんですよね・・・動画使ったら？
実は、GIFの読み込みにはみなさんが想像するより遥かに多くの時間がかかります。Lighthouseでは、代わりに下記2つのフォーマット推奨しています。
MP4
生成されるファイルはわずかに大きめになりますが、ほとんどの主要なブラウザと互換性があります。
WebM
最も高度に最適化されたビデオ形式ですが、ブラウザとの互換性は限られています。
ちなみに、過去コンテンツのGIF画像を変換するにはFFmpegが便利です。
詳細については、GoogleによるGIFを動画に変換する方法についてのガイドをご確認ください。このガイド内でもFFmpegを使った事例が紹介されています。
ウェブフォント読み込み中のテキストの表示
私にとって、この項目は最も厄介な推奨項目でした。特に日本語フォントは読み込みに時間がかかる大きなファイルになる傾向にあります。何も対策せずにいると、使用しているフォントが完全に読み込まれるまでブラウザでテキストが表示されないこともあり得ます。
Googleは@font-faceで「swap」を適用することで、この問題を解決することを推奨しています。例えば、Googleフォントは、HTMLタグとして読み込む場合も、CSS内で読み込む場合もswapが初期設定として採用されています。
<link href="https://fonts.googleapis.com/css2?family=Quicksand:wght@300&display=swap" rel="stylesheet">/* vietnamese */
@font-face {
font-family: 'Quicksand';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url(https://fonts.gstatic.com/s/quicksand/v21/6xK-dSZaM9iE8KbpRA_LJ3z8mH9BOJvgkKEo58m-xDwxUD2GF9Zc.woff) format('woff');
unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
}
/* latin-ext */
@font-face {
font-family: 'Quicksand';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url(https://fonts.gstatic.com/s/quicksand/v21/6xK-dSZaM9iE8KbpRA_LJ3z8mH9BOJvgkKEo58i-xDwxUD2GF9Zc.woff) format('woff');
unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
font-family: 'Quicksand';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url(https://fonts.gstatic.com/s/quicksand/v21/6xK-dSZaM9iE8KbpRA_LJ3z8mH9BOJvgkKEo58a-xDwxUD2GFw.woff) format('woff');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}ただ、厄介なことに、各種プラグインがこのswapを定義せずにリソースを読み込んでいるケースが多く、それが原因でページ評価がガタ落ちします。しかも修正が非常に面倒という・・・
Elementorなど、専用のフォントを読み込んでいるプラグインはこの項目に対する意識が弱く、swapをつけていません。このケースに対しては、後述するpreloadを使ってそのフォントファイルを最初に強制的に読み込ませることで回避します。
テキスト圧縮の有効化
Litehouseの「テキスト圧縮の有効化」は、GZIP圧縮の使用を意味します。
基本的には、サーバー側でテキスト圧縮が自動的に有効になっているはずです。
むしろ、有効になっていない場合はサーバーを移行した方が良いです。その程度のサーバーとしか言えません。
サイトのテキスト圧縮が有効化を確認するにはGiftOfSpeedが便利です。これにより、GZIP圧縮が正常動作しているかだけでなく、サイトで使用しているサーバーの種類なども分かります。
必須のドメインへの事前接続
Googleアナリティクスなど、必ず接続するサービスのドメインのDNS(名前解決)作業を早く開始するために、[preconnect属性]を使ってブラウザにそのサービスのドメインの先読みを指示することができます。
ページをこの手法を用いて改善できるとGoogleが判断した場合、「必須のドメインへの事前接続」の提案が表示されます。
実装するには下記の様なコードをmetaタグ内に記載する様にします。
指定するのはファイル名ではなく「ドメイン」です。
<link rel=“preconnect” href=“example.com”>もちろん、なんでもかんでも優先度を上げるべきではなく、どうやら2つまでにするべきみたいです。私は3つ以上入れているため、警告が表示されています。また、実際に入れた方が良いドメインに関してはLighthouseが提示してくれるので、無理に入れようとする必要はありません。
キー リクエストのプリロード
[必須のドメインへの事前接続]と同様に、重要なリソースの先読み指示に使います。
preloadはpreconnect違い、外部サービスのドメインを指定するのではなく同一ドメインから読み混んでいるアセットに対して使います。
より具体的に言うと、ほとんどの場合でWEBフォントに対して使います。@font-fisplayでswapが適用されていないWEBフォントはもれなくこの項目に引っかかりますので、それらのファイルを全て、下記の様な形でheadタグに挿入します。
<link rel=“preload” href=“example.com/assets/webfont”>こうすることで、[ウェブフォント読み込み中のテキストの表示]も解決できます。
実はこれを解決しないと、Lighthouseの評価が50点くらい落ちます。絶対にやるべき項目です。
複数のページ リダイレクトの回避
リダイレクトは、あるURLが別のURLを指すように指定したいときに使用されます。通常は利用しませんが、URL構造を変更した時などに使います。
静的なアセットと効率的なキャッシュ ポリシーの配信
要するに「[ブラウザキャッシュ]を使え」ということです。
多くのプラグインがブラウザキャッシュを備えているので、実装に困ることはないでしょう。ただし、キャッシュのインターバルの設定には要確認がです。
「Cache-Control」と「Expires」ヘッダーを使用して、キャッシュの有効期限を最適化することが可能です。w3-total-cacheなど、キャッシュの有効期限を最適化することができるプラグインをきちんと選んでください。
ちなみに、Googleがsuisyousuruブラウザキャッシュの期間が「365日」です。これ以上の日数を指定しないとLighthouseで警告が出ます。
第三者の仕様の最小化
サードパーティのスクリプトが読み込み速度に悪影響を及ぼし、Lighthouseから低評価を受けることもあります。第三者のコードを全て除外することは不可能です。Google Analyticsとかどうするんですか？
そこで、削除候補に上がっている候補の中から、必須でないものの削除止める様に務めることがベストです。外せないものは外せない・・・・これは仕方がないです。
過大なネットワーク ペイロードの回避
Googleはページの合計バイト数を1,600 KB以下にすることを推奨しています。これに対応するために、ページ上で容量が大きいファイルを上から列挙して改善を催しているのがこの推奨項目です。
この項目を解決する直接的な方法はなく、CSS / JSの縮小や遅延読み込み,WEBフォントの使用を止めるなど複合的な対応がこの項目の改善につながります。
過大な DOM サイズの回避
CSSの詳細度と似た話になります。DOMは広義にはHTMLソースのことで、ご存知の通りHTMLには階層構造があります。ページのDOMが深いほどHTMLの解析に時間がかかります。
<div id="wp-ug-li-1-293" class="wp-block-ug-list-block-ul wp-ug-li-com wp-ug-li-1 wp-block-ug-list-block-1-ed8c707a-7108-4f4a-8b73-201a5bd9282e">
<ul class="ug-list-text ugicon ugicon-code">
<li>ページキャッシュの適用</li>
<li>ブラウザキャッシュの適用</li>
<li>サーバースタティックキャッシュの適用</li>
<li>オブジェクトキャッシュの適用</li>
<li>画像の遅延読み込み</li>
<li>gzip圧縮</li>
<li>CSS遅延読み込み</li>
<li>JSの遅延読み込み</li>
</ul>
</div> このコードはメンテナンス性を踏まえれば最適な物で、変えるべきでありません。しかし、厳密に言えば1番外側の<div>はなくてもリストは作れるわけです。この<div>がある分、DOMの階層が深くなっているわけですから、下記の様にした方が読み込みは速くなります。
<ul class="ug-list-text ugicon ugicon-code">
<li>ページキャッシュの適用</li>
<li>ブラウザキャッシュの適用</li>
<li>サーバースタティックキャッシュの適用</li>
<li>オブジェクトキャッシュの適用</li>
<li>画像の遅延読み込み</li>
<li>gzip圧縮</li>
<li>CSS遅延読み込み</li>
<li>JSの遅延読み込み</li>
</ul>DOMの階層もサイトの読み込みに影響を与えることを理解すると、Elementorの階層の深さにはうんざりすると思います。私もうんざりしています。こういったエディターは仕様上どうしても無駄な階層構造を作らなりと成り立たない場合もあり、この様なプラグインが読み込まれているページでこの項目をクリアするのは難しいです。
まとめ
Lighthouseは、2021年から本格的に重要になる検索エンジンの指標です。これを向上させるにはこれまでのべた数多くの推奨項目に向き合わなければなりません。
今回の記事では、Lighthouseスコアそのものよりも推奨項目とその対策に重点をおきました。導入が難しそうに感じた方はIDEA HACKが提供するWordPress テーマBrandiaとAMPを導入してみてください。これら2つのツールを使えは、IDEA HACKの様に90点を常に出せる様になりますよ。私たちのプロダクトがどうやってあなたのサイトを改善するかに関しては、下記の記事も参考になると思います。
