クライアントに送られる JavaScript を減らしたい。何から手をつけますか。
まず計測します。当てずっぽうで軽量ライブラリに差し替えても効かないことが多いためです。なお Next.js 16 では、ビルド出力からルートごとのサイズ表示が無くなっています。
面接官が見ているのは計測から入れるか。
よくある答えと、面談でどう見られるか
- まず計測して、重いルートを特定してから手を入れる
順序として正しいです。ただし道具に注意が要ります。next build の出力にあったサイズと First Load JS は Next.js 16 で削除されました。現在は bundle analyzer か Lighthouse を使います。 - 使っているライブラリを軽いものに置き換える
効くこともありますが、順序が逆です。まず何が重いかを見ないと、効かない作業に時間を使います。 - クライアント境界の位置を見直して、下げられないか確認する
効果が大きいのはたいていこれです。境界が1枚上にあるだけで下の依存が丸ごと乗ります。 - すべてのコンポーネントを遅延読み込みにする
初期表示に必要なものまで遅らせると、かえって遅くなります。分割の粒度を間違えると、リクエストが増えるだけです。
面接官は何を見ているか
- まず現状を計測しようとした
- どのルートが重いかを特定する発想があった
- 'use client' の位置を見直す案を持っていた
模範解答
まず計測します。当てずっぽうで軽量ライブラリに差し替えても、効かないことが多いためです。
ここは道具がバージョンで変わったので注意が要ります。以前は next build の出力にルートごとのサイズと First Load JS が並んでいて、それを見れば重いルートが分かりました。Next.js 16 でこの2つの指標は削除されています。公式の説明は「Server Components を使う構成では不正確だと分かったため」で、Turbopack と Webpack で数字が食い違っていたことも理由に挙げられています。
現在の計測手段は2つです。バンドルの中身を見るなら bundle analyzer、実際のページ性能を見るなら Lighthouse のようなCore Web Vitals と実ダウンロード量を測るツールです。公式もこの2つを案内しています。
重いルートが分かったら、見る順番は3つです。1つ目は 'use client' の位置で、必要以上に上に付いていれば下げます。2つ目は重いライブラリで、Client Component 側から使っているものがあれば、サーバー側に寄せられないかを考えます。3つ目は、初期表示に不要なものを遅延読み込みに回すことです。
効果が大きいのはたいてい1つ目です。境界が1枚上にあるだけで、その下の依存が丸ごと乗ってしまうためです。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
一部しか触れられなかった場合
JavaScript が多いと、具体的に何が悪いのですか。触れられなかった場合
JavaScript が多いと、具体的に何が悪いのですか。