SPA + サーバーサイドレンダリング、そのダルさに関する私見

いわゆる SPA + サーバーサイドレンダリングがダルい

唐突ですがおさらいです。

なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば

であり、特に SPA + SSR の文脈においては

Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。

のような特徴がありました。

しかし、そもそも Critical Rendering Path の短縮や、Googlebot レンダリングの安定性が他の手段で担保されているならばそれでもよく、これらが SPA + SSR の固有メリットというわけではありません。AMP や App Shell モデル、Service Worker による夢実装など初期表示を速くする試みは増えていますし、Googlebot 対策は prerender.io とかが頑張って....くれる.....かもしれません。

prerender.io、Headless Chrome に対応したらよいけど、PhantomJS と再会してしまったので辛い

例えば Web Components がまじめに普及したとしたら...？

一方で SPA + SSR は引用のとおり 技術的には過渡期の歪なキメラっぽさ という一面を持っています。Web Components などがクライアントサイドの仕様で検討されている時点で、SSR のスジに将来性があるとは思えません。

どうしてもやるなら Web Components 関連仕様 ( HTML Imports と Custom Elements と Shadow DOM と Templates… ) を node で再実装しないといけない。不可能とは言いいませんが、それを作っている間に他の技術の発達で SSR が不要になる可能性のほうが高いのではないでしょうか。

すでに v1 相当のステキ実装があったらゴメン、眺めてたら Server-side Web Components: How and Why? みたいな面白アイディアはあった

HTML レベルのキャッシュを是とした App Shell のようなモデルとの相性の悪さも目立ちます。ログイン状態があると、SSR に持たせるキャッシュも細切れにせざるを得ないので煩雑な上に、大した効果も上がらないということもあります。

複雑性の焦点をシステム全体のどこに配置するか

で、なんで肝心の SSR がダルいかというと

  • node サーバの仕事が増えると、サーバ側の計算コストが増える
  • 負荷の高い処理のためにキャッシュをサーバ側でもたないといけない
  • node サーバだのキャッシュサーバだの障害点が増える

という点があげられます。ちなみにモジュールを Isomorphic/Universal に保つのは言うほど難しくないので問題ではありません。他に手段がないならば仕方ない作業コストです。

ただ、やはり他の手段があるならばクライアントに計算コストを寄せて完結させるほうが複雑性を高めすぎない自然な設計になるのではないでしょうか。

SPA 単品かトラディショナルな SSR 単品で済ませたくない？

SPA + SSR 運用の現状を見るに、もちろん直近においては有力な選択肢のひとつだとは思いますが、先を見据えるならどこかで手離れしていくことが望ましい設計パターンになるのではないか、というように考えている次第です。

ということで、神の啓示にしたがって次回は「SSR に対するダルさから App Shell モデルの素振りついでに webpack と和解を試みた」です。

なんでもかんでも SPA にしようぜ！っていう話ではもちろんありません