SSRとCSRでどのくらいパフォーマンスに差が出るか計測してみた
Makuake Advent Calendar 2023の11日目の記事です。
CoreWebVitalsみたいなフロントエンドのパフォーマンスに関して、よく「FEのパフォーマンスはSSRの方が有利」というのを聞きますが、SSRとCSR(SPA)でどのくらい差がでるのか？簡単にでも良いから測ってみようと思い立って、実際にやってみました。
使ったアプリケーション
OpenWeatherMapのv2.5APIに緯度経度を渡して天気情報を表示するというもの。
中身はNuxt3を使っていて、CSRの方はssr: falseにしています。
ソースコード
インフラ構成
DockerでNuxt3を動かしてAppRunnerにデプロイしました。今回はCloudFrontは置かず、キャッシュヒットはしない前提で試しています。
前提条件
- https://www.webpagetest.org/ を利用
- Test Locationは
Tokyo Japan - EC2 - ブラウザはChromeにして、回線速度は4G（モバイル）とCable（デスクトップ）でそれぞれ計測
4G (9Mbps, 170ms RTT)の場合
SSR
| 回数 | TTFB | Start Render | FCP | Speed Index | LCP | CLS | TBT | DC Time | DC Requests | DC Bytes | Total Time | Total Requests | Page Weight |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1回目 | 1.110S | 1.200S | 1.196S | 1.839S | 2.623S | .018 | .000S | 2.616S | 10 | 162KB | 3.294S | 11 | 162KB |
| 2回目 | 1.186S | 1.200S | 1.251S | 1.943S | 2.678S | .018 | .000S | 2.675S | 10 | 162KB | 3.365S | 11 | 162KB |
| 3回目 | 1.105S | 1.200S | 1.191S | 1.676S | 2.582S | .018 | .000S | 2.571S | 10 | 162KB | 3.255S | 11 | 162KB |
CSR
| 回数 | TTFB | Start Render | FCP | Speed Index | LCP | CLS | TBT | DC Time | DC Requests | DC Bytes | Total Time | Total Requests | Page Weight |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1回目 | .875S | 3.100S | 3.066S | 3.562S | 4.484S | .018 | .000S | 1.675S | 10 | 164KB | 4.454S | 15 | 167KB |
| 2回目 | .877S | 3.000S | 3.033S | 3.476S | 4.454S | .018 | .000S | 1.661S | 10 | 164KB | 4.433S | 15 | 167KB |
| 3回目 | .874S | 3.100S | 3.122S | 3.576S | 4.506S | .018 | .000S | 1.679S | 10 | 164KB | 4.472S | 15 | 167KB |
Cable (5/1 Mbps, 28ms RTT)の場合
SSR
| 回数 | TTFB | Start Render | FCP | Speed Index | LCP | CLS | TBT | DC Time | DC Requests | DC Bytes | Total Time | Total Requests | Page Weight |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1回目 | .506S | .600S | .595S | .981S | 1.487S | .018 | .000S | 1.484S | 10 | 162KB | 1.629S | 11 | 162KB |
| 2回目 | .472S | .500S | .549S | .923S | 1.457S | .018 | .000S | 1.453S | 10 | 162KB | 1.590S | 11 | 162KB |
| 3回目 | .290S | .400S | .367S | .781S | 1.276S | .018 | .000S | 1.267S | 9 | 160KB | 1.410S | 11 | 162KB |
CSR
| 回数 | TTFB | Start Render | FCP | Speed Index | LCP | CLS | TBT | DC Time | DC Requests | DC Bytes | Total Time | Total Requests | Page Weight |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1回目 | .183S | 1.100S | 1.115S | 1.406S | 2.021S | .018 | .000S | .558S | 8 | 160KB | 2.001S | 16 | 167KB |
| 2回目 | .185S | 1.100S | 1.100S | 1.406S | 2.000S | .018 | .000S | .578S | 9 | 163KB | 1.980S | 15 | 167KB |
| 3回目 | .182S | 1.100S | 1.095S | 1.406S | 1.995S | .018 | .000S | .577S | 10 | 164KB | 1.967S | 16 | 167KB |
感想
TTFB(Time To First Byte)こそCSRが勝っていますが、他は大体SSRが勝っていて、正直思っていた以上に結果に差が出ました。簡易なアプリケーションではそこまで差が出ないかな？と思っていましたが、そんなことは無さそう。もちろん作り方にもよると思いますが、4G環境では2秒近くの差が出たりと、無視できません。
速度の面だけ見るとSSRが優秀！となりますが、Nodeのサーバーが必要になるので、その分のサーバー運用コストがかかることになります。
CSRの方は今回は単にNuxt3の設定を変えただけでしたが、S3にstaticなコンテンツを置いて配信させることができるので、運用コストを下げることが可能です。
一方でCSRの方はユーザーの回線環境によってパフォーマンスにかなり影響を受けてしまいます。
SSRが良さそうな場面
- ECサイトなど表示速度が離脱率や売り上げにも影響を与えやすい
- スマートフォンからのアクセスが多い（4G等の回線で見てる可能性が高い）
- サーバーの運用にコストを割ける
CSR(SPA)が良さそうな場面
- PC（WiFi環境）からのアクセスが多い
- BtoBのSaaSなど表示速度が直接離脱率や売り上げに影響を与えにくい
- サーバーの運用にコストを割きたくない
他にも色々変数はあると思いますが、パッと思いつく使い分けとしてはこんな感じかなと思います。どちらもメリットデメリットあるので、トレードオフを意識しながらサービスに求められる特性や、会社の状況に合わせて使い分けていきたいですね。
Discussion