サイトからのおしらせ(クリックで一覧)

「クリティカルなリクエストの深さの最小化」を攻略する ~Pagespeed Insights対策

この記事は約6分で読めます。

質問者の写真

「クリティカルなリクエストの深さの最小化」って何!?
どんな対策すればいいのか見当もつかない!
 

「クリティカルなリクエストの深さの最小化」って?

みんな大好きGoogleのPagespeed Insights(PSI)。
その中でも難解な項目の一つが「クリティカルなリクエストの深さの最小化」ではないでしょうか?

Googleのページには次の通り書いてます。

クリティカル リクエスト チェーンは、クリティカル レンダリング パス(CRP)の最適化技術のコンセプトの 1 つです。 CRP を考慮してリソースに優先度を設定し、読み込む順序を指定すると、ブラウザでより早くページが読み込まれるようになります。

引用:Google Developers「クリティカル リクエスト チェーン」

どこの記事を見ても、こうした定義の話ばかり。
具体的に何をすればいいかは書いてなかったり。

質問者の写真

アフィリエイトのために記事乱造すればいいってもんじゃないよ!
 

そのくらいの悪態をつきたくなりました。

そこで、私がどうやってこの項目をクリアしたか記してみたいと思います。
全てのケースに当てはまるというわけではないでしょうが、参考にはなるでしょう。

「クリティカルなリクエストの深さの最小化」問題の検討

私はどのリソースで出ていたか

当サイトで出ていたリソースは2つ。
両方ともwebフォントです。

実はこのこと自体が考えるためのヒントです

攻略するためのキーワードは「優先度」と「順序」

webフォントで指摘された。
そして定義には「優先度」と「順序」。

とくれば、

解答者の写真
対策として思いつくのはpreloadじゃないかしら?
 

link rel=preloadとは?

preloadには、指定したリソースを先読みさせる役割があります。
以下、Firefoxの開発元Mozillaによる説明です。

<link> 要素の rel 属性で preload を指定すると、 HTML の <head> 要素内で読み込みリクエストを宣言し、ページのライフサイクルの早期の、ブラウザーの主なレンダリング機構が起動する前に読み込みを始めたい、すぐに必要なリソースを指定することができます。これにより、そのリソースがより早く利用でき、ページのレンダリングがブロックされにくくなり、性能が向上します。

引用:Mozilla「rel=”preload” によるコンテンツの先読み」

うまく使えば高速化に役立ちます。
そしてPSIにおいてもpreload自体が「キー リクエストのプリロード」という指摘項目になっています。

しかし私の場合は「キーリクエストのプリロード」でwebフォントは指摘されませんでした。
一見関係ないように見えます。

「クリティカルなリクエストの深さの最小化」の具体的対処法

クリティカルリクエストチェーンにおいては「preloadを使え」というのではなく「preloadを用いるのが解決手段の1つ」という意味です。
具体的な対処法については本項目で述べます。

当サイトの状況を検討してみる

変更前のヘッダーへの記載は次の通り。

<link rel="preload" href="https://test.kimoota.net/wp-content/themes/hoge/hogefonts.css" as="style">
<link rel="stylesheet" href="https://test.kimoota.net/wp-content/themes/hoge/hogefonts.css" media="print" onload="this.media='all'">
<link rel="preload" href="https://test.kimoota.net/wp-content/themes/hoge/hogehogefonts.css" as="style">
<link rel="stylesheet" href="https://test.kimoota.net/wp-content/themes/hoge/hogehogefonts.css" media="print" onload="this.media='all'">

webフォントのcssを非同期で読み込む技法です。
詳しくはこちらの記事を御覧ください。

しかし、フォントファイルの方はpreloadしていなかった。
そのため、間隔が空いてしまっていたわけです。

つまり、

解答者の写真
webフォントもプリロードすればいいわけね
 

webフォントをプリロードするための方法

しかし問題があります。

質問者の写真

webフォントってブラウザで読み込むファイルが違くない?
 

ttf、woff、woff2とあるわけで。
だからこそ私もプリロードしようとは思っていませんでした。

しかしwoff2対応も広まった今、決め打ちしてもいいのではないか。
そう考えて、まずcssの@font-faceにおける順番を変更します。

@font-face {
font-family: 'hogefonts';
src: url('/font/hogefonts.woff2') format('woff2'),
url('/font/hogefonts.woff') format('woff'),
url('/font/hogefonts.ttf') format('truetype');
}

こう書けばwoff2から優先して読み込まれていきます。

その上で、woff2についてのみプリロードします。

<link rel="preload" href="https://test.kimoota.net/wp-content/themes/hoge/hogefonts.woff2" as="font" type="font/woff2" crossorigin>

ヘッダーへ記載する順番

フォントファイルをプリロードする意義は、本来はcssを読み込まないとわからないリソースを先読みして時間の短縮を図る点にあります。

つまりcssより前にフォントファイルを読み込まないとだよね

hogefonts(仮)においては、ヘッダーへ次の通り記載します。

<link rel="preload" href="https://test.kimoota.net/wp-content/themes/hoge/hogefonts.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="https://test.kimoota.net/wp-content/themes/hoge/hogefonts.css" as="style">
<link rel="stylesheet" href="https://test.kimoota.net/wp-content/themes/hoge/hogefonts.css" media="print" onload="this.media='all'">

まずwebフォントファイルをプリロードで読み込む。
そしてwebフォントのcssを読み込む。
これでPSIからの警告が消えました。

実際にF12で滝を見ても、かなり早い段階でフォントが読み込まれています。

おまけ

現在も警告は一応残ってます。

最初の移動先
https://test.kimoota.net – 160 ms, 47.75 KB

さすがに対策しようがありません。
元々、合格・不合格の項目ではないので、これでOKです。

まとめ

解答者の写真
私のパターンはあくまで1つの例にすぎません。
恐らく色んなパターンがあるものだと思います。
ただ解決法を考えるヒントにはなるのではないでしょうか?
よろしければ参考にしてみてください
 
この記事を書いた人:天満川 鈴

広島市内のパチンコホール勤務。
3号機時代からのパチンカス。

ADHD、精神障害者手帳3級所持。

慶應義塾大学商学部→国家一種経済職→公安調査庁。
在職時は国際テロ、北朝鮮を担当。

「小説家になろう」の底辺作者。
朝鮮総聯へのスパイ工作を描いた小説「キノコ煮込みに秘密のスパイスを」はアマチュア小説ながら週刊誌報道され、話題となった。