スクリーンショットが2MBもある理由と、60〜90%縮める方法
Dov Azencot
@DovAzencot一度、ひとつのデザインレビューのメールスレッドにあるスクリーンショットを数えたことがあります。11枚、すべてPNG、平均で2MB弱。20メガバイト超の、ほとんど白いダッシュボードが、全員が別タブに同じアプリを開いている6人のあいだを飛び交っていました。誰も気にしませんでした。「ちゃんと動いた」からです。そこに罠があります。スクリーンショットは静かに巨大で、その理由はコンピューターがそれをどう撮るかに組み込まれています。
スクリーンショットが2MBのファイルになる理由
スクリーンショットのショートカットを押すと、OSはPNGで保存します。これは妥当なデフォルトです —— PNGは可逆なので、キャプチャは画素単位で完璧になり、くっきりした文字だらけのスクリーンショットには本当に正しい判断です。問題は、PNGがサイズをどう扱うかにあります。
PNGはすべての画素を正確に保存します。今の画面は高密度で、Retinaや4Kディスプレイのウィンドウ全体をつかめば横2,000画素を超えることもあり、PNGはその何百万もの画素を一つ残らずフル解像度で忠実に記録します。フレームの60%が同じような白であっても気にしません。何も捨てないのは、捨てることがPNGの仕事ではないからです。だから、ほぼ空の設定ページのスクリーンショット —— 見た目はほとんど何もない —— でも、1.5〜2.5MBの重さになります。中身がまばらでも、キャンバスそのものが巨大だからです。
打ち手: WebPに変換する
WebPにはPNGにできないことができます —— くっきりした輪郭と透明を保ったまま、非可逆で圧縮すること。スクリーンショットに限っていえば、その組み合わせは魔法に近い。スクリーンショットはほとんどが平坦な面(圧縮が安上がり)で、少しの文字(WebPが鋭く保つ)だからです。非可逆の処理は知覚できないノイズを捨て、目は一度も苦情を出しません。
自分のディスクにあるスクリーンショットからの実際の数字です。
| スクリーンショット | PNGだと | WebPだと |
|---|---|---|
| ほとんど白い設定ページ | 1.6MB | 約180KB |
| フル表示の分析ダッシュボード | 2.4MB | 約310KB |
| ダークモードのコードエディタ | 1.9MB | 約240KB |
おおよそ85〜90%オフで、並べて見てもどちらがどちらか分かりません。文字は画素レベルまで読めるままです。これは私がやるなかで単位あたりの見返りが最も大きい変換です。まさにスクリーンショットが最初から途方もなく重すぎるからで、絞り出せる「何もない部分」が膨大にあるのです。
「文字がぼやけませんか?」
これが恐れられている点で、もっともな心配です。おそらくJPGのスクリーンショットで、縁取りの出たぼやけた文字を見て、非可逆の形式はすべてそうなると思ったのでしょう。WebPはJPGより輪郭に強い —— 明確に強い。適切な画質設定なら、WebPスクリーンショットの文字はくっきり保たれます。文字の形のまわりのノイズを探して400%まで拡大しても、普通のUIキャプチャでは何も見つかりませんでした。
正直な例外はあります。小さいファイルを追って画質を思い切り下げれば、いずれ文字が甘くなります。対処は簡単で、それをしないことです。中くらいの画質設定なら、文字を保ったまま60〜90%の勝ちがすでに得られます。破綻する領域まで押し込む理由はありません。
縮めても効かない場面
PNGをそのままにしておくケースが二つあります。
スクリーンショットがデザインツールに戻され、注釈をつけたり、書き込んだり、合成したりするなら、可逆のままにします。WebPの非可逆処理は一方通行の扉で、これから編集して書き出し直すものに圧縮を焼き込みたくはありません。WebPを送り、PNGのマスターは残す —— いつもと同じルールです。
そして、スクリーンショットがすでに小さいなら —— 小さく切り抜いたディテール、ボタン一つ、すでに約100KBを切っているもの —— 変換してもほとんど針は動きません。60〜90%の勝ちは、キャンバスが巨大だから巨大になっているファイルから来ます。小さな切り抜きは、その問題をすでに解決済みです。意味のない工程を足さないことです。
実際のやり方
スクリーンショットは、メールやドキュメントに近づく前に、このサイトのPNG→WebP変換ツールに通します。ブラウザ内で起きるので、キャプチャ —— 正直なところ、画面の半分と背景に写り込んだものまで見せていることが多い —— は端末から一切出ません。PNGを置いて、サイズの列がストンと下がるのを眺め、WebPをダウンロードして、そちらを添付します。
大事なのはツールではなく、反射です。「撮ったら縮める」が自動になれば、同じアプリをすでに開いている相手に2MBの画像を撃ち込むこともなくなり、メールの送信は速くなり、スレッドが数十メガバイトに膨れ上がることもなくなります。あの11枚のスクリーンショットのメールも、20超ではなく合計2MB程度で済んだはずです。同じ写真。何もかも同じ。ただ、死んだ重さだけがない。
関連記事
PNGをWebPに変換する理由(と、あえてしない場面)
PNGは編集には最高のフォーマットですが、配信するには無駄が多い。WebPで実際にどれだけ減るのか、逆に減らない場面はどこか、そして絶対に破らないルールを一つ、正直に書きます。
AVIF対WebP —— 小さいファイルが必ずしも正解ではない
AVIFはたいていWebPよりサイズが小さく、ときに20%以上も差がつきます。その余分な圧縮がエンコード時間や特殊なケースで何を代償にするのか、それでもWebPを選ぶ場面を書きます。
SVGからPNGへ —— 本当に画素が必要なとき(と、そうでないとき)
SVGは無限に拡大できて、しかも小さいままなので、ラスタライズは格下げに感じます。実際そうな場合もあります。ベクターからPNGの画素が本当に必要な場面と、SVGを触らずに残すべき場面を書きます。
記事一覧