ページの事前生成

ビルドによる事前生成

ここでいうビルドとは、公開前に静的サイトジェネレーター（SSG）やWebフレームワークを実行する工程です。APIから取得したデータやテキストをテンプレート、コンポーネントと組み合わせて、配信用のHTMLとして書き出します。

ユーザーがアクセスしたときには、ビルド済みのHTMLを配信するだけで済むため、データベースの読み出しやHTML生成の処理を省けます。また、作成されたWebアプリケーションはアプリケーションサーバーを動かさずにCDNで配信でき、大量のアクセスにも強く、配信コストも抑えられます。

解決できる問題

事前生成は、ユーザーがアクセスしたときに必要な処理を減らす方法です。そのため、次のような課題を抱えているサイトでは、大きく改善できる可能性があります。

• ページの表示が遅い
• アクセスが増えるとサーバーに負荷がかかる
• SPAで作ったページの初期表示が遅い
• ブラウザで実行するJavaScriptが多く、端末の負荷が高い
• サーバーやCMSの運用、セキュリティ対応に手間がかかる
• アクセス集中に備えた構成やコストが重い

ビルド済みのHTMLをCDNから配信できる構成にすることで、表示速度、アクセス集中への強さ、運用のしやすさをまとめて改善しやすくなります。

事前生成が難しいケースとは？

すべてのページや要素を事前生成できるわけではありません。ユーザーごとに内容が変わる画面、認証状態によって表示が変わる領域、在庫や通知のようにアクセス時点の情報が必要な領域は、ビルド時に内容を確定できません。

その場合でも、ページ全体を動的に生成する必要はありません。共通の本文や頻繁に更新されない情報は事前生成し、個別性や即時性が必要な部分だけをAPI連携やAstroのサーバーアイランドなどで動的に扱う構成にできます。

また、サイト全体をSSRにするのではなく、一部のページだけをSSRにする選択肢もあります。事前生成できるページはHTMLとして用意し、アクセス時に内容を決める必要があるページだけをSSRで生成します。

ピクセルグリッドの強み

事前生成を活かすには、Webフレームワークや静的サイトジェネレーターの知識に加え、どの情報をビルド時に組み込み、どの処理を動的に扱うかを設計する知識が必要です。

その点、ピクセルグリッドには、小規模・大規模それぞれに応じた静的サイトジェネレーターの知見があります。また、SPAが一般化する以前から、動的なAPI連携に取り組んできました。たとえば、自社メディアにて購読ユーザーだけがアクセスできる記事を事前に生成し、認証とは切り分けて管理するなど、さまざまな要件に対応してきました。

また、各種サービスを組み合わせて要件を実現してきた経験も豊富です。サービス独自のAPIを含め、多くのサービスのAPI連携に関する知見があることも強みの1つです。

扱える静的サイトジェネレーターやWebフレームワーク

そのほかにも多数のSSGやWebフレームワークに対応できます。使うツールは要件に合わせて提案いたします。