「JavaScript重視のアプローチは、長期的なパフォーマンス目標と両立しない」——Automattic社のパフォーマンスチームに所属するSérgio Gomes氏のこの主張が、Web開発コミュニティで大きな反響を呼んでいます。React全盛の時代に一石を投じる内容で、Hacker Newsでも活発な議論が展開されました。

JS-heavyアプローチとは

Gomes氏が指す「JS-heavyアプローチ」とは、大量のJavaScriptをブラウザに送り込み、クライアント側で実行することに依存する開発手法のことです。SPA（Single Page Application）が典型ですが、MPA（Multi Page Application）でも同じ問題が発生することがあります。

フレームワークの約束と現実

ReactなどのフレームワークはDX（Developer Experience）の向上を約束してきました。「モダンなスタックを使えば、アジャイルに開発でき、バグも少なく、メンテナンスしやすいコードが書ける」というのが、長年語られてきたストーリーでしょう。

しかしGomes氏の経験では、この恩恵がユーザーに還元されることは稀だったそうです。むしろ、バンドルサイズの肥大化、不要な再レンダリング、読み込み時間の増加といった問題が、プロジェクトの成長とともに蓄積していく傾向があったと報告しています。

なぜ長期的に悪化するのか

個人的にこの問題は身に覚えがあります。チームが小さいうちは適切にパフォーマンスを管理できても、人数が増え機能が追加されるにつれ、JSバンドルは膨らんでいきます。「あとで最適化しよう」と思いつつ、結局手を付けられないまま放置されるケースを何度も見てきました。

Gomes氏は、フレームワーク自体が悪いわけではなく、「JSをクライアントに大量に送る」というアーキテクチャの根本的な構造に問題があると指摘しています。サーバーサイドで処理できることをわざわざクライアントに委ねる設計は、長期的に見てパフォーマンスの負債になりやすいのです。

サーバーサイド回帰の流れ

この議論は、Next.jsのServer Components、Astro、HTMXといったサーバーサイド重視のアプローチが注目を集めている背景とも一致します。JavaScriptなしで実現できるモダンCSSテクニックの記事でも紹介したように、CSSだけで実現できることも増えてきました。

Oatのような超軽量ライブラリが注目される理由も、まさにこの文脈にあるのではないでしょうか。8KBで動くUIコンポーネントという発想は、JS肥大化への明確なアンチテーゼと言えます。

開発者が今できること

では、具体的にどうすればいいのか。Gomes氏は「可能な限りサーバーサイドを優先するアプローチ」を推奨しています。全てのSPAを否定しているわけではなく、プロジェクトの性質に応じて適切なアーキテクチャを選ぶことが大切だという主張です。

パフォーマンスバジェットを設定し、CIでバンドルサイズを監視する仕組みを導入するのも効果的です。web.devのパフォーマンスガイドは実践的なリソースとしておすすめできます。

元記事の全文はSérgio Gomes氏のブログで公開されており、Core Web Vitalsの文脈からも読み応えがあります。Webパフォーマンスに課題を感じている方は、ぜひ一度目を通してみてください。