WordPress から Astro へ: リビルドで Lighthouse 100 を達成した方法
WordPressからAstroへ: Lighthouse 100達成までの道のり
正直に言いましょう。私たちの古いWordPressサイトは恥ずかしいものでした。見た目が悪かったからではなく、実はかなり良く見えていました。しかし内部はどうかというと？3.2秒のTime to Interactive、58前後を彷徨うLighthouseパフォーマンススコア、そしてデプロイのたびに爆弾を解除しているような気分にさせるプラグインの山。私たちはウェブ開発エージェンシーです。クライアント向けに高速なサイトを構築しています。そして私たち自身のサイトは…高速ではありませんでした。
そこで私たちはサイトを一から再構築し、Astroを使用しました。結果は以下の通りです。Lighthouseの4つのカテゴリ全て（Performance、Accessibility、Best Practices、SEO）で完璧な100点。単一ページではなく、すべてのページで。ここが私たちがどのようにして達成したのか、途中で何が壊れたのか、そして何を違う方法でやるべきだったのかというストーリーです。
目次
- WordPressを離れた理由
- Astroを選んだ理由
- マイグレーション戦略
- 違いを生んだアーキテクチャの決定
- パフォーマンス最適化の深掘り
- Lighthouse 100スコアカード
- ビフォーアフター：数字で見る結果
- 途中で間違ったこと
- 独自のマイグレーションへのレッスン
- FAQ
WordPressを離れた理由
ウェブの約43%がWordPressで動作しています。悪いプラットフォームではありません。私たちはクライアント向けにたくさんのWordPressサイトを構築してきたし、適切な場合は今後も構築し続けるでしょう。しかし私たちのエージェンシーサイト（主に静的なマーケティングサイトとブログ）に関しては、WordPressは最悪の意味でやり過ぎていました。
私たちのWordPressセットアップは次のようなものでした：
- テーマ: Sage（Roots.io）上に構築されたカスタムテーマ
- プラグイン: Yoast SEO、WP Rocket、Advanced Custom Fields Pro、Gravity Forms、その他を含む14のアクティブプラグイン
- ホスティング: WP Engine Professional プラン（月60ドル）
- CDN: Cloudflare Pro（月20ドル）
- ビルドの複雑さ: PHPテンプレート、アセット用Webpack、MySQLデータベース
WP Rocketが積極的にキャッシュを行っていても、Core Web Vitalsは平凡でした。Largest Contentful Paint（LCP）はモバイルで2.4秒。Cumulative Layout Shift（CLS）は0.12でした。悪くはありませんが、良くもありません。そしてプラグインを更新するたびに、何かが壊れる可能性がゼロではありませんでした。
本当のところは？月3,000回程度のアクセスのあるサイトに対して、毎月80ドルのホスティングコストを支払っていました。それは多くのトラフィックではなく、本質的にはパンフレットサイトとブログの機能に対して大金です。
最後の一押し
最後の藁は2025年1月に来ました。WordPressのコア更新が私たちのカスタムGutenbergブロックを破壊しました。修正にはACF Proのアップデートが必要で、それはテーマのPHPバージョン互換性のアップデートが必要で、それはホスティング環境のアップデートが必要でした。日常的なアップデートのはずが、1日がかりの作業になってしまいました。
私はチームを見て言いました。「私たちはクライアントにヘッドレスを勧めています。なぜ自分たちはそれを実践していないのか？」
Astroを選んだ理由
再構築のために4つのオプションを評価しました：
| フレームワーク | メリット | デメリット | 判定 |
|---|---|---|---|
| Next.js | よく知っている、優れたエコシステム | コンテンツサイトにはオーバースペック、サーバーまたはエッジランタイムが必要 | 重すぎる |
| Astro | コンテンツ指向、デフォルトでゼロJS、島アーキテクチャ | より小さいエコシステム、新しい | 完璧 |
| Eleventy | シンプル、高速ビルド、成熟している | 限定的なコンポーネントモデル、モダンDXが少ない | 次点 |
| Hugo | 非常に高速なビルド、単一バイナリ | Goテンプレート構文が苦しい、柔軟性が限定的 | 不適切 |
私たちはたくさんのNext.jsプロジェクトをクライアント向けに構築しており、動的機能が必要なものの定番です。しかしコンテンツが豊富なマーケティングサイトの場合はどうでしょう？Next.jsは必要かどうかに関わらずブラウザにJavaScriptランタイムを送信します。静的エクスポートを使用しても、Reactをブラウザに送ります。
Astroの哲学は私たちに響きました：HTMLを送信し、必要な場所にのみJavaScriptを追加します。彼らの島アーキテクチャは、完全にインタラクティブなReactコンポーネントが完全に静的なHTMLの横に座ることができることを意味し、静的部分はゼロJavaScriptを送信します。これはまさに私たちが必要としていたものです。
また、2024年を通じて、クライアント向けにAstro開発作業をもっと行ってきたので、チームはフレームワークに慣れていました。これは学習演習ではなく、私たちがすでに信頼していたツールでした。
コンテンツレイヤーの質問
早期に下した決定：私たち自身のサイトにヘッドレスCMSを使用しないことでした。クライアントプロジェクトでは、しばしばヘッドレスCMSセットアップをContentful、Sanity、またはStoryblokで推奨します。しかし私たちのブログの場合、すべての著者はMarkdownとGitに慣れた開発者です。Markdownファイルを使用したAstroのContent Collectionsはリポジトリにコミットされました。より簡潔で高速でした。
ビルド時にAPI呼び出しなし。コンテンツ用のコンテンツ配信ネットワークなし。管理または支払うべき追加のサービスなし。ただのフォルダ内のファイルです。
マイグレーション戦略
大規模な一括マイグレーションはしませんでした。これが私たちのフェーズアプローチです：
フェーズ1: コンテンツ監査（1週間）
wp-cliを使用してすべてのWordPressコンテンツをエクスポートし、turndown（HTMLからMarkdownへのコンバーター）と正規表現クリーンアップを使用して作成した独自のスクリプトを使用してポストをMDXに変換しました。当時は47ブログポストがありました。そのうち約12ポストは古いか、パフォーマンスが低かったため、関連する新しいコンテンツにリダイレクトし、移行しませんでした。
フェーズ2: Astroでのデザインシステム（2週間）
コンポーネントライブラリをAstroコンポーネントとして再構築しました。ボタン、カード、セクションレイアウト、ナビゲーション—すべて.astroファイルとして。いずれもフレームワークは不要。純粋なHTMLとCSSでスコープされたスタイル。
フェーズ3: ページビルド（2週間） ホームページ、機能ページ、概要、お問い合わせ、ブログ一覧、個別ブログポスト、404。コンポーネントライブラリを使用してすべてAstroページとして構築しました。
フェーズ4: パフォーマンスチューニング（1週間） ここでLighthouse 100の作業が本当に始まりました。詳細は以下をご覧ください。
フェーズ5: ローンチとリダイレクト（2日） 古いURL各々に対して適切な301リダイレクトを設定し、Screaming Frogで何も壊れていないか検証し、Google Search Consoleに新しいサイトマップを送信し、DNSを切り替えました。
総タイムライン：クライアントプロジェクトの傍ら、約6週間のパートタイム作業。
違いを生んだアーキテクチャの決定
デフォルトではゼロJavaScript
サイト全体は約2KBのJavaScriptで配信されます。これはタイプではありません。2キロバイト。そのほとんどはモバイルナビゲーション切り替えと分析用の小さなスクリプトです。
ここが私たちのモバイルナビです—フレームワークなし、依存関係なし：
---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
<span class="sr-only">Toggle menu</span>
<svg><!-- hamburger icon --></svg>
</button>
<nav id="mobile-menu" hidden>
<slot />
</nav>
<script>
const toggle = document.getElementById('menu-toggle');
const menu = document.getElementById('mobile-menu');
toggle?.addEventListener('click', () => {
const expanded = toggle.getAttribute('aria-expanded') === 'true';
toggle.setAttribute('aria-expanded', String(!expanded));
menu?.toggleAttribute('hidden');
});
</script>
Astroコンポーネント内の<script>タグは自動的にバンドルおよび重複排除されます。小さく、バニラJS、どこでも動きます。
CSSの方針：スコープされたスタイル+最小限のグローバルレイヤー
コンポーネントレベルのスタイルにはAstroの組み込みスコープCSS、そしてタイポグラフィ、リセット、カスタムプロパティ、ユーティリティクラス用の単一グローバルスタイルシート（ミニ化時約8KB）を使用しました。Tailwindなし。議論の余地のある見方ですね。
大規模なアプリケーションおよびクライアントプロジェクトではTailwindが大好きです。しかしこのサイズのサイトでは、不要なビルド複雑さとファイルサイズが追加されました。私たちの手書きCSSはパージを使用してもTailwindの出力より小さいです。
/* Global custom properties */
:root {
--color-text: #1a1a2e;
--color-bg: #ffffff;
--color-accent: #e94560;
--color-accent-dark: #c81e45;
--font-body: 'Inter', system-ui, sans-serif;
--font-heading: 'Cal Sans', var(--font-body);
--max-width: 72rem;
--space-unit: 0.25rem;
}
スマートなプリロード付き静的生成
すべてのページはビルド時に静的生成されます。Astroの組み込みprefetch統合を使用して、ホバー時にリンクをプリロードし、ナビゲーションを瞬時に感じさせます：
// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
site: 'https://socialanimal.dev',
integrations: [mdx(), sitemap()],
prefetch: {
prefetchAll: false,
defaultStrategy: 'hover',
},
build: {
inlineStylesheets: 'auto',
},
});
パフォーマンス最適化の深掘り
Lighthouse 100に到達するのは、正しいフレームワークを選ぶ以上のことが必要です。Astroは素晴らしいスタートを提供していますが、最後の10～15ポイントには意図的な努力が必要です。ここが私たちが行ったことです。
画像の最適化
Astroの組み込み<Image />コンポーネントは、自動フォーマット変換（WebP/AVIF）、遅延ロード、CLS防止のための適切なwidth/height属性を使用したレスポンシブ画像を処理します。
---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image
src={heroImage}
alt="Social Animal development team working on headless architecture"
widths={[400, 800, 1200]}
sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
format="avif"
fallbackFormat="webp"
quality={80}
loading="eager"
/>
ヒーロー画像特に、ファーストビュー上にあるのでloading="eager"を使用します。他すべてはデフォルトでloading="lazy"を取得します。
また、サイト上のすべての画像を確認し、「これは画像である必要があるか？」と聞きました。いくつかの装飾要素はCSS勾配またはSVGの代わりになりました。例えば、ヒーロー背景は、細かいノイズテクスチャがインライン化されたSVGで適用されたCSS勾配です。
フォント読み込み戦略
フォントはLighthouseキラーです。これが私たちのアプローチです：
すべてをセルフホストします。 Google Fonts CDNはありません。InterとCal Sansをダウンロードし、独自ドメインから配信します。これにより、fonts.googleapis.comへのDNSルックアップ、TCP接続、TLSハンドシェイクが排除されます。
積極的にサブセットします。
glyphhangerを使用して、実際に使用する文字を分析し、pyftsubsetでフォントをサブセット化しました。私たちのInter Regular WOFF2は96KBから18KBになりました。メトリクスに合わせて慎重に選択したシステムフォントフォールバックと共に
font-display: swapを使用します。 スワップ中のレイアウトシフトを最小化します。重要なフォントファイルをプリロードします：
<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />
ホスティング：Cloudflare Pages
WP Engine（月60ドル）からCloudflare Pages（無料ティア）に移行しました。本当に無料です。私たちのサイトはCloudflareの無料プランの範囲内です—月500ビルド、無制限の帯域幅、無制限のリクエスト。
Cloudflare Pagesはgitプッシュからデプロイし、グローバルエッジネットワークから配信、キャッシュヘッダーを自動的に処理します。平均ビルド時間はサイト全体で22秒です。WordPressセットアップと比較して、キャッシュパージだけでもこれより長くなることはありました。
月ホスティングコストは80ドルから0ドルに削減されました。
重要なCSSインライン化
build.inlineStylesheets: 'auto'を設定すると、Astroは小さいスタイルシートを自動的にインライン化します。ページでは、すべての重要なスタイルが<head>にインライン化されるため、ゼロのレンダリングブロックCSSリクエストがあります。ブラウザはすぐにペイント開始できます。
サードパーティスクリプト規律
これがほとんどのサイトが完璧なスコアを失う場所です。すべてのサードパーティスクリプトは潜在的なパフォーマンス災害です。私たちはひどく限定しました：
- 分析: Google Analytics（70KB以上のJavaScript）からPlausible Analytics（< 1KBスクリプト、非同期読み込み）に切り替えました。Plausible に月9ドル支払います、そしてデータ品質は正直に私たちのニーズのために優れています。
- フォーム: /contactでの連絡先フォームは、単純なHTMLフォームとCloudflare Pages Functionsを使用したサーバー側処理を使用します。JavaScriptフォームライブラリなし。
- チャットウィジェットなし。 ソーシャルメディア埋め込みなし。クッキー同意バナーなし（同意が必要なクッキーは使用していません）。
Lighthouse 100スコアカード
2025年5月現在の実際のLighthouseスコアは、スロットルされた接続（Lighthouseデフォルトモバイルシミュレーション）でChrome DevToolsを使用して測定されました：
| メトリック | スコア |
|---|---|
| Performance | 100 |
| Accessibility | 100 |
| Best Practices | 100 |
| SEO | 100 |
| First Contentful Paint | 0.6s |
| Largest Contentful Paint | 0.8s |
| Total Blocking Time | 0ms |
| Cumulative Layout Shift | 0 |
| Speed Index | 0.8s |
Total Blocking Timeの0msは私のお気に入りの統計です。ゼロ。メインスレッドをブロックしているJavaScriptが本質的にありません。今までもこれからも。
ビフォーアフター：数字で見る結果
| メトリック | WordPress（前） | Astro（後） | 改善 |
|---|---|---|---|
| Lighthouse Performance | 58 | 100 | +72% |
| LCP（モバイル） | 2.4s | 0.8s | 3倍高速化 |
| CLS | 0.12 | 0 | 排除 |
| TBT | 380ms | 0ms | 排除 |
| ページ重量（ホーム） | 1.8MB | 142KB | 92%削減 |
| HTTPリクエスト | 47 | 6 | 87%削減 |
| 配信されたJavaScript | 340KB | 2KB | 99.4%削減 |
| 月ホスティングコスト | 80ドル | 9ドル（Plausibleのみ） | 89%削減 |
| ビルド/デプロイ時間 | 3～5分 | 22秒 | 約10倍高速化 |
| Time to First Byte | 420ms | 18ms | 23倍高速化 |
ページ重量削減は私たち自身にも驚くべきものです。1.8MBから142KB。これはjQuery、React、WP Rocketのスクリプトローダー、Yoastのスキーママークアップインジェクター、および14個のプラグインスタイルシートの配信を止めるときに何が起こるかです。
途中で間違ったこと
すべてが滑らかなセーリングではありませんでした。正直なとき。
間違い1：コンテンツ管理をほぼ過度に設計しました
最初の直感は、ブログ用にSanityをヘッドレスCMSとして設定することでした。Sanityスキーマを構成してSanity Studioを設定するのに2日間を費やしました。その後、「実際にこれを使うのは誰ですか？」と振り返りました。答えは…私たち。開発者。マークダウンをVS Codeに書き込むのに完全に満足しています。SanityをrippedずにAstro Content Collectionsに進みました。進行中のコストと複雑さが保存されました。
間違い2：フォントサブセットが特殊文字を破壊しました
最初のフォントサブセットは非常に積極的でした。使用しないと思っていた文字を除外し、エムダッシュといくつかのカールクォートが付いたブログポストを公開し、ボックスとしてレンダリングされました。レッスン：実際のコンテンツでサブセットをテストします、「ABCDEFG」だけではなく。
間違い3：OpenGraph画像を忘れました
OpenGraph画像のない状態で起動しました。誰かがTwitter/XまたはLinkedInでブログポストを共有すると、汎用フォールバックが表示されました。@astrojs/ogを使用してOG画像生成パイプラインを構築する必要がありました（内部ではSatoriを使用）。元々のスコープに含まれていたべきでした。
間違い4：301リダイレクトマップにギャップがありました
Screaming Frogを使用して古いURLをマップしたにもかかわらず、外部サイトがホットリンクしていたいくつかの画像URLを見逃しました。起動から約1週間後、Cloudflareの分析でこれらを捕捉し、欠落しているリダイレクトを追加しました。マイグレーション後は常にサーバーログをチェックしてください—Google Search Consoleがすべてをキャッチするわけではありません。
独自のマイグレーションへのレッスン
WordPressから静的優先フレームワークへの移動を検討している場合、これは私があなたに伝えることです：
マイグレーション前に監査してください。 パフォーマンスが出ていないコンテンツを削除します。マイグレーションは枝刈りするのに素晴らしい機会です。
ジョブにツールをマッチさせてください。 Astroは私たちに完璧でした。主にコンテンツだからです。重いインタラクティビティが必要な場合、Next.jsまたは同等のフレームワークがより良い呼びかけかもしれません。
古いアーキテクチャをカーゴカルトしないでください。 WordPressセットアップをAstroで複製しようとしませんでした。ゼロから全てを再考しました。実際にフォームプラグインが必要ですか？いいえ、
<form>要素とサーバーレス機能で良好に動作します。前に測定、後に測定、継続的に測定してください。 GitHub ActionsでLighthouse CIジョブを設定しました。それはすべてのプルリクエストで実行されます。プルリクエストが任意のスコアを95以下に下げた場合、チェックが失敗します。
最後の5%のための予算です。 Lighthouse 85から95への取得は簡潔です。95から100への取得には、フォントサブセット化、重要なCSS分析、画像フォーマット最適化、サードパーティスクリプト監査が必要です。時間を計画してください。
ホスティングコストは古いセットアップを恥じるべきです。 静的ファイルを配信し、重大なホスティング料金を支払っている場合、何か間違っています。静的ホスティングは今や商品です。
このようなマイグレーション、あなたのプロジェクトのために見ても何が見えるか興味がある場合は、価格ページをチェックするか、お問い合わせください。私たちは今、何人かのクライアント向けこのマイグレーションパスを実行しました、パフォーマンス利得は一貫して劇的です。
FAQ
WordPressサイトをAstroにマイグレーションするのにどのくらい時間がかかりますか？ 私たちのサイト（ブログポストを含むおよそ50ページ）について、それはおよそ6週間のパートタイム作業を要しました。数百のポストと複雑なカスタム投稿タイプを備えた大きなサイトは8～12週間かかることができました。実際の開発は通常、コンテンツ監査とリダイレクトマッピングより高速です。
代わりにNext.jsでLighthouse 100を取得できますか？ 可能ですが著しく難しいです。Next.jsは静的ページであってもブラウザにJavaScriptランタイムを配信します（React水和レイヤー）。近くを取得できます—95～99のスコアは慎重な最適化で達成可能です。しかしAstroのゼロJS―デフォルトアプローチは完璧なスコアをコンテンツサイトについてより達成可能にします。
WordPressのような連絡先フォームと検索について？ 連絡先フォームは純粋なHTMLフォームとサーバーレス機能バックエンド（Cloudflare Pages Functions、Netlify Functions等）で良好に動作します。検索のために、私たちはPagefindでクライアント側検索を使用し、これはビルド時に検索インデックスを構築し、JavaScriptの5KB以下だけを配信します。それは高速で、オフラインで機能します。
WordPressからAstroへのマイグレーションはSEOに影響しますか？ 正しく処理した場合はありません。私たちはすべてのURLの301リダイレクトを設定し、可能な場合はURL構造を保持し、新しいサイトマップを送信し、すべての構造化データを保ちました。実際に、マイグレーション後3か月で、有機トラフィックが23%増加しました。おそらく改善されたCore Web Vitalsのため。
Astroサイトでコメントのような動的コンテンツをどう処理しますか？ 私たちはブログにコメントを持ちません—WordPressではほぼすべてがスパムでした。コメントが必要な場合、Giscus（GitHub Discussions―ベース）またはHyvor Talkのようなサービスは良好に機能します。彼らは埋め込みコンポーネントとしてロードし、初期ページ読み込みに影響しません。
Astroは大規模サイトのための本番準備ができていますか？ 完全に。Astro 5.x（2024年後期にリリース）は成熟して安定しています。Porsche、Google、Microsoft、Netlifyのような企業は本番環境でそれを使用します。ビルド性能も良好にスケール—数千ページを持つサイトは正しい構成で1分未満で構築されます。
WordPressと比較して進行中のメンテナンスはどう見えますか？ 劇的に少なく。プラグイン更新なし、データベースメンテナンスなし、PHPセキュリティパッチなし。私たちはDependabot PRを経由して月に一度Astroと依存関係を更新します。各アップデートのレビューとマージに約5分かかります。WordPressアップデートトレッドミルと比較してください。
非技術チームメンバーはまだAstroサイトのコンテンツを編集できますか？ 私たちのセットアップで（Gitのリポジトリ内のMDXファイル）、MarkdownおよびGit基本ワークフローに快適である必要があります。非技術的な編集者を持つチーム向け、私たちはAstroを視覚インターフェース持つSanity、Contentful、またはStoryblokのようなヘッドレスCMSと組みを勧めます。編集者はビジュアルインターフェースを取得し、あなたは静的生成のすべてのパフォーマンス利益を得ます。