SPA, SSG, SSRはどんなアプリケーションに向いている？ （前編）

こんにちは！ファンタラクティブPRの石原です。
ファンタラクティブでは毎週、代表の井村とデザインマネージャーの中村が話すPodcast「FUNTERACTIVE Radio（通称ファンタラジオ）」を配信しています。

本記事は、Podcastで配信したエピソード「#41　SPA, SSG, SSRはどんなアプリケーションに向いている？（前編）」の書き起こしです。
ゆっくり内容を追いたい方はこちらの記事を、会話を聴く方がわかりやすいという方はぜひPodcastを聴いてみてくださいね。
（以下のリンクはSpotifyですが、Apple PodcastやGoogle Podcastなどでもお聴きいただけます。）

SPA、SSR、SSGはそれぞれ何の略でどういう定義？

井村：「今日はファンタラクティブの実際の仕事として実装の話とか、あとプロジェクトのマネジメントの話とかいろいろあって、実装の話をしたいなと。」

中村：「はい、今日はデザイナー視点でわからないところを社長にぶつけていく感じでいこうかなと思ってます。実装周りの基本的な用語のところから入っていけたらなと思うんですけど、いいですか？
SPA、SSR、SSGってあるじゃないですか。レンダリングがどうってやつ。あの辺の正式名称の確認からしていいですか。」

井村：「そうね。今日はちょっとそのあたりの話をさせてもらえたらなと思っていて。エンジニアでもそんなにSPA、SSG、SSR全部やったことありますっていう人ってあんまりいないので。
名前の話から言うと、SPAがSingle Page Applicationの略で、SSGがStatic Site Generatorで、SSRがServer Side Renderingっていう。実は同じSSでも全然違う話をしてる。singleとかserver sideとかstatic siteとか全然違う略語なんですけど。」

中村：「そう、サーバサイドレンダリングだけすごいわかりやすいなと思って。」

SPAはHTMLはどのページでも同じ、JSでレンダリングし直す

井村：「シングルページアプリケーションって5年ぐらい前からずっと言われてるけど、何なんだって話ある。」

中村：「あれだよね。ネイティブアプリじゃなくて、Web上でアプリケーションを起動できるぐらいのニュアンスで捉えてるんだけど。」

井村：「それで言うと全部アプリケーションなんだけど、動かし方がちょっと違って、大きく分けるとSPAと残りのSSGとSSRは近い部分があって。」

中村：「シングルページアプリケーションはフロント側のフロントサイドレンダリング？」

井村：「そうそう。ページ遷移の仕組みがちょっと違って、シングルページアプリケーションって同じページの中で遷移してても実はちゃんとは遷移してないというか。
元々のWebサイトって原始的なものだとHTMLがそれぞれにindex.htmlがあって、中に別のディレクトリがあってその中にまたindex.htmlがあってみたいな感じで。で、都度そのURLを叩いてそこに毎回httpのリクエストを投げにいくっていう感じなんですけど。
シングルページアプリケーションの場合は、それが全部JavaScriptで遷移しているように見えるみたいな。
クリックしても一からhttpリクエストを投げにいくわけではなくて、JavaScriptでURLが書き変わって、そこで中の情報だけもう一回取りにいってるみたいな状態。
だから実際は、1ページのシングルページの中で全部ページ遷移っぽい動きだったりとか、例えばもちろんモーダル開くとかもそうだし、Webサイトを見てるみたいな動きをしているっていう。」

中村：「だから、APIの通信は挟んでるんですよね？」

井村：「そう、ページ遷移はしてないんだけど、0から取りにいってはないけど、もちろんURLが変わって、そのURLによって中の情報っていうのは変わるじゃないですか。」

中村：「あー、必要最低限の情報の通信だけでするってこと？」

井村：「そうそう。いわゆるAjax通信とか言われるもので。」

中村：「はい、はい、理解した。あれですね。スマホアプリとかと構造は似てるんですかね？ローカル側にコンポーネントとか要素っていうのがあって、通信だけで必要な情報を落としてくる。」

井村：「そうだね。そうそう、そのAPIがあって、クライアントサイドとか、それがスマホだったり、PCの中で動いている部分があるっていうのは似てるね。」

中村：「一番最初のタイミングに、情報、コンポーネントとかデータとかがローカル側に持っていかれるってこと？」

井村：「そうそう。結構具体的な話になっちゃうけど、今言ってたみたいにSPAのデメリットというか苦手なところとしては、最初にJavaScriptの塊みたいなのがドンって落ちてくる。データは都度通信するとか。もちろん最初にバンっと取って来ちゃうこともできるんだけど、最初の初回のローディングが結構重いんだよね。で、次に遷移する時は結構速くて。っていうのがSPAの特徴であり、デメリットの一つかな。」

中村：「それを分割して取りにいくとか、ローディングの仕組みとか工夫とかって何かあったりするんですか？」

井村：「もちろんローディング自体はね。例えば、最初にローディング出しといてっていうのは全然あるけど、分割して取りにいくってのはちょっと難しいかなっていう。よっぽどものすごい高レベルなことをやらないとという、高レベルというか低レベルというか。」

中村：「なるほどな〜、いや、面白いな。僕、出身がゲーム畑なもんでね。昔よく3Dのゲームでバトルに入るときに、ローディングめちゃくちゃ挟むゲームあったじゃないですか。あれって3Dが展開されている時間を稼いでる時間だったりするんですけど、それに似てるなーって思いましたよ。そういうことですよね。」

井村：「そういうこと、そういうこと。」

中村：「なるほど。デザイナー的に気を付けるべき視点ってあるんですか？」

井村：「デザイナー的には、今作ってるサービスがSPAなのかSSGなのかSSRなのかっていう仕組みは理解してた方が良いなと思ってて、今言ってたみたいにどこでローディングが挟まるべきかみたいな話とかっていうのはやっぱあるし。」

中村：「パーツにすると軽いみたいなのは？ゲームほど厳密じゃなさそうだけど。」

井村：「それはでも、どのレンダリング方式でも、例えばもちろんだけど、動画を長尺にしたら重いとか、画像はjpgにするのかpngにするのか、それともWebPとか使うのかみたいな。
SPAに向いてるものって言うと、管理画面系とか、いわゆるSEOだったりとか、SNSにシェアとか、URLがあんまり関係ないもの…」

中村：「ちょっと待った、URLが関係ないものって何ですか。」

井村：「関係ないっていうか、特に一番わかりやすいのはそのOGPっていうシェアした時にFacebookとかTwitterとかに画像出たりするじゃないですか。
SPAは普通に作ると、どのページでも基本的な情報は一つになってしまって、要はSPAのページでHTMLを見てもらうと、どのページでも全部一緒なんですよ。で、そこにアクセスしてきてからURLをもう一回判断してJavaScriptで全部レンダリングし直すので、JavaScriptを理解してくれる、もちろんブラウザって普通にそうですし、あと例えばGoogleのHTMLのクローラーは最近JavaScriptを解釈するって言われているので、SPAのサイトであろうがちゃんとクロールしてくれるって言われているんですけど。
ただ、FacebookとかTwitterのそのOGPの仕組みっていうのは、本当に書いてあるHTMLをそのまま解釈するだけなんで。例えば記事詳細ページにいっても、普通にトップページみたいなOGPになっちゃうっていうか。」

中村：「SEOが不利だとか言われてるのはそういう原因ってこと？」

井村：「今の話はSEOとはあまり関係なくて。SEOはクローラーがいるから解釈してくれるらしいんだけど、要はそこでちょっとブラックボックス感あるじゃない？例えば、Googleのクローラーがじゃあどこまで本当にJavaScriptを解釈してるのかはわからないから、多分大丈夫だと思うし、実際実績としても別にSPAで作ってもインデックスされているサイトでいっぱいあると思うんですけど。ちょっと怖いぐらいのニュアンスなのかなと。ここはちゃんと検証すれば、別にSPAでもSEOは必ずしも中の作りがちゃんとしていれば弱いとは言えないんじゃないかなと思う。」

中村：「弱いと言われてたのは、もう結構前の話みたいな感じですか？」

井村：「そうだね、多分出始めの頃はそこまでちゃんと解釈してないと思うので。でも他の方法、SSGとかSSRに比べたら不安が残るのは事実なので、特にそういうSEOで本当に食ってるようなサイト、SEOが流入のメインの経路ですみたいなところに、わざわざSPAで作るっていうのはちょっとリスクはあるよね。」

SSRはサーバを持ち、二段階のレンダリングをする

中村：「なるほど。はい、ちょっとSPAでずっといっちゃいそうなので、SSRいきます？SSGの方がいいですか？」

井村：「どっちもいこうかなと思うんですけど、さっきSSRとSSGが両方とも近いっていう話をしたのは、例えばNuxt.jsの場合もそのベースとなるモードっていうのはSPAモードかSSRモードかみたいな感じで、そのSSRの中にSSGが別の方法として入ってるみたいな感じなんですけど。
SSRの場合、二段階あるんですよね、レンダリングするタイミングが。SPAって1回しかないんですよ、レンダリングするタイミングって。
SSRの場合、まずサーバを持ちます。Node.jsなり何なりが動くサーバを持って、そこにアプリケーションデプロイしておきます。で、ユーザーがそこにアクセスしていきますよね。『なんたらかんたら.com』みたいなURLでアクセスしてきて、そうすると1回、サーバサイドでレンダリングがされてHTMLとCSSとJavaScriptのセットがユーザーに返ってくると、その時点である程度ページできてるんですね。で、さらにそれをクライアントサイドでもう一回JavaScriptが動いて、そのユーザーごとに見せなきゃいけない情報とかをレンダリングし直して表示が完成するっていう、サーバサイドのレンダリングとクライアントサイドのレンダリングっていうのが二段階で動くっていうのがSSRの仕組み。」

中村：「うんうん。個人的にはオンラインゲームの仕組みかなっていう解釈をしてるんですけど。ホスト側の色々なユーザーが集まっているところの情報と、自分のローカルのところが2回描画されるっていうのに近いなみたいな。厳密に言うと違うんですけどね。
これによるメリットっていうのは何ですか？」

井村：「SSRの方はいわゆる、元々は一般的なアプリケーションをPHPとかRailsとかで書いてた時って、当たり前だけど、クライアントサイドのJSっていうのはちょっと付け足しみたいなもので、基本はサーバサイドでRailsとかがデータベースと通信して、他のAPIとか通信して描画したHTMLを返してくるっていうのが普通だったので。どっちかというと、元々の普通のWebのあり方みたいな。」

中村：「何かその印象強いですね。」

井村：「うん。もちろんさっきのSEO問題とかOGPの問題っていうのも全部言われるごとに適切な情報をサーバサイドでレンダリングして返すので全く問題ないし、速度とかももちろんサーバのスペック上げたりとか、サーバ上で何かしらキャッシュしたりとかっていうようなことで、いわゆる今までのアプリケーション近いような形で返してくれるっていう。万能型といえば万能型です。一番癖がないというか。」

中村：「一番多い感じですかね？」

井村：「いや、多分だけど、SPAが一番多いんじゃないかなとは思ってて。なぜかというと、SSRってサーバを持たなきゃいけないんですよ。Node.jsが動くサーバ用意して、そこにアプリケーションもちゃんとデプロイしなきゃいけないし、あとはその二段階レンダリングが動くってのはちょっとややこしくて、ちゃんとチューニングすればすごい速くなったりとか適切になったりするんだけど、同じアプリケーションの中でどっちでレンダリングさせるかみたいなのを結構考えて設計しなきゃいけない。
SPAだと作る方はすごい楽でレンダリングも1回しかないから、どっちに書こうが結局同じことが走るっていうか。」

中村：「なるほどね…どちらにせよ知識がないと重たくなったり、操作性が悪くなったりっていうのもありそうですね。」

井村：「SSRがそんな感じで、かねてから人類はそのサーバを立ててそこにアプリケーションをデプロイしてたんですけど、サーバレスという言葉とかフレームワークが出てきて、要はサーバ持ちたくないっていう人が結構増えてるんですよね。特にフロントエンドの技術じゃないですか、こういうSPAとかって。フロントエンドエンジニアってそんなに別にサーバサイドにめちゃくちゃ詳しいわけでもないし、サーバ持ってるってことはいろんなコストがかかってくるというか、バージョン上がったらバージョン上げなきゃいけないし、セキュリティアップデートが入ったらセキュリティアップデートしなきゃいけないし、それこそ駐車場借りてるとか部屋借りてるとか、定期的にメンテナンスを入れなきゃいけないのと一緒のものが増えるんですよね。
SPAとかSSGの場合は、例えばamazonのS3っていう、ただ単に本当に静的なものをポンって置いておく、すごい簡易的な物置みたいなところで全部完結しちゃうので、費用も安くなるし、落ちることはないし、定期的にこっちでメンテを入れる必要もなくて。勝手にAmazonとかが時々アップデートしてくれたりとかってメンテナンスもしてくれるみたいな感じなので、そこの懸念が一つ減るっていう。」

中村：「そうっすね〜。サーバサイドエンジニアの数が、Amazonのサービスのおかげで人口変わったんじゃないかみたいな話をよく聞きましたけど。」

井村：「まあねえ。昔のインフラの方って、どっちかっていうとハードでね、データセンター行ってハードウェア組んでるみたいな方も多かったので。
それだけプロフェッショナルが必要な世界っていうか、サーバを作るのもそうだし、監視とか維持ってすごい大変なので。もちろん大規模なサービスだったらちゃんとサーバ立ててSSRするっていう方がいいと思うんですけど、小規模なサービスとか、管理画面とかに都度サーバを立てるのかっていうと、やったところで担当者がずっと張り付けるわけでもないし。」

中村：「サーバサイドエンジニアって基本的に勤務時間が不規則になるイメージがありますな。」

井村：「本当にちゃんとね、それこそ24/365（24時間365日）で監視とかになると、当たり前だけど。」

中村：「24/365って略し方するんですね（笑）。
確かにその反応速度みたいなところをすごく大事にしてたなっていうのをちょっと思い出しますね。」

井村：「普段からずっとってことはないんだけど、いざ落ちたとかね。障害になったってなると、夜中も動いているサービスだったらね、誰かが作業しないと動き始めないから。」

中村：「なるほど。」

SSGはサーバサイドのレンダリングを事前に行うので速い

井村：「最後SSGなんだけど、SSGの場合はさっきのサーバサイドのレンダリングとクライアントサイドのレンダリングで二段階あるっていうところは変わらなくて。で、そのサーバサイドのレンダリングっていうのを事前にやっちゃう。
サーバサイドレンダリングは、リアルタイムでユーザーが来る度にサーバサイドでレンダリングしてるんですけど、それを事前にビルドっていう形でHTMLに全部書き出しちゃうっていう。サーバサイドレンダリングを事前にやっておくみたいな。
例えばそのビルドの時間って5分とかかかるんですけど、そのビルドした後のものをサーバとかS3とかそういうホスティングする場所にポンって置いておく。あとはユーザーはそれを取りに来てクライアントサイドのレンダリングだけが後で走るっていう状態にしておく。
そうすると、なんとなく今ので想像つくと思うんですけど、まず速いんですよね。
サーバサイドのレンダリングをリアルタイムでやらないので、その分の時間がアクセスのときに早くなるっていうの？1回レンダリングをその事前に省いておくというか。」

中村：「レンダリングを先にやるっていうのは、つまりどういうことだ？」

井村：「さっきSPAのときって全部HTMLの中身スカスカで、何もないよって話をしたと思うんですけど、例えばメディアで100記事あるメディアがありましたみたいなので、SSGを事前にやっておくと、まずそのビルドの時点で全部中身までHTML書き出しちゃうんですよ。要は記事の内容とかAPIから取ってきて、1回そのHTMLとして、記事の内容って別に人によって変わったりしないじゃないですか、見る人によって。
なので、そこをもう書き出しちゃって置いておくと。そうするとブラウザでアクセスしたときにHTMLも全部ある状態。」

中村：「はい、はい。つまるところ、SSGはサーバサイドレンダリングの一種とも言える？」

井村：「そう、事前にビルドしてっていうのはフロントの仕組みとしては結構近い。2種類レンダリングがあるっていうのは。ただレンダリングするタイミングとか場所が違うっていうのかな。」

中村：「なるほどね、理解した。ローカルで描画されているわけじゃなくて、サーバ側の…静的サイトジェネレーター？」

井村：「Static Site Generatorだから、静的サイト生成だよね。」

中村：「サーバサイドレンダリングもう一回聞いていいですか？
一般的なサーバサイドレンダリングとSSGの違いがいまいち…SSGはわかったんだけど、サーバサイドレンダリングってなんだっけ？って今またなりました。」

井村：「サーバサイドレンダリングは、さっき話した話になっちゃうけど、本当にサーバがあってユーザーがいてユーザーがアクセスするとサーバで1回レンダリングが走って、ある程度のHTMLを生成して…」

中村：「あーわかった、トリガーが違うのか。アクセスした時にそこで初めて走るのね、レンダリングはね。だけど、SSGは先にレンダリングしてあった情報を拾ってくるってことか。」

井村：「ビルドするのは大体僕らの場合はCIって言って、ビルド用のサーバみたいなのは別にあって、例えば記事更新した時とか、あとはそのコード自体が変わってデプロイしなきゃいけない時にビルドを回しておいて、それをあと静的なサーバに設置しておくだけっていう状況にするっていう。」

中村：「うんうん。それぞれ3種類フレームワーク紹介しましたけど、どういう時に有効か？みたいな話…次回ですかね。ちょっとこれ色々まだ掘り下げられそうだなと。基礎的な理解が深まったところで、一旦この辺にしてきますか？」

井村：「そうだね。次回は、どんなアプリケーションに向いてるのか？みたいな話をちょっと考えておきます。」

中村：「賢くならないと。」

井村：「じゃあ、本日はそんな感じで、皆さんありがとうございました。」