先月、スクリーンショット14枚入りのチュートリアルを公開した。公開後にページの総容量を確認してみたら、38MBあった。ほとんどテキストのページが、38MBだ。
スクリーンショットは全部PNG、Macのスクリーンショット機能から出したまま。フルスクリーンのRetinaキャプチャ1枚で4.2MBあった。みんながやるように、OSが出したそのままをアップロードしていた。
スクリーンショットが重い3つの理由
- Retina解像度。 最近のディスプレイのスクリーンショットは、CSSピクセルの2倍・3倍ある。記事中で1440px幅で表示される図が、実は4320px幅のPNGだったりする。
- PNGは可逆圧縮。 UIの文字の輪郭はくっきり出るが、ファイルサイズは肥大化する。写真っぽいグラデーションや影が入ると一気に膨らむ。
- 誰もアップロード前に圧縮しない。 プラットフォームは4MBの元画像を、そのまま全読者に配信してしまう。
決定的だったのはこれだ。圧縮後のスクリーンショットは4.2MBから380KBになったのに、記事の表示幅では違いがまったく分からなかった。PNGが温存しているディテールは、どうせ縮小表示されるので読者には一生見えないディテールなのだ。
30秒で直す方法
もうスクリーンショットを手作業で調整したりしない。今の手順はこうだ。
- いつも通りスクリーンショットを撮る——PNG、フルRetinaのまま。
- ZipPicの画像圧縮ツールにドラッグ＆ドロップ——無料、ブラウザだけで動く、登録不要、アップロードなし。
- ローカルで圧縮され、ビフォーアフターが並べて表示される。文字の輪郭がくっきり見える範囲で画質スライダーを調整。
- ダウンロードして、圧縮版を記事にアップロード。
14枚入りのチュートリアルは38MBから5MB以下になった。読み込みは「コーヒーを淹れる時間」から一瞬に。モバイル回線の読者にも優しいページになった。
誰も考えないこと：スクリーンショットの中身
スクリーンショットは、性質上センシティブなアップロードだ。開いているタブ、ファイルパス、背後に写ったSlackのDM、消し忘れたターミナルに残るAPIキー。「無料オンライン圧縮ツール」にスクリーンショットをアップロードするというのは、その全部を見知らぬ誰かのサーバーに渡すということだ。
自分はファイルサイズのためにローカル圧縮を始めたが、プライバシーのために続けている。マシンの外に何も出ない。処理はブラウザ内のWebAssemblyで完結し、動くのはダウンロードしたファイルだけだ。
次にチュートリアルを書くとき、試してみてほしい。PNGスクリーンショットを1枚、ローカルで圧縮して、記事の表示幅で並べて見比べる。違いが分からなければ——分からないはずだ——もう元画像をアップロードする理由はない。