公開日:
更新日:
9 min read
技術革新レンダリング方式を整理する - AstroとCloudflareで考える最適な選択
Astro v4でブログサイトを構築する過程で、 レンダリング方式について改めて整理する機会がありました。 既存のテーマを使わずにゼロから開発を進める中で、 記事検索やお問い合わせフォームの実装方法を検討することになり、 SSRやSSGなどの選択肢について深く考えることになりました。 この記事では、その過程で整理したレンダリング方式の特徴と、 実際のプロジェクトでの選択について共有したいと思います。
レンダリング方式
ウェブページのレンダリング方式には主に3つのアプローチがあります。
CSR（Client-Side Rendering）
最初にブラウザが最小限のHTMLとJavaScriptファイルを受け取り、その後ブラウザ上でJavaScriptを実行してページの内容を生成します。 最初の読み込みは軽量ですが、JavaScriptの実行が完了するまでユーザーは完全なコンテンツを見ることができません。 SPA(Single Page Application)はこの方式を採用することが多いです。
SSG（Static Site Generation）
ビルド時にすべてのページのHTMLを生成します。 ユーザーのリクエストに対して、事前に生成された完全なHTMLを返すため、表示が高速です。 ブログや企業サイトなど、頻繁に更新されないコンテンツに適しています。
SSR（Server-Side Rendering）
ユーザーのリクエストごとにサーバー上でHTMLを生成します。 最新のデータを含んだページを提供できますが、リクエストのたびにサーバーでの処理が必要です。 ユーザー認証が必要なページや、リアルタイムデータを扱うページに適しています。
AstroにおけるCSRの扱い
CSR（Client-Side Rendering）については、Astroはデフォルトで「アイランドアーキテクチャ」を採用しており、 必要な部分のみJavaScriptを使用する設計となっています。 つまり、フルCSRではなく、必要な部分のみクライアントサイドでレンダリングする仕組みを持っています。
アイランドアーキテクチャーとは
アイランドアーキテクチャーは、ウェブページを「海（静的なHTML）」と「島（インタラクティブな機能）」に例えた設計手法です。 広大な海のような静的なHTMLの中に、ボタンやフォーム、カルーセルなどの動的な機能を持つ「島」が点在するイメージです。 ページの大部分は静的HTMLという「海」として生成され、必要な部分だけが JavaScript で制御される「島」として存在します。 この設計により、ページ全体をJavaScriptで制御するフルCSR（クライアントサイドレンダリング）と比べて、初期読み込みが高速で、かつ必要な部分だけインタラクティブな機能を実現できます。
例えば、ブログ記事のページでは、記事本文は静的なHTMLとして配信し、コメント欄やいいねボタンなど、 ユーザーとのインタラクションが必要な部分だけをJavaScriptで制御します。 これにより、ページの主要なコンテンツを素早く表示しながら、必要な機能も提供することができます。
Astroのレンダリングモード
astro.config.mjsのoutput設定で指定する3つの選択肢があります。
static
静的サイト生成を意味します。サイトをビルドした時点ですべてのページがHTMLとして生成され、それ以降は生成されたHTMLファイルがそのまま配信されます。例えば企業のホームページのように、頻繁に内容が変わらないウェブサイトに適しています。
hybrid
基本的に静的生成ですが、一部のページだけを動的に生成できるモードです。静的ページと動的ページを混在させることができます。サイト内検索のように、ユーザーの入力に応じて結果を表示する機能が必要な場合に、その部分だけを動的に生成することができます。
server
すべてのページをサーバーサイドで動的に生成します。ユーザーがページを表示するたびにサーバーでHTMLを生成するため、常に最新のデータを表示できます。ログインが必要なページや、リアルタイムにデータを表示する必要があるページに適しています。
サーバーサイドの実装はAstroで可能
Cloudflare Pagesでお問い合わせフォームを実装する際、 当初はCloudflare Workersを使用する必要があると思い込んでいました。 その後、Cloudflare Pages Functionsの存在を知りましたが、 wranglerでのコードデバッグができないという技術的な課題に直面しました。
新規にブログサイトを構築するにあたり、 せっかくなので既存のテーマを使用せずにブログテーマを自分でゼロから開発することにしたところ、 Astro 4.0のSSR機能を使えば、CloudflareのSSRサポートにより、 WorkersやPages Functionsを使わなくても実装できることが分かりました。 Astroのプロジェクト内でフォーム処理やメール送信などのサーバーサイド機能を完結させることが可能で、 これにより開発とデプロイメントのプロセスがシンプルになり、コードベースも一元管理できます。
ただし、WorkersやPages Functionsを使用してサーバーサイド機能を分離して開発する方法にも、 マイクロサービス的なアプローチとしての利点があります。 APIの再利用性や、フロントエンドとバックエンドの明確な責務分離という観点では、 これも十分に理にかなった選択です。 結果として、既存のソリューションに囚われず自分でゼロから開発に取り組んだことで、 プロジェクトの要件に応じて選択できる技術の幅を広げることができました。
プロジェクトに合わせた選択を
レンダリング方式の選択は、プロジェクトの要件や運用方針によって変わってきます。 Astro v4は複数のレンダリング方式をサポートしており、必要に応じて使い分けることができます。 私の場合は、お問い合わせフォームの実装をきっかけにSSRを選択しましたが、 これは一つの選択肢であって、唯一の正解というわけではありません。
大切なのは、プロジェクトの要件を理解し、それに合わせて適切な技術を選択することです。 時にはシンプルなSSGで十分かもしれませんし、 場合によってはhybridモードでSSGとSSRを組み合わせるのが最適かもしれません。
テクノロジーの選択は、常にプロジェクトのゴールに紐づいて考えていきたいものですね。