ブログの画像が重すぎたので圧縮したら、LCPがほぼ半分になった
スマホ写真をそのまま載せていたブログの画像をWebP・品質80・幅1920pxに統一したら、LCPが4.6秒→1.8秒に。実際の手順と、アップロード不要の自作圧縮ツールを紹介。
白状すると、このブログの前身サイトでは、スマホで撮った写真をそのまま記事に貼っていた。1枚4MBとかのやつを、平気で。
気づいたのはLighthouseを回したときで、パフォーマンススコアが50点台。指摘の筆頭が「Properly size images」と「Serve images in next-gen formats」。つまり、ほぼ画像のせいだった。
LCPの犯人は、たいていファーストビューの画像
LCP（Largest Contentful Paint）は「ページ内で一番大きい要素が表示されるまでの時間」。ブログの場合、一番大きい要素はほぼ確実にアイキャッチ画像だ。つまりアイキャッチが重い＝LCPが遅い＝Googleの評価も下がる、という単純な構図になっている。
目安として、LCPは2.5秒以内が「良好」。4MBの画像は4G回線だと読み込みだけで数秒かかるので、この時点で勝負がついてしまう。
実際にやったこと（3つだけ）
凝ったことはしていない。次の3つに統一しただけ。
- 幅1920pxにリサイズ — ブログの表示幅は広くても800px程度。4000px超のスマホ写真は完全に無駄。Retina対応を考えても1920pxあれば十分
- WebPに変換 — 同じ見た目でJPEGより25〜35%小さい。今どきのブラウザは全部対応している
- 品質80% — ここが一番大事かもしれない
手元のアイキャッチ（3.8MBのPNG）で試した結果がこれ。
| 状態 | サイズ | LCP（4Gスロットリング） |
|---|---|---|
| 元画像そのまま | 3.8MB | 4.6秒 |
| WebP・品質80・幅1920px | 178KB | 1.8秒 |
サイズは約1/20、LCPはほぼ半分。もちろん数値は環境によって変わるけれど、体感でも「一拍待つ」が「すっと出る」に変わるくらいの差はある。
品質80という数字について補足すると、90と80を並べて見比べても、写真では違いがほぼわからない。なのにファイルサイズは1.5〜2倍違う。80を切って70台に入るとグラデーション部分にノイズが見え始めるので、迷ったら80でいい。
オンラインの圧縮ツールに、仕事の画像を投げたくない
で、圧縮を何でやるかという話。
世の中に画像圧縮のWebサービスは山ほどあるが、大半は画像をサーバーにアップロードする方式だ。個人ブログの写真ならまだしも、仕事で扱う画面キャプチャや資料画像を、どこの誰が運営しているかわからないサーバーに送るのは正直気が引ける。利用規約を読みに行くのも毎回は面倒くさい。
ブラウザにはcanvasというAPIがあって、実は画像の変換くらいなら端末の中だけで完結できる。それなら自分で作った方が早い、ということで作った。
画像をドロップすると、ブラウザ内でWebP変換とリサイズをして、削減率を出してくれる。サーバーには何も送信しない（そもそも送信するコードが存在しない）ので、社外秘のキャプチャでも安心して使える。複数枚まとめてドロップも可。
圧縮以外で効く小ワザ
画像まわりでLCPに効くやつを、ついでに置いておく。
<img>にwidthとheightを必ず書く。レイアウトシフト（CLS）対策- ファーストビューより下の画像は
loading="lazy"。ただしアイキャッチには絶対つけない（遅延させたらLCPが悪化する。逆効果） - アイキャッチには
fetchpriority="high"をつけると、ブラウザが優先的に読んでくれる
このあたりを揃えると、Lighthouseの画像系の指摘はだいたい消える。うちのスコアが50点台から90点台に上がった要因は、正直なところ大半が画像だった。凝った最適化の前に、まず画像。順番はそれで間違いない。