kk-web

続々 サーバーサイドレンダリングについて、改めて勉強し直してみる

2019-12-18

少しずつ理解が深まってきたので、備忘録がてら。

この記事を読む前に、この記事を読まれることをおすすめします、めちゃくちゃわかりやすく書かれています。

その上で、補足を書いていこうと思います。

そもそもサーバサイドレンダリングってなによ

上記の記事では、「SSR と CSR」の手法に対して、以下のような説明となっています。

リクエスト時にサーバ側で最低限（ファーストビューや SEO 用の部分）レンダリングし、それ以降をクライアント側でレンダリングする（SSR と CSR）

なので、以前書いた記事のような描画が行われるわけですね。

サーバサイドレンダリング(以下 SSR)とは、あくまでファーストビューを高速化する目的や、Twitter や Facebook などの SEO 対策として行うに過ぎないというイメージです。

ファーストビューが表示された後、componentDidMount が呼ばれるときには、既にクライアントサイドレンダリング(以下 CSR)に切り替わっているということですね。

SSR を実装するにあたって、シングルページアプリケーション(以下 SPA)か否かということは関係がないです。

が、ほとんどのケースで SPA が採用されるのでは？と思っています。

じゃあプリレンダリング(以下、Pre-rendering)ってなんだよ

文字通り、事前にレンダリングを行っておく手法となります。

事前にレンダリングを行わない場合、render(または hydrate)のターゲットエレメントの子要素は空となります。

なので、build された html ファイルをのぞいてみると、以下のような状態となっています。

<!doctype html>
<html lang="en">
  <head>
    ...
  </head>
  <body>
    ...
    <div id="root"></div>
    ...
  </body>
</html>

対して、Pre-rendering を行った場合は、以下のような状態になります。

<!doctype html>
<html lang="en">
  <head>
    ...
  </head>
  <body>
    ...
    <div id="root">hoge</div>
    ...
  </body>
</html>

従って、上のケースでは以下のようなフローが取られます。

なにも表示されない → スクリプトが実行される → DOM が<div id="root"></div>に差し込まれる → 表示される

対して、下のケースでは、

hoge が表示される → スクリプトが実行される → DOM が<div id="root"></div>に差し込まれる → 差分が更新される

となります。

なので、Pre-rendering では以下のメリットが得られます。

  • ファーストビューの表示が早い
  • url のパスが静的に生成されるページについては、Twitter や Facebook などの SEO 対策が可能

その一方で、以下のようなデメリットが生じる可能性があります。

  • ページ数が多いサービスであったり、複雑な処理が組まれているサービスの場合、build に時間がかかる
  • url のパスが動的に生成されるページについては、Twitter や Facebook などの SEO 対策ができない

このサイトにさらに詳しいことがわかりやすく書かれています。

じゃあ static なサイトってなんだよ

Pre-rendering が行われたサイトは、static なサイトとなります。

render(または hydrate)のターゲットエレメントの子要素が空でない開発自体は、結構レガシーな印象があります。

url のパスごとに初期表示が異なる以上、パスごとに html ファイルを切る必要が出てくるので、SPA の考え方からすると、一周回ってきた感じを受けます。

SPA ってどういう扱いなんだよ

CSR にせよ SSR にせよ Pre-rendering にせよ、SPA 自体は動いているケースが多いのかなーと。

CSR の場合はファーストビューの時点から、Pre-rendering についてはファーストビュー以降、SSR についてはケースバイケースなのかなと。

いずれのケースにせよ、code-splitting は求められてくるのかなーと。

結局、CSR と SSR、Pre-rendering はどう扱えば良いんだ

個人的には、以下のような感じです。

CSR

  • Twitter や Facebook において、url のパスごとの SEO が対策できない
  • 楽して開発できる
  • サーバにあまり負荷がかからない

Pre-rendering

  • Twitter や Facebook において、url の静的なパスごとの SEO が対策可能
  • 楽して開発できる(create-react-app の場合、単に react-snap を導入するだけで対応できる)
  • サーバにあまり負荷がかからない

SSR

  • Twitter や Facebook において、url のパスごとの SEO が対策可能
  • 開発難度は高い
  • サーバに結構な負荷がかかる

みたいな感じです。

最近自分の周りで妙に SSR で流行っていて、Nextjs などを安易に導入している現場が目につくなぁと思い、改めて SSR のメリットデメリットをがっつり調べてみました。

個人的な考えとしては、SSR って選択肢としては、さほど上位には来ないよなぁ…って感じです。

SEO 周りについてはしょうがないケースもあると思いますが、ファーストビューの考慮って意味では、Pre-rendering で十分でしょって思うことが多いです。

React を扱う上では、やはりまずは create-react-app で開発を行うことが大事なのかなーと思っています。

React を使用した正しい開発手法を学んだ上で、Nextjs であったり Gatsby であったりに進むべきではないかなと。

© 2018 kk-web