iPhoneの写真は3〜6MB。デスクトップのスクリーンショットは2〜4MB。「画質を落としたくないからPNGで保存」したファイルは、よく8MBになります。これをポートフォリオ、ブログ、メールのスレッドで掛け算すると、500KB版と見分けもつかない写真のために数百MBを送りつけていることになります。
画像圧縮は、そのギャップを埋めます。Zebraはモダンな画像コーデックを、WebAssemblyでブラウザ内に直接走らせます。ファイルは端末に留まったまま。ほとんどの写真が、見た目の画質を落とさずに60〜90%小さくなります。
コツは、正しいコーデックと正しい品質設定を選ぶこと——そして、それをあなたが手動でやる必要はありません。写真をドロップすれば、Zebraが中身を見て最適な処理を選びます。以下では、そのしくみと、プリセットの選び方、どの形式で保存すべきかまで、順を追って解説します。
3ステップ
- 画像圧縮ツールを開く。
- JPG・PNG・WebPをドラッグ(1ファイル25MBまで)。複数枚をまとめてドロップすれば一括圧縮——ログインで最大5ファイル、プレミアムで15ファイルまで。
- Light・Medium・Strongから選び、圧縮を押して、ダウンロード。1枚なら直接ダウンロード、複数枚なら1つのZIPにまとまって出てきます。
Macなら4MPのiPhone写真が約2秒、12MPの写真で4〜6秒で終わります。モバイルSafariは数秒上乗せ。15枚のバッチも1枚あたりほぼ同じ時間で順に処理されます——アップロードがないので、速度を決めるのは通信ではなくあなたのCPUです。回線が遅い場所でも、混雑した会場のWi-Fiでも、処理速度は変わりません。文書を小さくしたいなら、PDF圧縮ガイドが同じ考え方を解説しています。
なぜ画像は大きくなるのか
写真が重くなる理由は、だいたい4つに分かれます。それぞれに、削れる余地があります。
- 解像度。 4032×3024のiPhone JPEGは1220万ピクセル。仮に無圧縮で1ピクセル4バイトなら、それだけで50MBの生データです。JPEGはこれを約4MBに圧縮しますが、より賢いエンコーダーと少し低めの品質設定で再エンコードすれば、そこからさらに60%削れます。多くの写真は、必要以上のビットを使って同じ見た目を記録しているのです。
- フォーマットの選択。 PNGはすべてのピクセルをロスレスで保存します。それはくっきりした文字のスクリーンショットや、透過のあるアイコンには正解。でも写真には不正解——JPEGなら喜んで捨てる、目に見えないノイズを、4MBかけて律儀に記録しています。「高画質だからPNG」という思い込みが、いちばん多い無駄の原因です。
- エンコーダーの質。 ブラウザ内蔵のJPEGエンコーダーは保守的です。安全側に振って、ビットを多めに残します。Zebraはトレリス量子化とプログレッシブスキャンでチューニングしたJPEGエンコーダー(mozjpeg)を使い、同じ品質で10〜20%小さいファイルを作ります。設定は同じ、写真も同じ、でもファイルは小さい——エンコーダーを替えるだけで得られる差です。
- EXIFメタデータ。 GPS座標、カメラの機種、レンズ、撮影日時、フルの編集履歴。役立つこともありますが、共有には要らない数百KBのことも多い。Zebraは再エンコード時にEXIFのほとんどを削るので、ファイルが軽くなると同時に、撮影場所や機種が受信者に漏れなくなります。
Zebraが使う3つのコーデック
ひとくちに「圧縮」といっても、写真とスクショとアイコンでは、正しいやり方がまったく違います。Zebraはファイル形式と中身を見て、3つのコーデックから正しいものを自動で選びます。
- mozjpeg — JPEG入力と、透過なしPNGの自動変換に使います。Mozillaが開発したこのエンコーダーはトレリス量子化という技法で、どのピクセルにどれだけビットを割くかを最適化し、ブラウザ内蔵のエンコーダーやPhotoshopの「Web用に保存」を、同じ品質で10〜20%上回ります。プログレッシブスキャンにも対応しているので、読み込み途中でも全体がぼんやり見え、体感の表示速度も上がります。同じ見た目、より小さいファイル——差の正体はこのエンコーダーです。
- oxipng — 本物の透過を持つPNGに使います。ロスレスのDEFLATE再最適化を、複数のフィルターパスで行います。「ロスレス」なので1ピクセルたりとも変わりません——ただ、より賢い並べ方で詰め直すだけ。1MBのPNGアイコンセットは、たいてい700〜800KBに落ちます。データはビット単位で完全なまま、梱包がタイトになっただけです。透過を使うUI素材やロゴを、品質を1ミリも落とさずに軽くしたいときの正解です。
- libwebp — WebP入力に使います。WebPはすでに効率的なフォーマットですが、選んだ品質目標で再エンコードすれば、さらに20〜40%削れます。行き先がモダンなブラウザ(2022年以降が目安)なら、WebPは同じ品質でJPEGより一段小さく収まる有力な選択肢です。
3つともjSquashプロジェクトを通じてWebAssemblyにコンパイルされています。ブラウザのタブの中だけで動きます——サーバーなし、アップロードなし、テレメトリなし。デスクトップアプリを入れる必要も、コマンドラインを叩く必要もなく、写真をドロップした瞬間に、その写真に最適なコーデックが選ばれて走り出します。
自動モード:安全なときはPNG→JPEG
ほとんどの「PNG」ファイルは、実はPNGである必要がありません。人は「ロスレス=高画質」と思って写真をPNGで保存し、結果として400KBのJPEGと見分けもつかない4MBのファイルを抱えてしまいます。
Zebraはドロップされた全PNGをチェックします:アルファチャンネルが完全に不透明(透過なし)なら、そのファイルはJPEGとして再エンコードされます。写真PNGでは知覚差ゼロのまま5〜10倍のサイズ削減になります。本物の透過があるPNG(UIモック、アイコン、ステッカー)はPNGのまま——アルファに触れずロスレスで再最適化します。あなたが選ぶ必要はありません。ドロップすれば、正しい道を選びます。
Light、Medium、Strong
| プリセット | JPEG q | WebP q | PNG最適化レベル | 典型的な削減率 |
|---|---|---|---|---|
| Light | 88 | 88 | 2 | 30〜50% |
| Medium | 78 | 78 | 4 | 60〜80% |
| Strong | 65 | 65 | 6 | 80〜95% |
Light(品質88)は、普通の画面ではオリジナルと見分けがつきません。印刷したり拡大したりする写真、あるいはメタデータを剥がしてエンコードを引き締めたいだけのときに。
Medium(品質78)はデフォルトです。出力はA4印刷に十分シャープで、Retinaやモバイルでは区別不能。特別な理由がなければ、これを選んでください。
Strong(品質65)は、200%以上に拡大すると平坦な部分(空、壁)に目立つアーティファクトが出ますが、拡大して粗探しするより容量が大事なメール、Web共有、チャットには最適です。
なぜ何も端末から出ないのか
無料の画像圧縮ツールのほとんど——TinyPNG、Compressor.io、ImageOptim Online——は、ファイルをサーバーにアップロードします。そのモデルには現実的なコストがあります。
- 画像が他人のディスクに乗る。 「24時間で削除」の約束があっても、保持ウィンドウは存在します。証明写真、プライベートなチャットのスクショ、機密のものには、そのウィンドウ自体が間違ったウィンドウです。
- 帯域を2倍使う。 サーバーへ上り、サーバーから下り。モバイルでは、そこが遅い部分です。
- EXIFメタデータがファイルと一緒に旅する。 スマホのGPS座標はJPEGヘッダーに焼き込まれています。アップロードすれば、サーバーもそれを読みます。
Zebraはモダンな画像コーデックを、ブラウザのタブ内でWebAssemblyモジュールとして走らせます。画像はローカルでデコード・再エンコード・再梱包されます。ネットワーク通信なし、保持ウィンドウなし。ページを読み込んだ後にオフラインになっても、圧縮は動きます——機内モードで試してみてください。ちゃんと動くのが、何もアップロードしていない何よりの証拠です。
この設計が効くのは、たとえば身分証のスキャン、契約書のスクショ、まだ公開していない商品のカット、プライベートな会話のスクリーンショットのような、「他人のサーバーに一瞬でも置きたくない」ファイルを扱うときです。「24時間で削除します」という約束は、削除されるまでの数十分〜数時間、あなたのファイルが他人のディスクに存在することを意味します。ローカル処理なら、その時間そのものが存在しません。
JPG vs PNG vs WebP — どれで保存すべきか
圧縮後にどの形式で保存すべきか、短い判断ツリーです。迷ったらこの順に自問してください。
- 透過の要らない実写? JPEG。品質78〜85が印刷以外のすべてに十分です。人物、風景、料理、商品——写真的な階調を持つものは、ほぼこれで正解。JPEGは連続した色の変化を効率よく捨てるので、実写と最も相性がいいフォーマットです。
- 透過のある写真(まれ——たいてい切り抜き)? 相手が2022年以降のブラウザを使うならWebP。安全策としてPNG。背景を抜いたカットや、ロゴを重ねる素材はここに当てはまります。
- UIスクショ、アイコン、ロゴ、くっきりした文字? PNG。文字やアイコンのくっきりした縁は、JPEGだとリンギング(縁のまわりに出るモヤモヤしたノイズ)で汚れ、しかも修復できません。フラットな色面と鋭いエッジを持つものは、PNGでロスレスに保つのが鉄則です。
- アニメーション? WebP(古い互換性が必要ならGIF)。アニメーションPNGも一応動きますが、対応がまちまちです。
- モダンなWebで全ブラウザ対応が保証されている? すべてWebPに。ZebraがAVIFを追加したらAVIFに。
要するに、「なめらかな写真ならJPEGかWebP、くっきりした図版ならPNG」。この一言を覚えておけば、9割の判断は済みます。
こんなときに使う
具体的な使いどころをいくつか。どれも「同じ見た目で、もっと軽く」を求める場面です。
- メール添付の上限をクリアする。 多くのメールは合計25MB前後が上限。旅行写真を何枚か送りたいのに弾かれる——そんなときは、まとめて圧縮してZIPで受け取り、そのまま添付。Mediumなら見た目そのままで、合計サイズが数分の一になります。
- ウェブサイトやブログを速くする。 表示速度はSEOにもユーザー体験にも直結します。4MBのヒーロー画像を400KBに落とせば、ページの読み込みが体感で変わります。まず切り抜きで必要な範囲にしてから圧縮すると、さらに効きます。
- フリマ・ECの出品写真。 商品画像はサイズ上限のあるプラットフォームが多い。フル解像度のスマホ写真をそのまま上げると弾かれることがありますが、Mediumで圧縮すれば、見た目を保ったまま上限内に収まります。
- チャットやSNSへの共有。 LINE、Slack、Discordに送ると再圧縮される場合がありますが、あらかじめ自分でMedium/Strongにしておけば、二重の劣化を最小限に抑えられます。
圧縮すべきでないとき
一方で、圧縮が逆効果、あるいは不要な場面もあります。
- 編集用のマスターファイル。 オリジナルはフル品質で保管し、コピーを圧縮しましょう。あとで色調整や切り抜きをやり直す可能性があるなら、元データは触らないのが鉄則です。SNSのアスペクト比に合わせたいだけなら、画質を落とすより先に写真を切り抜くほうが賢いことが多いです。
- すでに小さいファイル。 200KB未満はたいてい割に合いません——再エンコードのオーバーヘッドが、削れる量を上回ることがあります。もう十分軽いものを、無理に縮める必要はありません。
- くっきりした文字のスクショ。 JPEGリンギングが文字を台無しにします。PNGのままに——Zebraがロスレスで再最適化します(透過を含むスクショでは、これが自動で選ばれます)。
- A3以上で印刷するもの。 大判印刷は品質の余裕が命。Lightに留めるか、圧縮をスキップしてマスターをそのまま印刷に回しましょう。
Zebraは、再エンコードでファイルが大きくなる場合(すでに最適化済みのPNG、低品質の小さいJPEG)も検出し、縮んだフリをせずにオリジナルを返します。だから「とりあえずドロップしてみる」で損はありません——縮められるものは縮め、縮められないものはそのまま返ってきます。