梅雨と夏の間。
じめじめで蒸し暑いし、蚊の襲撃に毎晩怯えているよっし～です。
サイト高速化に関わるといつかは目にするであろうプリロード（preload）。
videoやaudio要素、ヘッダーのlink要素の属性の1つで、意味としては「事前に読み込む」というものです。
WordPressのテーマやプラグインの機能としてもたまに見かけます。
そんなプリロードですが、Webサイトの高速化には本当に必要なのでしょうか。
わたしはこれまでに500件以上のサイトをPageSpeed Insightsベースで高速化してきましたが、link要素のプリロードは見つけ次第削除しています。
だって意味ないんだもん。
その理由を書いていこうと思います。
まずはlink要素のプリロードについて知ろう
link要素のプリロードとは具体的は以下の様なタグです。
<link rel="preload" as="font" href="font.woff">
<link rel="preload" as="image" href="image.png">他にも種類はあるけど、webサイト高速化によくあるのはこんな感じのです。
このタグをヘッダーに追加することで、指定したものを最初の方で読み込むようになります。
”最初の方”っていうのを掘り下げると、まず、ページの読み込みはhtmlソースの上から順に行われています。
このプリロードタグは<head>タグ内に設置されているので、body要素、つまり実際に表示される部分が読み込まれるよりも前に読み込まれるようになります。
自分で言っといてなんだけど、ややこしいね（汗
まぁ、ざっくりと「最初の方に読み込まれるもの」と覚えておけばいいと思う。
どんな時に何のためにプリロードするの？
わたしはプリロードをしないので、正直なところよく分かりませんorz
でも一応調べてみると、
- PageSpeed Insightsでキーリクエストのプリロードという警告が出たから
- CSSを遅延読み込みするため
- レザリングブロックを回避するため
などの記事を見つけました。
気になる方は検索してみてください。
ただ、わたしからするとどれも疑問に思うところがあり、それで本当に効果があるのかな～というところです。
実際にこうなる！というものを確認できればいいんだけど、どの記事も難しい単語を並べてそれっぽく説明している感じで、結果が見て取れませんでした。
プリロードを削除する理由
いよいよ本題です。
まずプリロードを削除する理由は、「意味がないから」とでも言っておきましょう。
例えばフッターとかページの後の方で読み込んでいたものを最初に読み込ませるって言ってもだよ、そもそもなぜそれを後の方で読み込んでるの？っていうのがあります。
最初からヘッダーやページの最初の方で読み込んでれば、プリロード必要ないじゃんっていうことです。
お仕事で見かけるのはこんなパターンです。
- ウェブフォント遅延読み込み機能をオンにすると同時にそのウェブフォントをプリロード
- Googleフォント、fontoawesomeはとりあえずプリロード
- 画像遅延読み込みをすると同時にファーストビューの画像をプリロード
- 用途不明のファイルをプリロード
何となく意味ないってわかるかな。
一応それぞれ説明しておきます。
ウェブフォント遅延読み込み機能をオンにすると同時にそのウェブフォントをプリロード
だったら最初から遅延読み込みしないでよって言いたい。
遅延読み込みするのだってリソースはあるんだから、無駄だよね。
Googleフォント、fontoawesomeはとりあえずプリロード
意味はありますか？
こうするとPageSpeed Insightsのスコアは上がるのですか？
わたしが試した限りでは目に見えた効果はありませんでした。
画像遅延読み込みをすると同時にファーストビューの画像をプリロード
画像遅延読み込みの仕方に問題があるよね。
画像遅延読み込みはオフスクリーンに対してするのが効果的なんだよ。
PageSpeed Insightsでも警告は「オフスクリーン画像の遅延読み込み」って書いてあるよね。
ファーストビューの画像は遅延読み込みしないように除外するのが正しいのです。
用途不明のファイルをプリロード
プリロードしたものはファーストビューで必ず読みこまれるんだよ。
ページのどこでも使われていないものをプリロードしたら逆にファーストビューの読み込みが増えて速度は落ちちゃうよ。
PageSpeed Insightsの「キーリクエストのプリロード」警告は何なの？
PageSpeed Insightsでは以下の様な説明書きがあります
`<link rel=preload>` を使用して、現在ページ読み込みの後のほうでリクエストしているリソースを優先的に取得することをご検討ください。
大抵の場合は誤った遅延読み込みです。
PageSpeed Insightsでは以下の詳細のリンクがあるのですが、
https://web.dev/uses-rel-preload/
こちらの例では、
index.html
|--app.js
|--styles.css
|--ui.jsのようにJavascriptを介してCSSやJavascriptを読み込んでいます。
こういった場合はプリロードをすると効果的ですよ～ということですが、、、
こういう設計をファーストビューですること自体が問題じゃないかな？
表示速度の観点から見たらだけど。
プリロードで目に見えた効果があるならやった方がいいとは思う
WordPress高速化のお仕事では、link要素のプリロードは見つけ次第削除しているわたしですが、その理由は先述した通りです。
ここまでプリロードを散々にディスってきましたが、プリロードをしてPageSpeed Insightsのスコアが上がるのならやる価値はあるはずです。
ただ、わたしの経験ではプリロードをしてもPageSpeed Insightsのスコアが目に見えて良くなった、ということが一度もないのでこういう考えに至っています。
あ、遅延読み込みしたものをプリロードしたことで効果があった！っていうのはダメだからね！
あとがき
お仕事の方で余裕が出てきたので、また久しぶりにブログを更新してみました。
書きたいネタはあるけど忙しくて書けない！っていう時は忙しいのキツイって思ってたけど、、、
実際に余裕が出てくるとそれはそれで物足りないというか、休んじゃっていいのかなという危機感というか。
なんかフワフワします。
仕事が忙しいっていうのは嬉しいことなんだとしみじみ。
更新頻度が高くなってきたら、「コイツ暇なんだな～」と思ってやってください(;´Д｀)
こんばんは。
このサイトは表示が速いので、以前から個人的に注目していました。
この記事も大変興味深く拝見させていただきました。
概ねおっしゃる通りだと思います。
一例として、以下のようなケースはどうでしょうか？
例えば、クソ重たい容量の外部CSSファイル（以下、「クソCSS」と呼びます）があるとします。
このクソCSSにはファーストビュー範囲内のWebフォント表示に関する記述が書かれているとします。
クソCSSをhead要素内で普通に読み込む場合は、クソCSSがダウンロード・解析されるまではレンダリングがブロックされ、画面描画（first paintのことです）が開始されません。
しかし、このクソCSSを遅延読み込みさせるとレンダリングブロック要素ではなくなるため、クソCSSがダウンロードされる前でも画面描画が開始されます。
つまり、first paintのタイミングが速まります。（この速さを※１とします）
ただ、この時点ではクソCSSがまだダウンロード・解析されていないため、Webフォントは適用されないことになります。（FOUCが発生するということ）
次に、クソCSSをpreloadさせるとします。
すると、クソCSSはレンダリングブロック要素ではないためにfirst paintのタイミングはそのまま維持でき、かつ、preloadさせることによってダウンロードの優先順序が先になるため、さっきより早い段階でWebフォントが適用されることになります。（この速さを※２とします）
preloadさせる前（※１）と後（※２）を比較すると、リソースのトータルのダウンロード量は変わらないため、表示速度自体はほぼ変わらないかもしれません。
そのため、Pagespeed Insightsのスコアもほぼ変わらないと思われます。
しかし、画面上でWebフォントが適用されるタイミングは速まっているため、閲覧した人の体感としては速くなったと感じるのではないでしょうか。
たにさん、こんにちは！
コメントありがとう☆
一言で高速化と言っても人それぞれ何をもって高速化とするかや、施策できる範囲も決まっていると思います。
そんな中で、「Webフォントが適用されるタイミングは速まっているため、閲覧した人の体感としては速くなったと感じる」というのはおっしゃる通りだと思います。
私の考えや実際の作業としてはですが、CSSがとても重いといっても全て遅延読み込みすると画面が一瞬崩れてから表示されるような挙動になるため、好ましくないと考えています。
CSSの中でもクリティカルCSS（ファーストビューに使われているCSS）をまず見極めるのですが、大抵の場合テーマ出力するメインのCSSはクリティカルCSSなので、これは遅延読み込みせず圧縮インライン読み込みをしています。
インライン読み込みであればレンダリングブロックは起こらず、また、そこにウェブフォントに関わる記述があったとしてもヘッダーで読み込んでいるのでページの最初の方で読み込まれることになり、プリロードも必要なくなります。
その他では例えば目次プラグインのrtocですが、こちらのCSSにはGoogleフォントが記述されています。
この場合、Googleフォントはプリロードした方がいいかですが、目次部分がファーストビューに表示されているのであればクリティカルCSSになりますので、Googleフォントをプリロードするよりも、CSS自体を圧縮インライン読み込みにした方が効率は良いです。
ですが、圧縮インライン読み込みが難しいという場合、Googleフォントをプリロードするとたにさんがおっしゃったような効果が期待できると思います。
とはいえ、基本的にはGoogleフォントは重いので可能な限り削除するようにしているんだけどね(*´ω`*)
返信ありがとうございます。
夜分遅くに申し訳ありません。
以下からはファーストビューにGoogleフォントがあるという前提で考えてみます。
CSSをインラインで記述する場合はキャッシュされないというデメリットがありますが、おっしゃる通りレンダリングブロックは起きなくなるメリットがあります。
私はその目次プラグインを使用したことがないので詳細は分かりませんが、使用されているサイトを検索してソースを見てみたところ、インラインCSSの中で@importによって以下のようなCSSが読み込まれ、
//fonts.googleapis.com/css2?●●●（ここにフォントの種類などのクエリ）
上記CSSの中でfont-faceのsrcによってフォントファイルが読み込まれていました。
ということはつまり、
HTML内のインラインCSS → GoogleCSS → フォントファイル
という3回のラウンドトリップによってWebフォントが適用されます。
もしフォントファイルをHTML内でpreloadすると、
(同時ダウンロード)HTML内のインラインCSS
(同時ダウンロード)HTML内のフォントファイルpreload → GoogleCSS
の2回のラウンドトリップでWebフォントが適用されることになります。
これは私自身もとても興味のあって後学のためにハッキリ知っておきたい問題なので、実際にサンプルを作ってテストをしてみました。
【前者のケース】
//www.1-firststep.com/samplephp/preload-timing/index-4.html
【後者のケース】
//www.1-firststep.com/samplephp/preload-timing/index-5.html
ChromeのDevToolsを使い、速度をSlow 3Gにしてそれぞれのページを何度も表示させてみてください。
どちらもLoadは4.10秒当たりでほぼ変わりませんが、Webフォントが適用されるのは前者は6.7秒あたり、後者は4.7秒あたりになります。
CSS内のfont-familyでWebフォントを指定しても、フォントファイルを読み込まない限りは画面上に反映されないので、フォントファイルのpreloadはやはり必要なのではないかと思います。
まぁ、ファーストビューにWebフォントを使うことに私は個人的には反対なのですけどね。
この辺りはサイトのデザインや設計段階の問題になりますね。
連続してのコメントで申し訳ありません。
先ほどのコメント内で間違っている箇所がありましたので訂正いたします。
【誤り】
(同時ダウンロード)HTML内のインラインCSS
(同時ダウンロード)HTML内のフォントファイルpreload → GoogleCSS
【正しい】
HTML内のインラインCSS → GoogleCSS(同時ダウンロード)
HTML内のフォントpreload → フォントファイル(同時ダウンロード)
の2回のラウンドトリップになります。
たにさん、コメントありがとう☆
サンプルを拝見しました。
これは分かりやすいですね！
プリロードの効果が見て取れます。
CSSのインライン読み込みと言っても、中で@importがある場合は要注意だなと思いました。
勉強になります( ..)φメモメモ
丁寧に解説していただき感謝です♪
また何か気になる点がありましたらコメントいただければなと思います！
今後ともよろしくお願いいたします。
おはようございます。
返信ありがとうございます。
私自身もWebフォントのベストプラクティスは曖昧になっていた部分だったので、実験でハッキリわかってよかったです。
このぐらいのマニアックな話になると理解できる人も限られ、自分のブログに書いてもアクセスはほとんど増えないので、ノウハウを秘密にしたままになるケースが多いのですが、Yossybunnyさんなら理解できるかと思って書き込ませていただきました次第です。