画像とフォントで表示速度を半分にする

「サイトが遅い」と相談を受けて中身を見ると、原因の上位に必ず入るのが画像です。とくに多いのが、スマートフォンで撮影した数 MB の写真を、サイズも形式も変えずにそのまま載せているケースです。

画像は、Core Web Vitals の中で「主要な中身が表示される速さ」を測る LCP を最も悪化させる典型要因です。ファーストビューの大きな写真が重いと、ページが表示されきるまでの時間がそのぶん延びます。

逆に言えば、画像を適切に直すだけで体感速度は大きく変わります。コードの書き換えやサーバーの引っ越しといった大がかりな作業の前に、まず取り組む価値があるのが画像の最適化です。

同じ写真でも、保存する「形式」を変えるだけでファイルサイズは大きく変わります。現在の主役は AVIF と WebP の 2 つです。

web.dev によると、AVIF は JPEG 比で約 50%、WebP 比でも 20〜30% ファイルサイズが小さくなります。見た目の品質をほぼ保ったまま、写真の重さを半分近くまで落とせるということです。ブラウザの対応も広く、2025 年 9 月時点で AVIF が約 94%、WebP が約 95% の環境で表示できます。

つまり「JPEG や PNG のまま載せている写真を AVIF / WebP に変換する」だけで、ほとんどのサイトは目に見えて軽くなります。撮影した写真をアップロードする前に、変換のひと手間を挟む。これが最も費用対効果の高い最適化です。

AVIF は軽い一方、ごく一部の古い環境では表示できません。そこで使うのが picture 要素です。複数の画像形式を並べて書いておくと、ブラウザが「自分が表示できる中で最も上にあるもの」を自動で選びます。

定石は、AVIF を主、WebP をフォールバック、JPEG を最終保険として並べる構成です。AVIF が使える環境では AVIF、使えなければ WebP、それも無理なら JPEG、と段階的に降りていきます。すべての訪問者が「その環境で最も軽い画像」を受け取れます。

この仕組みは一度組んでしまえば、あとは画像を差し替えるだけ。新しい形式が普及しても、同じ構成のまま対応できる拡張性も持っています。

画像でもう一つ起きがちなのが、読み込んだ瞬間に周囲のレイアウトがガタッとずれる現象です。これは Core Web Vitals の CLS（表示のずれ）を悪化させ、読んでいた行を見失わせたり、ボタンの誤タップを誘発したりします。

原因は、画像にサイズが指定されていないこと。サイズ指定がないと、ブラウザは画像が届くまで「どれだけの場所を空けておけばいいか」が分からず、画像が来てから慌てて場所を確定します。そのぶん下の要素が押し下げられてずれます。

対策はシンプルで、画像に幅と高さ（または縦横比）をあらかじめ指定すること。場所を先に確保しておけば、画像が届いてもレイアウトは動きません。img 要素に width と height を書く、この一手間だけで CLS の主因の一つが消えます。

画像の次に注意したいのがフォントです。Web フォントは読み込みに時間がかかり、その間に「文字が一瞬消える」「あとから別のフォントに入れ替わって行がずれる」といったちらつきが起きます。

web.dev が挙げる最有力の対策が、font-display: optional とフォントの preload の組み合わせです。optional は「読み込みが間に合わなければ無理に切り替えず代替フォントのままにする」設定で、後からの入れ替わりによるレイアウトシフトを防ぎます。preload は重要なフォントを早めに読み込ませる指定です。

補足として、フォントを自分のサーバーに置く（self-host）場合でも preload には crossorigin 指定が必要です。また size-adjust を使うと、代替フォントと本来のフォントの大きさの差を揃え、入れ替わり時のずれをさらに抑えられます。