【技術小話】「.webp」をResource HintsでPreloadさせることは正しいか

== お知らせ ==
⚠️ この記事は一部の技術者向けの記事です。
一般の方にはお楽しみいただけない内容になります。
==========

◎お急ぎの方のためにまず結論から
「気にせず「webp」をResource Hintsで提供(Preload)してたぶんOK」

◎理由
・「Resource Hints(Preload)」に対応していて、「webp」に対応していないブラウザは僅か。
・現状ではSEOにも良い影響しかもたらさない”はず”。

広告

ウェブサイトを高速化する技術の一つに「Resource Hints」があります。
これは、ウェブサイトの読み込みを始める際に、予め今後確実に必要となるデータをアクセスした端末に伝えることで、メインコンテンツと同時に並列でダウンロードさせることで、ページ全体の表示を早くするというものです。

これが導入されていない通常のウェブサイトでは、コンテンツが必要とわかる度に、ダウンロードを実行しています。

こんな感じ

1、ページのHTMLをダウンロード
2、HTMLの中でデータAが必要と判明
3、データAをダウンロード
4、HTMLの中でデータBが必要と判明
5、データBをダウンロード
6、HTMLの中でデータCが必要と判明
7、データCをダウンロード
8、ページの表示完了

この例では8つも手順が必要でした。

広告

これに対して、Resource Hintsを導入
つまり、HTML内のHEAD(ページの先頭部分)、またはレスポンスヘッダー(ページが読み込まれるより先に提供される情報)内でLINKとして「preload」=事前読み込み(またはpreconnect、prefetch、dns-prefetch等、詳細説明は省略)をするコンテンツを予め設定することで…

1、ページのHTMLをダウンロード開始
2、データAとデータBとデータCが必要と記載を発見(Resource Hints)
3、データA、データB、データCをダウンロード
4、ページの表示完了

という感じに、処理を並列化しつつ手順を減らすことで、大幅にウェブサイトの高速化が可能です。

このResource Hintsを使う中で、どのコンテンツをResource Hintsとして提供させるか、というのが一つの課題となります。
そして、この課題に取り組む時に一部の人がぶつかるであろう課題がこれ。

・最新の画像形式「webp」をResource Hintsで提供(Preload)するべきか問題

広告

画像のファイル形式といえば「jpeg」や「gif」が一般的です。
この2つはほぼ全てのブラウザが対応しているので、多くのサイトがこのどちらかの画像形式を使用しています。

これよりも新しい物としてGoogleが2010年末に制定した新画像ファイル形式が「webp」です。
「jpeg」や「gif」よりも、同じ画質でもファイルのサイズが小さくて済むメリットがあり、ファイルのサイズが小さいということはその分、ウェブサイトを高速で提供することができるということです。

しかし、この「webp」には「まだ新しい」という問題があり、全てのブラウザが対応している訳ではありません。
対応していないブラウザでは「webp」は表示されず、エラーとなります。

この問題を解決するため、多くの「webp」を利用しているサイトでは「webp」に対応しているブラウザにのみ「webp」を提供し、非対応のブラウザには「jpeg」や「gif」等の従来のファイル形式を提供するという対応をとっています。
(この記事を公開している近江通信でもそうしています。)

近江通信ロゴOG用イメージ
提供している画像の例。この画像のURLを確認すると、対応ブラウザでは「webp」非対応ブラウザでは「jpeg」となっている”はず”。

でも「webp」だからといって、個別にダウンロードさせていれば、それだけわずかに時間がかかってしまいます。

となれば、前述の「Resource Hints」を使う話というになるのですが、ここで一つ問題が発生。

もし「webp」に対応していないブラウザに「webp」を“Resource HintsでPreload=事前読み込み”(以下:Preload)させると、使わない(使えない)ファイルを供給したとして、ユーザーの帯域を無駄遣いすることになります。

広告

では「Resource Hints」を「webp」対応ブラウザにだけPreloadさせ、「webp」非対応のブラウザには「jpeg」や「gif」等の従来のファイルをPreloadさせれば良いということになるかもしれませんが…..

結論から言って、これは現実的ではありません。

アクセスしてくる端末に応じてPreloadさせるということは、Preloadを指示する文字列を動的に変更させる必要があるということになりますが、その動きを実装するには次の2つの方法しか”たぶん”ありません。

・HTMLのヘッダーで「JavaScript」を使って動的にPreloadを提供する
・PHPでレスポンスヘッダーをリファラ―ごとに分岐させる

1つ目のJavaScriptを使う案は論外。ページを速く提供することが目的なのに、JavaScriptで処理を追加するなんてありえません。2つ目の案は多くの人が実行する「キャッシュ化」という高速化技術と致命的に相性が悪く、これも多くの人にとって現実的ではありません。

では、どうするべきか。「webp」を「Preload」しない?

色々悩むことになりますが、ここで着眼点を変えてみましょう。

・WEBPとResource Hintsがブラウザに実装されたタイミング

ここに「WEBP対応ブラウザ」と「Preload対応ブラウザ」の表データがあります。

WEBP対応ブラウザ
https://caniuse.com/webp

Resource Hints対応ブラウザ
https://caniuse.com/link-rel-preload

この二つを見比べると、「Preloadに対応していて、「webp」に対応していないブラウザはほとんど存在しないことがわかります。

機能の実装タイミングについても、ほとんどのブラウザでwebpの方が先に実装されていて、Preloadの方が後で実装されていることが解ります。

数あるブラウザとバージョンの中で、次だけがPreloadに対応していて、「webp」に対応していないブラウザです。

Edge バージョン「17-18」
Firefox バージョン「56」
Safari バージョン「11.1-14」
Safari(iOS) バージョン「11.3-14.4」

どれもあまりにも古いバージョンで、ブラウザ公式のサポートも切れています
また、これは各ウェブサイトにより変動する値にはなりますが、近江通信にアクセスしている人で上記のブラウザを使っている人は全体の「0.1%以下」でした。

つまり「webp」をPreloadさせるようにすると、0.1%以下の古いブラウザを使うユーザーは数百kb無駄なリソースをダウンロードしてしまう代わりに、残りの99.9%のブラウザを使うユーザーは影響を受けないか、ページの表示が結構早くなるということです。

SEOの観点からも、上記の「Preload」に対応していて、「webp」に対応していないブラウザに「Google Chrome」が無い=Google検索に使用されることがあるデータ「Chrome User Experience Report」に悪い影響を与えることは無いということが言えます。

さらにページの表示速度がPreloadで加速すれば「Chrome User Experience Report」の数字が良くなり、SEOで有利になることが期待できるでしょう。

これらを踏まえると、「webp」をPreloadさせることは「とても合理的」と言えると思います。

広告

著者: 中村書記

交通ニュースなどを主に書くライター。三度の飯よりドライブが好き。法学系の人なのにすごく残念な人。Twitter:@oumi_nakamura / プロフィールページ