HeadlessCMSを使った3つのサイト構築手法

目次

• はじめに
• SPA
• SSG
• SSR
• さいごに

はじめに

以下はHeadlessCMSを使った3つのサイト構築手法の比較表になります。

次の章から、それぞれの手法について詳しく説明したいと思います。

SPA

Single Page Applicationの略で、ブラウザでHeadlessCMSの情報を取得しレンダリングする手法です。ページを表示するまでの流れは以下になっています。

1. ブラウザからサーバーへリクエスト
2. サーバーは中身が空のHTMLをブラウザに返却
3. ブラウザはHeadlessCMSから記事のデータを取得
4. ブラウザが取得した記事のデータを表示

メリット

SPAの1番のメリットは、webサーバー等のインフラ環境のことをあまり考えずに開発できることだと思います。

SPAの場合は、ブラウザからHeadlessCMSのAPIにリクエストを行って情報を表示します。サーバーにはHTML、 CSS、 jsの静的なファイルさえ設置できればいいので、特別なインフラ環境を用意する必要がありません。インフラ環境の知識があまりなくても、フロントエンド領域に注力すれば開発できることがメリットだと思います。

デメリット

ここからはSPAのデメリットをご紹介します。

1.SEOに弱い

こちらについては諸説ありますが、SPAの場合ユーザーがブラウザでサイトにアクセスしたタイミングでAPIへリクエストを行いページをレンダリングします。基本的にサーバーにアップロードされているファイルの中身は空なので、クローラーは空のページをクロールすることになるためSEOに弱いとされています。

また同様の原理から、SNS等でサイトをシェアしたときに表示されるogpの出しわけができません。サイト制作においてはこちらも大きなデメリットになるのではないでしょうか。

2.HeadlessCMSへのリクエストが多くなる

ページ遷移するときなどに都度HeadlessCMSへのリクエストが発生するため、APIへのリクエストが多くなります。HeadlessCMSではプランごとにAPIへのリクエスト数の上限が設定されています。リクエスト数の上限に達したことでHeadlessCMSから情報が取得できず、サイトが正しく表示されない可能性もあるので注意が必要です。

コメント

比較表では「○」の多かったSPAですが、デメリットを考慮するとWebサイト制作に採用するのは現実でない印象です。

SSG（Jamstack）

Static Site Generationの略で、最近流行りのJamstackもこの手法に該当します。HeadlessCMSで記事の更新などを行ったタイミングでHeadlessCMSに登録された情報を取得し、あらかじめ静的なHTMLファイルを作っておく仕組みになっています。ページを表示するまでの流れは以下です。

1. HeadlessCMSで記事が公開されたタイミング等で、記事情報が入ったHTMLを生成
2. ブラウザからサーバーへリクエスト
3. サーバーはあらかじめ生成しておいたHTMLをブラウザに返却
4. ブラウザでサイトが表示される
5. ※CMSを更新しない限り2からスタート

メリット

SSGはCMSサイトにもかかわらず、あらかじめHTMLファイルを生成しておく仕組みによって静的なサイトと同等の性質を得られます。SSGのほとんどのメリットは、この「静的なサイトと同等の性質」から生まれるものです。

1.SEOに強い

あらかじめHeadlessCMSの情報が入った静的なHTML作っておく仕組みになっているので、SEOに強いとされています。

2.パフォーマンスが高い

こちらも1と同様に、静的なHTMLを返却するので高速なページレンダリングを行うことができます。

3.セキュリティが高い

サーバーには静的なHTMLしか設置しないため、静的なサイトと同等の高いセキュリティが得られます。

4.インフラの費用が抑えられる

静的なファイルを設置しておけばいいのでサーバーなどインフラ環境の費用も抑えることができます。

デメリット

一見たくさんのメリットがあるように見えるSSGですが、それと同等のデメリットも抱えています。

1.HTMLを生成する仕組みが必要

当たり前ですが、あらかじめHTMLを生成する仕組みを用意する必要があります。

NetlifyやVercel、AWS Amplifyなどのサービスを使用できればすぐに構築できますが、それらのサービスが使用できない場合は、独自に開発を行う必要があります。フロントエンド領域に留まらない幅広い知見が必要になるため、一気にハードルが高くなる印象です。

2.即時公開ができない

SSG(Jamstack)を採用するときに大きなハードルになるのが、公開にかかる時間です。

SSGはCMSで1ページを更新したとしても全ページ再生性となるので、HeadlessCMSで公開ボタンを押してから実際にサイト常に反映されるまでに、一定の時間がかかります。

基本的にページ数に比例してページ生成時間は増えていくので、大規模サイトを作るときは注意が必要です。数年前に試したときは約3000ページのサイトを生成するのに20分程度の時間がかかりました。

3.下書き環境を構築する必要がある

こちらもSSG(Jamstack)を採用するときに大きなハードルになるポイントです。

たいていのCMS運用では、担当者が下書き状態を実際がサイトでどのように表示されるか確認した上で公開を行います。そのため、一般ユーザーが閲覧する環境とは別に、担当者が下書き状態を確認する環境を構築する必要があります。

ほとんどのHeadlessCMSが下書き状態の情報を取得するためのAPIを提供しているので、それを使って下書き確認環境を構築します。

ただしこの環境をSSGで構築してしまうと、CMS操作から実際の表示確認までに時間がかかってしまいます。SPAなどCMSに入力した内容が即時で確認できる構築を本番環境とは別に用意しなければいけません。

コメント

SSGはかなり合理的な手法である反面、若干企業のCMS運用にマッチしていない側面があるように感じています。サイト規模や既存の運用方法などを考慮して導入を検討してみてください。

SSGの弱点を補うISRという手法もありますが、個人的にはSSGが採用できない場合は、SSRを採用すればいいのではないかと思っているため割愛しています。ISRに興味がある方は下記などを読んでみてください。

ISR(Incremental Static Regeneration)とは？

SSR

Server Side Renderingの略です。この手法ではリクエストがあったタイミングで、サーバーがHeadlessCMSの情報を取得し生成したHTMLをブラウザ側へ返却します。ページを表示するまでの流れは以下です。

1. ブラウザからサーバーへリクエスト
2. サーバーはHeadlessCMSから記事のデータを取得
3. サーバーは記事のデータが入った状態のHTMLを生成しブラウザに返却
4. ブラウザでサイトが表示される
5. ※CDNを利用し、返却するHTMLをキャッシュさせれば3からスタート

メリット

SPAではブラウザが行っていたHeadlessCMSへのリクエストをサーバーが行うことで、SSRはSSGとSPA両方のメリットを併せ持っています。

1.SEOに強い

サーバー側でHeadlessCMSの情報を取得し生成したHTMLを返却するため、クローラーがクローリングする際にページの情報を伝えることができます。そのためSEOに強くogpの出し分けも可能です。

2.即時公開が可能

リクストが来たタイミングでHeadlessCMSの情報を取得しHTMLを生成するため、HeadlessCMSの情報を即時に反映することが可能です。

SPAとは違い、ブラウザへ返却するHTMLはCDNによってキャッシュできるため、実際はサーバーからHeadlessCMSへのリクエストは抑えることができます。

ただしHeadlessCMSが更新されたタイミングでは、HTMLを生成し直しキャッシュクリアを行うことで、CDNにキャッシュさせておくHTMLを更新する必要があります。

デメリット

SSRのデメリットはインフラ環境の構築が難しいことだと思います。こちらもSSG同様、VercelやAWS Amplifyなどをしようすれば簡単に実装することができますが、それらが使用できない場合は独自にインフラ環境を構築する必要があります。

この時いわゆるサーバーを利用すると、HeadlessCMSを利用しているにもかかわらずサーバーの運用コストがかかってしまうため、AWS LambdaやGCP Cloud Runなどのサーバーレスサービスを利用して構築することが多いと思います。（より具体的な構築手法に関しては下記にリンクを貼っておきますので、興味がある方はそちらをご覧ください。）

しかし実際の案件では、同一ドメイン内にCMS管理されていないLPなどの静的なコンテンツが格納されたり、複雑なリダイレクト要件があったりと、柔軟な対応が求められます。いわゆるサーバーであれば対応策がすぐわかるけれども、サーバーレスサービスでの対応の仕方が分からず、意外と工数がかかってしまうことも多いと思います。

[アップデート]AmplifyがNext.jsとNuxt.jsを利用したSSR（Server Side Rendering）に対応しました！

Cloud Runで手軽にサーバ

コメント

従来まではSSRはサーバー側に負荷がかかるということで避けられていた印象ですが、サーバーレスサービスを採用できるのであれば、かなり有力なHeadlessCMSを使ったサイト構築手法の1つだと思います。

さいごに

最近流行りのHeadlessCMSを使ったサイト構築手法でした。どの手法も、フロントエンド、バックエンド、インフラのような従来の縦割りの技術領域では対応できないことが多いので、意外とハードルが高いのではないかと思っています。

また選択すべき手法としては、個人的には、まずSSGを検討しダメならSSR、そしてページ数の多いサイトはSSR一択かなと思っています。