一度しか見ないネイティブアプリのウォークスルー画像、どこまで軽くできるか試してみた
iOSアプリにウォークスルー画面を実装しており、写真画像を使ったデザインを採用したいと考えている。ウォークスルーはアプリの初回起動時にしか表示されない。一度しか見ないコンテンツに対して1.5MBの画像を割り当てるのは、アプリサイズへの影響が大きく気になっていた (しかも複数枚である)。
テキストの視認性を維持しつつ、チーム開発のためにxcassetsで管理できる形式を保ったまま、どこまで軽量化できるかを検証した。本記事では、PNG最適化ツールからJPEGエンコーダーまで複数の手法を比較した結果を紹介する。
検証環境
- MacBook Pro (16インチ, 2021), Apple M1 Pro
- macOS Tahoe 26.4
- pngquant 3.0.3
- oxipng 10.1.1
- guetzli
- mozjpeg version 4.1.5 (build 20231012)
- Android Studio Panda 4 | 2025.3.4
ソース画像
元画像は1.5MBのPNGファイルで、夜景写真の上に白字で「WELCOME」と書かれたテキストオーバーレイ系のデザインだ。
品質の基準：Android Studio の WebP 変換
品質の基準を設けるにあたり、Android StudioのWebP変換機能を合格ラインとした。変換後のサイズは101KBで、テキスト周辺に若干のノイズはあるものの許容範囲内の品質だ。
なお、WebPはiOS 14以降であればUIImageやSwiftUI.Imageでファイルリソースとして利用できる。しかしXcodeのxcassetsにはWebP形式を追加できないため、チーム開発でアセット管理したい今回の用途では採用しないことにした。
各手法の検証
1. PNG のまま最適化：pngquant（非可逆圧縮）
pngquantは色数を削減することでファイルサイズを下げるツールだ。写真画像の場合は劣化が出ることもあるため、品質範囲の調整が必要になる。
brew install pngquant
pngquant --quality=60-80 --output output_pngquant.png source.png
変換後のサイズは454KBだった。色数削減の影響で、スカイツリーのライトアップ（紫〜ピンク）のグラデーションが段階的になるポスタリゼーションが発生した。特に青色が紫寄りにシフトしており、色の印象が元画像と変わってしまう点が気になった。夜空の微妙なグラデーションもやや均一になり、全体的にフラットな印象になった。テキストエッジはPNGのためブロックノイズなくクリーンだ。
2. PNG のまま最適化：oxipng（ロスレス圧縮）
oxipngはPNGのメタデータや圧縮アルゴリズムを最適化するツールだ。品質は完全に維持されるが、削減できる量は限られる。
brew install oxipng
oxipng -o max --out output_oxipng.png source.png
変換後のサイズは1.3MBで、ロスレスのため劣化はない。ただしサイズ削減効果はわずかだ。
3. PNG のまま最適化：pngquant → oxipng の組み合わせ
pngquantで色数を減らしたあと、oxipngでさらに最適化する2段階処理だ。組み合わせることで最大限のサイズ削減を狙える。
pngquant --quality=60-80 --output tmp.png source.png
oxipng -o max --out output_combined.png tmp.png
変換後のサイズは413KBだった。pngquant単体とほぼ同等の視覚品質で、グラデーションの段階感や夜空のフラット化も変わらない。oxipngを重ねることでファイルサイズは約40KB削減されるが、視覚品質の差はほぼない。PNGのままでは413KBが限界であり、目標の101KBには届かなかった。
4. JPEG 変換：Guetzli（Google製）
Guetzliは人間の視覚特性に基づいた圧縮を行うGoogle製の高品質JPEGエンコーダーだ。同品質であれば他ツールより小さく仕上がるとされる。品質の下限は84であり、それ未満には設定できない。また、処理が非常に遅く、変換に数分かかる場合がある点にも注意が必要だ。
brew install guetzli
guetzli --quality 84 source.png output_guetzli.jpg
変換後のサイズは187KBだった。q84という高品質設定のおかげで、WELCOMEテキスト周辺のリンギング（白いにじみ）はほぼ目立たない。スカイツリーの格子状の細部もよく保存されており、夜空のグラデーションもスムーズだ。PNGとの差は微細なテクスチャの変化のみで実用上問題ないレベルだが、基準の101KBには届かなかった。
5. JPEG 変換：mozjpeg（Mozilla製）
mozjpegはMozilla製の高効率JPEGエンコーダーで、同じ品質設定でも標準JPEGより小さく仕上がりやすい。品質を下げるほどファイルサイズは小さくなるが、テキスト周辺のノイズが増えるため、q80とq60の2段階で検証した。
brew install mozjpeg
# quality 80
/opt/homebrew/opt/mozjpeg/bin/cjpeg -quality 80 -outfile output_mozjpeg_80.jpg source.png
# quality 60
/opt/homebrew/opt/mozjpeg/bin/cjpeg -quality 60 -outfile output_mozjpeg_60.jpg source.png
q80の変換後サイズは177KBだった。Guetzli q84と同等の視覚品質で、テキスト周辺のリンギングは目立たず、スカイツリーの細部・夜空ともにスムーズだ。Guetzliより約10KB小さく仕上がっている。
q60の変換後サイズは105KBだった。WELCOMEテキストの白いエッジ周辺に薄いグレーのにじみ（JPEGリンギング）が発生する。夜空の暗い領域にわずかなブロックノイズも見られるが、暗部のため実機では目立ちにくい。スカイツリーのライトアップ細部はやや失われるものの、全体的には許容範囲内だ。
検証結果まとめ
mozjpeg q60がAndroid WebPとほぼ同等のサイズを達成しつつ、xcassetsで管理できる唯一の選択肢となった。テキスト周辺の品質は実機確認で許容範囲内であれば、最有力候補といえる。
写真の内容・明るさ・テキスト量によってサイズは変わるため、あくまで今回のケースの結果として参考にしてほしい。
| 手法 | サイズ | xcassets管理 |
|---|---|---|
| 元 PNG | 1.5 MB | ◯ |
| oxipng（ロスレス） | 1.3 MB | ◯ |
| pngquant（q60-80） | 454 KB | ◯ |
| pngquant → oxipng | 413 KB | ◯ |
| Guetzli（q84） | 187 KB | ◯ |
| mozjpeg（q80） | 177 KB | ◯ |
| mozjpeg（q60） | 105 KB | ◯ |
| Android WebP（基準） | 101 KB | ✕ |
画像品質の目視比較
各手法の出力からWELCOMEテキスト周辺を切り出して並べた比較だ。上段がPNG系、下段がJPEG系となっている。
なお、ブログへのアップロード時に再エンコードがかかると品質の差が正確に伝わらない可能性があるため、検証に使用した元の画像ファイルをGitHubに置いている。正確な品質差を確認したい場合はこちらを参照してほしい。
PNG 系の劣化傾向
pngquantによる色数削減はグラデーションのポスタリゼーションとして現れる。また、色数が減ることで青色が紫寄りの近似色に置き換えられる場合があり、ライトアップの印象が変わってしまうことがある。夜景のような微妙な色変化が多い写真では影響が出やすく、PNGのまま大幅に軽量化するのは難しい。
| 手法 | 夜空グラデーション | スカイツリーライトアップ | テキストエッジ |
|---|---|---|---|
| 元 PNG / oxipng | スムーズ | 滑らかな紫〜ピンク | シャープ（完全） |
| pngquant（q60-80） | やや均一・フラット | グラデーションが段階的・青が紫寄りにシフト | クリーン（ブロックなし） |
| pngquant → oxipng | pngquant と同等 | pngquant と同等 | クリーン（ブロックなし） |
JPEG 系の劣化傾向
JPEG系の劣化は主にテキストエッジ周辺のリンギング（白い文字の縁にグレーのにじみが出る現象）として現れる。q80以上ではほぼ目立たないが、q60になると白字テキストの縁でわずかに確認できる。今回の画像は夜景（暗い背景）のため、ブロックノイズが出ても目立ちにくいという有利な条件にある。
| 手法 | 夜空グラデーション | スカイツリー細部 | テキスト周辺のリンギング |
|---|---|---|---|
| Guetzli（q84） | スムーズ | よく保存 | ほぼなし |
| mozjpeg（q80） | スムーズ | よく保存 | ほぼなし |
| mozjpeg（q60） | 暗部にわずかなブロック | やや失われる | テキスト縁に薄いにじみ |
| Android WebP（基準） | スムーズ | よく保存 | ほぼなし |
WebP との比較
Android Studioで出力したWebP（101KB）は、mozjpeg q60（105KB）とほぼ同サイズながら、テキスト周辺のリンギングが少なく、視覚的にやや高品質に見える。WebPの圧縮効率の高さが出た結果だが、xcassetsでの管理ができないという制約が実用上のネックになる。
まとめ
今回の検証では、xcassets管理を前提としたとき、mozjpeg q60が最もサイズと品質のバランスに優れた選択肢だと判明した。元画像の1.5MBから105KBまで削減でき、基準としたAndroid WebP（101KB）とほぼ同等のサイズを達成している。
品質を最優先するならGuetzli q84またはmozjpeg q80（180KB前後）が候補になる。テキスト縁のにじみが許容できるかどうかは実機での確認が必要で、画像の内容・明るさ・テキスト量によって結果が変わる点には注意してほしい。PNGに固執する場合はpngquant → oxipngの組み合わせで413KBが現実的な限界であり、写真画像の大幅な軽量化にはJPEGへの変換が有効だということを実感した。
xcassetsでWebPを管理できれば、iOSとAndroidで差が発生せず悩む必要がなくなる。Xcode側で早く対応してほしいと思う。
ウォークスルー画像の軽量化に悩んでいる方の参考になれば幸いだ。
