【ITニュース解説】Compress Images Before You Upload: A Faster Website Workflow

ウェブサイトのパフォーマンスを向上させる上で、画像最適化は非常に重要な要素である。Google Lighthouseのようなウェブサイト診断ツールを使用すると、「画像を適切にサイズ変更する」という指摘をしばしば目にするだろう。これは、ウェブページを構成する要素の中で、画像がファイルサイズ的に最も重い部分であることが多く、ページの読み込み速度やユーザー体験に直接的な影響を与えるためだ。特に、ページ上で最初に表示される最も大きなコンテンツ（Largest Contentful Paint; LCP）が画像である場合、その画像の読み込みが遅れると、Googleの定めるCore Web Vitalsという重要なパフォーマンス指標のスコアも悪化してしまう。単に「画像を圧縮するのを忘れないように」と伝えるだけでは不十分であり、一貫性のある効果的なワークフローを確立することが求められる。

多くのコンテンツ管理システム（CMS）やプラグインには、画像をアップロードした後に自動で最適化する機能が備わっている。しかし、これにはいくつかの欠点がある。まず、元の高解像度ファイルがサーバーに残り続け、ストレージ容量を圧迫したり、バックアップの対象となったりする可能性がある。また、もし画像がGitリポジトリで管理されている場合、大きな画像ファイルはリポジトリの履歴に永久に残ってしまい、肥大化の原因となる。さらに、自動最適化は一律の設定が適用されるため、画像の特性に合わせた最適な品質調整が難しく、画質が不必要に劣化したり、逆に最適化が不十分でファイルサイズがあまり減らないといった結果のばらつきが生じることもある。そのため、画像をアップロードする前に最適化を行うことで、すべての画像が適切なサイズ、フォーマット、品質でウェブサイトに配置されるようになり、これらの問題を根本的に解決できる。

画像最適化のワークフローは、いくつかの段階を経て行われる。

最初のステップは、画像を実際に表示するサイズにリサイズすることである。これは画像最適化において最も大きな効果をもたらす部分でありながら、見過ごされがちだ。現代のスマートフォンで撮影した写真は、しばしば4000ピクセル以上の幅を持つが、ウェブページで表示されるのが800ピクセル幅の欄であれば、ブラウザはダウンロードされたピクセルの約96%を破棄していることになる。これは無駄なデータ転送である。画像は表示される幅に合わせてエクスポートし、高解像度スクリーン向けにはその2倍程度の幅を用意するのが一般的だ。ヒーロー画像のようなページを飾る大きな画像でも、幅は1600〜2000ピクセル程度に抑えるのが推奨される。これ以上大きくしても見た目の改善は少なく、ファイルサイズだけが不必要に増加する。また、srcset属性を活用するために、480、960、1600ピクセルといった複数の幅の画像を生成しておくと、ブラウザがユーザーの環境に合わせて最適なものを選択してくれる。画像の解像度を2倍にすると、ピクセル数は4倍に増えるため、ファイルサイズもそれに比例して大きくなることを理解しておくことが重要である。

次に、画像に適したフォーマットを選択する。フォーマットの選択は圧縮設定と同様に大きな影響を与える。写真にはJPEGが最も広く使われ、汎用性が高い。スクリーンショットやロゴ、鋭いエッジを持つグラフィック、透過が必要な画像にはPNGが適しているが、ロスレス圧縮のためファイルサイズが大きくなりがちなので、写真には適さない。現在、ほとんどのラスター画像にはWebPが推奨される。WebPはJPEGやPNGよりもファイルサイズを大幅に削減でき、透過もサポートされている。さらに新しいAVIFフォーマットは、WebPよりもさらに小さいファイルサイズを実現できるが、エンコードに時間がかかり、低い品質設定では色ずれが発生する可能性もある。ロゴやアイコン、シンプルなイラストには、どのサイズでも鮮明に表示され、ファイルサイズも非常に小さいベクターフォーマットであるSVGが最適である。アニメーションにはGIFではなく、短い動画ファイルを使う方が効率的だ。WebPやAVIFを使用する際は、古いブラウザのためにJPEGなどのフォールバックを用意するのが賢明である。

適切な圧縮設定で画像を圧縮することも重要だ。「品質を損なわずに圧縮」という表現をよく聞くが、これはPNGやロスレスWebPのようなロスレス圧縮の場合にのみ当てはまる。ロスレス圧縮は、画像のピクセル情報を完全に保持したまま、ファイルサイズを効率的に縮小する。一方、JPEG、ロッシーWebP、AVIFのようなロッシー圧縮は、一部の画像データを永続的に破棄することでファイルサイズを大幅に削減する。ロッシー圧縮の目標は、人間の目で品質の劣化がほとんど認識できないレベルで、ファイルサイズを劇的に減らすことである。JPEGやWebPでは品質設定を75〜85、AVIFでは50〜65程度に設定するのが良い出発点となる。これらの数値はフォーマットによって意味が異なるため、必ず圧縮前と圧縮後の画像を100%表示で比較し、顔や文字、滑らかなグラデーション部分にアーティファクト（ノイズやブロック化）がないかを確認することが重要である。単発の画像処理にはオンラインツール、視覚的な比較にはGoogleのSquoosh、ビルドスクリプトでの自動化にはコマンドラインツールがそれぞれ適している。一度圧縮されたJPEG画像を再度圧縮しても、効果は薄いか、かえってファイルサイズが増えることもあるため、常に元の画像から作業を始めるのが理想だ。

画像から不要なメタデータを取り除くことも忘れずに行う。デジタルカメラやスマートフォンで撮影された写真には、EXIFデータと呼ばれるメタデータが含まれており、これにはカメラのモデル、レンズ設定、撮影日時、そしてしばしばGPS位置情報が含まれる。これらの情報をウェブサイトで公開することは、プライバシー上のリスクを伴う可能性がある。メタデータを削除することで、個人情報の漏洩リスクをなくし、ファイルサイズもわずかながら削減できる。ただし、色プロファイル（特にsRGB）は維持するようにし、EXIFデータに含まれる画像の向き情報（縦向きか横向きか）は、削除する前に画像に適用しておく必要がある。そうしないと、縦向きの画像がウェブサイト上で横向きに表示されてしまう可能性がある。

このような最適化作業を一枚一枚手動で行うのは、手間がかかり非効率的だ。特に多数の画像を扱うウェブサイトでは、このプロセスをスクリプトで自動化することが不可欠である。Node.jsのsharpのようなライブラリを使用すると、元の画像ファイルから、指定された複数の幅、複数のフォーマット（AVIF、WebP、JPEG）、そしてメタデータが削除された最適化済み画像を自動で生成できるスクリプトを作成できる。このスクリプトを開発ワークフローに組み込むことで、チームの誰もが簡単に画像を最適化できるようになる。また、継続的インテグレーション（CI）環境やGitのプレコミットフックに、画像サイズが特定の予算（例えば300KB以下）を超えていないかをチェックする仕組みを追加することで、未最適化の画像が本番環境にデプロイされるのを防ぐことができる。この予算値は、サイトの要件に合わせて柔軟に調整するべきである。

画像を適切に圧縮するだけでなく、ブラウザが最適な画像をダウンロードできるように設定することも重要である。HTMLの<picture>要素は、複数の<source>要素と<img>要素を組み合わせることで、ブラウザがサポートする最も適切なフォーマットやサイズの画像を自動的に選択できるようにする。具体的には、AVIF、WebPの順に<source>要素で指定し、最後にJPEGを<img>要素でフォールバックとして設定する。srcset属性とsizes属性を使用すると、ブラウザはユーザーのスクリーンサイズや解像度に応じて最も適した幅の画像をダウンロードできるようになり、スマートフォンでデスクトップ用の大きな画像をダウンロードするといった無駄を省ける。また、<img>タグには必ずwidthとheight属性を設定し、画像が読み込まれる前にブラウザがそのためのスペースを確保することで、コンテンツの予期せぬ位置ずれ（Cumulative Layout Shift; CLS）を防ぐことができる。ページのメインビジュアルとなるヒーロー画像はLCP要素であることが多いため、遅延読み込みをせず、fetchpriority="high"を設定して優先的に読み込むように指示することが肝要である。一方、ページの下部にある画像はloading="lazy"とdecoding="async"を設定して遅延読み込みを有効にすると良い。

Next.jsやAstroのようなモダンなウェブフレームワークは、画像のリサイズ、フォーマット変換、srcsetの生成などを自動で行う組み込み機能を提供している。また、Cloudinaryのような画像CDNサービスは、URLパラメータに基づいて画像をオンデマンドで変換できる。これらのツールは非常に便利であり、積極的に利用すべきだ。しかし、それでも元の画像ファイル自体を事前に最適化しておくことには価値がある。これにより、リポジトリのサイズを小さく保ち、ビルド時間を短縮し、実行時の処理負荷を軽減できる。開発者だけでなく、コンテンツ編集者やマーケターが画像をアップロードする際にも、簡易的なワークフローを共有することが重要である。具体的には、画像をアップロードする前に、表示されるサイズに合わせてリサイズし、オンラインコンプレッサーで圧縮すること、そして画像に内容を説明する分かりやすいファイル名と代替テキスト（alt属性）を設定することを推奨する。

最適化を行った後は、その効果を必ず確認することが重要である。Google LighthouseやPageSpeed Insightsのレポートで、「画像を適切にサイズ変更する」「次世代フォーマットで画像を配信する」「画像を効率的にエンコードする」といった項目が改善されているかを確認できる。ブラウザの開発者ツールのネットワークパネルで、実際にダウンロードされた画像のファイルサイズ、フォーマット、幅などを確認するのも良い方法である。また、サイト全体で画像の問題を検出するために、サイト全体のSEO監査ツールを利用することも有効だ。多くのサイトで見られる間違いとして、一度圧縮されたJPEG画像を何度も再圧縮すること、ページの最上部のヒーロー画像を遅延読み込みしてLCPを遅らせること、写真にPNGフォーマットを使用してしまうこと、widthとheight属性を省略してCLSを引き起こすこと、巨大な画像をCSSで縮小してしまい元のファイルが重いままになること、AVIFやWebPにフォールバックを用意しないこと、不必要なRetina解像度でスクリーンショットをエクスポートすることなどが挙げられる。

ウェブサイトの画像最適化は、単にファイルを小さくするだけでなく、リサイズ、適切なフォーマット選択、賢明な圧縮設定、メタデータ削除、そして<picture>要素やsrcset、適切な読み込みヒントを用いた配信方法までを一貫して行うことが重要である。このワークフローをスクリプト化し、さらにCI環境でのチェックを導入することで、Lighthouseレポートから「画像を適切にサイズ変更する」という指摘を完全に消し去ることができるだろう。