PageSpeed Insightsのナゾのお告げ

ナゾのお告げ

Googleが提供しているPageSpeed Insightsという、ブラウザベースで使用できるツールがあります。任意のURLを入力すると、初期読み込み時パフォーマンス最適化のための具体的な提案をしてくれます。実際に計測してみると、おそらく殆どのWebページで下記の項目が表示されるのではないでしょうか。

日本語なのに、何を言っているかさっぱりわかりませんね(^_^;)
筆者も初めてこの記述を見た時は意味がわからず、見なかったふりをしました。

まず「スクロールせずに見えるコンテンツ」とは、ざっくりいうとファーストビューのことだと思われます（厳密に言うと、折りたたまれて非表示となっているコンテンツも除いた部分。原文は”above-the-fold content”）。さしあたってファーストビューのレンダリングのみを先に完了させて、ページが素早く表示されたとユーザーに感じさせる、というのがこの「お告げ」の狙いです。

クリティカル・レンダリング・パスとクリティカル・リソース

具体的にどうすればいいのかを検討する前に、ブラウザのレンダリング工程について簡単に見ていきましょう。

Webサイトパフォーマンスを話題にすると必ず出てくる言葉に「クリティカル・レンダリング・パス」というものがあります。「クリティカル・パス」というのは「重要な経路」という意味で、何か物事を進める過程において、欠くべからざる工程のことです。ブラウザのレンダリングの過程における「クリティカル・レンダリング・パス」とは「ブラウザがサーバーからHTMLのレスポンスを受け取り、スクリーンにピクセルが描画されるまでに必要な工程のこと」です。

ブラウザからHTMLファイルへのリクエストが送られると、サーバーから応答があり、ダウンロードが開始されます。ダウンロードが完了すると、ブラウザのHTMLパーサがパース（解析）を行います。この時、ソースに書かれている順番に外部ファイルが読み込まれていきます。CSSの外部ファイルがある場合はその読み込みが完了してからCSSのパースが開始されます。HTMLとCSSのパースが両方完了すると（DOM構築・CSSOM構築）、ようやくレンダリングの工程が開始される仕様になっており（※1）、つまり、HTMLファイル自体、そしてCSSファイルの読み込みが完了するまでレンダリングが始まらないことになります。こういったリソースは「クリティカル・リソース（※2）」または「レンダー・ブロッキング・リソース」と呼ばれているようです。

因みに、HTMLの中にscriptタグがあると、スクリプトの実行が終わるまでパースはブロックされます。すなわちJavaScriptはDOMの構築をブロックします。DOMの構築が終わらないとレンダリングが開始されないので、JavaScriptもクリティカル・リソースであると言えます。

ですので、HTML・CSS・JavaScript（クリティカル・リソース）の読み込みを早くすること、または数を減らすこと、そして読み込みの順序を考慮するなどして、レンダリング開始までにかかる時間をできるだけ短くすること（=クリティカル・レンダリング・パスの最適化）がWebサイトパフォーマンスを良くすることにつながります。

ナゾのお告げに従ってみる

クリティカル・レンダリング・パスの最適化のために必要なことを整理します。

リソースの読み込みを早くするには、コメントやスペースを削除してリソースのファイルサイズを抑えたり、データ転送の際にGzip圧縮を利用したり、ブラウザキャッシュを利用するなどが、有効な手段となります。とはいえ、コメントやスペースを削除すると、ソースの可読性や保守性が損なわれてしまいます。こういった処理を行う場合は、開発環境とは別にデプロイ用のファイルを自動的に書き出すなど、ワークフローを整える必要がありそうです。

次に、クリティカル・リソースの数を減らすことを考えてみましょう。具体的には外部ファイルをHTML内にインライン化しすればいいのですが、すべてのCSSルールセットをインライン化すると、クリティカル・リソースの数は減るものの、HTMLファイルのサイズがCSSファイルのサイズ分増えてしまいます。ファイルサイズを肥大化させずにクリティカル・リソースの数を減らすにはどうしたらいいでしょうか。

CSSについては「お告げ」に記載されているように「リソースの重要部分を HTML 内に直接インライン化」します。

すなわち、ファーストビューの表示に必要なCSSルールセットのみをインライン化し、CSSファイル自体は非同期で読み込む（＝レンダリングをブロックしない形で読み込む）ようにします。（詳細は割愛しますがJavaScriptについては、インライン化する以外に描画に関係のない外部ファイルは非同期で読み込む（=async属性を付ける）などの対応でクリティカル・リソースでなくすることができます。）これについても、手動で行っていてはソースコードの保守性が著しく損なわれることになりそうです。そこで、gulpのCriticalというパッケージを使ってインライン化作業を行ってみました。

すると、単純に二つのCSSファイルを読み込んでいただけのソースコードが…

このようになりました。

CSSファイル読み込み用のlinkタグのrel属性が”preload”となっています（※3）（loadイベント発火後に”stylesheet”に書き換える）。するとこのCSSファイルは非同期で読み込まれるようになり、レンダリングをブロックしなくなります。ただし、この状態ではスタイル適用前の状態が一瞬表示されてしまうため（※4）、ファーストビューの表示に必要なCSSルールセットをインライン化してhead内に記述しています。

この作業を施したページをPageSpeed Insightsで計測したところ「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」というお告げが消え、とりわけモバイルでのスコアが大幅に改善しました。

とはいえ、両者のページ描画完了までにかかる時間はさほど変わらないようでもあります。ChromeDevToolsのperformanceパネルでプロファイルを取り、両者のイベントログを見てみました。左側は適用前、右側が適用後のイベントログです。

適用前はCSSファイルの読み込みとCSSのパースが完了してから初めてレンダリングが始まっており（1583ms後）、最初の描画は1618ms後に開始されています。一方、適用後はCSSファイルの読み込み完了を待たずにレンダリングが開始されており（1228ms）、最初の描画は1254ms後に開始されています。初期の描画（First Meaningful Paint）まで364ms短縮されています。しかし体感速度的にはさほど変わらない気がします。そして、loadイベントが発火するのは、3.94s → 3.75sと、あまり変わっていません。

同じくChromeDevToolsのAuditsパネル(※5)でパフォーマンスのスコアを取ってみました。

performanceパネルの結果とは若干数値が異なりますが、First Meaningful Paintのスコアが改善されているのがわかります（因みに、Auditsの計測結果は毎回大きく異なり、動作が安定していない様子…）。

スコアとしてはいずれも改善が見られましたが、このサンプルでは体感速度的に著しく改善されたわけでもありません。スコアはあくまでもツールの示す指標であり、目指すのはユーザーが快適に閲覧できるページを作ることで、スコアを上げること自体が目標ではありません。複数の計測方法を併用し、CSSファイルの読み込みが初期読み込み時のボトルネックになっていることが明らかな場合のみ、インライン化作業を行えばいい気がします。

また、サイト内共通のファイルを読み込んでいる場合は、2ページ目閲覧以降はブラウザキャッシュが効いた状態となり、リソースのダウンロードにかかる時間は大幅に短縮されます。このことも念頭に置き、労力と効果のバランスを勘案して最適化していくのが良さそうです。

メディアクエリごとにファイルを分ける

CSSファイルの読み込みを早めるためには、メディアクエリごとにファイルを分けるのも有効です。linkタグのmedia属性に表示中のページにマッチしないメディアクエリが指定されていると、そのCSSファイルの読み込みは後回しにされます。描画に必要なリソースがすべてダウンロードされてから取得され、レンダリングもブロックしません。すなわちクリティカル・リソースではなくなります。クリティカル・リソースであるCSSのファイルサイズが減らせるとともに、レンダリング（CSSのマッチング処理）にかかる時間も減らせるので、クリティカル・レンダリング・パスを最適化できることになります。

下記のようにスタイルシートを読み込むと…

<link rel="stylesheet" href="css/style.css">
<link rel="stylesheet" href="css/style_pc.css" media=(min-width:768px)>

このことから、CSSをモバイルファーストで記述すると、モバイルでの表示時にはクリティカル・リソースの数・ファイルサイズともにPC表示時よりも小さくなり、パフォーマンス的によりモバイルフレンドリーになることがわかります。

とはいえ、近頃はメディアクエリごとに記述するよりも、運用のしやすさから次のように同じセレクタごとにまとめて記述することが多いのではないでしょうか。

.sp {
    display: block;
}

@media only screen and (min-width: 768px) {
    .sp {
        display: none;
    }
}

とりわけSassなどのCSSプリプロセッサを使っている方は、設定ファイルにメディアクエリ用の設定を書いておいて、効率よく記述できるようにしている方が多いと思います。筆者は下記のソースをSCSSの設定用ファイルに記述し、実際に記載するソースをスニペットに登録して、トリガーを数文字入力するだけでメディアクエリの記述ができるようにしています。

@mixin mq {
  @media only screen and (min-width: $breakPoint) {
    @content
  }
}

こういったワークフローを今更変えたくはないですよね。そこでメディアクエリごとに記述をまとめるgulpのパッケージを見つけましたが…

メディアクエリごとにファイルを分割するというオプションはなさそうです…。HTTP/1.1では、パフォーマンス最適化のためにはファイルをまとめる方向に向かっていたので、メディアクエリごとにCSSファイルを分割する方法は、筆者自身もこれまで取ってこなかった気がします。HTTP/2が普及するにつれて、このあたりの傾向も変わってくるのでしょうか。

ファイル分割するためのgulpパッケージ、もしくはgulpの利用以外で同様の操作を実現する方法をご存じの方はご一報ください(^^)/

参考

• クリティカル レンダリング パスの最適化
• Browser Rendering Optimization (動画レッスン)
• Website Performance Optimization (動画レッスン・日本語字幕有)
• Client-Server Communication (動画レッスン)