個人の意見 aka ポエムです。
界隈的には今さら感がすごいけど。
そんな今さらポエった事情としては、
- とある案件でSPAをReactで作りつつサーバーサイドレンダリング（以下SSR）をすることになるかも
- SPAじゃないページもまとめてReactでSSRすることになるかも
- ただ個人的にはSPA+SSR不要論者
- サーバーサイドのテンプレートとしてのReactも冗長なだけやろ派
- でも仕事なのでしゃーない（お客様がそう申されるなら・・
- なのでやるからには再考察してみて、前向きにやれる要素を見つけたい！
- けどどんだけ考えてもやっぱり意義が見つけられなーい( ´Д｀)=3
という感じで、SSR自体の是非はまあどうでもよくて、ただ個人的に「しなくていい」と思ってる気持ちをまとめたものです。
技術に是も非もないです。大事なのはどう使うかなのです。
ちなみにやってみた結果・・とかいう話ではなく、やってないけどやらなくてよさそうだなーという話です。
20170724: なぜか今さら盛り上がってたのであれこれ追記
なぜしなくていいと思ってるか
コストの割に、メリットが薄い。コスパが悪すぎる。と思うから。
狭い観測範囲で見てる限りでも、
- ちょっと大変とかではなくめっちゃ大変
- そのくせ100点の満足度にはなってない
なのでここにコストをかけるくらいなら、他にやることあるでしょーという。
政治的な理由だとか、コストをかけるヒト・カネが余ってるとか、人に言えない理由があるとかならどうぞ頑張ってください。
なので絶対するな！っていうのではなく、やることやってやりたいならやればいいし、無理してやらないといけないことでもないと思ってるよ、という話です。
SSRする理由といわれているポイントに対する個人的な解
○○だからSSRが必要！SSRすれば○○できる！みたいなやつに対して、SSRしなくても○○できると思ってるやつ。
SEO対策
サーバーでUA見て、botに返す用ページを作るのはどうか。
jsもcssもない、本質的なコンテンツのみをDBから取ってきて埋めたプレーンなHTML。
普通のブラウザには、いつもどおりのコンテンツを返す。
てかコレSEOって言葉がすごい誤解を招くと思ってて、要はOGPの`meta`タグの対応ができればそれでいいんでしょ・・？
そこだけサーバーサイドで差し替えて、後はいつも通りでもOKなのでは・・？
こうすりゃOGPももちろん問題ない。
SSRで頑張って`body`配下のアレコレをやる意義とは・・と思ってます。
なんかそのうちGoogleBotが解釈したページと、一般的なブラウザが解釈したページが異なる場合ペナルティ！とかにならないかぎり。
ならんやろうけど。あとこのSNS全盛の時代にGoogleのインデックスがーとかどうなんだろうという気持ちもある。
面倒な点としては、GoogleだけじゃなくてTwitterもFacebookもLINEも・・ってな感じでBotホワイトリストの管理がちょっとアレなくらい。
けど、SSRを頑張る工数に比べたら微々たるもの・・。
もしくは、単なるLPを前段におくのではダメなの？、という。
~~~~ ここから追記 ~~~~
このBot用に違うページを返す手法は、クローキングといってGoogle的にはよしとしないそうな。
ならまあ`body`配下は何もしない、`meta`だけ差し替えるでいいんじゃないですかねー。（それすらダメなのかはこの記事からは読み取れなかった
初期表示が速くなる
ボトルネックがネットワークコストなのであれば、
この記事に書いてあるようにデータを埋めてネットワークリクエストを短縮するだけで、ほとんどのケースで十分な気がする。
てかこんな手法、iOS3くらいの時代から存在するテクニックな気がしてて、このパターンでも足りない・・もっと速く・・！ってなった人がSSRに行くのは納得です。
でもそれすらやらずにいきなりSSR！って話も多い気がしてて、飛躍しすぎでは・・という。
GraphQLだとかBFFだとかいう話もそうで（表示の高速化を主旨とするなら）、それより先に、マスターデータの最新を吐いて埋めるとかCDNに載せるとか、やれることやった上での選択であって欲しい。
そもそもネットワーク以前にサーバーサイドでデータの取得に時間がかかる問題は、SSRでもこの手法でも同じはず。
まーパフォーマンスチューニングを最適化と捉えるか、実装の延長で捉えるかの違いな気もするけど・・。
ちなみにこの場合とSSRとの差異は、「埋まってるデータを取り出して画面を構築するステップの有無」になるけど、そこってそんな時間かかるか・・？というのが個人的な主張です。
てかそもそも、AMPとかSPAじゃないページをシェアさせるとか、方法は他にもあるはずで、なぜ全部を詰め込んで頑張ろうとするのかが個人的にはわからない・・。
古いブラウザ・低性能マシンにやさしい
具体的にどのラインなのかが不明なので、いまだにAndroid2系とか謎タブレットとかそういうのを対象にしてるとする。
そもそもそんなレベルの古いブラウザ・低性能マシンに優しくしたいなら、それこそSPAなんかやめたらいい（ReactもやめてBabelもやめてね）のに・・。
そんでどーせSSRした後のことはケアしないんやろうし。そんなうわべだけの優しさなんか欲しくないのよ！
てかサービスにおいてそいつらのシェアはどれくらいなんだ、本当にターゲットに入れるのかという話が先。
このご時世に本当に考慮しないといけない低スペックって具体的にどんなもんなんやろう・・。
という気持ちになるのであまり気にしなくていいと思ってる。
コスパのコスとは
Nodeでのサーバーサイド・BFF的なやつが必須になる
これがとにかく大変な認識です。
そういうSaaSとか使うにしても、それだけ依存が増えることがコスト。
だからここに問題を感じない環境にいるなら、別にコストではないのかなーと。
Isomorphicなコード
手書きで実装するのは大変なので、3rdのライブラリとかOSSとか使いますよね？
それらが読み込むだけで爆死するケースもあるので・・そこがコスト。
videoとかcanvasとかやってると割とよくあるので個人的な印象に寄ってる感はある。
`renderToString()`相当のパフォーマンス
とりあえず遅いらしいけど、コンポーネント数（幅）の問題なのか、ネスト（深さ）が問題なのか、具体的な問題点がいまいちわかってない。
どっかに情報ないかしら・・？
逆にいうとこれくらいまでなら、パフォーマンスは気にしないでOKという線引ができるのかなーとか。
頑張って実装するまでもなく、見積もりする方法ってないんだろーか。
そういや`renderToStream()`がマージされてたけど、アレにしたらどうなるとかいうデータもあったら知りたいなー。