速くする

画像、読み込みを止めるもの、JavaScript の量。この順に手を入れると、たいていの遅さは解けます。

図を大きく見る

図の中身を文字で読む

• 効く順に手を入れる。上から3つで、たいていの遅さは解ける。
• 1　画像　ページ全体の重さの過半を占めることが多い
• 表示する寸法の2倍を超えないところまで縮める（横1200pxの枠に4000pxを置かない）
• AVIF か WebP を第一候補にする。写真は JPEG より小さくなる
• srcset で画面幅ごとの候補を渡す。最初の画面より下は loading="lazy"
• 最初の画面に映る画像だけは lazy にしない。fetchpriority="high" を付ける
• 2　読み込みを止めるもの　head の中の CSS と同期 script は、表示を待たせる
• script には defer を付ける。head で同期実行しない
• Webフォントは font-display: swap と preload。読めない時間を作らない
• 3　JavaScriptの量　転送量より、解析と実行の時間が効く
• その画面で要らないものを送らない。使う場面まで読み込みを遅らせる
• サーバーの応答（TTFB）と配信の距離は、上の3つを終えてから見る。静的サイト生成やキャッシュはここに効く。
• 計測せずに手を入れない。何が重いかは、開いてみるまで分からない。

ひと目で#

画像 → 読み込みを止めるもの → JavaScript の量。 この順で手を入れると、たいていの遅さは解けます。

画像フォーマット

AVIF と WebP を第一候補に。写真は JPEG より小さくなる

srcset

画面幅ごとの候補を渡し、ブラウザに選ばせる

遅延読み込み

最初の画面より下の画像だけ loading="lazy"

レンダリングブロック

head の CSS と同期の script は、表示を待たせる

クリティカルCSS

最初の画面に要る分だけ先に届ける

静的サイト生成

ビルド時に HTML を作る。応答が速い

プログレッシブエンハンスメント

HTML だけで成り立たせ、その上に足していく

効く順#

遅らせてよい画像、いけない画像#

loading="lazy" は近づくまで取りに行かない指示です。最初の画面に映る主役の画像にこれを付けると、HTML を読み終えるまで取りに行かず、LCP がそのぶん遅れます。

図を大きく見る

図の中身を文字で読む

• ✕ 画像を全部 lazy にする　○ 最初の画面だけ先に読む　届く順番
• ✕ 全部 lazy
• HTML
• HTMLを読み終えてから主役を探し始める
• 最初の画面の底
• ○ 主役だけ先に
• HTML
• 解析と並行して主役が届く
• 主役の画像にも lazy が付いている　上は fetchpriority="high"　「最初の画面」は端末で変わる。
• HTMLを読み終えるまで取りに行かず、　下だけ loading="lazy"　狭い画面ほど、上に入る画像は少ない。
• LCP がそのぶん遅れる　主役が先に届き、下は近づいてから取りに行く　迷ったら先頭の1枚だけを高優先にする。

境目は「最初の画面に映るか」です。映るものは fetchpriority="high" で先に取りに行かせ、それより下だけ lazy にします。狭い画面ほど最初の画面に入る画像は少ないので、迷ったら先頭の1枚だけを高優先にします。

間違えやすいところ#

• ✕測らずに手を入れる何が重いかは、開いてみるまで分からない
• ✕全部の画像を loading="lazy" にする最初の画面の画像まで遅れ、LCP が悪くなる
• ✕原寸のまま width で縮める転送量は変わらない
• ✕Webフォントを何書体も読み込む1書体でも数百KB。字形のサブセットを考える
• ✕font-display: block のまま放置する文字が読めない時間ができる
• ✕画面ごとに分けずに1つに束ねる使わないコードの解析時間を、全員が払う
• ✕JavaScript が動かないと何も出ない構造にする失敗したときに白紙になる

対策を確かめる#

本文の「効く順」を、手を入れたか確かめる形にしました。各項目に、そのまま貼れる1行を添えています。チェックはこの端末に残ります。

• 画像を表示寸法の2倍以下に書き出したsrcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="(min-width: 60rem) 60rem, 100vw"
• 写真を AVIF か WebP で出した<picture><source type="image/avif" srcset="hero.avif"><img src="hero.jpg" alt=""></picture>
• 最初の画面に映る画像を先に読ませたfetchpriority="high"
• 最初の画面より下の画像だけを遅らせたloading="lazy" decoding="async"
• img・video・広告枠に寸法を書いたwidth="1600" height="900"
• script で表示を止めていない<script src="/app.js" defer></script>
• Webフォントの woff2 を先に取りに行かせた<link rel="preload" href="/fonts/base.woff2" as="font" type="font/woff2" crossorigin>
• フォントの読み込み中も文字が出るfont-display: swap;
• その画面で使わない JavaScript を送っていない<script type="module" src="/js/home.js"></script>
• 変わらないファイルをキャッシュさせたCache-Control: max-age=31536000, immutable

JavaScript が無効でもチェックは付けられますが、記録はこの端末に残りません。

実装#

直す例#

架空の案件を1つ例にとります。どこを見て、何をどう直すかを書きます。

工房の通販ページです。商品写真24枚に loading="lazy" が一括で付いています。良かれと思った指定ですが、最初の画面に映る1枚目まで後回しになり、LCP がそのぶん遅れています。

境目は「最初の画面に映るか」です。先頭の1枚だけ fetchpriority="high" にし、lazy は外します。残り23枚はそのままで構いません。

同じページで、写真は 3000px の JPEG が原寸で置かれ、width で表示だけ縮めてありました。転送量は縮んでいません。表示寸法の2倍を上限に書き出し、AVIF と WebP を用意して srcset で選ばせます。24枚のうち、最初に届く必要があるのは1枚だけです。

確認する#

• 最初の画面に映る画像が lazy になっていない（かつ高優先が付いている）
• 配信している画像の実寸が、表示寸法の2倍以下に収まっている
• ネットワークの記録で、最初の画面に要らないファイルが先に届いていない

使えるパターン#

• 図版とキャプション
• スケルトン読み込み

このページで扱う語#

この話が要る場面#

このページが答えになる、現場の困り事です。困り事の側から探すと、同じ場所に着きます。

1. 画像をAVIF/WebPに
2. script に defer
3. 使わないJSを送らない

この場面のほかの困り事と、そのまま貼れる部品は速くする、出す前と出したあとにまとめてある。逆引きには全188件。

出典#

• web.dev「Fast load times」
• MDN「レスポンシブ画像」

関連#

• 速度の指標何を測るか
• Webフォント読み込みの制御
• レイアウトの実装実装の骨格
• 性能と配慮動きの負荷