今更なテーマではありますが、PageSpeed Insightsを使って得たものやそれに基づく仮説などを、後ほど振り返れるように記事の形で残したいと思います。
読まれる方はこの記事についての以下の点にご注意を。
- 根拠に乏しく「やったらできた」的な荒い内容
- 英語版ヘルプはあまり見れていない
- 間違った理解で書いている可能性がある
流し見程度にご覧いただくのがよいと思います。
目次
今回は長い上に各節がほぼ独立しているため、以下に簡易的な目次をつけました。
なお、一番下のAMPの部分は番外編的なオマケです。
PageSpeed Insightsの前提
PageSpeed Insightsで点数だけ見るもの悪いことではありませんが、PageSpeed Insightsは何に対してどのような目的で存在しているのか、という点から考える方がより得るものが大きいと思います。
この件は以下のページに書かれていますが、要点部分を引用します。
PageSpeed Insights では、次の項目について、ページのパフォーマンスをどの程度改善できるか測定します。
- スクロールせずに見える範囲のコンテンツの読み込み時間: ユーザーが新しいページをリクエストした瞬間から、スクロールせずに見える範囲のコンテンツがブラウザで表示されるまでの経過時間。
- ページ全体の読み込み時間: ユーザーが新しいページをリクエストした瞬間から、ブラウザでページが完全に表示されるまでの経過時間。
単にページ全体に対する速度向上を目指しているのではなく、スクロールせずに見える範囲のコンテンツも対象となります。
この点から、ページ全体の速度が早くともファーストビューの速度が遅ければ減点になる、ということが明確になったと思います。
モバイルとPCをどうやって分けているのか
計測結果はモバイルとPCのタブに別れていますが、これは以下のような方法で行われています。
URL を 2 回（モバイル ユーザー エージェントと PC ユーザー エージェントで 1 回ずつ）取得します。
計測結果を見ていると本当にUAを変えただけには思えないのですが、説明としてはUA変更以外のものが書かれていません。
PageSpeed Insightsの今後に関して
PageSpeed Insightsのページ上部には以下の説明が記されています。
PageSpeed Insights のモバイルページ向けユーザー エクスペリエンス テストはモバイル フレンドリー テストに統合されました。モバイル フレンドリー テストはこちらからお試しいただけます。
統合されたのは「モバイルページ向けユーザー エクスペリエンス テスト」だけの模様ですが、PageSpeed Insights 自体がどうなるのかはわかりませんでした。
消えるとは書いていませんので、継続を願いたいところです。
モバイルフレンドリーテスト
その他のリソースには以下の3つがあります。
- サイト全体のモバイル ユーザビリティ レポートを開く
- モバイル フレンドリー ページの詳細
- コメントや質問をディスカッション グループに投稿
レポートは「サイト全体のモバイル ユーザビリティ」しかありませんが、これはSearch Consoleの「モバイルユーザビリティ」に飛ばされるため、PageSpeed Insightsのような詳細なものではありません。
PageSpeed Insightsの各項目に関するメモ
PageSpeed Insgithsの各項目の中で個人的に分かりにくいものに関し、何度も試した上での私的な見解などを記載します。
冒頭に書いたとおり、信頼性はまったく保証しませんので悪しからず。
スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する
WordPressの場合、style.cssがheadにあるだけで「修正を考慮」の黄色警告がでる可能性が高いです。
また、以下の場合は赤色警告になる可能性があるようです。
- headにcssが2つ以上ある
- headにcssとjsが１つずつ以上ある
cssに関しては、2つのうち１つが数行程度の小さなcssの場合は無視されることもあるようです。
この項目は最近強化されて厳しくなったのではと考えています。
アップデートの情報が見つからない(公開しないという話だったかもしれませんが)ので根拠となる情報はありませんが。
対策の基本
PageSpeed Insightsの該当箇所に既にかかれていますが、以下の3つが対応策の模様です。
- レンダリングをブロックするリソースの読み込みを遅延させる
- 非同期に読み込む
- リソースの重要部分をHTML内に直接インライン化
jsの対策
jsファイルの場合、jQueryなどのライブラリに依存するファイルでなければasyncを使い、依存する場合はdeferを使うことになりそうです。
asyncとdeferに関しては以下のページが詳しいと思います。
上記のページを読めば「asyncやdeferを使えばなんだか早くなる」などというふわっとした理解ではなく、実際には「該当のjsファイルにdocument.write()が使われておらず、DOM構築に影響を与えないという宣言」であるなど、jsを非同期で早く読み込める理由がわかるかと思います。
deferにはいくつか注意点がありますが、そこが重要になりdeferも使えないとなると、ほとんどお手上げかもしれません。
考えられるのはsetTimeoutなどで遅延させるなどでしょうか。
ただ、特殊な場合を除いて「document.write()があるからdeferが使えない」という状況には多少問題があるように思えますので、その点では構造自体の変更を検討するべきなのかもしれません。
cssの対策
どちらかと言えば、Googleはページ全体よりもファーストビュー内のレンダリングを速めることを重視しているようで、以下のページなどである程度具体的な方法を公開しています。
外部 CSS リソースが小さい場合は、HTML ドキュメントに直接挿入できます。これをインライン化といいます。
小さい CSS をこのようにインライン化すると、ブラウザはページのレンダリングを続けることができます。
なお、CSS ファイルが大きい場合、CSS を完全にインライン化すると、PageSpeed Insights から、ページのスクロールせずに見える範囲が大きすぎることを警告される場合があります（スクロールせずに見える範囲のコンテンツのサイズを減らすをご覧ください）。
大きな CSS ファイルの場合は、スクロールせずに見える範囲のコンテンツのレンダリングに必要な CSS を特定してインライン化し、残りのスタイルの読み込みはスクロールせずに見える範囲のコンテンツの後まで遅らせる必要があります。
サンプルコードもありますのでそちらを見ると、loadイベントでcssのlink要素をhead内に入れる模様です。
個人的に疑問なのは、cssを二回読むことになるならloadイベントで読み込まれた際に再描画が発生し、結局遅くならないのかなという点です。
もっともその辺りに問題がないからマニュアルで指示しているのだとは思いますが。
レンダリングについてさらに詳しく
以下のGoogleのページが意外にも日本語で読めます。
表示可能コンテンツの優先順位を決定する
説明を読んでも分かりにくいのが「表示可能コンテンツの優先順位を決定する」の項目です。
個人的に状況で警告がでると思われる具体的な状況を記載してみます。
- ファーストビュー内に大きめの画像などがあり、その読み込みが重い（遅い)ために、他の要素の読み込みが遅延して間に合わない
- フッターに配置した上に戻るボタンがファーストビュー内にあり、その表示が間に合わない
- cssが長く読み込みに時間がかかり、背景画像の表示が間に合わない
- ファーストビュー内に、SNSボタンなどjsで遅れて表示する要素が存在する
「間に合わない」と書いていますが、具体的な指定時間はよくわかりません。限界となるデータサイズも同様です。
詳細をみれば何%読み込めたのか、その読み込みた部分はどこまでかがわかりますので、何となく雰囲気は掴めるかもしれません。
ともかく、ファーストビューのHTMLだけ見ていても改善できないのではと思います。
画像を最適化する
画像の総データサイズにもよると思いますが、留意するべきなのは以下の点かなと考えています。
- 圧縮できる余地がどれけあるか
100KBの画像で「80%削れます」だと赤警告になる可能性がありますが（経験談)、おそらく100KBで「5%削れます」だと黄色警告になると思います。
デザインの観点から画像のサイズ自体はどうしようもない場合がありますので、とりあえず求められるサイズまで削減してから考えたほうがよいかもしれません。
画像の及ぼす影響
以下はモバイルの点数です。
つづいて、以下は上記と同じページの削減後です。
違いは、Googleの提示する画像の削減量を満たしているかどうかです。
通常3.5MBもの削減を指示されることはまずないと思いますが、このレベルであれば画像に対する警告だけで80点近い減点になります。
この点から、どれだけ画像に対する点数の比重が大きいのかが明確にわかるかと思います。
なお、上記ページは画像にあるように以下のURLを持つページですので、どのようなページだったのか実際に確認いただけます。
管理外の画像
警告が出た際に注意するべきなのは以下の点です。
- 削減指示がでた画像が自サーバーにない場合
取れる方法は以下の3つでしょうか。
- 該当画像を触れる方に対応を依頼する
- 計測に引っかからない程度に遅延表示させる
- 該当画像を削除する
なお、AdSenseが問題となる場合は、試せていませんが以下の記事にあるスクリプトで遅延表示が可能かもしれません。
サーバーの応答時間を短縮する
動的CMSには厳しい項目です。
WordPressの場合、黄警告になることは良くある印象で、何回も行うと赤警告になる場合もあります。
preg_matchなど時間のかかる処理を多用していたり、ループでまわしている数が多く中身の処理も重い場合、簡単に赤になるかもしれません。
TOPページやアーカイブページなど記事一覧が存在するページだけで警告が出るのであれば、この点が原因かもしれません。
個人的な感覚にすぎませんが、サーバーや閲覧時の環境に依存するにしても、実際にブラウザで計測したよりも値の開きが大きい印象が強いです。
順当に考えれば各国の拠点的なものがあるとは思いますが、この計測がどこでどこ基準でおこなわれているのかはよくわかりませんでした。
なお、どうやら1秒を越えるとほぼ赤警告になるようなので、一気に点数が下がります。
WordPressでも中身によっては200msを切ることはできますが、どのページでも常に200msを切るというのは難しいように思います(実現できているサイトがあれば是非知りたいです)。
そのため、安定して高得点となると以下の方法しかないかなと思います。
- プラグインなどでキャッシュを使う
なお、静的サイトであれば警告のでる可能性は低いと思っていたのですが、そうでもないようです。
この件に関しての実例は、記事末のAMPキャッシュの部分をご覧下さい。
ブラウザのキャッシュを活用する
SNSボタンや計測ツールなど外部のものを読み込んでいる時点で、ストレートな改善案はなさそうです。
実際には以下のような対策をとることになるでしょうか。
- 外部読み込みのあるものは、一切使わない
- 外部読み込みのあるののは、全て読み込みを遅延させる
遅延表示に頼らざるを得ない部分は多そうですが、ファーストビュー内に外部サービスを利用するものがあった場合は悩みどころです。
何らかの手段を講じ、警告の出ない状態のものを作る必要があるかもしれません。
CSS/JavaScript/HTML を縮小する
縮小する系は単に縮小すればOKですが、計測時の点数によっては１つ縮小しただけでは加点がない場合があります。
やるなら3つか2つ同時のほうが良いかもしれませんが、1点上がるか上がらないかよりも警告の数を減らすという観点から考えたほうが進めやすいと思います。
結び
間違ったことを書いていなければ良いなとは思いますが、自信はありません。
現状のモバイルフレンドリーテストのページで得られる検査結果は大雑把な印象で、もしも PageSpeed Insights が消えてしまうと色々と不便になるため、ぜひ残して欲しいです。
ツールによる評価に固執することの危険性
改めて書くまでもありませんが、PageSpeed Insightsしろ他のツールにしろ、点数化しているタイプのものはそれぞれの基準で評価しているに過ぎません。
今後HTTP2のようにより高速な仕組みが出てくれば、サイト自体も適した形に変わることになるためです。
サイトの状態を考慮しない計測ツールに固執しても、速度の向上は望めません。
反面、仕事に絡むサイトの場合は速度を求めて売り上げを捨てるという訳にもいきませんから、速度に固執しすぎないことも重要に思います。
AMPページの点数
ちょっと気になっていたAMPページのPageSpeed Insightsの点数を知らべてみました。
AMPキャッシュのページ
- 当サイト記事のAMPキャッシュ
- モバイル 90点 / パソコン 83 点
AMPキャッシュのパソコン版では、「サーバーの応答時間を短縮する」が赤警告で、「リンク先ページのリダイレクトを使用しない」以外が全て黄警告でした。
速度を向上させるためのキャッシュなのに「サーバーの応答時間を短縮する」で警告がでているのをみると、微妙な気持ちになります。
ちなみにこれは複数回のテストの中でたまたまでてきたものですが、PageSpeed Insightsの不安定さの一端が垣間見える、かもしれません。
しかしここまで警告が出ていても、問題の度合いが軽微なら80点台がでるというのは初めてみました。
AMPフォーマットのページ
- 当サイト記事のAMPフォーマットの記事
- モバイル 88点 / パソコン 95 点
AMPフォーマットのページは、実は結構高速です。
0人がこの記事を評価
役に立ったよという方は上の「記事を評価する」ボタンをクリックしてもらえると嬉しいです。
連投防止のためにCookie使用。SNSへの投稿など他サービスとの連動は一切ありません。
