エンジニアが「ブログを移行した」と言えば、次に期待されるのはパフォーマンスの自慢話と相場が決まっています。 私も例に漏れず、移行後のサイトに対してLighthouseを実行してみました。
結果は残酷でした。 Performance: 55。
Astroを使えば勝手に爆速になると思っていた私の浅はかさが、真っ赤な数字として突きつけられた瞬間でした。 しかし、ここからがAntigravity（自律型エージェント）の本領発揮です。
1. 現状分析と「目」の良さ
私はエージェントに「100点取れるまで頑張って」とだけ伝えました。
すると彼は、lighthouse コマンドを叩くPythonスクリプトをその場で書き上げ、ボトルネックを特定し始めたのです。
- 画像の最適化漏れ: R2から配信しているサムネイル画像が、PNGのまま（数百KB）で読み込まれていた。
- フォントのレンダリングブロック: Webフォント（Noto Sans JP）の読み込みがFCPを遅らせていた。
- コントラスト比: デザイン重視で選んだグレーの文字色が、アクセシビリティ基準を満たしていなかった。
2. 施策1：画像の遅延読み込みと次世代フォーマット
エージェントは astro:assets の <Image /> コンポーネントを導入しようとしました。
しかし、リモート画像（R2）をビルド時に最適化するには、astro.config.mjs へのドメイン追加が必要でした。
image: {
domains: ['static.a3ro.cc'],
},この設定を自動で挿入し、WebPへの変換とリサイズ（480x270）を適用。結果、画像転送量は10分の1以下に激減しました。
3. 施策2：フォントの断捨離
「Webフォントは美しいが、遅い」 エージェントは究極の選択を提案してきました。「システムフォントにしませんか？」
Techブログにおいて重要なのは可読性と速度です。私は提案を受け入れました。
BaseLayout.astro からGoogle Fontsの読み込みタグを削除。CSS変数を書き換え、OS標準のフォントスタック（San Francisco, Helvetica, YuGothic etc.）に切り替えました。
結果、レンダリングブロック要因が消滅し、First Contentful Paint (FCP) が劇的に向上しました。
4. 施策3：アクセシビリティの完遂
Lighthouseは「見やすさ」もスコア化します。
文字色が薄すぎて読みにくい箇所（#6B7280など）を、コントラスト比4.5:1を満たす濃さ（#4B5563）に修正。
さらに html タグへの lang="ja" 属性の確認も怠りませんでした。
5. 結果：Perfection
本番環境（Cloudflare Pages）へのデプロイ後、PageSpeed Insightsで計測を行いました。 AdBlockなどの拡張機能をオフにした「クリーンな状態」での計測結果がこれです。
Performance: 100 Accessibility: 100 Best Practices: 100 SEO: 100
完全勝利です。
トップページだけでなく、Markdown画像を含む記事詳細ページにおいても、fetchpriority や srcset を適切にハンドリングすることで満点を達成しました。
ローカル計測での「56点」という絶望から這い上がり、エージェントとの対話（と、多少の強引なCSS over-ride）によって、A3roは理想の数字を手に入れたのです。
なにより、これらの修正を「私がコードを1行も書かずに」、エージェントとの対話だけで完遂したという事実。
これこそが、A3roプロジェクトが目指した「次世代の執筆体験」の成果です。
追記（2026-01-08）： 記事数の増加に伴うページネーション実装と、その後のパフォーマンス維持についての続編記事を書きました。LCP最適化の参考として合わせてご覧ください。