サーバーサイドレンダリングについて、改めて勉強し直してみる
サーバーサイドレンダリング(以下 ssr)についての知見がふわっとしているので、改めて勉強し直してみます。
ssr とは
この記事がわかりやすいです。
「サーバーサイドレンダリング」とは一体なんでしょうか?混乱を避けるため厳密な説明は避けますが、少なくとも私たち Web デベロッパーのここ数年の文脈においては、 「(元々ブラウザ上でしか動かなかった)JavaScript をサーバー内部で実行して、HTML を生成すること」を指します。
なるほど?
でもまだピンときてません、多分そもそもクライアントとサーバーの間で行われているリクエストのフローが理解できていないからだと思います。
ssr と クライアントサイドレンダリング(以下 csr) の違い
この記事がわかりやすいです。
なるほどー。
シンプルに HTML/CSS/JacaScript のみで動くアプリケーションの場合
上記の記述っぷりは多少引っかかりますが、言いたいことはよくわかりますし、このケースが書いてあるのでとてもすんなり理解できました。
上記のケースがいわゆる静的(static)なサイト、つまり url ごとに html ファイルが切られているケースなんですかね?
ssr = static だと思っていたんですが、自分の認識は全く間違っていたみたいです。
ssr のメリット
よく聞くのは、以下の 2 つなイメージです。
- 初回レンダリングが早い
- seo に強い
一つずつ考えていきます。
初回レンダリングが早い
ssr では、サーバー側の Nodejs の上で JavaScript を実行して html を生成してそれをクライアント側に返すみたいなので、確かに早そうです。
初回のレンダリングについては理解できたんですが、2 回目以降のレンダリングはどうなるんですかね?
spa の場合と static な場合で全く挙動が異なりそうなんですが。
spa と static の違い
この記事に答えが書いてありました、図付きでとてもわかりやすいです。
想像通り、サーバーで html ファイルを単数持つのか、複数持つのかの違いがあるみたいです。
改めて、初回レンダリングが早いというのは
csr の spa よりは、ssr の方が早いよって感じみたいです。
csr の static なケースとかはどうなんだろう。
そう考えると、csr の spa ってかなり遅そうな印象です。
引っかかってるポイント
この記事によると、
サーバ側で React Component のビルドを行い、初回の HTML 生成(レンダリング)をサーバ側で行うことをサーバサイドレンダリング(SSR)と呼びます。
ということは、2 回目以降もサーバー側でレンダリングする場合は ssr と呼ばない…?
ちょっと頭がこんがらがってきました。
seo に強い
twitter とか facebook とかは、確か js ファイルをクロールしてくれないみたいなことを聞いたことがあります。
よって、クローラがサーバーに対しリクエストを要求した時、static なサイトは言わずもがな、html だけを返す ssr も url ごとの meta データが送られるってことですかね?
ちょっと中途半端な記事になってしまいましたが、なんとなーく理解できてきました。
今の自分の知識でまとめてみると、
- サーバー側で JavaScript を実行してクライアント側に html を返すのが ssr
- クライアント側で JavaScriot を実行するのが csr
- url ごとに html ファイルが切手ある場合は static
- html ファイルがエントリポイントにしかないのが spa
- ssr = spa でないという認識は間違い
これくらいは理解できました、なるほどなぁ。
加えて、個人的な感想としては、
- csr の spa は確かに遅そうだけど、code splitting したら大したことないんじゃないの?
- url ごとに seo 対策が必要なケースでも、必ず ssr をしなきゃいけないということはないと思う
- 経験上、ssr なサイトを作るのは、やっぱり大変
- やっぱり ssr はいらないんじゃないのって思った(小並)
- 今のとこ最強なのは static かなぁと…gatsby も react-static も nextjs もそうだし
- twitter や facebook の seo を気にしないなら spa で十分
って感じです。
まだふわっとしていることも多いんですが、今日はこのくらいで。