◆ SSR って必要性を感じない
  ◆ JavaScript  動かない環境は考えないし
  ◆ Google は JavaScript  実行後の結果をインデックスするし
  ◆ ブラウザで実行してもたいして表示時間に差はないし
◆ WebComponents では SSR 不可
  ◆ コンポーネント内は JavaScript  で作る前提で HTML をサーバ側で事前に作りようがない
  ◆ HTML はルートコンポーネントだけになる

SSR

SSR ってなぜか需要ありますよね
やってることは サーバ側で HTML を作っておくというものです
JavaScript で全部の DOM を作るページだと HTML はほとんど何も書いてなくて head タグの中身くらいです
それを JavaScript で処理して DOM を作るのですが SSR だとサーバサイドで初期状態の DOM を作って HTML に含めます
昔ながらのサーバ側で HTML を作って返すものです

基本 React や Vue などフレームワークで DOM を作るのが前提で フレームワークが行う DOM 作成の処理をサーバで行います
なので基本 Node.js がウェブサーバになります
レスポンスが動的なものでなく 事前に HTML を作ってしまって静的ファイルとしてレスポンスを返すのだと Node.js 以外の Apache などでも可能です

SSR 要らないと思う

そういうページのほぼ全ては何らかの JavaScript の処理がページ内にあるはずです
なので SSR の目的が JavaScript が動かない環境への対応というわけではないと思います
JavaScript での処理が前提のページで初期画面だけ見れてもたいして嬉しくないです

SEO のためと書いてるのを見たことがありますが Google は JavaScript を実行した結果を解析すると何年も前から言っています
そのエンジンは最新版の Chrome ではなく古めの Chrome のものなので 最新ブラウザ前提のつくりであれば動かないでしょうけど SEO を気にしてるサイトってほとんど IE 対応していると思います
古めの Chrome と言っても IE 用に polyfill 入れたりしてれば動いているはずです

その他 Bing とかは詳しくないので JavaScript を処理してないのかもしれません
しかし 今どき Google 以外を使う人なんて僅かですし そのマイナー検索エンジンにクロールしてもらうためだけに SSR 対応させるのは割りに合わないと思います

最初から DOM があるので表示が高速という話も聞いたことはあります
速くはなるのですが DOM 構築ってそこまで時間がかかるものでもないはずです
ほとんどが DOM に応じてスタイルあててレイアウト計算して実際に描画してという JavaScript 外の処理なので気にするほどでもないと思います

それにブラウザでの DOM 更新処理は初回に限らずなにかのボタンを押したり ページ移動時に毎回起きるはずです
その DOM 処理が目に見えて遅いと言うならこれらの操作時にも毎回遅い更新が発生してることになります
それなら SSR で初回だけごまかすんじゃなくて作りを見直したほうが良いと思います

ブラウザでやってもほとんど時間がかからないのだとすればやっぱり SSR は不要だと思います
それにブラウザ側にやらせて支障ないものであればサーバ側の負荷を減らすためにできる限りブラウザ側に処理をやらせたいですし

反対に SSR が嬉しいと思ったことはスクレイピングなど JavaScript を動かさず表示されるデータを取得したいときです
最近は Chrome を使って JavaScript 実行後の HTML を取得するのも比較的簡単ですが JavaScript を動かさず単純に HTML を取得してパースするだけで済むほうが楽です
しかし これって一般的な使用方法とはずれてきますし ブラウザ使わず機械的に処理する人向けに SSR 入れるのも変な話です

やっぱり「いるのそれ?」って思う技術なんですよね

WebComponents

React などのこれまでの DOM (Light DOM) を作る仕組みであればサーバ側で DOM を用意することは可能です
しかし 将来的に増えるであろう WebComponents では現状不可能だと思います

WebComponents ではそのコンポーネントの中身を JavaScript で作ります
HTMLElement が CustomElement にアップグレードされて constructor が呼び出されて Shadow Root を作ったり作らなかったりして コンポーネント内部の innerHTML 部分を作ります

サーバ側で全体の DOM を作っておくことはできませんし HTML の body はルートコンポーネントを配置するくらいにしかなりません

こういう感じです

[index.html]
<!doctype html>
<meta charset="utf-8" />
<script type="module" src="app/index.js"></script>

<root-component></root-component>

[app/index.js]
import root_css from "./root.css"
import common_css from "./common.css"
import "./components/root-component.js"

document.adoptedStylesheets = [common_css, root_css]

[app/components/root-component.js]
import common_css from "../common.css"
import css from "./root-component.css"

customElements.define("root-component", class extends HTMLElement {
constructor() {
this.attachShadow({mode: "open"})
this.shadowRoot.adoptedStylesheets = [common_css, css]
this.shadowRoot.innerHTML = "<h1>root</h1>"
}
})

CSS は今のところは ESModules で import できませんが proposal にはあって将来的に実装されそうなので import で書いてます
root-component では短く h1 タグを作ってるだけですが ここにサブコンポーネントを入れたりします

こういう作りの場合 h1 タグをサーバ側で作ることはできないです
作ることはできても HTML に含められません
root-component の次あたりに CustomElement を使わない版のツリーを用意しておいて root-component の準備が完了したら HTML に直に書かれたほうを削除すれば見た目は維持できるかもしれません

<root-component></root-component>
<h1>root</h1>

しかし ほぼ一瞬しか見えないのに同じものを WebComponents なしで作って配置しておくのはムダが多く感じます
特に Shadow DOM を使うと CSS 空間が異なるので それを使わずに Light DOM で同じものを実現するのはがんばり過ぎな感じがします

今のところ WebComponents で SSR するための仕組みは特に聞かないですし わざわざ用意するほどでもないと思います
そう考えたらやっぱり今 SSR をしてるのを見ていても なんというか廃止予定が決まってるツールを使い続けてるのを見ているような気持ちです

ブログみたいなサイトを静的サイトジェネレータに使って JavaScript は一切なしの HTML と CSS だけのサイトにするというのであれば有用だと思うんですけどね