JavaScript依存のWeb開発は限界か - パフォーマンスの現実と解決策

JavaScript依存のWeb開発に警鐘が鳴っています。Automattic社のエンジニアが問題を指摘しました。しかしReactを捨てろという話ではありません。そこで今回は、JS依存の問題点と現実的な解決策を解説します。

Automatticエンジニアの主張

PerfOpsチームのエンジニアが論じました。JS重視のアプローチは長期的なパフォーマンス目標と両立しないと言います。しかしJavaScriptを全否定しているわけではありません。つまり使い方の問題なのです。

具体的にはSPAへの過度な依存がリスクです。またサーバーサイドレンダリングとの適切な使い分けが必要です。したがって、バランスの取れたアーキテクチャ設計が求められています。

2024年の調査データは衝撃的です。Slackは55MBのJSを読み込みます。LinkedInは31MB、Gmailは20MBです。さらにテキスト表示が主なMediumでも4MBが必要です。

またJSペイロードの中央値は2024年に14%増加しました。モバイルで558KB、デスクトップで613KBです。特にJSはブラウザの全活動の中で最もCPUを消費します。そのため、低性能デバイスでは深刻な問題になります。

「Web標準ファースト」という哲学が台頭しています。つまりブラウザネイティブ機能を優先する考え方です。さらにサーバーファーストアプローチも広がっています。具体的にはロジックをサーバー側に移し、JSの送信量を減らす手法です。

またゼロJSデフォルトのフレームワークも登場しています。たとえばAstroはデフォルトでJSを出力しません。さらにSvelteやSolidがシンプルさで人気を集めています。したがって、選択肢は確実に増えているのです。

WordPressもJS削減の方向に動いています。2025年にはPHPのみのブロック登録が可能になりました。つまりJSなしでブロック開発ができるのです。またブロックエディターやブロックテーマが標準的なアプローチになっています。

さらにビルドツールも進化しています。具体的にはViteが38%の採用率を達成しました。またesbuildも11%に成長しています。しかしwebpackはまだ広く使われています。そのため、移行には時間がかかるでしょう。

まず月次のnpmパッケージ監査が効果的です。不要な依存関係を定期的に削除しましょう。またshadcn/uiのようなコピー&ペースト型コンポーネントも有効です。さらにSignalsベースのリアクティビティで必要な部分だけを更新できます。

しかしJSを完全に排除するのは現実的ではありません。だからこそ適材適所の使い分けが重要なのです。このようにJS依存の問題は認識されつつも、解決には段階的なアプローチが必要です。