MENU

nuxt.jsとcdnで実現する高速配信と最適化の完全ガイド

大規模情報サイト運営
cdn nuxt.js
2025/11/29
目次

はじめに

概要

本シリーズでは、Nuxt.jsアプリケーションでCDNを効果的に使う方法を分かりやすく解説します。cdnURLの設定やアセット配信ディレクトリの管理、静的生成・サーバーレス環境での配信戦略など、実際の運用に役立つポイントを中心に扱います。

対象読者と前提

この章はフロントエンド開発者や運用担当者を想定します。Nuxtの基本的な使い方（プロジェクト作成やビルド）の経験があると理解が早まりますが、初心者にも配慮して丁寧に説明します。

なぜCDNが重要か

CDNを使うと、ユーザーに近い場所から静的ファイル（JavaScript、CSS、画像など）を配信できます。読み込み速度が改善し、サーバー負荷が下がります。例えば、海外ユーザーの多いサイトでは、配信元を分散するだけで体感速度が大きく変わります。

本書の進め方

各章で設定例と運用上の注意点を示します。実際のconfig例やデプロイの手順も載せますので、手元のプロジェクトに応用しやすいです。読み進めながら試していただければ、設定の意味と効果がつかめます。

注意点

CDNは強力ですが、キャッシュの扱いやパスの設定を誤ると更新が反映されないことがあります。以降の章で具体的な回避策も説明しますので、順を追ってご覧ください。

Nuxt Configuration – CDN設定の基礎

概要

Nuxtのnuxt.config.tsにあるapp.cdnURLは、本番で静的アセットやメディアをCDNから配信するための絶対URLを指定します。デフォルトは空文字列で、環境変数NUXT_APP_CDN_URLを使ってランタイムに変更できます。

基本的な設定例

下記のようにnuxt.config.tsで指定します。

export default defineNuxtConfig({
  app: {
    cdnURL: process.env.NUXT_APP_CDN_URL || ''
  }
})

例: NUXT_APP_CDN_URL=https://cdn.example.com

動作イメージ

指定したURLが先頭につく形で、ビルド済みのアセット（例: /_nuxt/ で配信されるファイル）やメディアの絶対パスに適用されます。開発時は空にしてローカルを使い、本番だけCDNに切り替える運用が一般的です。

注意点

  • URLはプロトコルを含む絶対パスにする（https://…）。
  • 末尾のスラッシュの有無で生成されるパスが変わるので統一します。
  • CDN側のキャッシュ設定や無効化（invalidate）を運用で用意してください。

テスト方法

  1. ビルドして公開環境でNUXT_APP_CDN_URLを設定して動作確認します。
  2. ブラウザのネットワークタブでアセットのホストを確認します。

実際のデプロイ先で環境変数を設定すれば、静的アセットの配信元を簡単に切り替えられます。

アセット配信ディレクトリの管理

概要

buildAssetsDirはビルド後に生成されるアプリ用アセット（JS/CSSなど）のフォルダ名を指定します。デフォルトは「/_nuxt/」で、baseURLやcdnURLに対する相対パスとして扱われます。ビルド時に確定し、ランタイムで変更できません。

基本動作と例

例えばbaseURLを「/app/」にし、buildAssetsDirを「/_nuxt/」のままにすると、アセットは「/app/_nuxt/」から参照されます。cdnURLを設定すると、アセットの参照先はCDN上の「https://cdn.example.com/app/_nuxt/」のようになります。

デプロイ上の注意点

  • ビルド時に決まるため、本番環境でパスを切り替えられません。別のパスを使う場合は再ビルドが必要です。
  • CDN配信時はパスの一貫性を保ち、キャッシュ設定を確認してください。ファイル名がハッシュ化されていればキャッシュ破棄が楽です。

実用的なヒント

  • シンプルにしたい場合はデフォルトを使い、baseURLでアプリのルートを制御すると管理が楽です。
  • 静的ホスティングでは、ビルド成果物をそのまま対応するディレクトリに置くだけで動作します。変更が必要ならビルド設定を更新して再出力してください。

本番環境でのデプロイメント戦略

概要

Nuxt（Nitro）はNode.jsプリセットでビルドし、生成されたサーバーがデフォルトでポート3000をリッスンします。本番では単独で公開せず、nginxやCloudflareといったリバースプロキシの背後で運用することが一般的です。これらがSSL終端やCDNキャッシュを担当します。

実運用での基本戦略

  • リバースプロキシをフロントに置き、HTTP/HTTPSや静的資産のキャッシュを処理します。例えばnginxでポート80/443を受け、内部でアプリに転送します。
  • アプリは内部ポート（例:3000）で動かし、プロキシが外部公開を制御します。

環境変数による制御

  • PORTやHOSTでリスン先を変更できます。例: PORT=8080
  • SSL終端はプロキシで行うため、アプリ側は通常HTTPで動作させます。ただし内部でTLSが必要な場合は環境変数で切り替え可能です。

デプロイ手順例（簡潔）

  1. ビルド: npm run build
  2. サービス化: systemdやpm2でバックグラウンド実行
  3. nginx設定: upstreamで内部ポートを指定し、SSL証明書を設定
  4. モニタリング: ログとヘルスチェックを配置する

注意点

  • 静的ファイルは可能ならCDNに置いて負荷を下げます。したがってキャッシュ戦略を明確にしてください。
  • ポートやホストの設定ミスが起きやすいので、環境ごとの設定を分けて管理します。

静的生成とCDN最適化

概要

nuxi generateコマンドでサイトを静的に生成すると、全てのルートを事前にHTMLとして出力できます。出力されたファイルはCDNや静的ホスティングにそのまま置けるため、配信が速く、スケーラブルです。

nuxi generateで何が起こるか

nuxi generateは各ルートをレンダリングしてHTMLファイルを作ります。画像やスクリプト、CSSも静的アセットとして出力されます。結果はS3やNetlify、Vercelの静的配信領域にアップロードできます。

CDNに最適化するポイント

  • アセットの参照先をCDNに合わせる: nuxt.configでベースURLやアセットの公開パスをCDNのURLに合わせます。例:
export default defineNuxtConfig({
  ssr: false, // クライアントのみの場合
  app: { baseURL: 'https://cdn.example.com/' }
})
  • キャッシュヘッダを設定する: 静的ファイルは長めのキャッシュを付け、差分が出るファイルはハッシュ名にして更新を反映します。

動的ルートへの対応

動的なページ（例: /product/123）はビルド時に一覧を渡してプリレンダリングできます。プリレンダ用のルートリストを用意するか、必要に応じて一部をクライアント側でフェッチしてください。無理に全てを生成するとビルド時間が長くなるので注意します。

クライアントサイドのみの構成

ssrをfalseにすると完全にクライアントサイドレンダリングになります。静的ファイルだけで動作し、設定が簡単です。ただし初回表示で空白が見える場合があるので、必要に応じてプリフェッチやスケルトンを用意します。

デプロイ例

  1. nuxi generate を実行
  2. 出力フォルダをCDNや静的ホスティングへアップロード
  3. CDNのキャッシュ設定とヘッダを調整

これで高速で信頼性の高い配信が実現できます。

ハイブリッドレンダリングと柔軟な配信

概要

Nuxtはサーバーサイドレンダリング（SSR）とクライアントサイドレンダリング（CSR）を同一プロジェクトで組み合わせて使えます。用途に応じてページ単位で振り分けることで、パフォーマンスと運用性を両立できます。

ページごとのレンダリング切替

静的なランディングページはビルド時に静的出力し、ユーザー毎に変わるページはSSRにします。多くの場合、マーケティングやFAQは静的、認証や管理画面はSSRにすると分かりやすいです。ルート設定やページメタでレンダリングモードを指定します。

部分的なクライアントレンダリング

重いインタラクションは動的インポートやクライアント専用コンポーネントに分離します。これにより初期表示を早くしつつ、必要な部分だけクライアントで水和（hydration）します。

APIとサーバー機能の使い分け

データ取得はAPIエンドポイントで行い、キャッシュや認証はサーバー側で処理します。静的ページはビルド時に必要データを埋め込み、動的ページはリクエストごとにAPIで取得すると運用が楽です。

デプロイの考え方

同一リポジトリで静的配信とSSRエンドポイントを用意できます。CDNで静的アセットを配り、サーバーはSSRやAPIだけを担当させる構成が現実的です。

ベストプラクティス

  • 各ページの要件を明確にする
  • 動的部分は遅延読み込みで切り離す
  • APIとキャッシュ戦略を早めに設計する
  • テスト環境で複数モードを確認する

これらを組み合わせると、過不足のない柔軟な配信が実現できます。

サーバーレスおよびエッジ環境へのデプロイ

はじめに

Nuxtはさまざまな配信環境へ簡単にデプロイできます。ここではサーバーレス（クラウド関数）とエッジ（CDN近傍で動く軽量実行環境）への実践的な手順と注意点を分かりやすく説明します。

サーバーレスへの展開（例: Netlify, Vercel）

手順は概ね共通です。ビルドコマンドに「nuxt build（または nuxi build）」を指定し、出力ディレクトリを設定します。Netlifyなら出力は dist、Vercelはフレームワーク自動検出で設定が不要な場合があります。サーバーレス関数はリクエストごとに起動するため、初回遅延（コールドスタート）を想定してください。

エッジへの展開（例: Cloudflare Workers, Vercel Edge）

エッジ環境はユーザーに近い場所で応答するため高速です。ただし実行時間や利用可能なAPIに制限があります。画像処理など重い処理は避け、キャッシュを積極的に使う設計にします。

実際の設定例

  • Netlify: ビルドコマンドを nuxt build、公開ディレクトリを dist に設定。CLIがフレームワークを自動検出します。
  • Vercel: リポジトリを接続すると自動設定されることが多く、必要に応じてビルドコマンドを上書きします。

注意点とベストプラクティス

  • 環境変数はプラットフォームの設定画面で管理してください。
  • 長時間処理や大きなバイナリは避け、外部サービスへ委任します。
  • ローカルで nuxi preview や各プラットフォームのローカルツールで動作確認を行ってください。

これらのポイントを踏まえると、Nuxtをサーバーレスやエッジで安全かつ高速に運用できます。

画像CDNの統合

概要

@nuxt/imageモジュールを使うと、Sirvなどの画像配信CDNと容易に統合できます。画像の自動最適化やレスポンシブ配信が可能になり、ページ表示が速くなります。

導入とインストール

  • インストール例: npm install @nuxt/image
  • nuxt.configでモジュールを有効にします。

基本設定例（nuxt.config）

export default {
  modules: ['@nuxt/image'],
  image: {
    providers: {
      sirv: { baseURL: 'https://your-account.sirv.com' }
    }
  }
}

上記は例です。実際はCDNのベースURLや認証情報を設定してください。

コンポーネントでの利用

<NuxtImg src="/photos/sample.jpg" provider="sirv" width="800" format="webp" alt="説明" />

プロバイダー指定でSirv経由のURLへ変換され、幅に応じた最適な画像が配信されます。

最適化オプションと運用上の注意

  • format（webp等）、qualityを指定して軽量化します。
  • キャッシュ設定はCDN側と合わせて行ってください。ブラウザキャッシュやCDN TTLを適切に設定すると効果が高まります。
  • 事前に画像をSirvへアップロードするか、オリジンプルを利用します。
  • CORSや署名付きURLが必要な場合はCDN側の設定を確認してください。

これらを組み合わせると、画像の最適化と高速配信が実現できます。具体的な設定はプロジェクトやCDNの仕様に合わせて調整してください。

設定ファイルでのプリセット指定

nitro.presetとは

nuxt.config.tsでnitro.presetを指定すると、ビルド出力をデプロイ先に合わせて最適化します。ランタイムやハンドラ形式が変わるため、手作業の調整を減らせます。

設定例

以下は設定の一例です。

export default defineNuxtConfig({
  nitro: {
    preset: 'node-server' // 'vercel', 'netlify', 'cloudflare' など
  }
})

よく使うプリセット例と特長

  • node-server: Node.jsサーバー向け。従来のサーバーで動かすときに使います。
  • vercel / netlify: それぞれのホスティングの関数形式に合わせて出力します。
  • cloudflare: エッジワーカー用の最適化を行います。

選び方のポイント

デプロイ先のドキュメントに合わせて選んでください。たとえばVercelならvercelを選ぶと自動で関数配置が整います。ローカルで動作確認する際は実際の環境に近いプリセットを選ぶと問題を早く見つけられます。

注意点

  • エッジプリセットは一部のNode APIが使えない場合があります。外部モジュールの互換性を確認してください。
  • プリセットを変更したら再ビルドが必要です。

以上がnitro.presetの基本的な使い方です。

＼ 最新情報はInstagramで📲 ／

Instagramを見る

人気投稿

大規模情報サイト運営
cdn nuxt.js
よかったらシェアしてね！
  • URLをコピーしました！

この記事を書いた人

userのアバター user

関連記事

目次