ウェブシステムへの画像縮小処理の導入について

はじめに

近年ではスマートフォンで撮影される画像も非常に高解像度となり、従来に比べて画像ファイル自体のサイズが大きくなる傾向にあります。こうした画像をウェブシステム内で利用するケースも増えてきました。

しかし、これらの画像をウェブシステムにアップロードしてユーザーにそのまま表示させると、大量のデータを読み込む必要があり、ウェブページの表示完了までに時間がかかってしまいます。これは、ページの表示速度の低下といったパフォーマンス上の問題に加え、モバイル端末の通信量制限に対する負荷という面でも、ユーザーフレンドリーとは言えません。 加えて、AWS をはじめとしたクラウド環境では、データ転送量に応じた従量課金が発生するため、システム運用者にとっても負担が大きくなる可能性があります。

そこで、ユーザー向けのページ（フロントページ）では、画像を適切に縮小したりことなるフォーマットの画像を返すことでデータ転送量を削減し、システム全体のパフォーマンス向上とコスト削減を図る最適化が取り入れられつつあります。 

本記事では、画像縮小の具体的な手法や方式について解説し、実際に導入して得られた知見を共有します。

画像縮小の手段

画像縮小の方法は、大きく分けて以下の2つの手段に分類できます。

1. 静的ファイル変換（アップロード時変換）

画像をアップロードしたタイミングで、あらかじめ複数の解像度や画像フォーマット（例：WebP, AVIFなど）に変換し、それぞれを保存する方式です。表示時には事前に生成された画像を利用するため、処理負荷が軽いことが特徴です。 

代表的な例として、WordPressではアップロード時に複数サイズの画像が自動生成され、テーマ側で適切なサイズを選択することが可能です。ただし、明示的に指定されない限り、期待した画像サイズが使用されないこともあり、最適化の効果が限定的になる場合もあります。

また、ウェブアプリケーションの中で ImageMagick などの画像処理ライブラリを利用することで、アップロードしたオリジナルのファイルとは異なる画像のコピーファイルを保存する処理を組み込むことも可能です。

この方式はウェブサーバーから返すファイルがすでに決まった状態なので、処理の負荷が小さいことが特徴です。 一方、選択肢が多くなるとその分サーバーのディスク容量が必要になります。

2. 動的ファイル変換（リクエスト時変換）

画像のアップロード時にはオリジナルの画像のみを保存し、閲覧リクエストの内容（サイズやフォーマット）に応じて、その場で変換処理を行う方式です。nginx や ImageMagick をバックエンドに持つ画像変換API、あるいはCloudflare ImagesなどのCDN連携型サービスがこの手法に該当します。

この方式は柔軟性に優れる一方で、画像変換処理の負荷が高いため、CDNやローカルストレージでのキャッシュ戦略と組み合わせて利用するのが一般的です。

導入経験のある画像最適化手法

弊社では、画像最適化を明示的に行う必要がある場合、基本的に動的ファイル変換の方式を採用しています。 WordPress などのように、すでに最適化機能を備えたプラットフォームであれば静的ファイル変換も容易に導入できますが、独自実装する場合は設計が煩雑になりがちです。その点、動的変換をインフラレベルで整備することでシステムの構成をシンプルに保つことができ、また、最適化担当の役割を明確にできるという利点があります。

以下に、弊社で実際に採用した動的ファイル変換の手法を紹介します。

1. ImageMagick を利用した画像リサイズ用 PHP アプリケーション

弊社ではフィーチャーフォン時代から、画像を動的にリサイズ・最適化するシステムを開発・運用していました。 このアプリケーションでは、リクエストパラメータで指定された解像度に従って、ImageMagick による画像変換を実行し、結果をレスポンスとして返します。変換後の画像はサーバーのローカルストレージにキャッシュとして保存しておき、2回目以降のリクエストではキャッシュを返却することで、サーバー負荷を軽減するという仕組みになっていました。

2. nginx の image_filter モジュールを用いた変換

ウェブサーバーである nginx には、image_filter というモジュールが存在し、画像のリサイズや回転処理を行うことができます。

当初、このモジュールを活用して画像の縮小処理を行っていましたが、EXIF 情報（画像の追加情報や、撮影状況などを示すメタデータ）が無視されるという問題が判明しました。

近年のスマートフォンで撮影された画像は、撮影時の端末の向きを示す回転情報が EXIF に記録されており、これを適切に読み取らないと意図しない向きで画像が表示されることがあります。

この問題の根本原因は、image_filter モジュールが内部で使用している画像処理ライブラリ libgd が、EXIF 情報を取り扱わないことにあります。 そのため、EXIF に準拠した画像表示を実現するには、image_filter モジュールでは対応が難しいという結論になりました。

そこで、この問題を解決する手段を探した結果、次に紹介する imgproxy が有効な代替手段となりました。

3. imgproxy を利用した動的画像変換

imgproxy は、URLパラメータを指定して画像のリサイズ・フォーマット変換などを動的に行う専用の画像変換プロキシサーバーです。MITライセンスによる無償版と、有償の商用版が提供されており、無償版はDocker イメージとしてすぐに試すことができます。

先に述べた通り、nginx の image_filter を利用する設定を書いていたので、その部分を imgproxy を利用するように rewrite することで、これまでと挙動を変えることなく、代替機能を導入することができました。 内部で利用している画像処理ライブラリ libvips が EXIF 情報の回転にも対応しているため、スマートフォン画像の取り扱いも可能です。

また、imgproxy 自体はキャッシュ機構を持ちませんが、CDNやnginxのキャッシュと組み合わせる前提で設計されているため、これらのシステムを適切に組み合わせることで全体をシンプルに保ちつつ、十分なパフォーマンスが得られます。

まとめ

スマートフォンの普及とカメラの高解像度化、さらにネットワーク速度の向上により、ウェブシステム上で扱う画像ファイルのサイズは年々増加しています。その一方で、こうしたインフラ面の進歩により、画像の最適化が軽視されがちになっている傾向があるように感じています。

しかし、一定以上の規模を持つウェブサイトにおいては、ユーザー体験の向上、サーバー負荷の軽減、クラウド環境における通信コストの削減といった観点から、画像最適化は今なお重要な課題であると考えています。

本記事で紹介した「動的画像変換」は、既存のウェブシステムに対しても後から導入できる手法です。nginx のリバースプロキシ機能を活用して imgproxy を組み込むことで、既存コードやストレージ構成に大きな変更を加えることなく、柔軟かつ段階的に画像最適化を実現できます。さらに、後から導入したものなので、必要に応じて容易に切り戻すことも可能なメリットがあります。 

画像最適化は、パフォーマンスチューニングやコスト削減の一環として取り組む価値のある施策です。この記事の内容が何らかの参考になれば幸いです。