Web サイトの表示速度を改善したいと思ったことはありませんか？画像は Web ページの中で最も容量を消費する要素の一つです。Nginx の image_filter モジュールを使えば、サーバー側で自動的に画像をリサイズしたり、WebP 形式に変換したりできるため、ページの読み込み速度を大幅に向上させることができます。

この記事では、Nginx の image_filter モジュールを使った画像最適化環境の構築方法を、初心者の方にもわかりやすく解説していきます。実際の設定例やトラブルシューティングも含めて、すぐに実践できる内容となっていますよ。

背景

Web サイトにおける画像の課題

現代の Web サイトでは、高解像度の画像が多用されています。しかし、これらの画像はファイルサイズが大きく、ページの読み込み速度を低下させる主な原因となっているのです。

特にモバイルデバイスからのアクセスが増加している現在、画像の最適化は Web サイトのパフォーマンス向上に欠かせません。Google も Page Speed Insights で画像最適化を重要な指標として評価しています。

従来の画像最適化手法

これまで画像最適化は、以下のような方法で行われてきました。

#	手法	メリット	デメリット
1	手動での画像編集	品質をコントロールしやすい	時間がかかる、更新が大変
2	ビルド時の自動変換	一度設定すれば自動化できる	デプロイ時間が長くなる
3	CDN の画像最適化サービス	簡単に導入できる	コストがかかる、外部依存
4	クライアント側での処理	サーバー負荷が少ない	ユーザー環境に依存する

これらの方法にはそれぞれメリットがありますが、コストや運用の手間という課題も存在します。

Nginx image_filter モジュールの登場

Nginx の image_filter モジュールは、Web サーバー自体が画像処理を行う仕組みです。リクエストに応じて動的に画像をリサイズしたり、形式を変換したりできるため、柔軟な画像最適化が可能になりました。

以下の図は、Nginx の image_filter モジュールを使った画像配信の基本的なフローを示しています。

mermaidCopy codeflowchart LR
  client["クライアント<br/>(ブラウザ)"] -->|画像リクエスト| nginx["Nginx<br/>image_filter"]
  nginx -->|元画像読み込み| storage["画像ストレージ"]
  storage -->|元画像データ| nginx
  nginx -->|リサイズ/変換処理| cache["Nginx Cache"]
  cache -->|最適化済み画像| client

この図が示すように、Nginx がクライアントとストレージの間に入り、リクエストに応じて画像を最適化して配信します。一度処理した画像はキャッシュされるため、2 回目以降のアクセスは高速になるのです。

課題

画像最適化における具体的な課題

Web サイト運営において、画像に関する以下のような課題に直面することがあります。

デバイスごとの最適なサイズが異なる

スマートフォン、タブレット、デスクトップなど、デバイスごとに最適な画像サイズは異なります。すべてのデバイスに対して個別に画像を用意するのは大変な作業ですね。

画像フォーマットの選択が複雑

WebP は JPEG や PNG に比べて 25-35% ほどファイルサイズが小さくなりますが、古いブラウザでは対応していません。ブラウザごとに最適なフォーマットを配信するには、複雑な処理が必要になります。

ストレージ容量とコストの問題

複数サイズ、複数フォーマットの画像を事前に生成すると、ストレージ容量が膨大になってしまいます。これはコスト増加につながる深刻な問題です。

パフォーマンスと品質のバランス

画像を圧縮しすぎると品質が劣化し、圧縮が不十分だと読み込みが遅くなります。この最適なバランスを見つけるのは簡単ではありません。

以下の図は、これらの課題の関係性を示しています。

mermaidCopy codeflowchart TD
  problem["画像最適化の課題"]
  problem --> device["デバイス対応"]
  problem --> format["フォーマット選択"]
  problem --> storage["ストレージ容量"]
  problem --> balance["品質とサイズのバランス"]

  device --> manual["手動管理は<br/>非効率"]
  format --> complex["条件分岐が<br/>複雑"]
  storage --> cost["コスト増大"]
  balance --> trial["試行錯誤が<br/>必要"]

  manual --> solution["Nginx<br/>image_filter"]
  complex --> solution
  cost --> solution
  trial --> solution

これらの課題を解決するために、Nginx の image_filter モジュールが効果的なソリューションとなるのです。

解決策

Nginx image_filter モジュールによる解決アプローチ

Nginx の image_filter モジュールは、上記の課題を以下のように解決します。

動的な画像処理でデバイス対応

リクエスト時に動的に画像をリサイズできるため、1 つの元画像から複数サイズの画像を生成できます。URL パラメータでサイズを指定するだけで、必要なサイズの画像を取得できるのです。

ブラウザの Accept ヘッダーで自動フォーマット選択

Nginx の設定で Accept ヘッダーを判定し、WebP 対応ブラウザには WebP を、非対応ブラウザには JPEG を配信できます。この自動選択により、常に最適なフォーマットを提供できるのです。

元画像のみ保存でストレージ削減

事前に複数バージョンを生成する必要がなく、元画像のみを保存すればよいため、ストレージ容量を大幅に削減できます。

キャッシュによる高速化

一度処理した画像は Nginx のキャッシュに保存されるため、2 回目以降のリクエストは高速に応答します。

以下の図は、Nginx image_filter モジュールによる解決策の全体像を示しています。

mermaidCopy codeflowchart TB
  subgraph request["リクエスト処理"]
    req["画像リクエスト"] --> check["キャッシュ確認"]
    check -->|キャッシュあり| cached["キャッシュから配信"]
    check -->|キャッシュなし| process["画像処理"]
  end

  subgraph processing["画像処理フロー"]
    process --> load["元画像読み込み"]
    load --> resize["リサイズ処理"]
    resize --> convert["フォーマット変換"]
    convert --> quality["品質調整"]
    quality --> save["キャッシュ保存"]
  end

  save --> deliver["最適化画像を配信"]
  cached --> deliver

  deliver --> client["クライアント"]

この図が示すように、Nginx はリクエストごとに最適な処理を選択し、効率的に画像を配信します。

具体例

環境構築の準備

まずは、Nginx に image_filter モジュールを組み込むための環境を構築していきましょう。

必要なパッケージの確認

Nginx の image_filter モジュールは、画像処理ライブラリである GD ライブラリに依存しています。まず、現在の Nginx に image_filter モジュールが含まれているか確認しましょう。

bashCopy codenginx -V 2>&1 | grep -o with-http_image_filter_module

このコマンドで何も表示されない場合は、image_filter モジュールが含まれていないため、再コンパイルまたはモジュール付きパッケージのインストールが必要です。

Docker を使った環境構築

最も簡単な方法は、Docker を使って Nginx 環境を構築することです。以下の Dockerfile を使えば、image_filter モジュールを含む Nginx 環境を簡単に用意できますよ。

dockerfileCopy codeFROM nginx:latest

# GD ライブラリと依存パッケージのインストール
RUN apt-get update && apt-get install -y \
    libgd-dev \
    libwebp-dev \
    libjpeg-dev \
    libpng-dev \
    && rm -rf /var/lib/apt/lists/*

この Dockerfile は、公式の Nginx イメージをベースに、画像処理に必要なライブラリをインストールします。

bashCopy code# Dockerfile からイメージをビルド
docker build -t nginx-image-filter .

# コンテナを起動
docker run -d -p 80:80 \
  -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf \
  -v $(pwd)/images:/var/www/images \
  nginx-image-filter

これで、image_filter モジュールが使える Nginx 環境が起動しました。

基本的な画像リサイズ設定

それでは、実際に画像をリサイズする設定を作成していきましょう。

シンプルなリサイズ設定

まずは、固定サイズにリサイズする最もシンプルな設定から始めます。以下の設定は、すべての画像を幅 800px にリサイズします。

nginxCopy codehttp {
    # 画像処理用のバッファサイズを設定
    # 大きな画像を処理する場合は、この値を増やす必要があります
    proxy_buffers 16 16k;
    proxy_buffer_size 16k;

    server {
        listen 80;
        server_name localhost;

        # 画像の配置ディレクトリ
        root /var/www/images;
    }
}

この設定では、Nginx の基本的な構成を定義しています。proxy_buffers は画像処理に必要なバッファサイズを指定しています。

nginxCopy code        # リサイズ用のロケーション設定
        location /resize/ {
            # 元画像のパスを設定
            # /resize/photo.jpg → /original/photo.jpg を参照
            rewrite ^/resize/(.+)$ /original/$1 break;

            # 画像フィルターを有効化
            image_filter resize 800 -;

            # 処理後の画像品質を設定 (1-100)
            image_filter_jpeg_quality 85;

            # バッファサイズを設定 (処理する最大画像サイズ)
            image_filter_buffer 20M;
        }

この設定では、​/​resize​/​ 配下へのリクエストに対して、画像を幅 800px にリサイズして配信します。image_filter resize 800 -; の - は、アスペクト比を維持することを意味していますよ。

動的なサイズ指定

URL パラメータでサイズを指定できるようにすると、より柔軟な対応が可能になります。

nginxCopy code        # 動的リサイズ用のロケーション
        location ~ ^/dynamic/(\d+)x(\d+)/(.+)$ {
            set $width $1;
            set $height $2;
            set $image_path $3;

            # 元画像のパスを構築
            alias /var/www/images/original/$image_path;

            # 指定されたサイズにリサイズ
            image_filter resize $width $height;
            image_filter_jpeg_quality 85;
            image_filter_buffer 20M;
        }

この設定により、​/​dynamic​/​400x300​/​photo.jpg のような URL で、任意のサイズの画像を取得できます。正規表現で幅と高さを抽出し、変数として image_filter に渡しているのです。

WebP フォーマットへの変換

次は、モダンな画像フォーマットである WebP への変換を実装しましょう。

ブラウザの対応判定

WebP に対応しているブラウザかどうかは、Accept ヘッダーで判定できます。以下の設定は、ブラウザが WebP に対応している場合のみ WebP を配信します。

nginxCopy code        # WebP 変換用のロケーション
        location /optimized/ {
            set $webp_suffix "";

            # Accept ヘッダーに image/webp が含まれているかチェック
            if ($http_accept ~* "image/webp") {
                set $webp_suffix ".webp";
            }

            # 元画像のパスを設定
            rewrite ^/optimized/(.+)$ /original/$1$webp_suffix break;
        }

この設定では、Accept ヘッダーを確認し、WebP 対応ブラウザには .webp 拡張子を付加しています。ただし、この方法では事前に WebP ファイルを用意しておく必要があります。

リサイズと WebP 変換の組み合わせ

リサイズと WebP 変換を同時に行う、より実用的な設定を見ていきましょう。

nginxCopy code        # map ディレクティブで Accept ヘッダーを判定
        # http ブロック内に配置します
        map $http_accept $webp_enabled {
            default 0;
            "~*webp" 1;
        }

map ディレクティブを使うと、条件判定をより明確に記述できます。この設定は http ブロック内に配置してください。

nginxCopy code        # リサイズ + WebP 変換のロケーション
        location /auto/ {
            # 元画像のパスを設定
            rewrite ^/auto/(.+)$ /original/$1 break;

            # 幅 1200px にリサイズ
            image_filter resize 1200 -;

            # WebP 対応ブラウザの場合は WebP で出力
            # ※ image_filter モジュール単体では WebP 出力は非対応
            # そのため、別の方法が必要です
            image_filter_jpeg_quality 85;
            image_filter_buffer 20M;
        }

実は、Nginx の標準 image_filter モジュールは WebP への変換に対応していません。WebP 変換を行うには、外部モジュールや別のアプローチが必要になります。

WebP 変換の実装方法

image_filter モジュール単体では WebP 変換ができないため、以下のアプローチが考えられます。

ngx_http_image_filter_module の拡張版を使用

WebP 対応の拡張版モジュールを使用する方法です。GitHub で公開されているサードパーティモジュールを組み込む必要があります。

bashCopy code# Nginx をソースからビルドする場合
./configure \
  --with-http_image_filter_module \
  --add-module=/path/to/webp-module

make
make install

ソースからのビルドは少し難易度が高いですが、WebP 対応の最も直接的な方法です。

ImageMagick や外部ツールと組み合わせる

Nginx の image_filter でリサイズを行い、WebP 変換は別のツールで事前処理する方法もあります。

bashCopy code# ImageMagick を使った WebP 変換
for file in original/*.jpg; do
  cwebp -q 85 "$file" -o "webp/$(basename "$file" .jpg).webp"
done

このスクリプトは、JPEG ファイルを WebP に一括変換します。事前にこの処理を行っておき、Nginx では WebP ファイルを配信するという運用も可能です。

Lua モジュールを使った動的変換

ngx_http_lua_module と LuaJIT を使えば、より柔軟な画像処理が可能になります。

nginxCopy code        location /webp/ {
            content_by_lua_block {
                local webp = require "webp"
                -- Lua による WebP 変換処理
                -- (実装は省略)
            }
        }

Lua を使う方法は高度ですが、カスタマイズ性が非常に高いのが魅力です。

キャッシュ設定による高速化

画像処理はサーバーに負荷がかかるため、適切なキャッシュ設定が重要です。

Nginx のプロキシキャッシュ設定

処理済み画像をキャッシュすることで、2 回目以降のアクセスを高速化できます。

nginxCopy codehttp {
    # キャッシュの保存場所とサイズを定義
    # keys_zone: キャッシュキーを保存するメモリ領域 (10MB)
    # max_size: ディスクに保存する最大サイズ (1GB)
    # inactive: この期間アクセスがないキャッシュを削除 (30日)
    proxy_cache_path /var/cache/nginx/images
                     levels=1:2
                     keys_zone=image_cache:10m
                     max_size=1g
                     inactive=30d;
}

キャッシュの保存場所とサイズ制限を定義します。levels=1:2 は、キャッシュファイルを階層化してディレクトリに保存する設定ですよ。

nginxCopy code    server {
        location /cached/ {
            # キャッシュを有効化
            proxy_cache image_cache;

            # キャッシュキーの生成方法を定義
            # URL とリクエストメソッドをキーにします
            proxy_cache_key "$scheme$request_method$host$request_uri";

            # キャッシュの有効期間を設定
            # 200, 301, 302 レスポンスは 30 日間キャッシュ
            proxy_cache_valid 200 301 302 30d;

            # エラーレスポンスは 5 分間のみキャッシュ
            proxy_cache_valid 404 5m;

            # キャッシュ状態をヘッダーに追加 (デバッグ用)
            add_header X-Cache-Status $upstream_cache_status;

            # 元画像のパス
            rewrite ^/cached/(.+)$ /original/$1 break;

            # 画像処理
            image_filter resize 800 -;
            image_filter_jpeg_quality 85;
            image_filter_buffer 20M;
        }
    }

この設定により、一度処理した画像は最大 30 日間キャッシュされます。X-Cache-Status ヘッダーで、キャッシュがヒットしたかどうかを確認できるのです。

エラー処理とセキュリティ対策

実運用では、エラー処理とセキュリティ対策も重要です。

画像サイズの制限

悪意のあるリクエストで巨大な画像サイズを指定されると、サーバーに大きな負荷がかかります。サイズ制限を設けましょう。

nginxCopy code        # サイズ制限付きの動的リサイズ
        location ~ ^/safe/(\d+)x(\d+)/(.+)$ {
            set $width $1;
            set $height $2;
            set $image_path $3;

            # サイズの上限チェック (Lua が必要)
            # 代替案: map を使って許可するサイズを定義
            if ($width !~ ^(400|800|1200|1600)$) {
                return 400 "Invalid width";
            }

            if ($height !~ ^(300|600|900|1200)$) {
                return 400 "Invalid height";
            }

            alias /var/www/images/original/$image_path;
            image_filter resize $width $height;
            image_filter_jpeg_quality 85;
            image_filter_buffer 20M;
        }

この設定では、許可されたサイズのみを受け付けるようにしています。これにより、任意のサイズ指定による攻撃を防げます。

エラーハンドリング

画像が見つからない場合や、処理に失敗した場合のエラーハンドリングも設定しましょう。

nginxCopy code        location /protected/ {
            # 元画像のパス
            rewrite ^/protected/(.+)$ /original/$1 break;

            # 画像処理
            image_filter resize 800 -;
            image_filter_jpeg_quality 85;
            image_filter_buffer 20M;

            # エラー時の代替画像を設定
            error_page 404 /images/not-found.jpg;
            error_page 415 /images/invalid-format.jpg;
        }

error_page ディレクティブで、エラー時に表示する代替画像を指定できます。404 は画像が見つからない場合、415 は非対応フォーマットの場合のエラーコードです。

nginxCopy code        # not-found.jpg のロケーション
        location = /images/not-found.jpg {
            root /var/www/error-images;
        }

        # invalid-format.jpg のロケーション
        location = /images/invalid-format.jpg {
            root /var/www/error-images;
        }

エラー画像は別のディレクトリに配置し、無限ループを防ぎます。

実践的な設定例

最後に、これまでの内容を組み合わせた、実践的な設定例をご紹介しましょう。

完全な nginx.conf の例

以下は、リサイズ、キャッシュ、エラーハンドリングを含む実用的な設定です。

nginxCopy code# Nginx 設定ファイル全体の構成

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # ログフォーマットの定義
    log_format main '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'cache:$upstream_cache_status';

    access_log /var/log/nginx/access.log main;

この部分は Nginx の基本設定です。ログフォーマットにキャッシュステータスを追加することで、キャッシュの効果を確認できますよ。

nginxCopy code    # キャッシュディレクトリの設定
    proxy_cache_path /var/cache/nginx/images
                     levels=1:2
                     keys_zone=image_cache:10m
                     max_size=1g
                     inactive=30d
                     use_temp_path=off;

    # WebP 対応判定用の map
    map $http_accept $webp_suffix {
        default "";
        "~*webp" ".webp";
    }

    # 許可する画像サイズの定義
    map $width $valid_width {
        default 0;
        "400" 1;
        "800" 1;
        "1200" 1;
        "1600" 1;
    }

map ディレクティブで、WebP 対応判定と許可サイズの定義を行っています。これにより、後続の設定がシンプルになります。

nginxCopy code    server {
        listen 80;
        server_name localhost;

        # 元画像の配置場所
        root /var/www/images;

        # 最大アップロードサイズ
        client_max_body_size 20M;

サーバーブロックの基本設定です。client_max_body_size で、処理する最大画像サイズを制限しています。

nginxCopy code        # 動的リサイズ + キャッシュ
        location ~ ^/img/(\d+)/(.+)$ {
            set $width $1;
            set $image_path $2;

            # サイズの妥当性チェック
            if ($valid_width = 0) {
                return 400 "Invalid image size";
            }

            # キャッシュ設定
            proxy_cache image_cache;
            proxy_cache_key "$scheme$request_method$host$request_uri";
            proxy_cache_valid 200 30d;
            proxy_cache_valid 404 5m;
            add_header X-Cache-Status $upstream_cache_status;

            # 元画像のパス
            alias /var/www/images/original/$image_path;

            # 画像処理
            image_filter resize $width -;
            image_filter_jpeg_quality 85;
            image_filter_buffer 20M;

            # エラーハンドリング
            error_page 404 /error/not-found.jpg;
            error_page 415 /error/invalid-format.jpg;
        }

この設定が、画像最適化のメインとなるロケーションブロックです。URL から幅を取得し、リサイズ処理を行います。

nginxCopy code        # エラー画像の配信
        location /error/ {
            root /var/www;
            internal;
        }

        # 元画像への直接アクセスを禁止
        location /original/ {
            deny all;
            return 403;
        }

        # ヘルスチェック用エンドポイント
        location /health {
            access_log off;
            return 200 "OK\n";
            add_header Content-Type text/plain;
        }
    }
}

セキュリティ対策として、元画像への直接アクセスを禁止しています。また、ヘルスチェック用のエンドポイントも用意していますよ。

パフォーマンステストと検証

設定が完了したら、実際にパフォーマンスを測定してみましょう。

画像の配置とテスト

まず、テスト用の画像を配置します。

bashCopy code# 元画像ディレクトリの作成
mkdir -p /var/www/images/original

# テスト画像の配置
cp test-photo.jpg /var/www/images/original/

# Nginx の設定をリロード
docker exec nginx-image-filter nginx -s reload

設定を変更したら、必ず Nginx をリロードして変更を反映させましょう。

curl によるテスト

コマンドラインから画像リサイズをテストできます。

bashCopy code# 800px 幅にリサイズされた画像を取得
curl -I http://localhost/img/800/test-photo.jpg

# レスポンスヘッダーの確認
# X-Cache-Status: MISS (初回)
# X-Cache-Status: HIT (2回目以降)

-I オプションでヘッダーのみを取得し、キャッシュが機能しているか確認できます。初回は MISS、2 回目以降は HIT となるはずです。

bashCopy code# 画像をダウンロードしてサイズを確認
curl -o resized-800.jpg http://localhost/img/800/test-photo.jpg

# ファイルサイズの確認
ls -lh resized-800.jpg

# 画像の実際のサイズを確認 (ImageMagick が必要)
identify resized-800.jpg

実際に画像をダウンロードして、正しくリサイズされているか確認しましょう。

以下の表は、画像最適化の効果を測定する際のチェックポイントです。

#	確認項目	確認方法	目標値
1	リサイズの正確性	identify コマンド	指定サイズと一致
2	ファイルサイズ削減率	ls -lh で比較	元画像の 30-50%
3	キャッシュヒット率	X-Cache-Status ヘッダー	2 回目以降 HIT
4	レスポンス時間	curl -w "%{time_total}"	1 秒以内
5	画質の劣化具合	目視確認	劣化が目立たない

トラブルシューティング

実装中によく遭遇するエラーと、その解決方法をご紹介します。

エラー: image_filter: unable to allocate memory

このエラーは、image_filter_buffer の設定が小さすぎる場合に発生します。

エラーコード: Nginx Error Log に記録

エラーメッセージ:

textCopy code2025/11/14 10:30:15 [error] 1234#1234: *1 image_filter: unable to allocate memory

発生条件: 処理しようとする画像が image_filter_buffer で指定したサイズを超えている

解決方法:

1. image_filter_buffer の値を増やす
2. アップロード可能な画像サイズを制限する
3. 事前に画像を適切なサイズに圧縮する

nginxCopy code# バッファサイズを増やす
image_filter_buffer 50M;  # デフォルトは 1M

# または、処理する画像サイズを制限
client_max_body_size 10M;

エラー: image_filter: not a JPEG or PNG file

対応していない画像フォーマットを処理しようとした場合のエラーです。

エラーコード: HTTP 415 Unsupported Media Type

エラーメッセージ:

textCopy code2025/11/14 10:35:22 [error] 1234#1234: *2 image_filter: not a JPEG or PNG file

発生条件: JPEG/PNG/GIF 以外のフォーマット(例: BMP, TIFF)を処理しようとした

解決方法:

1. 対応フォーマットのみ受け付けるよう制限する
2. エラー時の代替画像を設定する
3. 事前に対応フォーマットに変換する

nginxCopy code# 対応フォーマットのみ処理
location ~ ^/img/(\d+)/(.+)\.(jpg|jpeg|png|gif)$ {
    # ... 設定内容 ...
}

# それ以外はエラー
location ~ ^/img/(\d+)/(.+)$ {
    return 415 "Unsupported image format";
}

キャッシュが機能しない

X-Cache-Status が常に MISS になる場合のトラブルシューティングです。

症状: 何度アクセスしても X-Cache-Status: MISS となる

原因と解決方法:

1. キャッシュディレクトリの権限不足

bashCopy code# キャッシュディレクトリの権限を確認
ls -la /var/cache/nginx/

# 権限を修正
chmod 755 /var/cache/nginx/images
chown nginx:nginx /var/cache/nginx/images

2. proxy_cache_key の設定が不適切

nginxCopy code# キャッシュキーを確認・修正
proxy_cache_key "$scheme$request_method$host$request_uri";

# デバッグ用にキャッシュキーをログに出力
add_header X-Cache-Key "$scheme$request_method$host$request_uri";

3. キャッシュ可能な条件を満たしていない

nginxCopy code# キャッシュ可能な条件を確認
proxy_cache_valid 200 301 302 30d;

# 必要に応じて条件を追加
proxy_cache_valid any 1h;  # すべてのレスポンスを 1 時間キャッシュ

パフォーマンス最適化のベストプラクティス

実運用でのパフォーマンスをさらに向上させるためのテクニックです。

Worker プロセス数の最適化

CPU コア数に応じて Worker プロセス数を調整しましょう。

nginxCopy code# CPU コア数を自動検出して設定
worker_processes auto;

# または明示的に指定 (4 コアの場合)
worker_processes 4;

# 各 Worker の最大接続数
events {
    worker_connections 2048;
    use epoll;  # Linux の場合
}

worker_processes auto を使うと、Nginx が自動的に最適な数を設定してくれます。

gzip 圧縮との併用

画像以外のリソースには gzip 圧縮を適用しましょう。

nginxCopy codehttp {
    # gzip 圧縮を有効化
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml+rss;

    # 画像は既に圧縮されているため gzip 対象外
    gzip_disable "msie6";
}

gzip 圧縮は CPU を使用するため、適切なレベル(6 程度)に設定することが重要です。

HTTP/2 の活用

HTTP/2 を有効にすると、複数の画像を並列でダウンロードできます。

nginxCopy codeserver {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    # ... その他の設定 ...
}

HTTP/2 は HTTPS 環境でのみ有効なので、SSL 証明書の設定が必要です。

まとめ

Nginx の image_filter モジュールを使った画像最適化環境の構築方法について解説してきました。要点を振り返ってみましょう。

主要なポイント

動的な画像最適化が可能

image_filter モジュールを使えば、リクエストに応じて動的に画像をリサイズできます。複数サイズの画像を事前に用意する必要がなく、ストレージ容量とメンテナンスコストを削減できるのです。

キャッシュによる高速化

一度処理した画像はキャッシュされるため、2 回目以降のアクセスは高速に応答します。適切なキャッシュ設定により、サーバー負荷を最小限に抑えられますね。

柔軟な設定が可能

URL パラメータでサイズを指定したり、ブラウザの Accept ヘッダーでフォーマットを切り替えたりと、柔軟な画像配信が実現できます。

WebP 対応には工夫が必要

標準の image_filter モジュールは WebP 変換に対応していないため、拡張モジュールや外部ツールとの組み合わせが必要です。ただし、リサイズだけでも大きな最適化効果が得られますよ。

実装時の注意点

設定を実装する際は、以下の点に注意してください。

• セキュリティ対策: 画像サイズの制限を設けて、サーバー負荷を防ぐ
• エラーハンドリング: 適切なエラーページを設定し、ユーザー体験を向上させる
• パフォーマンス測定: 実際の効果を測定して、設定を最適化する
• 段階的な導入: まず小規模でテストしてから、本番環境に展開する

今後の展望

Web の世界は常に進化しています。AVIF のような新しい画像フォーマットも登場していますし、ブラウザのサポート状況も日々変化しています。

Nginx の image_filter モジュールは、基本的な画像最適化には十分な機能を提供してくれます。この記事で紹介した設定をベースに、皆さんの環境に合わせてカスタマイズしていってください。

画像最適化は、Web サイトのパフォーマンス向上における重要な要素です。適切に実装すれば、ユーザー体験の大幅な改善につながりますよ。

関連リンク

• Nginx 公式ドキュメント - ngx_http_image_filter_module
• Nginx 公式ドキュメント - Proxy Cache
• Can I use - WebP image format
• Google Developers - Serve images in next-gen formats
• WebP 公式サイト
• Docker Hub - Nginx Official Image
• ImageMagick 公式サイト