Q.StudioからAstroとCloudflareへ移行するメリットとデメリットは何ですか？

Studioは、デザインの編集から公開サイトの配信までをひとつのサービスの中で済ませます。AstroとCloudflareの組み合わせでは、この二つを別々に持ちます。Astroがページを前もってHTMLに書き出し、Cloudflare Pagesがそのファイルを世界各地の配信網に置いて、訪問者に近い場所から届ける形です。

ページの閲覧があるたびにサーバー側の関数で画面を組み立てる処理を挟まないため、静的なコンテンツを身軽に配信できます。

費用もかかりにくい形です。Cloudflare Workersでは静的アセットへのリクエストが無料かつ無制限で、ファイルの保存に追加の料金もかかりません。なお、サーバーサイドレンダリングなどでWorkerスクリプトを呼び出して処理を動かす場面では、Workersの料金体系が適用されます。

公開先の選択肢が1つのサービスに固定されない点も特徴です。AstroはNetlifyやVercelなど複数のホスティングサービスに対応しており、手元の端末でビルドした出力ファイルをアップロードする形式も選べます。一般的な公開設定もシンプルで、ビルドコマンドはastro buildまたはnpm run build、公開ディレクトリにはdistを指定します。設定の流れはAstroの公開設定ガイドにまとまっていますね。

いまStudioで社内の担当者がお知らせやブログを書いている場合、移行後も同じように更新できるのかが気になるところでしょう。ブログ記事などをWeb上の画面から書きたい場合は、外部のCMSとの連携が欠かせません。AstroではMarkdownファイルの代わりにCMSの編集画面を使う構成も選べますが、初期の接続設定やデータ連携の実装が必要です。

特にmicroCMSの項目構成を手作業でAstro側のZodスキーマに書き写す構成をとる場合、項目を1つ増やすたびにCMS側とAstro側の両方を手動で直す手間がかかります。最初は小さな手間でも、運用が長くなるほど面倒が積み重なりがちです。

お問い合わせフォームも、Studioほど手軽ではありません。Studioならフォーム名はデザインエディタで変え、公開パネルからサイトを更新すれば反映されます。届いた回答も管理画面でフォーム名ごとにまとまって見られます。

一方のCloudflare Pagesでは、フォームの公式実装例でもHTMLのフォームに加えて、送信内容を受け取るWorkerの処理を自分で書いていますね。回答をどこに保存し、誰に通知するかまで決めて作るので、Studioで当たり前に使えていた部分ほど作業が増えます。

更新のしやすさとフォームの手軽さは、Studioがはじめから持っている強みです。移行するなら、更新の方法とフォームの受け口を、移行先でどう用意するか先に決めておきましょう。

Studioで作ったページを、そのままAstroへ持っていけるのでしょうか。StudioにはサイトのHTMLを書き出す機能がないため、デザインはAstro側で組み直すことになります。ブログ記事などの蓄積がある場合は、テキストをMarkdown形式へ変換して取り込むのが基本です。書き出しの機能がない以上、記事も一件ずつ取り出して整える前提になります。

URLを変えずにホスティングだけを移すなら、次の順で進めます。

1. Astroでページと記事を作り直し、今のURLと同じパスになるよう配置する
2. Cloudflare PagesのプレビューURLで、本番に出す前に表示を確かめる（検索に載らないようnoindexを付けておく）
3. 切り替えの少なくとも1週間前に、DNSのTTLを数時間ほどに下げておく
4. DNSを新しい環境へ向け、表示とフォームの動きを確かめる
5. Googlebotを含むアクセスが新しい環境で正しく受け取れ、旧環境へのアクセスがなくなってからStudio側を止める

3番のTTLの引き下げは必須ではありません。それでも、DNSの切り替えが早く行き渡るので、旧サイトと新サイトが混ざって見える期間を短くできます。

Googleが案内するURL変更を伴わない移転の進め方は、Googleのサイト移転手順で確認できます。途中でURLが変わるページが出てくるなら、転送の設定もあわせて用意しましょう。

Studioは重いと聞いて、移行を考え始めた人もいるでしょう。ただ、Studioは2026年6月11日に、従来のSPA基盤をMPA基盤へ刷新し、SSRをベースにした新しい公開サイト基盤を正式リリースしました（新しい公開サイト基盤のお知らせ）。同じお知らせでは、テンプレートを基に実装を調整したサイトのモバイル計測として、旧基盤が63、新基盤で調整した状態が100、CMSを使った場合でも98前後というLighthouseのスコアが示されています。これはStudio自身の検証で、どのサイトでも同じ数字が出るわけではありません。なお、新しい基盤は既存のプロジェクトには自動では切り替わりません。

Astroコンポーネントはビルド時やリクエスト時にHTMLへ変換され、標準の状態ではブラウザ向けのJavaScriptを追加しません。軽く作りやすい仕組みですが、Studioより速いと言い切れる比較はありません。

結局、速さは製品名よりページの作り方で変わります。実際の表示速度には、ページ内に配置した画像の容量や点数、外部スクリプトの読み込み、Webフォントの種類や太さの数などが強く影響します。

比べるときは、プレビューではなく公開中のサイトで測りましょう。ライブプレビューは公開サイトより遅く表示されるためです。MobileとDesktopの両方で3回以上計測し、中央値を見ます。PageSpeed Insightsの点数は試験環境での参考値なので、実際の訪問者の体感とは分けて見たほうがよさそうですね。