同じVPSでも，Nginxの設定次第でWebの体感速度は劇的に変わる．圧縮もキャッシュもHTTP/2も効かせていないデフォルト設定のままでは，せっかくの高速なサーバーを活かしきれていない．

表示速度は単なる快適さの問題ではない．SEO(Core Web Vitals)・直帰率・コンバージョンに直結する事業上の重要指標だ．そして多くの改善は，Nginxの設定を数行足すだけで実現できる．

この記事は，VPSでNginxを動かす個人開発者，サイトの表示速度を本気で上げたいエンジニアに向けている．圧縮・キャッシュ・HTTP/2・配信最適化を，コピーして使える設定例とともに解説する．

読み終えたとき，あなたのサイトは転送量が減り，再訪が速くなり，同時接続にも強くなっている．費用ゼロで効く，最もコスパの高い高速化だ．

なぜNginxチューニングが効くのか

Webの遅さの主因は，多くの場合「転送するデータが大きい」「同じものを毎回取り直している」「接続のオーバーヘッド」の3つだ．Nginxチューニングはこの3つを直接叩く．

圧縮はデータ量を減らし，キャッシュは再取得を無くし，HTTP/2は接続効率を上げる．どれもサーバー側の設定だけで完結し，アプリのコードを触る必要がない．

そしてこれらはCore Web Vitals(LCP等)を改善する．表示速度はGoogleのランキング要因であり，速いサイトはSEOでも有利になる．

費用は基本ゼロ．高速なVPSの性能を，設定で最大限引き出す── これがNginxチューニングの価値だ．

圧縮を効かせる ― gzipとBrotli

最初にやるべきはテキスト系リソースの圧縮だ．HTML・CSS・JS・JSON・SVGは圧縮でサイズが7〜8割減ることも珍しくない．転送量が減れば，そのぶん表示は速くなる．

nginx.conf の gzip 設定

gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types text/plain text/css application/json
           application/javascript text/xml application/xml
           image/svg+xml application/font-woff;

gzip_comp_levelは圧縮率とCPU負荷のバランスで，5〜6が実用的だ．高くしすぎるとCPUを食う割に効果が薄い．gzip_min_lengthで小さすぎるファイルは圧縮しない(オーバーヘッドの方が大きいため)．画像(JPEG/PNG)やすでに圧縮済みのものは対象から外す．

Brotliでさらに縮める

可能ならBrotli(Googleが開発した圧縮)も併用したい．gzipよりさらに10〜20%小さくなる場合がある．Nginxにbrotliモジュールが入っていれば有効化でき，対応ブラウザにはBrotli，非対応にはgzipと自動で振り分けられる．

ブラウザキャッシュ ― 同じものを取り直させない

画像・CSS・JS・フォントといった変わらない静的ファイルは，ブラウザに長期間キャッシュさせる．これにより再訪時の読み込みが劇的に速くなり，サーバーの負荷も下がる．

静的ファイルのキャッシュ設定

location ~* .(jpg|jpeg|png|gif|webp|svg|css|js|woff2|ico)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

expires 1y＋immutableで「1年間キャッシュ，再検証不要」を指示する．ただしこれはファイル名にハッシュを付ける運用(例: app.3f2a.js)が前提だ．更新時はファイル名が変わるため，古いキャッシュが残る問題を避けられる．HTML本体は短め(または都度検証)にするのがセオリーだ．

HTTP/2を有効にする ― 接続効率を上げる

HTTP/2は，1本の接続で複数リソースを並行してやり取りできる(多重化)．多数のCSS/JS/画像を読み込む現代のサイトで効果が大きい．HTTPSが前提だが，前回のCertbot記事でHTTPS化していればすぐ有効化できる．

HTTP/2の有効化

server {
    listen 443 ssl;
    http2 on;            # 新しい書式(旧: listen 443 ssl http2;)
    server_name example.com;
    # ... ssl設定 ...
}

HTTP/2では，かつての高速化テクニック(CSSスプライト・ファイル結合)の一部が不要〜逆効果になる点も知っておきたい．多重化により小さなファイルを並行取得できるため，無理に1ファイルに結合しなくてよくなった．

静的ファイル配信の最適化 ― Nginxの土俵で戦う

静的ファイルの配信は，アプリ(Node/PHP等)に通さず，Nginxが直接返すのが鉄則だ．Nginxの静的配信は極めて高速で，アプリの負荷も減らせる．

静的配信とsendfileの最適化

sendfile on;          # カーネルレベルで効率的に配信
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;

# 静的ファイルはNginxが直接,APIだけアプリへ
location /static/ { root /var/www/site; }
location /api/    { proxy_pass http://127.0.0.1:3000; }

sendfile onは，ファイルをカーネル空間で直接送る最適化で，静的配信の効率を上げる．「静的はNginx，動的はアプリ」と役割を分ければ，アプリは本来のロジックに専念でき，全体のスループットが上がる．

gzip_staticで圧縮の二度手間を省く

毎リクエストで圧縮するとCPUを使う．ビルド時に.gzを生成しておき，gzip_static onで「圧縮済みファイルがあればそれを返す」ようにすれば，配信時の圧縮処理が不要になる．静的サイトで特に効く．

プロキシキャッシュ・FastCGIキャッシュ ― 動的ページもキャッシュする

WordPressのような動的サイトでも，生成結果をNginxでキャッシュすれば，バックエンド(PHP/アプリ)を都度動かさずに高速応答できる．アクセスが集中するページほど効果が絶大だ．

FastCGIキャッシュ(WordPress等)の骨子

fastcgi_cache_path /var/cache/nginx levels=1:2
    keys_zone=WP:100m inactive=60m;

location ~ .php$ {
    fastcgi_cache WP;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $skip_cache;   # ログイン時等は除外
    # ... fastcgi_pass 等 ...
}

キャッシュは強力だが，「キャッシュしてはいけないページ(ログイン後・カート・管理画面)」を除外する設計が肝心だ．これを誤ると，他人のログイン状態が表示されるような事故になる．Cookieやパスで$skip_cacheを制御し，慎重に適用する．

設定変更の安全な反映と検証

Nginxの設定変更は，必ず構文チェックしてからリロードする．いきなりrestartして設定ミスがあると，サイト全体が落ちる．

安全な反映と効果の確認

sudo nginx -t                 # 構文チェック(必須)
sudo systemctl reload nginx   # 無停止リロード

# 圧縮が効いているか確認
curl -s -H "Accept-Encoding: gzip" -I https://example.com/style.css | grep -i content-encoding
# HTTP/2が効いているか
curl -sI --http2 https://example.com | head -1

nginx -tで構文を確認し，reload(無停止)で反映するのが鉄則だ．効果はcurl -Iでレスポンスヘッダを見れば確認できる(content-encoding: gzip，HTTP/2 200など)．ブラウザの開発者ツールのNetworkタブでも転送サイズと圧縮を確認できる．

補論：チューニングは「速い土台」があってこそ最大化する

Nginxチューニングは強力だが，土台のVPSが遅ければ上限も低い．ディスクI/Oが遅ければ静的配信もキャッシュ書き込みも詰まる．速い基盤の上でこそ，設定の効果が最大化する．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はNVMe SSDで静的配信・キャッシュI/Oが高速に動き，HTTP/2の多重化やgzip_staticの効果をそのまま引き出せる．スナップショットを取ってからNginx設定を触れば，構文ミスでサイトを落としても即座に巻き戻せるので，安心してチューニングを攻められる．

高速化したサイトを独自ドメイン＋HTTPSで公開すれば，体感速度とSEOの両方で報われる．取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ でドメインを取得し，HTTP/2＋圧縮＋キャッシュの効いた「速いサイト」を月数百円〜で運用しよう．

よくある質問(FAQ)

Q1．まず何から手を付けるべき？

費用対効果が高い順に(1)gzip圧縮 (2)静的ファイルのブラウザキャッシュ (3)HTTP/2だ．この3つだけで体感速度と転送量が大きく改善する．動的サイトならその後にFastCGI/プロキシキャッシュを検討する．

Q2．gzip_comp_levelはいくつが最適？

5〜6が実用的だ．9にしてもサイズはわずかしか縮まらず，CPU負荷だけ増える．迷ったら6でよい．

Q3．キャッシュで更新が反映されない

静的ファイルを長期キャッシュする場合はファイル名にハッシュを付ける運用(app.3f2a.js)が前提だ．更新時にファイル名が変わるため，古いキャッシュ問題が起きない．HTML本体は短めのキャッシュにする．

Q4．HTTP/2にするとCSS結合は不要？

多重化により無理な結合は不要〜逆効果になることが多い．ただしリクエスト数が極端に多い場合は依然として削減が有効な場面もある．まずHTTP/2を有効化し，実測で判断するのがよい．

Q5．WordPressのキャッシュは危険では？

ログイン後・管理画面・カート等を除外する設計が必須だ．これを誤ると他人のログイン状態が見える事故になる．Cookieやパスで確実に除外し，慎重に適用すれば，匿名ページの高速化に絶大な効果がある．

Q6．設定を変えたらサイトが落ちた

変更後は必ずnginx -tで構文チェックしてからreloadする．restartでなくreloadなら無停止だ．それでも問題が出たら，スナップショットで変更前に戻すのが最速の復旧になる．

まとめ ― 設定数行で「速いサイト」は手に入る

Nginxチューニングは，圧縮・キャッシュ・HTTP/2・配信最適化という数行の設定で，転送量を減らし再訪を速くし同時接続に強くする．費用ゼロで効く，最もコスパの高い高速化だ．

今日やるべきことは，gzipを有効化し，静的ファイルにキャッシュ設定を入れ，HTTP/2をONにすること．そしてcurl -Iで効いているか確認する．体感の変化はすぐ分かる．

速いサイトは，ユーザーにもSEOにも報われる．スナップショットで戻せるVPSがあれば，今夜から恐れずにチューニングを攻められる．