WordPressやめてAstroに移行したら爆速になった件
オンプレ WordPress から Astro + Cloudflare Pages へ移行した経緯と、移行中に作った仕組みのメモ
年末に突然、「このオンプレの化石 WordPress、もうやめよう」と思い立って、Astro への移行を始めました。
結論から言うと、もっと早くやっておけばよかったです。
いちばん衝撃だったのは、Astro と Cloudflare Pages の組み合わせがあまりにも軽かったことです。
表示はもちろん速いし、デプロイも速いし、記事修正の心理的ハードルまで一気に下がりました。
それまで「ブログ更新」はちょっとした運用作業でしたが、移行後はかなり普通の開発体験に近づきました。
何が起きたのか#
About ページにも書いた通り、移行の流れはこんな感じでした。
- 2025年12月28日
大晦日前に唐突に、オンプレで動かしていた古い WordPress からの移行を決意 - 2025年12月30日
初めて触る Astro + Cloudflare Pages のデプロイ速度に腰を抜かす - 2025年12月31日
旧記事の移植作業を開始 - 2025年12月31日
コメント管理用に Waline を Vercel 上へデプロイ - 2026年4月2日
WordPressの記事・ロジックの移行完了
完全に思いつきスタートだったのですが、逆にその勢いが良かった気がします。
「準備が整ったらやろう」だと、たぶんずっとやっていなかったと思います。
なぜWordPressをやめたのか#
WordPress 自体が悪いというより、今回の自分の用途とだんだん噛み合わなくなっていました。
- 表示のために PHP とデータベースが必要で、構成が重い
- 記事を書くより、保守や更新を気にする時間の方が目立ってきた
- ちょっとした見た目修正や埋め込み調整でも、テーマやプラグイン都合を考える必要がある
- オンプレ運用していると、「ブログを直す」の前に「サーバーを意識する」が挟まりやすい
もちろん WordPress は強力です。
ただ、今の自分のブログはニュースサイトでも共同編集メディアでもなく、基本的には個人の技術メモと制作記録です。
それなら、CMS の重装備よりも、静的サイトとして軽く置けることの方が価値が大きいと判断しました。
なぜAstroだったのか#
静的サイトジェネレーター自体は色々ありますが、今回は Astro がかなり刺さりました。
- コンテンツ中心のサイトと相性がいい
- MDX で記事を書ける
- 必要なところだけコンポーネント化できる
- 普通のフロントエンド開発に近い感覚で触れる
- 出力が静的なので、配信構成をかなり単純化できる
特に良かったのは、「ただの Markdown ブログ」より一段柔軟で、「フル CMS」よりかなり軽いちょうどよさです。
技術ブログは、画像・埋め込み・注意書き・コードブロック・独自 UI が頻繁に出てきます。
そのたびに Markdown の限界へ突っ込むのではなく、必要なら MDX コンポーネントを足せるのがかなり快適でした。
今の構成#
現在のブログは、ざっくり次のような構成です。
- ドメイン: Cloudflare Registrar
- フレームワーク: Astro
- テーマ: Astro Theme Pure
- ホスティング: Cloudflare Pages
- CI/CD: Cloudflare Workers Builds
- コメント: Waline
- コメント用サーバー: Vercel
- PV まわり: Supabase + Waline
サーバーサイドの複雑さをかなり外へ逃がした構成です。
旧環境では「ブログを公開するための箱」を自分で強く抱えていたのですが、今は「中身を作ること」に集中しやすくなりました。
どこが爆速になったのか#
タイトルでは勢いで「爆速」と書いていますが、体感的には本当にかなり変わりました。
1. 表示が軽い#
まず、静的配信なので初手から軽いです。
WordPress 時代のように毎回動的にページを組み立てる必要がなく、読者側の待ち時間も自分の気持ちの負担もかなり減りました。
2. デプロイが速い#
これが一番驚きました。
Astro でビルドして Cloudflare Pages に載るまでがあまりにも軽快で、「ブログ更新ってこんなに気楽でよかったのか」となりました。
WordPress 時代は、修正そのものより「壊してないかな」「キャッシュどうだろう」「プラグインの影響ないかな」と周辺を意識しがちでした。
今は Git ベースで差分が見えるので、修正して反映して確認するまでがかなり素直です。
3. 記事修正がコードになる#
これも大きいです。
記事がファイルとして置かれているので、変更履歴が追いやすく、まとめて置換したり、共通化したり、AI に手伝ってもらったりしやすいです。
WordPress の管理画面で 1 記事ずつ触っていたときより、圧倒的に機械処理と相性がいいです。
旧記事の移植で大変だったこと#
ただし、楽なことばかりではありませんでした。
一番大変だったのは、やはり過去記事の移植です。
WordPress の記事本文はデータベース側に入っているので、単純にファイルをコピーして終わり、とはいきません。
そこで公開ページをもとにスクレイピングしながら、1 記事ずつ Astro 用の mdx へ落としていく作業になりました。
本文テキストを移すだけならまだしも、技術ブログは記事ごとのクセが強いです。
そのまま Markdown 化すると崩れるので、結局Codexにお願いしていくつか専用コンポーネントを生やすことになりました。
移行中に作ったもの#
移植作業の中で、以下のようなコンポーネントを追加しました。
CaptionedImage#
WordPress 時代と同じように、「記事と同じディレクトリにある画像を相対パスで指定しつつ、サイズ変更とキャプションも付けたい」という用途のために作りました。
従来の不満点はこんな感じです。
- Markdown 画像
は相対パスが楽だが、サイズ指定がほぼできない astro:assetsの<Image src={photo} />は高機能だが、毎回 import が必要
そこで、相対パス文字列から記事フォルダ内の画像を解決して、<figcaption> までまとめて面倒を見るコンポーネントを作りました。
これで、移植時に画像の書き換えがかなり楽になりました。
<CaptionedImage
src="./example.jpg"
alt="記事用サンプル画像"
caption="記事用サンプル画像のキャプション"
width={500}
/>TweetEmbed#
X の公式埋め込みを使いつつ、サイトのダークテーマにも追従させるためのコンポーネントです。
DownloadConsent#
「利用規約を読ませるため、同意しないとダウンロードリンクを表示しない」タイプの記事向けの簡易 UI です。
厳密な認証は不要だったので、フロントエンドだけで軽く再現しています。
ProductLinkCard#
リンクが切れた Amazon アフィリエイト埋め込みを、そのまま空白のまま残したくなかったので作ったカードです。
商品名と説明文とリンクだけの軽い置き換えですが、本文の流れを壊しにくいので意外と便利でした。
LocalVideo#
WordPress 側に上がっていた動画を、記事フォルダに置いたローカルファイルとして参照するためのコンポーネントです。
これも「記事相対で書ける」というだけで、移植の手間がかなり減りました。
移行してよかったこと#
今のところ、移行してよかった点はかなり多いです。
- 表示と配信が軽い
- 記事が Git 管理できる
- まとめて修正しやすい
- 変な埋め込みをコンポーネントで吸収できる
- 見た目や構造を自分で把握しやすい
- AI と一緒に移植・整形を進めやすい
特に最後は、今回かなり大きかったです。
WordPress の DB 内に閉じている状態だと、AI に頼める作業がどうしても限定されます。
一方、公開 HTML をスクレイピングして MDX へ変換する形に持ち込めれば、記事単位でかなり作業を進められます。
まとめ#
オンプレの WordPress から Astro へ移行したことで、ブログはかなり扱いやすくなりました。
表示速度だけでなく、更新・修正・保守のすべてが軽くなった感覚があります。
ブログを続けるうえで大事なのは、たぶん「最強の構成」より「面倒くさくならない構成」なんだと思います。
今回の移行で、その意味ではかなり良い場所に着地できました。
まだ移植作業は続いていますが、少なくとも「もう WordPress には戻りたくない」と思える程度には、Astro 側が快適です。