写真はウェブに載せる前に縮小すべきだ、というのは誰もが知っています。問題はどこまで縮小するかです。これには答えが一つしかありません — その画像が画面で実際に表示される幅の二倍。以下は、その数字が用途ごとにいくつになるのか、そしてなぜ二倍なのかという話です。
今どきのスマートフォンの写真は長辺が4000ピクセルを超え、一枚3〜8MBあります。ところがブログ本文でその写真が実際に占める幅は800ピクセルほどです。残りの3200ピクセルは画面に描かれません。
ブラウザが勝手に縮小して表示するので、画面上は何の問題もありません。だからほとんどの人がそのままにします。代償は別のところに出ます — 訪問者は3200ピクセル分のデータを受け取り終えてから写真を見ることになり、モバイル通信で来た人はその分を実際に消費します。写真が十枚入った記事なら、40MBを受け取らせている計算です。
検索順位に使われる指標の中に、画面で最も大きい要素がいつ描き終わるかを測る値があります。本文の一番上の写真がたいていその要素なので、写真一枚が遅いとその値がまるごと遅くなります。
画面の1ピクセルと画像の1ピクセルは同じではありません。最近のスマートフォンやノートパソコンは、画面1ピクセル分の場所に実際の点を二つ打ちます。そのため800ピクセル幅で表示される場所に800ピクセルの画像を入れると、その画面ではぼやけて見えます。二倍の1600ピクセルを入れれば鮮明です。
二倍までで十分です。三倍にしても目では見分けがつかず、容量だけが2.25倍になります。点を三つ打つ画面も存在しますが、その画面で二倍と三倍を並べて見分けられる人はほとんどいません。
ここでいう「長辺」は、横長の写真なら横、縦長の写真なら縦のことです。
| 用途 | 画面での表示幅 | 保存する長辺 |
|---|---|---|
| ブログ本文の写真 | 700〜800px | 1600px |
| 一覧のサムネイル | 200〜300px | 600px |
| プロフィール画像 | 100px前後 | 300px |
| 画面全幅の背景 | 1200〜1600px | 2400px |
| OG画像(共有プレビュー) | — | 1200 × 630 固定 |
OG画像だけは性格が違います。これは表示される大きさから決まる値ではなく、規格です。リンクを Slack や X、チャットアプリに貼ったときに出るあのプレビュー画像で、縦横比がずれるとサービスごとに勝手な切り取られ方をします。1200 × 630 にきっちり合わせ、大事な文字は端から十分に離してください。
サイズを「横1600 × 縦1200」のように両方固定すると、縦長の写真が入ってきたときに歪むか切れます。「長辺1600」で指定すれば、横長は1600×1200に、縦長は1200×1600になり、比率を保ったまま両方とも適切な大きさになります。
プロフィール画像のように正方形にする必要がある場合は、縮小する前に切り抜くのが先です。縮小の段階で正方形を強制すると、どこを残すかをツールが勝手に決めることになります。
推測しなくても測れます。ブラウザでその写真を右クリックして「検証」を選ぶと開発者ツールが開きます。要素の一覧でその画像の行にマウスを乗せると、二つの数字が並んで表示されます。
元のサイズが表示サイズの二倍を超えている分は、捨てられているデータです。四倍、五倍になっている例はよくあります。
画像一括リサイズを開いて写真をまとめてドラッグしてください。サイズの欄で長辺を選び、上の表の数字を入れます。元より大きくしないのが既定値なので、すでに小さい写真が混ざっていても無理に引き伸ばされることはありません。
形式は写真ならWebP、品質は0.8前後が無難です。スクリーンショットやロゴのように線と文字でできた画像はPNGが適しています — こうした画像をWebPやJPEGに変換すると、容量がかえって増え、文字の輪郭が汚くなります。
結果はzip一つで受け取れます。ファイルはブラウザの外に出ないので、枚数にも容量にも上限はありません。
一度縮小した写真は元に戻せません。次のものは原本のまま残してください。
このツールは原本に触れず新しいファイルを作りますが、別の場所ですでに原本を上書きしてしまった場合は元に戻せません。大事な写真は原本のフォルダを分けて作業してください。