Next.js 14

claudejamodel: claude-sonnet-4-20250514

Next.js 14

2023年10月26日（木）に投稿投稿者: Lee Robinson (@leerob)、Tim Neutkens (@timneutkens)

Next.js Confで発表したとおり、Next.js 14は最も集中的なリリースです：

主な機能

Turbopack

App & Pages Routerで5,000のテストが通過
ローカルサーバー起動が53%高速化
Fast Refreshによるコード更新が94%高速化

Server Actions（安定版）

プログレッシブエンハンスメントによるミューテーション
キャッシュと再検証との統合
シンプルな関数呼び出し、またはフォームとのネイティブ連携

Partial Prerendering（プレビュー）

高速な初期静的レスポンス + ストリーミング動的コンテンツ

Next.js Learn（新機能）

App Router、認証、データベースなどを教える無料コース

アップグレード方法

今すぐアップグレードするか、以下のコマンドで開始してください：

npx create-next-app@latest

Next.jsコンパイラ：ターボチャージ

Next.js 13以降、PagesとApp Routerの両方でNext.jsのローカル開発パフォーマンスの改善に取り組んできました。以前はnext devやNext.jsの他の部分を書き直してこの取り組みをサポートしていました。その後、よりインクリメンタルなアプローチに変更しました。これにより、すべてのNext.js機能を最初にサポートすることに再集中したため、Rustベースのコンパイラは間もなく安定版に到達します。

基盤となるRustエンジンであるTurbopackで、next devの5,000の統合テストが通過しています。これらのテストには7年間のバグ修正と再現が含まれています。

大規模なNext.jsアプリケーションであるvercel.comでのテストでは、以下の結果が得られました：

ローカルサーバー起動が最大53.3%高速化
Fast Refreshによるコード更新が最大94.7%高速化

このベンチマークは、大規模なアプリケーション（および大規模なモジュールグラフ）で期待できるパフォーマンス改善の実用的な結果です。

next devのテストの90%が通過しているため、next dev --turboを使用する際により高速で信頼性の高いパフォーマンスが一貫して見られるはずです。

テストの100%が通過したら、今後のマイナーリリースでTurbopackを安定版に移行します。また、カスタム設定とエコシステムプラグインでのwebpackの使用も引き続きサポートします。

テスト通過率はareweturboyet.comで確認できます。

フォームとミューテーション

Next.js 9ではAPI Routesが導入されました。これは、フロントエンドコードと並行してバックエンドエンドポイントを素早く構築する方法です。例えば、api/ディレクトリに新しいファイルを作成します：

// pages/api/submit.ts
import type { NextApiRequest, NextApiResponse } from 'next';

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse,
) {
  const data = req.body;
  const id = await createItem(data);
  res.status(200).json({ id });
}

その後、クライアント側では、ReactとonSubmitのようなイベントハンドラーを使用してAPI Routeにfetchを行うことができます。

// pages/index.tsx
import { FormEvent } from 'react';

export default function Page() {
  async function onSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
    const formData = new FormData(event.currentTarget);
    const response = await fetch('/api/submit', {
      method: 'POST',
      body: formData,
    });
    // 必要に応じてレスポンスを処理
    const data = await response.json();
    // ...
  }

  return (
    <form onSubmit={onSubmit}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

Next.js 14では、データミューテーションの作成における開発者体験を簡素化したいと考えています。さらに、ユーザーのネットワーク接続が遅い場合や、低性能デバイスからフォームを送信する場合のユーザー体験を改善したいと考えています。

Server Actions（安定版）

API Routeを手動で作成する必要がなかったらどうでしょうか？代わりに、Reactコンポーネントから直接呼び出せる、サーバー上で安全に実行される関数を定義できます。

App RouterはReact canaryチャンネル上に構築されており、フレームワークが新機能を採用するのに安定しています。v14の時点で、Next.jsは安定したServer Actionsを含む最新のReact canaryにアップグレードしました。

Pages Routerの前の例は、1つのファイルに簡素化できます：

// app/page.tsx
export default function Page() {
  async function create(formData: FormData) {
    'use server';
    const id = await createItem(formData);
  }

  return (
    <form action={create}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

Server Actionsは、過去にサーバー中心のフレームワークを使用したことがある開発者にとって馴染みやすいものです。フォームやFormData Web APIなどのWeb基盤上に構築されています。

フォームを通じてServer Actionsを使用することはプログレッシブエンハンスメントに役立ちますが、必須ではありません。フォームなしで関数として直接呼び出すこともできます。

TypeScriptを使用する場合、クライアントとサーバー間で完全なエンドツーエンドの型安全性が得られます。

データの変更、ページの再レンダリング、またはリダイレクトは1回のネットワークラウンドトリップで実行でき、上流プロバイダーが遅い場合でも、正しいデータがクライアントに表示されることが保証されます。

さらに、同じルート内の多くの異なるアクションを含め、異なるアクションを構成して再利用できます。

キャッシュ、再検証、リダイレクトなど

Server Actionsは、App Routerモデル全体と深く統合されています。以下のことができます：

revalidatePath()またはrevalidateTag()でキャッシュされたデータを再検証
redirect()で異なるルートにリダイレクト
cookies()でCookieを設定・読み取り
useOptimistic()で楽観的UI更新を処理
useFormState()でサーバーからのエラーをキャッチして表示
useFormStatus()でクライアントでローディング状態を表示

Server ActionsによるフォームとミューテーションやServer ComponentsとServer Actionsのセキュリティモデルとベストプラクティスについて詳しく学んでください。

Partial Prerendering（プレビュー）

Next.js向けに取り組んでいるPartial Prerenderingのプレビューを共有したいと思います。これは、高速な初期静的レスポンスを持つ動的コンテンツのコンパイラ最適化です。

Partial Prerenderingは、サーバーサイドレンダリング（SSR）、静的サイト生成（SSG）、インクリメンタル静的再検証（ISR）への10年間の研究開発に基づいて構築されています。

動機

皆様のフィードバックを聞いています。現在、考慮すべきランタイム、設定オプション、レンダリング方法が多すぎます。完全に動的でパーソナライズされたレスポンスをサポートしながら、静的の速度と信頼性も求めています。

グローバルで優れたパフォーマンスとパーソナライゼーションは、複雑さを犠牲にすべきではありません。

私たちの課題は、開発者が学ぶべき新しいAPIを導入することなく、既存のモデルを簡素化して、より良い開発者体験を作ることでした。

サーバーサイドコンテンツの部分キャッシュは存在していましたが、これらのアプローチは、私たちが目指す開発者体験と構成可能性の目標を満たす必要があります。

Partial Prerenderingは学ぶべき新しいAPIを必要としません。

React Suspense上に構築

Partial PrerenderingはSuspense境界によって定義されます。動作方法は以下のとおりです。

以下のeコマースページを考えてみましょう：

// app/page.tsx
export default function Page() {
  return (
    <main>
      <header>
        <h1>My Store</h1>
        <Suspense fallback={<CartSkeleton />}>
          <ShoppingCart />
        </Suspense>
      </header>
      <Banner />
      <Suspense fallback={<ProductListSkeleton />}>
        <Recommendations />
      </Suspense>
      <NewProducts />
    </main>
  );
}

Partial Prerenderingが有効になっている場合、このページは<Suspense />境界に基づいて静的シェルを生成します。React Suspenseのfallbackが事前レンダリングされます。

シェル内のSuspense fallbackは、Cookieを読み取ってカートを決定したり、ユーザーに基づいてバナーを表示したりするような動的コンポーネントに置き換えられます。

リクエストが行われると、静的HTMLシェルが即座に提供されます：

<main>
  <header>
    <h1>My Store</h1>
    <div class="cart-skeleton">
      <!-- Hole -->
    </div>
  </header>
  <div class="banner" />
  <div class="product-list-skeleton">
    <!-- Hole -->
  </div>
  <section class="new-products" />
</main>

<ShoppingCart />はユーザーセッションを確認するためにCookieから読み取るため、このコンポーネントは静的シェルと同じHTTPリクエストの一部としてストリーミングされます。追加のネットワークラウンドトリップは必要ありません。

// app/cart.tsx
import { cookies } from 'next/headers'

export default function ShoppingCart() {
  const cookieStore = cookies()
  const session = cookieStore.get('session')
  return ...
}

最も細かい静的シェルを持つには、追加のSuspense境界を追加する必要がある場合があります。ただし、今日すでにloading.jsを使用している場合、これは暗黙のSuspense境界であるため、静的シェルを生成するために変更は必要ありません。

近日公開

Partial prerenderingは活発に開発中です。今後のマイナーリリースでより多くの更新を共有します。

メタデータの改善

ページコンテンツをサーバーからストリーミングする前に、ビューポート、カラースキーム、テーマに関する重要なメタデータを最初にブラウザに送信する必要があります。

これらのメタタグが初期ページコンテンツと一緒に送信されることを保証することで、テーマカラーの変更によるページのちらつきや、ビューポートの変更によるレイアウトのシフトを防ぎ、スムーズなユーザー体験を実現します。

Next.js 14では、ブロッキングメタデータと非ブロッキングメタデータを分離しました。メタデータオプションの小さなサブセットのみがブロッキングであり、非ブロッキングメタデータが部分的に事前レンダリングされたページの静的シェルの提供を妨げないようにしたいと考えています。

以下のメタデータオプションは非推奨となり、将来のメジャーバージョンでメタデータから削除されます：

viewport：ビューポートの初期ズームとその他のプロパティを設定
colorScheme：ビューポートのサポートモード（light/dark）を設定
themeColor：ビューポート周辺のクロームがレンダリングする色を設定

Next.js 14以降、これらのオプションを置き換える新しいオプションviewportとgenerateViewportがあります。他のすべてのメタデータオプションは同じままです。

今日からこれらの新しいAPIの採用を開始できます。既存のメタデータオプションは引き続き動作します。

Next.js Learnコース

本日、Next.js Learnで全く新しい無料コースをリリースします。このコースでは以下を教えます：

Next.js App Router
スタイリングとTailwind CSS
フォントと画像の最適化
レイアウトとページの作成
ページ間のナビゲーション
PostgreSQLデータベースのセットアップ
Server Componentsでのデータフェッチ
静的および動的レンダリング
ストリーミング
Partial Prerendering（オプション）
検索とページネーションの追加
データの変更
エラーハンドリング
アクセシビリティの改善
認証の追加
メタデータの追加

Next.js Learnは何百万人もの開発者にフレームワークの基礎を教えており、新しい追加についての皆様のフィードバックをお待ちしています。

コースを受講するには、nextjs.org/learnにアクセスしてください。

その他の変更

[破壊的変更] 最小Node.jsバージョンが18.17になりました
[破壊的変更] next-swcビルドのWASMターゲットを削除（PR）
[破壊的変更] next/fontを優先して@next/fontのサポートを終了（Codemod）
[破壊的変更] ImageResponseのインポートをnext/serverからnext/ogに変更（Codemod）
[破壊的変更] next exportコマンドを削除し、output: 'export'設定を優先（Docs）
[非推奨] next/imageのonLoadingCompleteを非推奨とし、onLoadを優先
[非推奨] next/imageのdomainsを非推奨とし、remotePatternsを優先
[機能] fetchキャッシュに関するより詳細なログを有効化可能（Docs）
[改善] 基本的なcreate-next-appアプリケーションの関数サイズが80%削減
[改善] 開発時にedge runtimeを使用する際のメモリ管理を強化

貢献者

Next.jsは、2,900人を超える個人開発者、GoogleやMetaなどの業界パートナー、そしてVercelのコアチームの共同作業の結果です。

GitHub Discussions、Reddit、Discordでコミュニティに参加してください。

このリリースは以下の方々によってもたらされました：

Next.jsチーム: Andrew、Balazs、Jiachi、Jimmy、JJ、Josh、Sebastian、Shu、Steven、Tim、Wyatt、Zack

Turbopackチーム: Donny、Just

要約

Summary

Key Points

Turbopack

Server Actions（安定版）

Partial Prerendering（プレビュー）

その他の改善

翻訳

Next.js 14

主な機能

Turbopack

Server Actions（安定版）

Partial Prerendering（プレビュー）

Next.js Learn（新機能）

アップグレード方法

Next.jsコンパイラ：ターボチャージ

フォームとミューテーション

Server Actions（安定版）

キャッシュ、再検証、リダイレクトなど

Partial Prerendering（プレビュー）

動機

React Suspense上に構築

近日公開

メタデータの改善

Next.js Learnコース

その他の変更

貢献者