【Nuxt3】CSRからユニバーサルレンダリングへ移行する前に考えておきたいこと

この記事は、社内アドベントカレンダー12/2の記事です！

はじめに

株式会社ウェイブの秋山です。

現在開発しているプロダクトではNuxt3でCSRを使用しています。
以前ユニバーサルレンダリングへの移行を検討したことがあり、その時の調査で感じたことを書いていきます。

CSR/ユニバーサルレンダリングとは

詳細は公式ガイドに記載されていますので、ここでは簡単にご紹介いたします。

CSR(Client-Side Rendering)とは

クライアントからリクエストが来た際に、サーバーではほぼ空のHTMLとJavascript/CSSを返し、
クライアント側でコンテンツのレンダリングを行います。

よく言われるCSRのメリット

• 比較的実装が簡単

デメリット

• 初期描画の遅さ
• SEO的にやりづらさがある

ユニバーサルレンダリングとは

CSRとSSRを組み合わせたようなレンダリング方法です。
クライアントからリクエストが来た際に、サーバー側でレンダリングを行いHTMLを返します。
最初、ユーザーには静的ページとして表示されますが、ハイドレーションを行うことでインタラクティブなページに生まれ変わります。
また、ハイドレーション後はCSRの挙動をします。

参考：
https://masteringnuxt.com/blog/what-is-universal-rendering

よく言われるユニバーサルレンダリングのメリット

• 初期描画が速く、ユーザーがページのコンテンツにすぐにアクセスできる

デメリット

• 実装難易度が上がる
  • サーバーサイドではwindow/docmuentなどブラウザ固有のAPIを扱えない
• サーバーコスト
  • サーバーサイドレンダリングのためにNode.jsサーバーが必要

ユニバーサルレンダリング移行の前に考えておきたいこと

ここからは実際に行った移行調査をもとに、移行前考えておきたいことを振り返ります。

CSRの状態で速度改善ができないか

例えば、

• 初期ロード時に不要な処理を行っていないだろうか
• バンドルサイズを削減したらどうだろうか

などCSRの状態でも速度改善を行うことはできます。

コストに見合うか

実装コスト・サーバー代等のランニングコストなどがありますが、それに見合うかどうか考えたいです。

例えばCSRの場合、デバイスや通信環境の影響を受けて速度がかなり遅くなることがありますが、
サービスによっては通信環境/デバイスをあまり考慮しなくてもよいものもあると思います。
例えば、デバイスや通信環境がある程度保証されている社内で使用するシステムなど。

(低速になりがちな満員電車でもそのサービスを使うことがあるか、などを考えても良さそう)

ユーザーへの恩恵とコストが見合うかは、他のことでも常に考慮したいと思いました。

今後の運用がやりづらくならないか

上の方のメリデメでも挙げましたが、CSRと比較すると、開発が少し難しくなります。
また、開発メンバーに必要な知識も増えそうです。

ブラウザ固有API系の扱い

window/locationやそれを使った外部パッケージの扱いに気を遣う場面が増えます。
端末サイズによるレスポンシブ対応もやりづらくなるかなと思いました。

不具合の原因が増える

考慮漏れの発生により、知らない間にCross Request State Pollutionが紛れ込んだりする可能性もあります。いくつかの記事を見た限りでは、一度紛れ込むと不具合発見までに時間がかかるようなので注意が必要そうです。

またキャッシュの考慮もCSRより慎重にやる必要があると感じました。

おわりに

私のチームではCSRの継続を選択しましたが、どちらの方が適しているかはチームやプロダクトの特性によって違うかと思います。
本記事が選択の手助けになれば幸いです。