console.lealog();

@leader22のWeb系に関する勉強めもブログですのだ

やっぱりサーバーサイドレンダリングなんかしなくていいやという気持ち

個人の意見 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。

普通のブラウザには、いつもどおりのコンテンツを返す。

こうすりゃOGPももちろん問題ない。
某社にいた時に採用してましたが、特に困ったことはなかったし。

てかコレSEOって言葉がすごい誤解を招くと思ってて、要はOGPの`meta`タグの対応ができればそれでいいんでしょ・・?
そこだけサーバーサイドで差し替えて、後はいつも通りでもOKなのでは・・?
SSRで頑張って`body`配下のアレコレをやる意義とは・・と思ってます。

なんかそのうちGoogleBotが解釈したページと、一般的なブラウザが解釈したページが異なる場合ペナルティ!とかにならないかぎり。
ならんやろうけど。あとこのSNS全盛の時代にGoogleのインデックスがーとかどうなんだろうという気持ちもある。

面倒な点としては、GoogleだけじゃなくてTwitterFacebookもLINEも・・ってな感じでBotホワイトリストの管理がちょっとアレなくらい。
けど、SSRを頑張る工数に比べたら微々たるもの・・。

~~~~ ここから追記 ~~~~

このBot用に違うページを返す手法は、クローキングといってGoogle的にはよしとしないそうな。

Cloaking - Search Console Help

ならまあ`body`配下は何もしない、`meta`だけ差し替えるでいいんじゃないですかね。(それすらダメなのかはこの記事からは読み取れなかった

初期表示が速くなる

ボトルネックがネットワークコストなのであれば、

サーバーサイドレンダリング不要論 - Qiita

この記事に書いてあるようにデータを埋めてネットワークリクエストを短縮するだけで、ほとんどのケースで十分な気がする。

てかこんな手法、iOS3くらいの時代から存在するテクニックな気がしてて、このパターンでも足りない・・もっと速く・・!ってなった人がSSRに行くのは納得です。
でもそれすらやらずにいきなりSSR!って話も多い気がしてて、飛躍しすぎでは・・という。

GraphQLだとかBFFだとかいう話もそうで(表示の高速化を主旨とするなら)、それより先に、マスターデータの最新を吐いて埋めるとかCDNに載せるとか、やれることやった上での選択であって欲しい。
そもそもネットワーク以前にサーバーサイドでデータの取得に時間がかかる問題は、SSRでもこの手法でも同じはず。
まーパフォーマンスチューニングを最適化と捉えるか、実装の延長で捉えるかの違いな気もするけど・・。

ちなみにこの場合とSSRとの差異は、「埋まってるデータを取り出して画面を構築するステップの有無」になるけど、そこってそんな時間かかるか・・?というのが個人的な主張です。

てかそもそも、AMPとかSPAじゃないページをシェアさせるとか、方法は他にもあるはずで、なぜ全部を詰め込んで頑張ろうとするのかが個人的にはわからない・・。

古いブラウザ・低性能マシンにやさしい

具体的にどのラインなのかが不明なので、いまだにAndroid2系とか謎タブレットとかそういうのを対象にしてるとする。

そもそもそんなレベルの古いブラウザ・低性能マシンに優しくしたいなら、それこそSPAなんかやめたらいい(ReactもやめてBabelもやめてね)のに・・。
そんでどーせSSRした後のことはケアしないんやろうし。そんなうわべだけの優しさなんか欲しくないのよ!

てかサービスにおいてそいつらのシェアはどれくらいなんだ、本当にターゲットに入れるのかという話が先。
このご時世に本当に考慮しないといけない低スペックって具体的にどんなもんなんやろう・・。

という気持ちになるのであまり気にしなくていいと思ってる。

おまけ

`renderToString()`相当のパフォーマンス

とりあえず遅いらしいけど、コンポーネント数(幅)の問題なのか、ネスト(深さ)が問題なのか、具体的な問題点がいまいちわかってない。
どっかに情報ないかしら・・?
逆にいうとこれくらいまでなら、パフォーマンスは気にしないでOKという線引ができるのかなーとか。

頑張って実装するまでもなく、見積もりする方法ってないんだろーか。

そういや`renderToStream()`がマージされてたけど、アレにしたらどうなるとかいうデータもあったら知りたいなー。

ATFレンダリングが個人的に・・・

SSR勢の現実解と言われているらしいAboveTheFold(最初に見えるとこだけ先に、それ以外はスクロールされたら)レンダリング

  • SSRでページがさくっと表示されるのは良い
  • ただしさくっと表示された = FullyLoadedとヒトは認識するのですぐスクロールして情報を探しちゃう
  • 何もない空間を見つめさせられること数秒

とかいう体験をよくするんですが、あれ微妙じゃないですか・・?
で、加えてむっちゃ頑張って作ったんやろうにこんなことになってしまって・・という気持ちになるので好きじゃない。

おわりに

というわけで、他にもやりようはあるのに、わざわざコスト高な選択肢を選ぶ理由がわからない。
そして界隈がそれを至上命題みたいな扱いにしてる理由がわからない。

個人的には、他にもやりようはあるしそれで十分やと思うし、やっぱりサーバーサイドレンダリングなんか頑張らなくて良い気がするなー、という気持ち。