生成した画像をそのまま載せたら重かった。軽くする手順を決めた

• 生成した原寸は、記事に載せるには大きすぎる
• 表示する幅に合わせて縮めるだけで、大幅に軽くなる
• 形式を変えると、さらに半分以下になる

生成した画像をそのまま載せていたら、表示が遅くなった。測って手順を決めた記録を書く。

どれくらい重かったか

実際の数字を出す。

• 生成した原寸 — 1枚あたり数百KB〜2MB
• 記事に3枚入れると、それだけで数MB
• スマホの回線では、表示まで数秒かかる

3つ目が問題だ。読む前に離脱される可能性がある。

表示する幅を調べる

まず、実際に何pxで表示されるか測った。

• 記事内の画像 — 最大864px
• 一覧のカード — 720px
• スマホでは、それ以下

原寸が1200pxなら、864pxまで縮めても劣化しない。表示より大きい分は、単に無駄になっている。

縮めるだけの効果

幅を合わせるだけで、かなり軽くなった。

• 1200px → 864px で、おおむね半分
• 画質の劣化は、見た目には分からない
• WordPressなら、自動で複数のサイズが作られる

3つ目を使えば、閲覧者の画面に合ったサイズが自動で選ばれる。設定を確認するだけで済む。

形式を変える

さらに軽くするなら、形式の変更が効く。

• 写真のような画像 — JPEGかWebP
• 図形と文字が中心 — PNGかWebP
• 透過が不要なら、JPEGで十分

3つ目を確認せずPNGで保存していた。透過していない画像をPNGで持つと、無駄に大きい。

どこまで圧縮するか

画質と容量の兼ね合いを、実際に比べて決めた。

• 品質85前後 — 見た目に差が分からず、容量は大きく減る
• 品質70以下 — 平坦な面に斑が出る
• 品質95以上 — 容量が増えるだけで、差は見えない

いまは85〜90で保存している。並べて見比べないと分からない程度の差なら、軽いほうを取る。

遅延して読み込む

容量を減らす以外の方法もある。

• 画面に入るまで読み込まない設定にする
• 最初に見える画像だけ、先に読み込む
• 記事の下のほうの画像は、後回しでよい

2つ目が重要だ。アイキャッチまで遅延させると、最初の表示が遅く見える。

測り方

感覚ではなく、測って判断している。

• 開発者ツールで、ページ全体の転送量を見る
• 画像が占める割合を確認する
• 最も大きい画像から順に対処する

3つ目が効率的だ。1枚だけ極端に大きい画像があることが多い。

自動化する

毎回手でやると続かないので、仕組みにした。

• 保存時に、決めた幅と品質で書き出す
• プラグインで、アップロード時に自動変換する
• 生成の段階で、必要な大きさだけ作る

3つ目が最も無駄がない。大きく作って縮めるより、最初から必要な大きさで作る。

やりすぎない線

軽さを追求しすぎて、質を落とした時期がある。

• 圧縮しすぎて、文字が読みにくくなった
• 小さくしすぎて、高精細な画面でぼけた
• 形式を変えて、一部の環境で表示されなかった

2つ目は注意が要る。表示幅の2倍を用意しないと、高精細な画面ではぼける。

アイキャッチだけ別扱い

記事の中で、アイキャッチだけは扱いを変えている。

• 最初に表示されるので、読み込みを優先させる
• 遅延の対象から外す
• 多少重くても、他を削って帳尻を合わせる

最初に目に入る画像が遅いと、ページ全体が遅く感じる。実際の合計が同じでも、体感が違う。本文中の画像は遅延させ、アイキャッチだけ先に読み込ませるという配分にしてから、測定値は変わらないのに体感が改善した。

効果の確認

対処した後、もう一度測った。

• 記事1本あたりの転送量が、半分以下になった
• スマホでの表示開始が、体感で速くなった
• 画質の劣化は、指摘されていない

やる前に測り、やった後にも測る。効果が数字で見えないと、やる意味があったか分からない。

まとめ

• 生成した原寸は、記事に載せるには大きすぎる
• 表示幅に合わせて縮めるだけで、おおむね半分になる
• 透過が不要ならJPEG。PNGのままだと無駄に大きい
• 品質85前後なら、見た目の差は分からない
• アイキャッチは遅延させない。最初の表示が遅く見える