コーポレートサンプルサイトをSSGにする

概要

コーポレートサンプルサイトはサイト全体がCSRの構成になっています。
これは、Kuroco管理画面での更新が即確認できる。ページ毎にクライアントサイドの処理かサーバーサイドの処理かを意識する必要が少ない。という利点があり、フロントエンドの構築にまだ馴染みがないユーザーにとって分かりやすい構成です。

コーポレートサイトの会社概要やニュースのページなど、表示する内容をバックエンドから都度取得する必要のないページは、デプロイ時に予め生成しておくことで、APIリクエストの数を減らし、表示も高速にすることが可能です。

本チュートリアルでは、コーポレートサンプルサイトの特定ページをSSGの構成に変更する手順を学びます。

備考

CSRとSSGの違いについて、詳しくはJamstackのアーキテクチャパターンを参照してください。

前提条件

このチュートリアルでは、コーポレートサンプルサイトの利用が可能な状態になっていることを前提とします。 まだの場合は以下のチュートリアルを実施してください。

備考

コーポレートサンプルサイトを利用する

HTMLレンダリング方式の変更はフロントエンド側の作業で完結します。 不明点がある場合はNuxt.jsのドキュメントを参照してください。

備考

https://nuxt.com/docs/guide/

レンダリング方式をSSGに変更する

対象ページに<ClientOnly>を追加する

デプロイ時はレンダリングをせず、クライアントサイドでのみ生成される箇所には<ClientOnly>を追加します。
コーポレートサンプルサイトの場合、プレビューページなど、レンダリング方式に関わらずクライアントサイドでのみ生成される箇所については既に<ClientOnly>が明示的に追加されていますので、ここでは以下の2ファイルに<ClientOnly>を追加します。

• /pages/ltd-news/detail/[slug].vue

 <template>
+  <ClientOnly>
   <div>
     <UiPageHeader
       :path="[{ label: '会員限定コンテンツ', to: '/ltd-news/' }]"

       </template>
     </div>
   </div>
+  </ClientOnly>
 </template>

 <script setup>

• /pages/mypage/edit/index.vue

 <template>
+  <ClientOnly>
   <div>
     <UiPageHeader
       :path="[{ label: 'マイページ', to: '/mypage/' }]"

       </div>
     </section>
   </div>
+  </ClientOnly>
 </template>

 <script setup>

SSGにするページのエンドポイントへのリクエストを調整する

エンドポイントからのデータを取得をサーバーサイドから実施するため、useFetchのserver: falseオプションを削除します。

例：/pages/contact/index.vue

 const { data: response } = await useFetch(
   `${config.public.kurocoApiDomain}/rcms-api/1/inquiry/1`,
   {
     credentials: "include",
-     server: false,
   }
 );

対象は8ファイル10箇所あります。

ページ	エンドポイント
/pages/index.vue	/rcms-api/1/news/list /rcms-api/1/ltd-news/list
/pages/company/index.vue	/rcms-api/1/content/details/company
/pages/contact/index.vue	/rcms-api/1/inquiry/1 (GET)
/pages/news/detail/[id].vue	/rcms-api/1/news/details/ /rcms-api/1/master
/pages/news/index.vue	/rcms-api/1/master
/pages/preview/news.vue	/rcms-api/1/master
/pages/privacy/index.vue	/rcms-api/1/master
/pages/service/index.vue	/rcms-api/1/master

サイト全体をSSGの構成にする

nuxt.config.ts を編集して、アプリケーション全体のサーバーサイドレンダリングを有効にします。 ssr: falseの部分をssr: trueに変更します。

import { defineNuxtConfig } from 'nuxt/config';

export default defineNuxtConfig({
  ssr: true, //サーバーサイドレンダリングを有効化
  runtimeConfig: {
    public: {
      kurocoApiDomain: 'https://**********.g.kuroco.app',
    },
  },
  app: {
    head: {
      title: 'front_nuxt_corporate',
  ・
  ・
  ・

ここまで実施したらnpm run devで表示の確認をします。 エラーが出る場合は修正漏れなどがないか再度確認してください。

デプロイする

表示に問題が無ければ変更をプッシュしてデプロイします。
ビルドが成功して表示が確認できたらレンダリング方式の変更は完了です。

バックエンドの変更の反映方法

SSGの構成になると企業情報のページなどはユーザーのアクセス時にAPIリクエストを送らなくなります。
これにより、事前に生成したHTMLを表示するため高速になりますが、再ビルドを実施するまでKuroco管理画面での変更が反映されなくなります。

例えば、Kuroco管理画面から企業情報のコンテンツを更新しても、これだけではフロントエンド側の表示は更新されません。

コンテンツの更新をフロントエンド側に反映させるには、GitHubのページで[Githubの連携対象]のブランチが設定してある状態で、 コンテンツ更新時に[Github Actions ワークフロー]を有効にして更新してください。

これにより、コンテンツ更新時にGitHub Actionsが実行され、フロントに反映されます。

備考

SSGにしています。コンテンツ更新後すぐにフロントに反映させるにはどうしたらいいですか？

他には、変更を反映したいタイミングでGitHubページの[Run Deployment]をクリックすることでもGitHub Actionsの実行が可能です。

ニュースページのアーカイブの表示ついて

コーポレートサンプルサイトのニュースページに表示しているアーカイブは、事前にバッチ処理でコンテンツ数を集計し、マスタに保存した値をAPIで呼び出して利用しています。

フロント

マスタ

バッチ処理

ユーザーのアクセス毎に、集計のためのAPIリクエストをする必要がないため、APIリクエストの数を削減できますが、コンテンツの更新やデプロイのタイミングによって、コンテンツ数の値がずれることがあります。

アーカイブの作成については、以下の方法もありますのでコンテンツの更新頻度やキャッシュ戦略によって検討してください。

• ユーザーのアクセスがあったタイミングでAPIを利用して集計する。その際、エンドポイントはできる限りキャッシュされたリクエストになるよう調整する。
• アーカイブの集計をコンテンツの更新後のトリガーに設定する。

関連ドキュメント

• Jamstackのアーキテクチャパターン
• コーポレートサンプルサイトを利用する
• コンテンツの更新時にGitHub Actionsを自動実行する