そもそもSSGってなに？
Static site generator。
静的なファイルを生成し、CDNに配置する。
動的なページではない場合に使える。(ニュースやブログ等)
なぜ静的なファイルを生成するといいの？
- クライアント側での初期データ(ニュースやブログで言う記事データ)を取得するAPIコールが不要になり、データの表示が早くなる
- 1のおかげでGoogle botなどのクローラはデータが挿入された意図通りにレンダーされたページを読み込むのでSEO的によい
- 静的なHTMLをCDNに配置することでWebサーバーを介す必要がなくなり、レスポンスが早い
つまりユーザー体験が向上し、さらに(ユーザー体験が向上した結果)SEOの評価向上に繋がる。
SSGが出てくるまでの経緯
React.js等DOM操作ライブラリの台頭
これまではRuby on RailsやDjangoのように、ページに掲載する情報はHTMLとしてサーバーがビルドしてクライアントに返していた。
しかし現在React.jsやVue.js等、ブラウザ上でJavascriptを使ってDOMを操作しHTMLを構築する技術が主流になっている。(そのおかげで動的なページ作成が容易になりユーザー体験や開発体験が向上した)
しかしHTMLはクライアント側で構築されるため、基本的にはサーバーが返すHTMLにデータを入れ込む事ができない。クライアント側が、HTMLやJSを取得した後に非同期でAPIコールを行いデータを取得する事になる。
1 - [Web server] <=(HTML取得)=> [Client]
2 - [Web server] [Client] =(データ取得)=> [API server]クライアント側でデータを取得する弱点
クライアント側でデータを取得する分、レンダーがAPIリクエストのレスポンスが帰ってくるまでその分遅れる。
またそうしたレンダーのタイムラグのせいで、データがまだ反映されていない空白のページとしてGoogleに認識されてしまい、SEO的なデメリットが発生する場合もある。
SSRによる解決
そこでサーバーサイドでデータを取得して、データが挿入されたレスポンスを返すSSR(Server side rendering)が登場した。
これによりデータ取得はクライアントサイドで行う必要がなくなった。
1 - [API server] <=(データ取得)= [Web server] [Client]
2 - [API server] [Web server] <=(データ入ったHTML取得)= [Client]でもSSRよりSSGがベターな場合がある
SSRによってクライアント側のデータ取得が必要なくなったが、レスポンス毎にWebサーバーがAPIコールや計算をしている。
クライアントによって異なるデータを取得する必要がある場合を除いて(ログイン済みのページ等)、ニュースやブログ等の場合同じHTMLを返せばよい。
そういう場合はレスポンス時にデータを取得してHTMLを作成する必要はなく、データが更新された段階でHTMLを生成すればよい。
このブログで言えばブログ記事が投稿されたことをトリガーにHTMLを生成すればよい。
0 - [API server] <=(データ取得)= [Web server] [CDN] [Client]
0 - [API server] [Web server] =(配置)=> [CDN] [Client]
1 - [API server] [Web server] [CDN] =(取得)=> [Client]
しかもCDNに配置することでWebサーバーの計算する負担をなくせる。そしてレスポンスが早い。