【Nginx講座 第7回】爆速化チューニング。Gzip圧縮、ブラウザキャッシュ、バッファサイズ最適化

「1秒の遅延」が、命取りになる時代。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、セキュリティ対策を行い、鉄壁の守りを固めました。
しかし、いくら安全でも「開くのに5秒かかるサイト」を、あなたは毎日見たいと思いますか？

Amazonの調査では「ページの表示が0.1秒遅れるだけで、売り上げが1%低下する」と言われています。
また、Googleの検索アルゴリズム（Core Web Vitals）においても、表示速度は極めて重要な評価指標です。
つまり、「遅いサーバーは、それだけで機会損失」なのです。

本記事では、通信量を劇的に減らす「Gzip圧縮」、再訪問時の読み込みをゼロにする「ブラウザキャッシュ」、そしてOSレベルでのI/O効率を最大化する「sendfile / tcp_nopush」など、プロが現場で行うチューニングの全貌を解説します。

---

第1章：通信量を1/5にする「Gzip圧縮」

Webサイトの表示が遅い最大の原因は「転送するデータ量が大きいこと」です。
HTML、CSS、JavaScriptなどのテキストファイルは、圧縮することで劇的にサイズを小さくできます。
Nginxには、データを送信する直前に自動で圧縮する Gzip機能 が備わっています。

推奨設定（nginx.conf）

http ブロック内に以下の設定を追記します。

http {
    # ...
    
    # Gzip圧縮の有効化
    gzip on;
    
    # 圧縮レベル（1〜9）。推奨は CPU負荷と効果のバランスが良い「1〜5」
    gzip_comp_level 4;
    
    # 圧縮する最小ファイルサイズ（小さすぎるファイルは圧縮すると逆効果）
    gzip_min_length 1024;
    
    # プロキシ経由のリクエストも圧縮する
    gzip_proxied any;
    
    # 古いIEなどは除外（今はほぼ不要だが念のため）
    gzip_disable "msie6";
    
    # 圧縮対象のMIMEタイプ（必須！）
    # text/html はデフォルトで含まれるため記述不要
    gzip_types
        text/css
        text/javascript
        text/xml
        text/plain
        text/x-component
        application/javascript
        application/x-javascript
        application/json
        application/xml
        application/rss+xml
        application/atom+xml
        font/truetype
        font/opentype
        application/vnd.ms-fontobject
        image/svg+xml;
        
    # ...
}

設定のポイント

• gzip_types: デフォルトではHTMLしか圧縮されません。CSSやJS、JSONなども対象に含めることが最重要です。
• gzip_comp_level: 「9」にすると最も小さくなりますが、CPUを激しく消費します。「4」あたりが費用対効果（CPU使用率と転送速度のバランス）のスイートスポットです。
• 画像は対象外: JPEGやPNGは既に圧縮されているため、Gzipをかけてもサイズは減らず、CPUの無駄遣いになります（SVGはテキストデータなので圧縮効果が高いです）。

---

第2章：再訪問を瞬時にする「ブラウザキャッシュ」

初めて訪れたサイトは読み込みに時間がかかりますが、2回目以降は速いですよね。
これはブラウザが画像やCSSをローカルに保存（キャッシュ）しているからです。
Nginx側で「このファイルは〇〇日間は変更されないから、保存しておいていいよ」と指示を出すことで、この効果を最大化できます。

Expires設定（locationブロック）

静的ファイルの拡張子ごとに、キャッシュ期間を設定します。

server {
    # ...

    # 画像、動画、フォント（変更頻度が低い）
    location ~* \.(jpg|jpeg|gif|png|ico|svg|mp4|webm|woff|woff2|ttf|eot)$ {
        expires 30d;           # 30日間キャッシュ
        access_log off;        # ログ出力を止めてI/O負荷軽減
        add_header Cache-Control "public";
    }

    # CSS、JS（更新される可能性がある）
    location ~* \.(css|js)$ {
        expires 7d;            # 7日間キャッシュ
        access_log off;
    }
}

Cache-Controlヘッダーの意味

expires ディレクティブを設定すると、自動的に Cache-Control ヘッダーも付与されます。
これにより、ブラウザは「有効期限内ならサーバーに問い合わせすらせず、ローカルのファイルを使う」ようになります。

---

第3章：カーネルの力を引き出す「OSレベルの最適化」

ここからは少しマニアックですが、効果絶大なLinuxカーネルレベルのチューニングです。
Nginxは「OSの機能」をうまく使うことで、驚異的なパフォーマンスを発揮します。

三種の神器（sendfile, tcp_nopush, tcp_nodelay）

nginx.conf の http ブロックにある、以下の設定を確認（有効化）してください。

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    # ...
}

1. sendfile on;

通常、Webサーバーがファイルを送信する時、カーネル空間（ディスク）→ユーザー空間（アプリ）→カーネル空間（ネットワーク）というコピーが発生します。
sendfile を有効にすると、カーネル内でディスクからネットワークへ直接データを渡すことができ、CPU負荷とメモリコピーを大幅に削減できます。

2. tcp_nopush on;

sendfile が有効な時のみ機能します。
ネットワークパケットを「ある程度まとめてから」送信します。
TCPヘッダーのオーバーヘッドを減らし、大容量ファイルの転送効率を上げます。

3. tcp_nodelay on;

こちらは逆に、小さなデータを「待たずにすぐ」送信します（Nagleアルゴリズムの無効化）。
キープアライブ接続時に、マウスの動きやAPIレスポンスなどの細かいデータを即座に届けるために重要です。
※一見 tcp_nopush と矛盾しそうですが、Nginxは状況に応じてこれらを巧みに使い分けます。両方ONで大丈夫です。

---

第4章：ファイルディスクリプタのキャッシュ

Linuxでは「すべてがファイル」です。
Nginxへのアクセスが増えると、ファイルの開閉処理（open/close）が頻繁に行われ、これが負荷になります。
open_file_cache を使うと、一度開いたファイルのメタデータ（場所やサイズ、権限情報など）をメモリにキャッシュできます。

設定例（httpブロック）

http {
    # 最大10,000個の情報をキャッシュ。20秒使われなかったら破棄。
    open_file_cache max=10000 inactive=20s;
    
    # キャッシュの有効性を確認する間隔
    open_file_cache_valid 30s;
    
    # inactive期間内に最低2回アクセスがあればキャッシュを維持
    open_file_cache_min_uses 2;
    
    # ファイルが見つからないエラーもキャッシュする
    open_file_cache_errors on;
}

特に、大量の小さな画像ファイルやCSS/JSを配信するサーバーで効果を発揮します。

---

第5章：ワーカーと接続数の最適化

第1章で少し触れた「プロセス数」と「接続数」の最適解についてです。

worker_processes

worker_processes auto;

基本は auto（CPUコア数と同じ）でOKです。
増やしすぎてもコンテキストスイッチ（切り替えコスト）が増えて逆に遅くなります。

worker_connections

events {
    worker_connections 1024;
    use epoll;  # Linux向けの最適化（通常は自動選択される）
    multi_accept on; # 可能な限り多くの接続を一度に受け入れる
}

• worker_connections: デフォルトの1024で十分な場合が多いですが、大規模サイトでは 4096 やそれ以上に増やします。
  ただし、OS側の ulimit -n（ファイルディスクリプタ上限）もあわせて増やす必要があります。

---

第6章：計測なきチューニングは「改悪」である

最後に、エンジニアとして最も重要なことをお伝えします。
「推測で設定を変更しないこと」です。
設定を変える前と後で、必ず計測を行いましょう。

おすすめ計測ツール

1. Google PageSpeed Insights:
   WebサイトのURLを入れるだけで、モバイル/PCでの表示速度をスコア化してくれます。
   「Gzip圧縮してください」「キャッシュポリシーを設定してください」といった具体的なアドバイスもくれます。
2. Chrome開発者ツール (Networkタブ):
   レスポンスヘッダーを見て Content-Encoding: gzip があるか、Cache-Control が効いているかを確認します。
3. 負荷テストツール (ab / wrk):
   ab -n 1000 -c 10 http://localhost/ のようにコマンドを打ち、秒間リクエスト処理数（RPS）を計測します。
   設定変更でこの数値がどう変わるかを見極めます。

---

まとめ：速さは正義

お疲れ様でした！
今回は、Nginxのパフォーマンスを極限まで引き出す設定について解説しました。

今回の重要ポイント：

• Gzip圧縮で転送量を減らす（ただしCPUとのトレードオフ）。
• 静的ファイルには長期間のExpiresを設定し、ブラウザにキャッシュさせる。
• sendfile, tcp_nopush, tcp_nodelay は三種の神器。
• open_file_cache でファイルアクセスのオーバーヘッドを減らす。

これらの設定を適用すれば、ユーザーは「サクサク動く！」と感動し、Googleもあなたのサイトを高く評価するでしょう。

さて、これでサーバー構築・運用の技術はほぼ網羅しました。
最終回となる次回は、運用を続ける上で欠かせない「ログ解析」と、サーバー構築の新しいスタンダード「DockerでのNginx運用」について触れます。
サーバーの中で何が起きているかを可視化し、モダンなインフラ管理へとステップアップしましょう。

次回、第8回（最終回）は「ログ解析と運用監視。アクセスログのカスタム設定とDockerでの運用」です。
JSON形式でのログ出力、解析ツールとの連携、そしてコンテナ技術によるNginxの新しい形。最後までお見逃しなく！