「ホームページをもっと速くしたい」「最新の技術を取り入れたいけど、何から手をつければいいかわからない」──そんなお悩みをお持ちの経営者の方も多いのではないでしょうか。今回は、Webサイト構築の定番フレームワーク「Next.js」の最新ベストプラクティスを、私自身の実務経験も交えてご紹介します。
Next.jsはReactベースのフレームワークとして、世界中の企業サイトやWebサービスで採用されています。2024年から2025年にかけて大きなアップデートが続き、2026年現在ではさらに安定した機能が揃いました。本記事では、その中でも特にビジネス成果に直結しやすい5つのポイントを厳選しています。技術の専門家でなくても理解できるよう、できるだけ平易な言葉でお伝えしますので、ぜひ最後までお付き合いください。
App Routerを標準の設計方針にする
Next.jsには従来の「Pages Router」と、新しい「App Router」という2つの仕組みがあります。簡単に言えば、App Routerはページの表示速度やSEO対策において、より優れた設計ができる仕組みです。
私自身、最初はPages Routerで十分だと思っていたのですが、App Routerに移行してみると、ページの読み込み体感が明らかに変わりました。新規でサイトを立ち上げる場合は、迷わずApp Routerを選ぶことをおすすめします。既存サイトでも段階的に移行できるので、焦る必要はありません。
Pages RouterとApp Routerの違いを整理する
両者の違いをもう少し具体的にお話しします。Pages Routerでは、pages/about.tsxのようにファイルを置けば、そのままURLに対応するページが作られます。シンプルで分かりやすい反面、レイアウトの共有やデータ取得のパターンに制約がありました。
一方、App Routerではapp/about/page.tsxというディレクトリ構造を使います。一見すると少し複雑に思えますが、この構造により「レイアウトの入れ子」が自然にできるようになります。たとえば、ヘッダーとフッターは全ページ共通、サイドバーはブログセクションだけに表示、といった構成を無理なく実現できます。Pages Routerの時代には_app.tsxやgetLayoutパターンなどでやりくりしていたものが、フレームワークの標準機能として整備されたイメージです。
段階的な移行のすすめ
「今動いているサイトをいきなり全部書き換えるのは不安」という声をよくいただきます。その心配はもっともです。実際、私たちが支援したあるクライアント企業では、まずトップページとお問い合わせページだけをApp Routerに移行し、残りのページはPages Routerのまま運用するという方法を取りました。
Next.jsはこの両方を同一プロジェクト内で共存させることが可能です。移行期間中にサイト全体が止まるリスクはありません。まずはアクセスの多い主要ページから着手し、効果を確認しながら段階的に広げていく。この進め方であれば、ビジネスへの影響を最小限に抑えつつ、新しい技術の恩恵を受けることができます。
Parallel RoutesとIntercepting Routesで表現力を高める
App Routerならではの機能として、Parallel Routes（パラレルルート）とIntercepting Routes（インターセプティングルート）があります。
Parallel Routesは、1つの画面内に複数の独立したコンテンツ領域を持たせる仕組みです。たとえば、ダッシュボード画面で「売上グラフ」と「最新の通知一覧」をそれぞれ独立して読み込み・更新できるようになります。一方の読み込みが遅くても、もう一方は先に表示される。ユーザーにとっての体感速度が大きく変わります。
Intercepting Routesは、モーダル（ポップアップ的な表示）の実装に威力を発揮します。写真ギャラリーで画像をクリックしたときに、ページ遷移せずにモーダルで拡大表示しつつ、そのURLを直接開いた場合にはフルページで表示する。こうした「URLとUIの挙動を分離する」表現が、追加のライブラリなしで実現できます。
Server Componentsを活用して表示速度を上げる
Server Components（サーバーコンポーネント）とは、サーバー側でページの中身を組み立ててからブラウザに届ける仕組みです。これにより、ユーザーの端末に送るデータ量が減り、表示が速くなります。
AとBどちらの方法が良いか悩む場面もありましたが、「まずはServer Componentsで作り、どうしても必要な部分だけブラウザ側で動かす」という方針にしてから、開発がとてもスムーズになりました。表示速度の改善はお問い合わせ率にも直結するので、経営面でも見逃せないポイントです。
なぜServer Componentsが速いのか
従来のReactアプリケーションでは、ブラウザがJavaScriptをすべてダウンロードし、そのJavaScriptが画面を組み立てるという流れでした。これは「クライアントサイドレンダリング」と呼ばれる方式で、JavaScriptのファイルが大きくなるほど、初回表示が遅くなるという課題がありました。
Server Componentsでは、サーバー上でHTMLが組み立てられた状態でブラウザに届きます。ブラウザ側で必要なJavaScriptは、ボタンのクリック処理やアニメーションなど、ユーザー操作に反応する部分だけです。あるプロジェクトでは、この切り替えによってブラウザに送信するJavaScriptの量が約40%削減できました。数字だけ聞くとピンとこないかもしれませんが、スマートフォンの3G回線でアクセスしたときの体感が大きく変わります。
Server ComponentsとClient Componentsの使い分け
実務で最もよく聞かれるのが「どこまでをServer Componentsにして、どこからClient Componentsにすればいいのか」という質問です。私自身も最初は手探りでしたが、以下のような判断基準に落ち着きました。
Server Componentsが適しているもの：
- データベースやAPIからデータを取得して表示するだけのコンテンツ
- ブログ記事、製品一覧、会社概要などの静的な情報表示
- ナビゲーションメニューやフッターなど、クリック以外のインタラクションがない部分
Client Componentsが必要なもの：
- フォームの入力状態を管理する部分（文字数カウント、リアルタイムバリデーションなど）
- ドロップダウンメニュー、アコーディオン、タブ切り替えなどのUI操作
- ブラウザのAPIを使う処理（位置情報の取得、ローカルストレージへの保存など）
コツは「Client Componentsの範囲をできるだけ小さくすること」です。ページ全体をClient Componentにするのではなく、インタラクティブな部分だけを小さなClient Componentとして切り出し、それ以外はServer Componentsのままにする。この考え方を「アイランドアーキテクチャ」と呼ぶこともあります。
Streamingで体感速度をさらに改善する
Server Componentsと組み合わせて活用したいのが、Streaming（ストリーミング）という仕組みです。ページ内のすべてのデータが揃うのを待つのではなく、準備ができた部分から順番にブラウザへ送り出す技術です。
たとえば、ECサイトの商品ページを考えてみてください。商品名と価格は即座に表示し、レビュー一覧は外部APIからの取得に少し時間がかかるので、その部分だけローディング表示にしておく。データが届いた瞬間に、ローディングがレビュー一覧に切り替わる。Next.jsではloading.tsxファイルやReactの<Suspense>コンポーネントを使って、この挙動を宣言的に書くことができます。
以前のやり方では「全部のデータが揃うまで白い画面を見せてしまう」か「複雑なローディング制御を自前で実装する」かの二択でした。Streamingのおかげで、ユーザーは待ち時間を意識しにくくなり、結果としてページの離脱率が下がる傾向があります。
Server Actionsでフォーム処理をシンプルにする
お問い合わせフォームや予約フォームなど、ユーザーが情報を送信する仕組みは、どのサイトにも欠かせません。Server Actionsを使うと、このデータ送信の処理を驚くほどシンプルに書けるようになります。
振り返ると、以前は別途APIを用意して複雑な構成にしていたのが遠回りでした。コードが簡潔になれば保守コストも下がりますし、不具合も起きにくくなります。同じように開発の複雑さに悩んでいる方には、ぜひ試していただきたい機能です。
従来のフォーム処理との比較
Server Actionsが登場する以前、フォームの送信処理は次のようなステップを踏むのが一般的でした。
- フロントエンド側でフォームデータを収集する
fetchやaxiosでAPIエンドポイントにリクエストを送る- バックエンド側でAPIルート（
/api/contactなど）を作成してリクエストを受け取る - データのバリデーション（入力チェック）を行う
- データベースに保存したり、メールを送信したりする
- レスポンスをフロントエンドに返す
- フロントエンド側でレスポンスを受け取り、成功・失敗の表示を切り替える
Server Actionsでは、このうち2と3のステップが丸ごと不要になります。フォームの送信先として、サーバー側で実行される関数を直接指定できるのです。APIルートのファイルを別途作成する必要がなくなり、「フォームの見た目」と「送信後の処理」が1つの流れとして見通せるようになります。
セキュリティ面での安心感
「サーバー側の処理をフロントエンドのコードに直接書いて大丈夫なのか」と不安に思われるかもしれません。これはもっともな疑問です。
実際には、Server Actionsの関数は"use server"というディレクティブで明示的にマークされ、ビルド時にサーバー側のコードとして分離されます。ブラウザに送られるのは「この関数を呼び出すためのリファレンス」だけであり、関数の中身（データベース接続情報やビジネスロジック）がユーザーに見えることはありません。
加えて、Next.jsはServer Actionsに対してCSRF（クロスサイトリクエストフォージェリ）対策を自動的に適用します。開発者が意識しなくても、一定のセキュリティ水準が確保される設計になっています。もちろん、入力値のバリデーションやサニタイゼーションは開発者の責任で行う必要がありますが、インフラレベルの防御を自前で構築する手間が省けるのは大きなメリットです。
Progressive Enhancementへの対応
Server Actionsのもう一つの利点として、Progressive Enhancement（プログレッシブエンハンスメント）への対応があります。これは、JavaScriptが何らかの理由で動作しない環境でも、フォームの基本的な送信機能が維持されるという考え方です。
Server Actionsを使ったフォームは、HTML標準の<form>タグの仕組みに基づいて動作します。JavaScriptが有効な環境ではページ遷移なしにスムーズに送信され、無効な環境でもページリロードを伴いつつ正常に処理が完了します。すべてのユーザーに対して確実にサービスを届けるという意味で、ビジネス上の機会損失を減らすことにつながります。
Metadata APIでSEO対策を確実に行う
検索エンジンに正しくサイトの情報を伝えるには、タイトルや説明文といった「メタデータ」の設定が欠かせません。Next.jsのMetadata APIを使えば、ページごとのメタデータをコード上で一元管理できます。
最初は見落としていたのですが、この設定を丁寧に行うだけで検索順位が改善したケースもありました。技術的には小さな作業でも、ビジネスへの影響は大きいかもしれません。
静的メタデータと動的メタデータ
Metadata APIには大きく分けて2つの使い方があります。「静的メタデータ」と「動的メタデータ」です。
静的メタデータは、会社概要ページやサービス紹介ページなど、内容が固定されたページに適しています。コード内に直接タイトルや説明文を記述するだけで設定完了です。シンプルですが、ページ数が増えてもそれぞれのページに最適化されたメタデータを持たせられるため、SEO上の効果は確実です。
動的メタデータは、ブログ記事や商品ページなど、コンテンツに応じてメタデータが変わるページに使います。データベースやCMSから取得した情報をもとに、ページタイトルや説明文を自動生成します。たとえば、ブログ記事のタイトルをそのままページタイトルに、冒頭の120文字をdescriptionに設定する、といった処理が数行のコードで実現できます。
Open Graphとソーシャルメディア対策
Metadata APIでぜひ活用していただきたいのが、Open Graph（OG）タグの設定です。これはFacebook、X（旧Twitter）、LINEなどでURLが共有されたときに、どのような画像・タイトル・説明文が表示されるかを制御するための仕組みです。
SNSでの記事シェアは、特にBtoBの企業サイトにおいても無視できない流入経路です。OGタグが未設定のままだと、URLだけが素っ気なく表示され、クリックされる可能性が大幅に下がります。一方、適切な画像とキャッチコピーが表示されれば、目に留まりやすくなります。
Next.jsのMetadata APIでは、OGタグの設定もページごとに行えます。さらに、opengraph-image.tsxというファイルを作成すれば、OG画像をプログラムで動的に生成することも可能です。ブログ記事ごとに異なるOG画像を自動生成し、記事タイトルを画像上にレンダリングする。これはSNS上での視認性を高める上でかなり有効な施策です。
構造化データ（JSON-LD）との組み合わせ
メタデータの設定と合わせて検討したいのが、構造化データ（JSON-LD）の導入です。構造化データとは、検索エンジンがページの内容を機械的に理解しやすいよう、決まった形式で情報を記述する仕組みです。
たとえば、企業情報ページに「Organization」の構造化データを埋め込むと、Google検索結果に会社名、ロゴ、所在地などがリッチに表示される可能性があります。FAQページに「FAQPage」の構造化データを入れれば、検索結果にQ&Aが直接表示される「リッチリザルト」の対象になることもあります。
Next.jsでは、<script type="application/ld+json">タグをServer Components内に直接記述できるため、構造化データの導入もスムーズです。Metadata APIと構造化データを組み合わせることで、検索エンジンに対して「このページは何について書かれていて、どのような情報を含んでいるか」を正確に伝えられるようになります。地道な作業ではありますが、検索流入を安定的に増やすための基盤として、取り組む価値のある施策です。
画像最適化で離脱率を下げる
Next.jsに標準搭載されている画像最適化機能（next/image）は、画像を自動的に圧縮し、画面サイズに合ったサイズで配信してくれます。一概には言えない部分もありますが、画像の読み込みが遅いサイトはユーザーの離脱率が高くなる傾向があります。
設定自体は難しくないので、まだ導入されていない場合は優先的に取り組む価値があると感じています。特にスマートフォンからのアクセスが多いサイトでは効果を実感しやすいのではないでしょうか。
next/imageが行っている最適化の中身
next/imageコンポーネントが裏側で行っている処理を、もう少し詳しく見てみましょう。主に以下の4つの最適化が自動的に適用されます。
フォーマットの自動変換： ブラウザが対応していれば、画像をWebPやAVIFといった次世代フォーマットに自動変換します。JPEGと比較して、同等の画質で30〜50%程度ファイルサイズが小さくなることがあります。開発者がフォーマットごとに画像を用意する必要はありません。
リサイズ： 元画像が3000×2000ピクセルだったとしても、表示サイズに合わせて適切な解像度の画像を生成します。スマートフォンの小さな画面に、デスクトップ向けの巨大な画像をそのまま送りつけるような無駄がなくなります。
遅延読み込み（Lazy Loading）： 画面に表示される直前のタイミングで画像を読み込みます。ページ下部にある画像は、ユーザーがスクロールして近づくまで読み込まれないため、初回表示に必要なデータ量が大幅に減ります。
レイアウトシフトの防止： 画像の読み込み完了前に、あらかじめ画像の表示領域を確保しておきます。これにより、画像が読み込まれたときにページのレイアウトがガタッとずれる現象（CLS：Cumulative Layout Shift）を防ぐことができます。
実装時に気をつけたいポイント
next/imageは非常に便利ですが、初めて使うときにいくつか戸惑いやすい点があります。私自身がつまずいた経験をもとに、注意点をお伝えします。
まず、widthとheightの指定です。next/imageでは原則としてこの2つの値を明示する必要があります。これはレイアウトシフトを防ぐために画像のアスペクト比を事前に把握する仕組みになっているためです。動的に画像を取得する場合はfillプロパティを使い、親要素のサイズに合わせて画像を表示する方法もあります。
次に、外部ドメインの画像を扱う場合です。CMSや外部サービスから配信される画像を表示するには、next.config.jsのimages.remotePatternsに許可するドメインを登録する必要があります。この設定を忘れると画像が表示されず、原因が分かりにくいエラーになることがあります。
最後に、ファーストビュー（最初に表示される領域）の画像にはpriorityプロパティを付けることをおすすめします。これにより遅延読み込みが無効になり、ページの表示と同時に画像が読み込まれます。メインビジュアルやヒーロー画像など、最初に目に入る画像はこの設定で表示速度を優先させるのが定石です。
Core Web Vitalsへのインパクト
画像最適化の効果は、Core Web Vitals（コアウェブバイタル）というGoogleが定める指標で定量的に測定できます。特に影響が大きいのは以下の2つです。
LCP（Largest Contentful Paint）： ページ内で最も大きなコンテンツが表示されるまでの時間です。多くのページでは、最も大きなコンテンツがメインビジュアルの画像です。next/imageの最適化とpriorityの設定により、この数値を改善できます。
CLS（Cumulative Layout Shift）： ページの読み込み中にレイアウトが予期せずずれる度合いです。width・heightの明示指定やplaceholder機能により、画像周りのCLSはほぼゼロに抑えられます。
Core Web Vitalsは2021年からGoogleの検索ランキング要因のひとつになっています。直接的な順位変動への影響度は様々な議論がありますが、ユーザー体験の指標として重視されていることは間違いありません。画像最適化はこれらの数値を改善する最も手軽で効果の大きい施策のひとつです。
パフォーマンス計測と継続的な改善
ここまで5つのベストプラクティスをご紹介してきましたが、施策を導入しただけで安心してしまうのはもったいない、というのが正直な実感です。効果を最大化するには、計測と改善のサイクルを回すことが大切です。
Lighthouseによる定期チェック
Googleが提供する「Lighthouse」は、Webページのパフォーマンス・アクセシビリティ・SEOなどを自動的にスコアリングしてくれるツールです。Chrome DevToolsから手軽に実行でき、具体的な改善提案まで示してくれます。
月に一度でもLighthouseでスコアを確認する習慣をつけておくと、知らぬ間にパフォーマンスが劣化していた、という事態を防げます。新しいページを追加したとき、大きな画像を差し替えたとき、外部スクリプトを埋め込んだとき。こうしたタイミングで計測しておくと、問題の早期発見につながります。
Next.jsのビルトインアナリティクス
Next.jsには@next/bundle-analyzerというパッケージがあり、ビルドされたJavaScriptのバンドルサイズを視覚的に確認できます。「どのライブラリがどれだけのサイズを占めているか」が一目でわかるため、不要なライブラリの除去やコード分割の判断に役立ちます。
また、next/headersやnext/navigationといったNext.js標準の機能を使うことで、サードパーティ製のライブラリを削減できる場面も多くあります。依存パッケージが減れば、バンドルサイズが小さくなるだけでなく、セキュリティリスクの低減やアップデートの手間削減にもつながります。
まとめ
今回ご紹介した5つのベストプラクティスは、どれも「サイトの表示速度」と「開発のしやすさ」を両立するためのものです。すべてを一度に導入する必要はなく、できるところから少しずつ取り入れていくのが現実的だと思います。
改めて、5つのポイントを振り返ります。
- App Routerを標準の設計方針にする ── 新規プロジェクトではApp Router一択。既存サイトも段階的に移行可能
- Server Componentsを活用して表示速度を上げる ── 「まずサーバー、必要な部分だけクライアント」の原則で設計する
- Server Actionsでフォーム処理をシンプルにする ── API層の構築コストを削減し、コードの見通しを良くする
- Metadata APIでSEO対策を確実に行う ── OGタグや構造化データと組み合わせ、検索エンジンとSNSの両方に最適化する
- 画像最適化で離脱率を下げる ── next/imageの標準機能だけで、Core Web Vitalsの大幅な改善が見込める
そして何より大切なのは、導入した後も計測と改善を続けることです。技術は日々進化しますが、「ユーザーにとって快適な体験を届ける」という目的は変わりません。
自社サイトのNext.js活用や技術的なご相談がありましたら、aduceのお問い合わせはこちらからお気軽にご連絡ください。現状の課題整理から技術選定、実装支援まで、一貫してお手伝いいたします。