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

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

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

SPAは管理画面などログイン前提のサービスに向いている

井村：「SPAとSSGとSSR、それぞれ向いてるアプリケーションのタイプで言うと、まずSPAのデメリットとしてはOGPが勝手にはできないとか、SEOは最近Google先生も解釈してるって話はあるんですけど、実際どこまでHTMLが向こうに解釈されているかは、ここの部分は出てるけどこっちの部分は出てないっていうのもありえなくはない。例えば、モーダルの中とかアコーディオンの中とかっていうのは、書き方によっては出ないかもしれないので、若干そのあたりがGoogle先生のブラックボックス頼みになってるっていうところがあったりとか。
あとは初回がJavaScriptがドーンと落ちてくるので、初回のアクセスの読み込みが（そこからのページ遷移は早いんだけど）遅いみたいなところがありまして。
結論何に向いているかっていうと、基本的には管理画面系はSPAでほぼ問題ないというか、逆にSSRとかSSGにすることはほぼないと思います。」

中村：「業務システムアプリケーションとか？数字だけを見るとかテーブルいっぱいあるとか、そういう系ですよね。」

井村：「そうですね。あと管理画面というか、ログインが発生するものって基本的にはそのユーザーごとに内容が全然違ったりとか、リアルタイムの更新が必ず求められるじゃないですか。管理画面であるデータ更新したのに、別のページでは変わってないみたいなとかはありえないし、ユーザーが百人いたら百通り全部違う内容が出ているので。
いわゆるログインして使うようなもの、to Cだろうがto Bだろうが、そこのSEOって当たり前だけどクローラーが元々入ってこれない、認証がないから。検索に引っかけるようなものではないし、OGPでシェアするようなものでもないので。我々の作っているアプリケーションは大半SPAで作ればOKみたいなものが多いですかね。」

中村：「管理画面系以外だと何かあります？」

井村：「例えばだけど、メルカリみたいなサービスが（メルカリはアプリだけど）Webでもやってたとして、ログインする場所だけではないじゃないですか。ログインしなくてもちゃんと商品が見れるとかだとちょっとSPAだと難しいかなと思うんだけど、完全にそのログインした後しか使わないようなもの…」

中村：「ああ、自分の中で完結するものってこと？」

井村：「そうだね、to Cだとログインしなくても、それなりに見れる場所が、例えば記事だけは見られるとか、商品は見られるとか、そういうのが結構多いから、そういう意味ではめちゃくちゃ全部が全部当てはまるって感じじゃないけど、どっちかっていうと業務システムとか、ちょっと中身分からないけど、例えばスマートHRみたいなものとかその人事の人がログインしてその中で使う。だからログインしないで触る画面があまりないようなものはSPAで結構作りやすいというか、向いてるアプリケーションかなと思います。

中村：「SPAが採用されている理由がここにきて初めて理解できた気がします。」

井村：「to B系のSaaSみたいなやつは大半当てはまるんじゃないかな。逆にto Cは一部ログインするにしても外に出ている部分っていうのが結構あったりするので。」

中村：「SPA続きでいくと、デザイナーとして気を付ける部分ってあります？」

井村：「SPAはSSGと比べて作る方からすると一番簡単っていうと言い方悪いけど、そこの三つの中で言うと一番考えなきゃいけないことが少ない。レンダリングも一回しか走らないし。なので他のものの方が考えることが多いかなって感じかな。」

中村：「じゃあその差分で後でSSRとSSGで聞きますかね。」

井村：「そうね。確かにデザイナー考えなきゃいけないとかあるかもしれない。逆にね、普段ヤスタカもSPAのデザインとかやってること多いと思うんで、こういうのでちょっとはまったなとか、もし思い出せれば。」

中村：「SPAは今まで考慮したことがあまり考慮されなくても、そのままスムーズにいってしまって便利だなって思っているところがありますね。」

井村：「じゃあまずはSPAは管理画面とかto B向けのSaaSとかに当てはまるのが多いですよと。」

中村：「はい、ありがとうございます。じゃあ次SSGいきましょうか？」

SSGはコーポレートサイトやメディアサイトに向いている

井村：「はい、SSGが向いているのはコーポレートサイト。あとはメディア。記事があってそれをユーザーが読むみたいなもの。」

中村：「日経新聞とか、いわゆるそういうメディアも含めて、全体的に向いている？」

井村：「そうですね。ただちょっと日経とかだと記事数が膨大だとか、あとリアルタイム性がものすごく求められるもの、例えばビルドの時間ってのはどうしてもかかってくるので、もうちょっと記事数が少なくてリアルタイムで更新しなくても良いもの、例えばニュースサイトとかはちょっと向いてないと思ってて、ニュースってタイムリー性がすごく求められるじゃない？記事数も多くなりがちだから、例えばその百記事ぐらいとか200記事とか場合によって1000記事とかぐらいのメディア。
で、あともう一個、うちでっていうか個人的に結構いいなと思ってるのがEC。例えば商品載せました、それが0秒後に反映されてないといけませんっていう話じゃなくて、別にそれが10分後に出ようがそんなに変わらないじゃないですか。ってなると、ECも結構向いてるんじゃないかなって個人的には思ってます。」

中村：「サーバで事前にレンダリングされてるものを表示するのがSSGですよね。」

井村：「そうね。例えばCIって呼ばれるような事前にビルドを一気にしておいて、それを公開用のサーバにドンって公開するっていうもので。」

中村：「念のための復習でした。なるほど理解できました。」

井村：「全部共通しているのは当たり前だけどSEOは結構必要だし、いわゆるシェアされてOGPの対応も必要だし、あとはテレビとかで紹介されたりとかして、SSGのいいところって、どこにホスティングするかにもよるんですけど、例えばAWS S3みたいなところにホスティングした時に一切負荷がかからないんですよ、基本的に。
で、特にログインしなくていいものに関しては、例えばメディアの記事って別にAさんが見ようが、Bさんが見ようが、Cさんが見ようが、内容って全部一緒じゃないですか？変わることないじゃん。記事の内容とかが基本的にね。で、特にログインが無いサイトだと、もう書いたものがそのまま出てくるだけっていう感じだから、そしたら都度サーバとかクライアントで描画する必要が全然ないんだよね。
コーポレートサイトも一緒じゃん。基本的には誰が見ても同じページだから、本当にサーバにHTMLをポンって置いておけば、めちゃくちゃ速いし絶対にサーバが落ちないしで、なおかつSEOとかもしっかりしてるみたいなところで考える。
あと、セキュリティ面でも、後ろにデータベースがあったとしても、もうビルドされたものってのはそことはつながってないので、よくWordPressでやると管理画面に入られちゃうとか、WordPressじゃなくてもそういう管理画面にアクセスされてしまうみたいなことがちゃんとやればできなくなるというか。」

中村：「作りがしっかりしていてセキュリティ的には安全。」

井村：「そう、速くてセキュリティが全く問題なくて、なおかつサーバが、例えばね、ECだと商品が急に紹介されることってあるじゃない？テレビで。そういう時にも落ちないっていうのは。あとサーバ代も安いし。」

中村：「サーバ代が安い仕組みがいまいちよく分かんなかった。」

井村：「AWS S3っていう。例えば、元々は画像を置いとくみたいな。Webサーバとして使うというよりかは、静的なものを置いておく場所みたいな感じだったから、そのサーバを動かしている方と比べると、そもそもの単価が安いというか、1時間当たりいくらみたいな、転送量でいくらみたいなのあるんですけど、そのレートが低いんだよね。」

中村：「たしかに圧倒的に安いみたいな話は聞いて、なんとなくは存じております。」

井村：「多分、普通100万PVとかでWebサーバ持ってホスティングしなきゃいけないとなると、その例えば数万円とか2万3万とか、少なくともかけなきゃいけないのが、AWS S3だけだとちょっと僕も正確なところは分からないけど、下手すると数百円とかで済む可能性もあるかなっていう。」

中村：「いや、そのぐらいの価格差があるということですね。」

井村：「そうね。しかも落ちない、メンテナンスしなくていいっていう中で、しかも値段も安いってなるとすごくメリット多い。」

中村：「なるほど。逆にコーポレートサイトで更新頻度が高い、例えばプレスリリースめっちゃ打つとかニュースリリースがめちゃくちゃあるコーポレートサイトとかだと向かないってことですか？」

井村：「それもリアルタイム性がどこまで求められるかかな。ビルドの時間がどうしてもかかるのと、コーポレートサイトってさ、ニュースリリース2万本とか書く人あんまいないじゃん。数十本とか数百本とかだとビルドの時間も早いんだよね。だから仮にビルドが走ったとしても、例えば5分以内にはデプロイできるとかだったら…」

中村：「新しいとこだけ時間がかかる？」

井村：「SSGの場合は元々全部ジェネレートし直すので時間かかるんだけど、今回多分話さないと思うんだけど、ISRっていうのが今あって。まさにさっき話してた、例えば、日経新聞みたいに何千万記事ありますみたいなサイトをどうするのかってなった時に、SSGだと対応できないのよ。下手すると全部やると2時間かかりますみたいなのが平気で起こるから。
ISRは今、社内でもいろいろ実験してて結構面白い仕組みなんだけど、すごい複雑なのでISR単品でちょっとやりたいなって感じ。この後紹介するSSG、SSRの合いの子みたいなのが出てきてはいるって感じだな。
今の段階で言うと、あくまであんまり記事数が少ないやつ、あとそのログインがある、例えばさメディアでもログインするのってあるじゃない？一部そのログインすることで、別のお気に入り機能が使えるようになるとか。」

中村：「ありますねえ。」

井村：「で、ECでも普通そうだと思うんだけど、ログインないECはあんまないと思ってて、それはそれで別にそのログインする前のところだけ静的に書きだしといて、ログインした後のところっていうのは動的に書き換えるっていう処理が走るので、それはそれで全然できるんですけど。
ただ、そうするとだんだんSPAにちょっと近づいてくる部分があるので。」

中村：「分かれてはいるけど、複合されているものも結構ありそうな話ですね。」

井村：「でも、元々はSSRじゃないと例えばOGPとかそういうメディアみたいなものって作れないんじゃないかって言われたんですけど、SSRって大変なんですよ、サーバ持たなきゃいけないし。環境もレンダリングもサーバサイドとクライアントサイドと2回やるっていうので、考えなきゃいけないことがすごい多い。本番環境に上げてみないとなかなか動きがイメージしづらいっていうのが結構あって。だんだんSSGでいいんじゃないみたいになってきてるっていう。」

中村：「サーバとフロントでバチバチするのがSSRっていう理解で合ってます？」

井村：「サーバとフロントでっていう意味だと、全部一緒かもしれないね。
SSRはフロントエンドやってて、SSRサーバまで立てられて管理できるっていう人が多分ほとんどいないっていうか、フルスタックエンジニアみたいになっちゃうから、そういう意味では明確にインフラエンジニアみたいな人がいないと、なかなかSSRはそもそも選択しづらい。最近そのマネージドサービスもあるけどね。
後はセキュリティ面とかを考えても、サーバってみんなが同じようにアクセスする場所じゃないですか。そこに残しちゃいけないデータを残してしまうというか。それがその他のユーザーと共有されちゃうみたいなことっていうのも、作りによってはあり得るので結構考えなきゃいけないことが増えるというか。」

中村：「なるほど。じゃ流れでそのままSSRに向いてるものいきますか？」

SSRはリアルタイム更新性が必要とされるものに向いている

井村：「SSRは今の話のそのSPAとかSSGに当てはまらないもの、どっちかっていうと最後の砦みたいな感じかなと思っていて。」

中村：「どちらでもできないみたいなものを、最終的にSSRでやるみたいな感じですか？」

井村：「一番は、リアルタイム更新性を求められるのと…要はSSGは選択できないじゃん？ビルドの時間がかかるから。さっきの日経新聞だったりとか。具体的に言うと、noteはNuxt.jsでSSRに移行しましたみたいなのが、技術的に外に発信されているんですけど、例えばnote書いて自分の記事反映されるのが5分後ですみたいなのってありえないじゃないですか。サービスとして。もちろん消したらすぐ消えてほしいしっていうのを実現しようと思うと、そもそもSPAかSSRしか選択肢がないので、その中でSPAはSEOの話だったりとか、今の諸々考えても選択しづらい。そうなると、SSRでってことになるんじゃないかなって。
さっきの日経とかもおそらくSSRじゃないと成り立たないと思うね。
記事数が多くて、ビルドが時間がかかりすぎる、なおかつOGPとかの対応ってのは絶対必須っていうことになってくる。」

中村：「SSRの利点？最終的にはそのカスタマイズ性とか含めるとSSRが高いってこと？」

井村：「そうだね、ここで詰まるみたいなものっていうのは、SSRが一番こわくないっていうか。
SPAとかSSGだと、一部の制限をかけてよりそこに特化した形で作ってるって感じになるので、SSGは分かりやすく商品とか記事数がどんどん増えていくと、ビルドがどんどん長くなるのと、途中でこんなの待ってられないですってなる可能性があるのと、あとは途中でリアルタイム性のあるコンテンツが必要になった場合…例えばよくあるのが、何月何日の24時ぴったりに新しい商品を公開したいとかっていうのは、普通にビルドしてるとそのズレがあって、毎回ビルドの時間って1分から5分ぐらいの間でブレがあるので、同じ記事数でも全く同じ秒数で完了するってわけじゃないんですよね。そういうのを考えると、APIのサーバの調子もあるし、何月何日何時ぴったりみたいな難しい。」

中村：「ビルドが終わった後の公開のタイミングって任意で決められないんですか？」

井村：「それは全ページ更新になっちゃうから。やろうと思えばできるかもしれないけど、そういう意味では、確かにヤスタカが言ったみたいに事前に手元でビルドしといて、何月何日に発射するっていうのはできるかもしれないけど、発射するのもそれなりに秒数かかるからね。」

中村：「ぴったりが難しい？」

井村：「そうそう。もしSSGでそういうのをやろうと思うと、事前にページだけビルドしておいて、そのフロントのコードで例えば404っぽく見せておくとか。ただ、時間はサーバサイドでコントロールするものなんですけど、それがクライアント側のコントロールになっちゃうっていうのはあるのであんまり良くない。あとAPI側でやるっていうのもあるけど考えることが多いというか。」

中村：「僕スマートフォンアプリ系の開発畑出身だったので。Webのリリースのタイミングとかのイメージがいまいち掴めなかったところがあったんで、ちょっと賢くなれて良かったです。
SPA、SSG、SSRの、それぞれデザイナーとして気を付けるところ。SSRは割とカスタマイズ性が高いから、気を付けるべきところは色々ありそうだなと思います。」

井村：「デザイナーとしてって言うと、そんなにないかもしれないね。SSRは要件定義とか、エンジニアはちょっと気をつけた方がいいと思ってて、ページの中でサーバサイドでレンダリングしてほしいところと、クライアントサイドでレンダリングを再度やらなきゃいけないところが入り乱れてくるので、そこの要件定義が結構大事。
ミスするとみんなに同じものが出ちゃうっていう風にもなるし、逆に全部サーバサイドでレンダリングすればいいじゃんってなると、それはそれで個人個人に対応出来ないところもあるので。」

中村：「これあれですね。ユーザビリティの話とか色々な話が要件に絡まってくるわけですね。」

井村：「SSGもそうだけどね。どこまで静的に書き出すかで、バックエンドのAPIを呼ぶ回数というのが変わってくるので、フロントが生きててもバックエンドが死んじゃうっていうのがあって。」

中村：「SPAに向かないやつってあります？超巨大だと読み込みにめっちゃ時間かかるとか、そういう話ってあったりするのかな？」

井村：「それは最初に話したみたいに、SEOを考えるとちょっと怖いっていう。これからもしかしたらどんどんSPAだけになっていく可能性はあるけどね。」

中村：「JavaScriptを実行する時間ってめちゃくちゃ長くなる可能性ってない？」

井村：「実感がないっていうよりかは、ダウンロード、ネットワークってそんなにめちゃくちゃ一気に速くはならないじゃん、いくら頑張っても。5Gとか出てきてるけどね。今も4Gになったから多分JSとかこれだけ書いても、あと画像ばんばん使っても大丈夫だったけど、10年前の回線で今みたいなサイト作ってたら多分落とせない。」

中村：「最近、画像とか別にあんま気にしなくていいよみたいな…気にしなきゃだめなんですけど。」

井村：「だって4Gがそもそも速いからさ、別に外でスマホ触っても…」

中村：「解像度優先というか、美しさ優先で画像が作りやすくなったんでね、やりやすいですね。こんなでかい画像を出す意味ある？みたいな話とかも逆に出てきたりしてね。」

井村：「5Gが当たり前になってくれば、その辺ももっと気にしなくてよくなるかもしれないね。」

中村：「いや逆にそのもっと高解像度に出さなきゃいけないみたいな話が出てきてるなと思って。」

井村：「動画ばんばん使ったりとかね。そういうサイトも増えてくるかもしれない。」

中村：「マルチデバイスの解像度で、Webよりもむしろスマホの方が解像度高く見えるからとか、72dpiじゃない方がいいとかいうのが出てきたりしてね。」

井村：「リアルタイムのそういう対話とかも全然会話できますよみたいなね。ドコモとかよく宣伝してるけど、本当にそうだと思うんで。」

中村：「やあ、変わってきましたね。時代がね、1ピクセルの色を減らすみたいなことをやってた時代が懐かしいですね。
じゃあ、この話題はまたもしかしたら続きがあるかもしれないということで。」

井村：「今日はこんなところにしましょう。ありがとうございました。」