静的サイトからフレームワークの実行時コードを取り除く

ブログプラットフォームBloffyを手がける個人開発者は、一般公開サイトからNext.jsを取り除いた結果、Google Lighthouseが測定する各項目で満点の100点を獲得したと述べている。この結果は、大部分が静的なウェブサイトにフレームワークのオーバーヘッドがどう影響するかを示す事例であり、あるフレームワークが別のものより常に速いことを証明する一般的なベンチマークではない。

開発者はPageSpeed Insightsで性能を測定し、キャッシュとコンテンツ配信ネットワークによって、サイトがすでに目標にかなり近づいていたことを確認した。Bloffyは配信と画像変換にCloudflareを使い、アプリケーション層のキャッシュや別個の画像処理サービスの必要性を減らしていた。その結果、主な未解決の問題として残ったのが、フレームワークによって配信されるJavaScriptだった。

プロジェクトの説明によると、ブログのページにはインタラクティブな機能がなく、事前にレンダリングされていた。クライアントコンポーネントを削除しても、残っていた実行時コードはなくならなかった。Next.jsのルーティング、エラー処理、LinkやImageのコンポーネントが、依然としてブラウザー側のコードとハイドレーションの仕組みを伴っていたためだ。開発者は、フレームワークを置き換えると決める前に、使われていないJavaScriptが約230,460バイトあると測定した。

レンダリングをHonoに移行

プロジェクトは手書きのHTMLに切り替えるのではなく、レンダリング層をHonoに移した。JSXとフレームワークの構造を維持しながら、クライアント側のJavaScriptなしでページを生成するようにした。移行後、開発者は未使用コードが407バイトに減り、ビルド時間が約40％短縮したと報告した。その説明によると、公開ページはその後、Lighthouseのパフォーマンス、アクセシビリティ、ベストプラクティス、SEOの各テストで100点に達した。

これらの数値は、このプロジェクトの構成と測定条件についてのものだ。Lighthouseの結果は、テスト対象ページ、ネットワーク、端末の設定、第三者のリソースによって変動する。開発者はまた、別のテストサイトでは意図的にインデックス登録をブロックしていたためSEOの点数が低かったと述べている。これは、点数を見る際に設定の背景を踏まえる必要があることを示している。

今回の移行は、より限定的な技術判断を反映している。静的なコンテンツ公開部分には、本格的なReactフレームワークのナビゲーション機能やアプリケーション機能が必要ない場合がある。Bloffyの場合、世界各地への配信はCDNが、画像変換はCloudflareが担い、一般公開ブログの利用体験はサーバーでレンダリングしたマークアップで実現できた。そのため、フレームワークの実行時コードは、対応する機能上の必要性がないままコストとなっていた。

Next.jsは引き続き、動的レンダリング、ルーティング、データアクセス、インタラクティブなReactコンポーネントを必要とするアプリケーション向けに設計されている。これに対し、Bloffyの経験が浮き彫りにするのは、サイトの実際の動作にツールを合わせることの価値だ。ページが実質的に文書であり、ブラウザー上のロジックを必要としない場合、実際に配信されるデータ量を測ることで、サーバー側のキャッシュだけでは解決できない改善の余地が見つかることがある。

このプロジェクトの結果は、限定的な意味では再現も可能だ。読者は公開ページをPageSpeed Insightsにかけ、配信されるJavaScriptを調べることができる。普遍的な比較を確立するものではないが、静的コンテンツの配信経路を簡素化することで、測定される性能がどう改善しうるかを示す具体例となっている。