遅いNext.js画面を改善する診断ポイント
「Lighthouseのスコアが真っ赤」「営業画面が開くまで数秒待たされる」「モバイルだと特に重い」——Next.jsでフロントを作った既存サービスの運用担当者から、こうした相談をよく受けます。表示速度はデザインの好みと違って数値で優劣がはっきり出るため、放置しているとCVRや継続利用率にじわじわ効いてきます。
厄介なのは、「Next.jsを使っているから速いはず」という思い込みです。Next.jsはSSRやコード分割など高速化の仕組みを備えたフレームワークですが、それはあくまで「正しく使えば」の話です。この記事では、Next.jsの画面が遅いと感じたときに私たちが実際に行う計測・診断の手順と、典型的な原因、改善の優先順位を発注者にも分かる言葉で整理します。
まず計測して「何が」「どれだけ」遅いかを数値化する
改善に着手する前に、感覚ではなく指標で状態を把握します。ここを飛ばすと「なんとなく画像を圧縮した」「なんとなくライブラリを削った」で工数だけ消費して終わります。
- Lighthouse(Chrome DevTools標準搭載)でスコアを取る。Performance・Accessibility・Best Practices・SEOの4指標のうち、まずPerformanceに注目します。モバイル回線を模したスロットリング環境でのスコアが重要で、開発者が使う高速な光回線・ハイスペックPCでの体感とは大きく乖離します。
- Core Web Vitalsの3指標を個別に見る。LCP(Largest Contentful Paint = メインコンテンツが表示されるまでの時間、目安2.5秒以内)、INP(Interaction to Next Paint = 操作への応答性、200ms以内)、CLS(Cumulative Layout Shift = レイアウトのガタつき、0.1以内)。3つは原因も対処法も別物なので、「遅い」を一つに丸めず分解します。
- 本番相当のデータ量・実際のネットワーク条件で計測する。開発環境や少量データでは再現しないことが多く、本番のAPIレスポンス量・画像枚数で見て初めて実態が分かります。
- Real User Monitoring(RUM)があれば実ユーザーの分布を見る。VercelのSpeed InsightsやGoogle Search ConsoleのCore Web Vitalsレポートは、実際のユーザー環境(回線・端末)での分布を教えてくれます。開発者の手元計測と乖離しているケースは珍しくありません。
この段階で「どのページの」「どの指標が」「どれくらい悪いか」が数値で揃えば、次の原因調査に進めます。既存プロダクトの改善に着手する際にまず見るべき観点は、既存プロダクトの改善、外部チームが最初に見る観点でも整理しているので、着手前に合わせて確認してください。
典型的な原因のパターン
計測結果を見ていくと、Next.jsの遅さは主に5つのパターンに集約されます。
レンダリング戦略の選択ミス
Next.jsにはSSR(サーバーサイドレンダリング)・SSG(静的生成)・ISR(差分再生成)・CSR(クライアントサイドレンダリング)と複数の描画方式があり、ページの性質に合わない方式を選んでいると顕著に遅くなります。頻繁に更新されない一覧ページを毎回SSRしてDBアクセスから待たせている、逆に更新頻度の高いダッシュボードを静的化できずCSRで全部クライアント側のuseEffect任せにしていて初期表示が真っ白、といったケースがよくあります。App Router移行前のPages RouterではgetServerSidePropsをとりあえず全ページに付けて回っている実装も散見されます。
JavaScriptバンドルの肥大化
日付処理・アイコン・チャートライブラリなど、一部の機能でしか使わないライブラリを全ページ共通のバンドルに含めてしまい、初期ロードのJS量が膨れているケースです。特にモーメント系ライブラリやUIコンポーネントキットを丸ごとimportしている、tree shakingが効かない書き方でimportしている、といったパターンが多く見られます。next build時のバンドルアナライザー(@next/bundle-analyzer)でページごとのJSサイズを可視化すると、どのページのどのモジュールが重いかすぐに特定できます。
画像の未最適化
next/imageを使わず素の<img>タグで実装している、画像サイズを指定せず表示崩れ(CLS悪化)を招いている、あるいはオリジナルサイズの画像をそのまま配信しているケースです。LCPが悪いページの多くは、ファーストビューの画像が原因になっています。next/imageは自動でWebP変換・遅延読み込み・レスポンシブサイズ出し分けを行いますが、既存コードで使われていない、あるいはpriority属性の付け忘れでLCP対象の画像が遅延読み込みされてしまっている、という細かい設定ミスも頻出です。
データ取得のウォーターフォール
コンポーネントごとにバラバラにfetchやuseEffectでAPIを呼んでいて、親の取得が終わってから子の取得が始まる、という直列の待ち行列(ウォーターフォール)が発生しているケースです。1つのAPIが200msでも、直列に5つ並ぶと1秒になります。React ServerComponentsやApp RouterのStreaming、あるいはPromise.allでの並列化ができていない実装で頻発します。
サードパーティスクリプトの重さ
広告タグ・チャットウィジェット・アクセス解析・A/Bテストツールなど、複数のサードパーティスクリプトを<head>で同期読み込みしていて、メインコンテンツの描画をブロックしているケースです。導入時は1つずつでも、運用を重ねるうちに5個、10個と積み重なり、気づけばサードパーティだけでLCPの半分を占めていた、という状態は珍しくありません。next/scriptのstrategy(lazyOnloadやafterInteractive)を使い分けずに全部デフォルト読み込みにしていると起きがちです。
改善の優先順位
原因が特定できたら、投資対効果の高いものから着手します。
- 画像最適化:
next/imageへの置き換え、ファーストビュー画像へのpriority付与。実装コストが低く、LCP改善への効果が大きいため最優先です。 - サードパーティスクリプトの読み込み方式見直し:
next/scriptのstrategyを用途に応じて設定するだけで、大きなコード変更なしにブロッキングを解消できます。 - データ取得の並列化: ウォーターフォールを
Promise.allや並列fetchに直す。ページごとに個別対応が必要ですが、影響ページが広く効果も大きい部類です。 - バンドル分割・不要ライブラリの削減: バンドルアナライザーで特定した重いモジュールを動的import(
next/dynamic)に切り出す、あるいは軽量な代替ライブラリに置き換える。 - レンダリング戦略の見直し: ページ単位でSSR/SSG/ISR/CSRを再選定する。既存の実装への影響範囲が最も広く、慎重な設計とテストが必要なため優先度としては最後に回すことが多いですが、根本原因がここにある場合は避けて通れません。
App Router移行との関係
Pages RouterからApp Routerへの移行は、それ自体が速度改善の目的化しやすいですが、慎重に判断すべきです。App RouterはReact Server Componentsによるサーバー側でのデータ取得・ストリーミングなど、レンダリング戦略の選択肢を広げる一方、移行自体に相応の工数がかかり、移行中に別のバグを埋め込むリスクもあります。
私たちが提案する順番は、まず計測して原因を特定し、Pages Routerのままでも直せる問題(画像・スクリプト・データ取得の並列化)を先に潰すことです。それでも解決しない構造的な遅さ——例えばレンダリング戦略そのものの限界——が残る場合に、初めてApp Router移行を検討します。移行を伴う改修を外部に依頼する際の進め方は、Next.jsのリファクタリングを外注するで詳しく解説しています。
外注時に確認すべきこと
パフォーマンス改善を外部に依頼する場合、着手前に次の点を発注者側でも押さえておくと成果がぶれにくくなります。
- Core Web Vitalsの数値目標を事前に合意する。「速くする」ではなく「LCPを4.2秒から2.0秒以内にする」のように、指標と数値で握る。
- 改善前後を同一条件(データ量・回線シミュレーション)で計測してもらう。Lighthouseは実行のたびに多少ぶれるため、複数回計測した中央値で比較するのが望ましいです。
- App Router移行を安易に提案されたら理由を確認する。移行自体が目的化していないか、計測に基づく原因特定が先にあるかを聞く。
- 段階的にリリースしてもらう。レンダリング戦略の変更は挙動が大きく変わるため、一部ページ・一部トラフィックへの適用から始めて安全に検証するのが基本です。
私たちが改善支援に入る際も、最初の1〜2週間は計測と原因の切り分けにあて、Before/Afterの数値を明示したうえで改善の優先順位を提案します。原因が曖昧なまま「とりあえずApp Routerに移行しましょう」とは言いません。
まとめ
- Next.jsの遅さは思い込みではなく、Lighthouse・Core Web VitalsでLCP/INP/CLSを個別に計測し数値で原因を特定するところから始めます。
- 原因はレンダリング戦略のミス・バンドル肥大・画像未最適化・データ取得のウォーターフォール・サードパーティスクリプトの重さに大別され、画像とスクリプトの見直しは投資対効果が高く着手しやすい打ち手です。
- App Router移行は速度改善の万能薬ではなく、計測で他の原因を潰したうえで根本的な限界が残る場合に検討すべき選択肢です。
torcheeesでは、既存プロダクトのパフォーマンス診断から、原因特定を踏まえた改善支援まで対応しています。まずは現状のNext.js画面がどこで遅くなっているか、無料相談で状況をお聞かせください。お問い合わせはこちら。改善支援の詳細はプロダクト改善・モダナイゼーション支援、対応技術はフロントエンド技術をご覧ください。