こんにちは！ ecbeing新卒一年目の長谷川 啓人です！
二度目の投稿になり、初めましての呪縛から解放されました。
今回はモダンなWebレンダリング方式であるSSRについて、まとめさせて頂きます。
このテーマについて解説されている記事自体は多く公開されています。しかし、新人目線ではわかりにくいものも多く感じたので、ここでは同じような立場の方々に向けて噛み砕いた解説をさせていただきましょう！
はじめに
皆さんは今からWebアプリケーションを一から作るとしたら、どういった技術を用いるでしょうか？ 新しく始めるからにはモダンでナウなライブラリを使ってみたい！ そう考える方も多いかと思います。
そこで2024年現在、モダンなWebアプリケーションとして色々と検索すると……SSRという技術に行き当たるのではないでしょうか。何やらMPAやSPAの更に進化したものっぽい……？ みんな使ってるし自分も採用しよう！
そんな認識でも問題なくWebアプリは構築できます。ですが、せっかくならばどのような利点があるのか、どのような技術が用いられているのか、もう少し知ってみませんか？ 好奇心には素直に従っておくと楽しいですよ！
MPAとSPAの復習
MPAとSPAはもう完璧さ！ という方は飛ばしちゃってください。
MPAとは『Multi Page Application』の略称であり、SPAは『Single Page Application』の略称です。
その名の通り、Pageの数が異なるというのが両者の違いですね！
MPAでは、各ページ毎に異なるHTMLがサーバーから用意され、ページを切り替えるごとにHTMLを一から準備しなおします。
対してSPAでは、同じサイトであればどのページであろうとも同じHTMLです。ページ遷移時にはHTMLを新たに取得しているのではなく、JSを用いて必要な情報を置き換えることであたかも違うページのように見せかけているのです。
正しく『MultiなPageのApplication』と『SingleなPageのApplication』というわけですね！
SSRとは？
SSRとは『スーパースペシャルレアリティ』の略称であり、ガチャから3%で……嘘です冗談です。石を投げないでください！ 石はください！
SSRとは『Server Side Rendering』の略称です。サーバー側でレンダリングする方式を指す単語であり、レンダリングとはHTMLの生成などを示します。
少しわかりにくいですが、SPAと比較すると理解が進むはずです。SPAでは常に同じHTMLを用いますが、その中身をJSで切り替えることであたかもページが遷移しているように見せかけるアプリケーションでした。
このHTMLの中身を切り替えることもレンダリングの一種と言えます。つまり、SPAとはクライアントでレンダリングしているアプリケーションでもあります。こういったSPAのような方式をSSRの対としてCSR（Client Side Rendering）と呼びます。
SSRはサーバーサイド……SPAの逆と考えれば良いわけですね。サーバーからダウンロードしてきたファイルを元にクライアントでレンダリングするのではなく、サーバーで予めレンダリングして完成したHTMLをダウンロード……クライアントでそのまま表示するといった方式です。
……ん？ 何か違和感が……？
MPAとSSRって一緒じゃない？
はい、ここまでを調べて僕の頭の中に浮かんだ疑問です。サーバーでレンダリングする方式がSSRなのであれば、MPAもSSRなんじゃないか？
MPAのフレームワークとしては.NET CoreやRailsなどがありますが、これらはサーバーでHTMLを生成してクライアントへ渡すという形を取っています。このサーバーでHTMLを生成するという挙動はSSRの定義そのものです。
しかしSSRがMPAであれば、SPAの進化どころか先祖返りを起こしてしまっています。流石にそんなわけがない。けれども、そうとしか思えない……。何を勘違いしているのでしょうか？
そもそも並べて考えるものではない！
右往左往していても仕方がないので、さっさと答え合わせとしましょう。 まず、SPAとSSRを比較するという前提からして間違っています。
MPAとSPAはアプリケーションの形式を、SSRはレンダリング方式を表す言葉です。 そうです！ そもそもこれらは別のものを指しているのですね！
なのに、SPAの進化系としてSSRを捉えてしまうから、話がややこしくなってきてしまっているわけです。
MPAとSSRが同じものなんじゃないか？ という疑問も的外れではなく、既存のMPAサイトとはMPAかつSSRというのが正しいのでしょう。
結局SSRって何が違うの？
話が整理できたところでSSRの特性について話していきましょう。ここでいうSSRとは狭義のサーバーサイドレンダリングではなく、SPAの進化系として語られる【SSR】となります。
その【SSR】とは、『サーバーサイドで部分的に処理が行われるSPA』のことです。
【SSR】はSPAと密接な繋がりを持っています。これは【SSR】のライブラリであるNuxt.jsやNext.jsが、SPAライブラリのVue.jsやReact.jsを内部に組み込んでいることからも明白です。【SSR】の根っこの部分はSPAそのままなのですね。
では一体何が変わったのかというと、初アクセス時の挙動が異なります。
SPAでは、初アクセス時からレンダリング前のHTMLとレンダリングの命令が記述されたJSをそのまま渡してきます。クライアントでレンダリングがされている所以です。
しかし【SSR】では、Node.jsによりサーバーサイドで予めJSを実行しておきます。これにより、初アクセス時には既にレンダリングが済まされたSPAのファイルがクライアントに送られてきます。
サーバーサイドで予めレンダリングされているSPA。それこそが【SSR】なのです。
つまり一般的に謳われる【SSR】とは、元がSPAのものに限定されていおり、正確には『SPAの挙動を取りサーバーサイド”でも”レンダリングできるWebアプリケーション』のことを指します。（クライアントサイドでもレンダリングは引き続き可能）
前述した通り、MPAだってSSRの一種なのですけどね。
【SSR】のメリット
しかし、クライアントで動作するSPAをSSRで動くようにしたのは何故でしょうか？
これには様々な理由が存在しますが……一番わかりやすいのはグーグルの検索エンジン対策となります。所謂SEOというやつですね。グーグル検索の結果を用意するクローラーは公開されている各サイトを確認し、その内容に応じてどういった検索ワードにヒットさせるかなどを決定しています。
しかしながら、SPAで受信できるHTMLは初め空っぽです。付随してくるJSが処理されて初めて、本来のページが完成するわけです。
一応、グーグルはJSでの処理も考慮して検索結果を決定していると公表していますが、アルゴリズムの詳細がブラックボックスになっている以上、我々在野の開発者が実際にどうなっているかを知る由はありません。
未知とは不安が芽吹く絶好の土壌です。SPAによるモダンなWebサイトはおしゃれだし便利だけど、それが原因でSEOに悪影響が出たらどうしよう……？ そんな心配の声が上がったのも無理がありません。
そこで生まれたのが【SSR】というわけですね。ニーズとしてはSPAの利便性を保ったまま、SEOにも対処したい。だからベースはSPAのままで、レンダリングの一部をサーバーへ託しているわけです。
どのようにサーバーでJSを起動しているのかと言えば、皆さん大好きNode.jsの出番というわけですね。
サーバーでレンダリングを実行しているわけですから、ダウンロードする頃には完成したHTMLを閲覧することが可能です。
初回アクセス時にさえ、サーバーサイドでレンダリングできていれば良いわけですから、ページ遷移の挙動はSPAそのままだったりします。
メリットと言えば、学習コストが非常に低いことも挙げられますね。なんたって、初回レンダリング以外はそのまんまSPAなわけですから。
SPA開発に馴染んでいる方であれば、一日で【SSR】の開発もそつなくこなせるようになるでしょう。（MPAからSPAへの移行コストはかなり重たい印象ではありますが）
まとめ
新しい技術とは開発者にとって極上の食事です。ついつい飛びつきたくなるのが性というもの。しかし、最新の技術をどうして採用するのか、その理由が曖昧なままでは悪影響を及ぼしかねません。
今回の例で言えば、SPAから【SSR】への移行コストは低いものの、そもそもSEOを気にしないサイトであれば移行する理由が薄いわけでして。下手な労力をかけずにSPAのまま運用しても問題ありません。
その技術が何をもたらし、対価にどれだけのコストを要求するのか。そういった事柄にも目を向けながら開発に携わっていけるよう、僕自身も心掛けていきたいものです。
お知らせ
ecbeingでは新進気鋭なエンジニアを募集しております！
careers.ecbeing.tech
