はじめに
SSR（Server Side Rendering）とCSR（Client Side Rendering）は、Webアプリケーションでよく耳にする言葉ですが、最初は「何が違うの？」と思いがちです。そこで今回は、それぞれの特徴をカレー作りで例えてわかりやすく説明しつつ、どんなサービスに向いているのかもご紹介します。
プログラミングは料理と同じ
私は駆け出しのエンジニアですが、学びの過程で「プログラミングは料理と似ている」と感じることがよくあります。料理をしたことがない人が、いきなり「フランス料理を作って」と言われても難しいように、プログラミングでも最初から複雑なシステムは作れません。
食材の切り方や火加減を学ぶように、プログラミングも基本の構文やロジックを一つひとつ身につけることが大切です。私自身も日々少しずつ積み重ねています。
焦らず、玉ねぎを飴色になるまで炒めるように基礎を丁寧に学んでいけば、やがて自分だけの“味”を出せるようになります。ぜひ一緒に学び、成長していきましょう！
SSRとCSRとは
-
SSR（Server Side Rendering）
サーバー側でHTMLを生成してクライアント（ブラウザ）に送る仕組みを指します。サーバー側でページのレイアウトやデータを組み込んで完了した形のHTMLを返すので、ユーザーはページを開いてすぐに完成した画面を見ることができます。一方、サーバーへの負荷や通信量が多くなる可能性があります。 -
CSR（Client Side Rendering）
クライアント（ブラウザ）上でJavaScriptが動き、HTMLを生成する仕組みです。最初は最小限のHTMLが返され、ページの表示や動的な要素の生成はブラウザ上のJavaScriptが担います。ユーザー側の端末で処理を行うため、インタラクティブなページを実現しやすい反面、初回表示が遅れる可能性があります。
カレー作りで例えると・・・
-
SSRは「完成したカレーを配達するイメージ」
カレーを作ってくれる人（サーバー）が、すべての工程を完了させてからユーザー（お客さん）に届けるイメージです。できたてアツアツで、パッと食べ始められますが、一度に大量の注文がくると、作る側（サーバー）の負担が大きくなり、配達（通信時間）も必要です。 -
CSRは「スパイスセットや下ごしらえの材料を送って、ユーザーが仕上げをするイメージ」
カレーのベースとなるスパイスや材料（JavaScriptのコード）をユーザー（ブラウザ）側に送って、最終的な仕上げを自分たちで行います。一度準備（初回読込）は少し時間がかかるかもしれませんが、そのあとは好みに合わせてスパイスを調整したり、トッピングを加えたりと拡張がしやすく、ユーザーに合わせたカレーを自由に仕上げることができます。
向いているサービス
-
SSR（Server Side Rendering）が向いているサービス
-
SEOを重視するサイト
（検索エンジンはJavaScriptで動的に描画するサイトを、必ずしも完全に読み取れない場合があるため、SSRで生成された静的HTMLが有利となる） -
初回表示速度を重視するサービス
（ユーザーが素早くコンテンツを見られるようにしたい場合） -
コンテンツ重視のサイト（ブログ・ニュースサイトなど）
（シェアやブックマークが多く、ページの読み込みが頻繁に行われる場合）
-
SEOを重視するサイト
-
CSR（Client Side Rendering）が向いているサービス
-
SPA（Single Page Application）
（画面遷移を少なくし、ダイナミックにUIを変化させたい場合） -
ユーザーのアクションによってリアルタイムにデータを表示・更新するようなインタラクティブなアプリ
（チャットアプリやリアルタイムダッシュボードなど） -
大規模なフロントエンドフレームワークを活用して、画面間の動きにこだわりたいプロジェクト
（React、Vueなど）
-
SPA（Single Page Application）
まとめ
SSRとCSRはいずれもWebアプリケーションを動かすための「レンダリング手法」ですが、それぞれメリット・デメリットや向いているサービスが異なります。
-
SSR
- SEOや初回表示の速度を重視したいサイトに向いている
- 完成したカレーをすぐに配達するイメージ
-
CSR
- ユーザー操作によるダイナミックな変化を求めるSPAに向いている
- スパイスをユーザー側に渡し、自由に仕上げるイメージ
カレー作りを思い浮かべながら、SSRとCSRの特徴を考えてみると理解しやすいかもしれません。みなさんもぜひ、自分なりの“スパイス”を加えて、より美味しいWebアプリケーションを作っていきましょう！