るいログ

ブログをGatsbyからAstroへ移行した話

約3年ぶりにブログを再開するにあたり、フレームワークの移行を行いました。

Gatsbyの技術的負債を解消

まず、Gatsbyのコントリビューターの皆様には感謝しています。

もともとWordPressで運用していた当ブログは、レンタルサーバー代が負担になっていました。そこで、約5年前にGatsbyへの移行を決断。Cloudflare Pagesにデプロイすることで、運用コストをドメイン代だけに抑えられたのは非常に助かりました。

このブログの遷移は以下の通りです。

WordPress
↓ 運用コストを改善
Gatsby
↓ 技術的負債を改善
Astro

Gatsbyを負債に感じた理由

更新頻度の低下

Gatsbyは2023年2月にNetlifyに買収されました。私の推測ですが、買収後1年以内にコアメンテナーがほぼ離れてしまったのではないかと思います。Vercel+Next.jsのようにNetlify+Gatsbyが強力な対抗になることを期待していましたが、残念です。

また、現在のスターターキットではエラーが出て動かないこともあるようです。

依存関係の脆弱性

私の記憶が正しければ、2023年2月の買収前のバージョンですでにいくつかの脆弱性が依存関係に含まれていました。（もしかするとテーマ由来かもしれません）

ブログ程度ならクリティカルな脆弱性以外は大きな問題ではありませんが、利用者としては気持ちの良いものではありません。

SPAである必要性がない

以前、別のツールサイトもGatsbyで作成していましたが、低速回線では内部リンクのクリックがすぐに反応しないことがありました。調査したところ、初期ページはHTMLで高速表示されますが、別ページはJavaScriptで配信されるため、ロード中は遷移できませんでした。この問題から、ツールサイトをSPAベースのGatsbyからMPAベースのAstroへ移行しました。

また、個人ブログのようなサイトでは多くのユーザーが1ページだけ閲覧して離脱します。わざわざ全ページ分のJavaScriptをバンドルして配信する必要はないのでは？と考えました。

レイアウトを再デザイン

以前のレイアウト

新しいレイアウト

デザインについて、完全には満足していません。（何かが違う気がします）

技術的なデザイン変更について

技術面では、投稿一覧・カテゴリ・タグを一気に削除しました。

主な理由は

特に「s」を付けるかどうかで悩みました。一般的には「s」付きが通例ですが、個人的に違和感がありました。そこで「いっそ/postsや/tags自体を無くしてしまえば？」と考えました。

投稿一覧・カテゴリ・タグを削除することで、サイトマップ汚染の軽減や管理コスト削減など、個人運用にはメリットが多いと感じています。代わりにサイト内検索を用意すれば、巡回したい人の入口にもなります。

CMSの利用（検討段階）

次の条件を満たすため、APIベースではなくGitベースのCMSを検討しました。

GitベースCMSの候補

tinaCMS（不採用）

最初はtinaCMS+Astroのスターターキットで始めましたが、以下の理由で不採用になりました。

依存関係の脆弱性は技術的負債になるため、回避することにしました。

Contentrain（不採用）

お手軽さは魅力的ですが、運営状況に不安があります。

現在、Discordで質問中。反応がなければ不採用予定です。
→ 2週間反応がないため、不採用になりました。

Decap CMS（検討）

基本的には、疎結合なtinaCMSだと思います。まだ未検証ですが、自前認証の例もあります。

CMSなんてなかった（現状）

現在はVSCodeでローカル編集しています。特に困っていることはなく、むしろGithub Copilot Chatが使えて便利です。

「どうしてもCMSが必要」「スマホで編集したい」などがなければ、このままVSCodeで編集でも十分だと感じています。