Warning: count(): Parameter must be an array or an object that implements Countable in /home/xs638785/agile-software.site/public_html/wp-content/plugins/rich-table-of-content/functions.php on line 490
CSR(Client Side Rendering)
CSR はブラウザ側で HTML/CSS を生成する際に JavaScript が実行されます。
初回にページ全体を処理するため、初回の読み込みは重くなりますが初回以降のページ遷移などのインタラクションは高速です。
- ブラウザが指定 URL へリクエストし、<body>が空っぽの HTML を取得
- ブラウザは JS を実行し HTML や CSS 等を<body>へレンダリング
- ブラウザは HTML の<body>に展開された HTML 情報を表示
※ CSR で配信されているアプリケーションを一般的に SPA(Single Page Application)と呼びます
SSR(Server Side Rendering)
SSR はサーバー側でレンダリング(描画)を行うため、CSR と比較するとブラウザで Javascript を実行するコストがないのが大きな利点です。
- ブラウザが指定 URL へリクエスト
- サーバー(NodeJS)がリクエストを受け取り、リクエストに応じて HTML/CSS 等を生成
- 完成した HTML/CSS をブラウザへレスポンス
SSG(Static Site Generator)
SSG はビルド時に HTML などのコンテンツが生成され、
各リクエスト時に再利用してブラウザに渡す手法です。
CSR・SSR はリクエスト時にビルドを行なっていましたが、
SSG は事前に作成された静的ファイルを返すだけなので表示速度が CSR・SSR に比べ高速です。
ページの更新時にアプリケーション全体をビルドしないといけないため
ページ数が多い大規模なアプリケーションには不向きです。
- ブラウザが指定 URL へリクエスト
- ビルド時に生成された静的ファイルをブラウザへレスポンス
ISR(Incremental Static Generator)
ISR は SSG と SSR の機能を兼ね備えた手法です。
リクエストがあるたびに HTML が生成されます。
処理の流れは SSG とほぼ同じなのですが、
SSG のデメリットである、更新時にアプリケーション全体をビルドしないといけない点を解決してくれます。
具体的には一定時間ごとにバックグラウンドでビルドを行なってくれており、
API からのデータ取得や再レンダリングを行なってくれます。
CSR・SSR と比べてデータ更新のリアルタイム性は低いものの、
SSG のようなページ速度の速さを実現したまま SSG よりリアルタイム性は高いものとなっております。
SSR が必要な理由
先述の通り、SSR は CSR と比べ、ページごとにレンダリングをサーバー側で行うことで初回のページ読み込みを高速に行うことが可能です。従来の Java や PHP 言語等のフレームワークのテンプレートエンジンによるレンダリングと似ていますね。
SSR が必要とされる理由は大きく分けて4つあります。
- SEO に強い
- 初期描画の表示速度が高速
- アプリケーションの仕様変更に強い
- 実行結果を Cloud Front などの CDN でキャッシュ可能
これらについて、以降で順に説明したいと思います。
SEO に強い
Google はページの読み込み速度が速いサイトには優先的に検索順位を与えるようになってます。
読み込み速度が早くなるとセッション時間やサイトの直帰率などのユーザー指標が改善されます。
かつてはクローラーは JavaScript を実行できず、インデックスさせるには SSR が必須となってましたが
近年は CSR のアプリケーションにおいてもインデックスされるようになってます。
ですが、下記のように JavaScript での処理が必要だと判断した場合は一度レンダリングの待ち行列に追加されるようになってます。正しく実装すれば CSR でもすべてのページを認識させることは可能ですが SSR よりもリスクは高くなります。
現在多くのサイトがJavaScriptベースになっているため、次のステップとしてはJavaScriptのレンダリングも必要となり、ページが一度レンダリングの待ち行列に追加されます。リソースが空き次第、ヘッドレスブラウザのような別サービスである「ウェブレンダリングサービス」(WRS)を使用し、JavaScriptを実行します。
SEO Mythbusting エピソード2のまとめ: Googlebotについて
SSR においては noindex などを指定しない限り確実にクロールされるので問題ありません。
こういった理由からクローラビリティにおいては CSR より SSR のほうが優れていると言えます。
初期描画の表示速度
CSR は初回の読み込み時間が SSR よりも遅くなりがちで SEO の面でも影響があると言えます。
同アプリケーションでも SSR にできるなら SSR にしたほうが良いと考えてます。
また、SSR はユーザーのネットワーク環境・デバイスのスペックに左右されないため、 安定した配信が可能です。(レンダリング処理をサーバー側で行う)
アプリケーションの仕様変更に強い
NuxtJS の場合は <client-only></client-only>
で囲むことにより、プロジェクト全体が SSR であっても部分的に SSR させない設定ができます。(NextJS でも同等の機能が存在)
また、JAMstack などの SSG の場合、サーバー側の NodeJS では機能が制限される一方、
SSR はコードで表現できる自由度が高く柔軟な開発が可能です。
今後動的な OGP などサーバー側が処理が必要になりそうな場合は CSR ではなく、
SSR や SSG、ISR で実装を進めることをおすすめします。
実行結果を Cloud Front などの CDN でキャッシュ可能
SSR を行うことで、サーバーサイドでレンダリングされた結果(HTML/JS)をキャッシュさせる事ができます。
Cloud Front などの CDN を利用することで、
オリジンサーバの代わりにコンテンツを配信することができ、表示速度などのパフォーマンス向上に繋がります。
キャッシュを利用する場合はどのタイミングでキャッシュを破棄するかなどの
キャッシュ戦略について検討が必要です。
認証後のメールアドレスなどの秘匿情報がキャッシュされ、個人情報の漏洩に繋がる問題もたまに見かけるため
個人情報を扱う部分は CSR、扱わない部分は SSR にする対応やキャッシュの破棄タイミングが重要になってきます。