最初は元のピクセル寸法を維持します。幅より先に形式と符号化を変え、最大幅を 0 に設定します。正確な輪郭には PNG、共有用の軽量コピーには WebP を試し、小さな文字を 100% 表示で確認します。

操作手順

検証した画像と結果

見出し、段落、ボタン、枠、小さなラベルを含む PicZip のトップページのモックアップを使いました。元の PNG は 450,313 バイト、新しい PNG は 927,696 に増え、同じ寸法の WebP は 82,578、元より 81.66% 小さくなりました。

幅 1000 ではさらに 33,020 バイト減りましたが、画素数は 1,728,000 から 833,000 となり、約 51.8% 減りました。メールやエディター、Web サイトで追加の縮小が入る前から、文字の情報が少なくなります。

元画像を追加し、最大幅を 0 にして符号化とリサイズの影響を分けます。これにより画素数を本当に減らす必要があるか判断できます。

検証前にメッセージアプリへ貼り付けて再ダウンロードしないでください。アプリ側で縮小や再圧縮が行われ、原本として信頼できないコピーになる場合があります。

PNG は透過、正確な輪郭、編集用の参照画像に向きます。ただし可逆だから小さくなるわけではなく、この試行では元の 2 倍以上になったため、元の PNG を残す方が適切です。

WebP は共有、ガイドへの挿入、Web 公開に使えます。ただし 82,578 バイトという数値だけで、すべてのラベルの読みやすさは証明できません。目で確認します。

ダウンロードを 100% で開き、最小のラベル、色付き背景上の薄い文字、細いアイコン、斜線、強い境界付近の文字を確認します。問題なく上限を満たすなら、削減率を大きく見せるためだけに幅を減らす必要はありません。

最終表示でも確認します。幅 1440 の画像を 720 CSS ピクセルで表示すると、同じ場所に幅 1000 の画像を置くより元の情報が多く残ります。ただし、ブラウザーの縮小処理と画面密度も見え方に影響します。

元に近いサイズで表示しないことが分かっている場合に減らします。幅 700 の記事欄に幅 3000 が不要な場合もありますが、高密度画面も考慮します。

1000 × 833、49,558 バイトの版は狭い記事欄に十分かもしれませんが、再利用する原本としては劣ります。後で別の寸法を作れるよう元を残します。この検証ではフルサイズの WebP ですでに 100 KB 未満だったため、その目標にリサイズは不要でした。

原本から開始し、最初は寸法を維持して利用先に合う形式を選びます。大見出しだけでなく最小の文字とアイコンを見ます。実際の表示寸法を確認してから縮小し、マスター画像を残します。

新しい可逆エンコードによりバイト数が増える場合があります。増えたら原本を残します。処理の完了は改善を意味しません。

ラベルと輪郭を確認すれば Web 配信に使える場合があります。正確な画素や編集忠実度が必要なら PNG を選びます。

共通の数値はありません。内容、寸法、エンコーダー、表示サイズが関係します。82 から始め、寸法を維持して実物を確認します。

利用先で画素数が余る場合に限ります。先に縮小すると細部が失われ、符号化の劣化との切り分けが難しくなります。