Astro Route Caching（Experimental）についてのメモです。
先出し：Astro Route Cachingとは
Route Cachingは、On-demand Rendering（SSR）のレスポンスをAstroの共通APIでキャッシュ管理できるようにする機能で、Astro v6.0系からExperimentalとして導入されました。この機能が何を解決するのかを理解するために、まずAstroのレンダリングモデルを整理しておきます。
前提として、Astroはコンテンツ駆動 + ブラウザや言語（HTMLなど）などのWeb標準を尊重し、拡張して使いやすくする傾向にあります。静的サイト + SSG向きだと謳われていますし、その類のプロジェクトに向いているという声には共感します。しかし、コンテンツをパーソナライズ1したり、動的に更新したい場面があるのも確かにあります。こうしたケースに対応するため、AstroではOn-demand Renderingというレンダリングもサポートしています。
Prerendering（SSG）の特徴と苦手なこと
デフォルト設定のSSGは、基本的に”ビルド時”にサーバーを介して.htmlファイルなどを生成し、それをホスティング環境によっては、CDNなどにキャッシュしながら配信します。ユーザーのリクエスト以前に配信ファイルが生成されている&キャッシュされているという観点で考えると、配信が最速になりやすいことがわかります。ブラウザなどのクローラーにも検出してもらいやすいのでOG画像なども取得してもらいやすかったり、インデックス漏れが少なかったりします。
今更ですが、先に配信ファイルを生成しておくこのSSGをAstroではPrerenderingと呼んでいます。pre（先んじて）でrenderingしておくのでわかりやすいですね。
このpreという特徴が最速配信（描画にも影響する）を実現していますが、裏を返せばビルド時に配信する内容が決定してしまうということでもあります。したがってパーソナライズや動的更新が難しいという特徴があります2。また、各フレームワークやSSGの仕組みによるかもしれませんが、基本的にフルビルド（全ファイルビルド）が必要になります。ビルド対象のファイル数が極端に多い場合や、変換処理が重い場合（例: mermaidからsvg、mdxからhtml）は、毎回それらを処理するので重くなる可能性もあります。
On-demand Renderingとキャッシュの課題
AstroはIslands architectureに見られる「必要ならJSを追加してね！」＝ 必要なら足し算しようという概念に基づいています。キャッシュについても同様で、今までは各プロジェクトのホスティング環境やCDNに付帯するキャッシュ機能を使用する形式でした。（例えば、VercelやNetlifyのISR機能など）
ここまで色々情報過多な気がしますが、抑えるべきポイントとしては以下の通りです。
- Astroには、Prerender（SSG）だけでなく、リクエスト時にビルドなしで動的更新するためのOn-demand Render（SSR）という仕組みがあります
- Prerenderは事前生成（= CDNなどへ配信ファイルを”キャッシュ”）しておきますが、On-demand Renderはデフォルトだとキャッシュされず、毎回リクエスト時に更新になります
- リアルタイム性が絶対的に必要ならこのままでもよいかもしれません。しかし、多少のラグを許容してキャッシュを保持した方がユーザー体験がよくなるケースも考えられます
- ただし、以前までは、PaaSやCDNなどのキャッシュ機能を自分で活用するしかありませんでした
こんなOn-demand Rendering特有の悩みを解決すべく、Astro開発者が使いやすく、キャッシュ管理をできるように共通APIとして提供を進めているのが、Route Cachingという機能です。
中締め
一旦疲れたので、#2メモ記事へ（近日中に書きます）