Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
102
Help us understand the problem. What is going on with this article?

More than 1 year has passed since last update.

@akashixi

SSR、SSG、Client Side Renderingの違いをまとめた

SSR、SSG、ClientSideRenderingの違いについて言語化。Next.jsチュートリアルの説明が個人的に一番わかりやすい。Pre-rendering and Data Fetching

Client Side Rendering

「Client Side Rendering = SPA」の文脈で使われることが多い気がする。

ブラウザ上でJavaScriptを実行してDOMを生成、マウントし、コンテンツを表示させる。SPAアプリの場合、以下のような中身が空のHTMLファイルを使うことが多い。

index.html
<html>
<head>
<title>sample</title>
</head>
<body>
<div id="app"></div>
<script src="/js/bundle.js"></script>
</body>
</html>

上記のHTMLファイルはルートディレクトリ直下に置くのが普通なため、/以外にリクエストが送られると404となる。開発時はwebpack-dev-serverがよしなに面倒を見てくれるが、ホスティング先ではそうではないので、初めてSPAでアプリを作ってホスティングしたときに戸惑うやつ。

なので、どのルートにリクエストが送信されても、上記のHTMLファイルがダウンロードされるように設定が必要。

「Vue.jsやReactを使っている = SPA」ではない。LaravelやRailsなどのテンプレートファイルにVueやReactコンポーネントを埋め込んで使う例もある。

メリット

  • ページ遷移が非常に高速(非同期で必要なデータを取得する場合は、そのコンテンツが表示されるまではラグがある)
  • 最低限必要なものはHTMLファイル、JSファイルのみであり構成がシンプル。この2つをホスティング先に置いておけばとりあえずページは表示される

デメリット

  • JSファイルが実行、評価されてDOMがマウントされるまでコンテンツが何も表示されない
  • JSファイルのサイズが大きくなると、ファイルダウンロードの時間が無視できないレベルになる
  • SEOで不利(クローラーがJavaScriptを実行できるようになったとのことなので、この問題は解決されつつある。ただ、即時的に評価されるのではなく、評価までにラグがあるらしい)
  • TwitterやFacebookのクローラーはJavaScriptを実行しないため、プレーンなSPAアプリだと動的なOGP対応ができない

SSR

「Server Side Rendering」の略。Vue.jsやReactコンポーネントをサーバー側で評価、実行し、その結果を配信する。

オリジンサーバーにリクエストがあるたびに上記の処理を行い、HTMLファイルを生成する。そのため、サーバーの負荷は他の2つより高くなる傾向があり、TTFB(Time To First Byte)の時間も長くなる。

JSファイルを配信しないというわけではない。インタラクティブな表現のためのJSファイルは必要。

Nuxt.jsやNext.jsを使って実装するのが楽。

メリット

  • レンダリング後のファイルを返却するためコンテンツ表示までの時間を短縮できる
  • SEOで不利を背負わない
  • 動的なOGP対応が可能

デメリット

  • キャッシュ設定が複雑になりがち
  • SSRするためのWebサーバーが必要になる

SSG

「Static Site Generator」の略。「SSRする」は意味が通じるが、「SSGする」は元の言葉の意味を考えるとおかしい気がする。

アプリのビルド時にあらかじめページ表示に必要なデータを取得し、各ページごとに静的なHTMLファイルを出力しておく。そしてサーバーへのリクエスト時にはこのHTMLファイルを返却する。

たとえばヘルプページなんかはユーザーごとに表示するコンテンツが変わるわけではない。それなら最初から静的なファイルとして用意しておけばよくね?的な発想。

ブラウザが静的なHTMLファイルを取得するのはサイトへの初回リクエスト時のみで、ページ遷移時には代わりにJSONファイルを取得し、動的に変化する部分はこのJSONファイル内のデータを使ってレンダリングする。

上記はイメージがつきにくいが、実際に自分で試してみるとわかりやすい。

Nuxt.js、Next.js、Gatsby.jsなどが対応。Next.jsではSSRとSSGを混在させることもできる。

メリット

  • ページ表示までに必要な時間はClient Side Rendering、SSRより高速
  • SEOで不利を背負わない
  • 動的なOGP対応が可能

デメリット

  • 外部からデータを取得している場合、外部データが更新されたタイミングで再ビルドを行わないと変更は反映されない
  • 上記の仕様から動的なデータが頻繁に変更される場合は採用しにくい。その場合はSSRのほうがマッチする

まとめ

要件的にSSGを選択できるなら、そちらのほうが良さそう。SSRとSSGのメリットはよく似ているが、メンテナンス性などを考えると基本的にSSGのほうが楽になるはず。というより、SSRは消極的に選択される手法な気がする。。。

102
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
102
Help us understand the problem. What is going on with this article?