Astro 5 でブログを再構築し、Lighthouse スコアを 68 から 100 に

先週、2 年間使っていた Next.js ブログをすべて作り直し、Astro 5 に乗り換えました。きっかけは Lighthouse スコアが 68 しかなく、友人から「読み込みに時間がかかりすぎる」と言われたことです。移行後は、ビルド時間が 2 分から 18 秒に、パフォーマンススコアが 68 から 98 に改善しました。
本記事では、Astro が速い理由、ブログの構築方法、SEO の設定方法の 3 点に絞って解説します。ブログのパフォーマンスに悩んでいる方の参考になれば幸いです。

68→98

Lighthouse パフォーマンススコア

Next.js から Astro 5 への移行

2分→18秒

ビルド時間

ビルド時間を 85% 短縮

2.1秒→0.8秒

FCP（初期表示）

62% 高速化

4.5秒→1.2秒

TTI（操作可能）

73% 高速化

280KB→45KB

JS バンドルサイズ

84% 削減

60%

Core Web Vitals 合格率

Astro サイト平均。WordPress / Gatsby は 38%

Source: 実プロジェクト測定データ

なぜ Astro に注目すべきか

正直、最初は Astro にあまり興味がありませんでした。Next.js、Nuxt、Gatsby——フレームワークの選択肢は多すぎます。「また新しいものを覚えるの？その時間は本当に元が取れるの？」と思っていました。
あるデータを見て、考えが変わりました。
State of JavaScript 2024 の調査では、Astro は関心度・継続利用率・満足度の 3 項目すべてで 1 位。利用率は Next.js に次ぐ 2 位でした。GitHub Octoverse 2025 では、成長率第 3 位の言語（フレームワーク）として挙げられています。
もう 1 つ興味深い数字があります。Astro サイトの 60% が Core Web Vitals の評価に合格しているのに対し、WordPress と Gatsby は 38% にとどまっています。この差は無視できません。
採用例も増えています。GitHub のドキュメント、Firebase の開発者向けドキュメント、Smashing Magazine（WordPress から移行）など。2025 年には Google、Reuters、Typst も導入を始めました。
ここで改めて考えました。私のブログに必要なのは何か？基本は Markdown 記事の表示、コードハイライト、たまにコメント機能——Next.js のような複雑なフルスタック機能は不要では？
私の結論はこうです：ブログ、ドキュメントサイト、マーケティングページなら、Astro は現時点でほぼ最適解。一方、EC や SaaS のようにインタラクションが複雑なアプリなら、Next.js の方が向いています。
どちらが優れているかではなく、用途の問題です。

Island アーキテクチャ——Astro が速い理由

ページの内容は表示されているのに、ボタンを押しても反応しない——そんな経験はありませんか？
原因は JavaScript のハイドレーション（Hydration）であることが多いです。従来のフレームワークは、ページ全体の JS をブラウザに送り、ブラウザ側で「活性化」させます。ページが複雑になるほど、待ち時間は長くなります。
Astro のアプローチは根本的に異なります。Island アーキテクチャ（Islands Architecture）という仕組みを採用しています。
イメージとしては、ページ全体が静的 HTML の海で、カウンター、フォーム、コメント欄のように本当にインタラクションが必要なコンポーネントだけが「島」として浮かび上がります。各島は独自に JavaScript を管理し、互いに干渉しません。
コードではこうなります：

---
// このコンポーネントは、ユーザーがスクロールして表示領域に入ったときだけ JS を読み込む
---
<Counter client:visible />

// このコンポーネントは常に純粋な静的 HTML。JS は一切読み込まない
<Header />

client:visible が見えますか？これは Astro への指示で、「ユーザーに見えたタイミングでだけアクティブにする」という意味です。ほかに client:load（ページ読み込み時）、client:idle（ブラウザがアイドル状態のとき）も選べます。
実際の効果は？私のブログでは FCP（First Contentful Paint）が 2.1 秒から 0.8 秒に、TTI（Time to Interactive）が 4.5 秒から 1.2 秒に短縮されました。JS バンドルは 280KB から 45KB まで減りました。
公平に言えば、ページ全体がインタラクティブなコンポーネントで構成されている場合、Astro は最適とは限りません。Astro の強みは「コンテンツの大部分が静的である」シナリオで発揮されます。ブログやドキュメントサイトにとっては、圧倒的な選択肢です。

Server Islands——Astro 5 の新機能

Astro 5 では Server Islands という機能が追加されました。
これまで、ページの大部分は静的だけど一部だけ動的（ユーザーアバターやカート内の数量など）という場合、ページ全体を動的レンダリングにするか、パーソナライズを諦めるしかありませんでした。
Server Islands の考え方はこうです：まず静的な HTML の外枠を返し、動的な部分だけサーバーが後から注入する。
公式には「パフォーマンスとパーソナライズはもはや両立できないわけではない」と説明しています。実際に試しましたが、非常にスムーズでした。

Content Layer——コンテンツ管理の新しいやり方

ブログ記事が 100 を超えると、コンテンツ管理が散らかり始めます。
従来は src/content に Markdown を積み上げ、ファイルシステムで整理していました。記事が少なければ問題ありませんが、増えるとファイル探しも CMS 連携も面倒になります。
Astro 5 の Content Layer はこの状況を大きく変えます。
核となるのは Loader という仕組みです。ローカルの Markdown、Strapi、Contentful、Notion、自作 API など、どこからでもコンテンツを読み込めます。データソースが統一されるので、管理がすっきりします。

// astro.config.mjs
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
  loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    tags: z.array(z.string()),
  }),
});

この設定は、「./src/content/blog からすべての Markdown を読み込み、各記事に title、pubDate、tags が必須」という意味です。
パフォーマンス面では、公式によると Markdown ビルドが最大 5 倍、MDX が 2 倍速くなり、メモリ使用量は 25〜50% 削減されます。私のブログでビルド時間が 2 分から 18 秒になったのも、この恩恵が大きいでしょう。
現在は glob loader でローカル Markdown を読み込んでいます。今後は Notion と連携して、執筆と公開を分けようと考えています。

View Transitions——滑らかなページ遷移

ここは手短に。
Astro 5 では従来の ViewTransitions コンポーネントが ClientRouter に名称変更されました。機能は同じで、クライアントサイドルーティングであることが名前からより明確になっています。

---
import { ClientRouter } from 'astro:transitions';
---
<html>
  <head>
    <ClientRouter />
  </head>
  <body>
    <!-- コンテンツ -->
  </body>
</html>

これを追加するだけで、ページ遷移にフェードなどのアニメーションが付き、SPA のような滑らかな体験になります。
2025 年現在、ネイティブ View Transitions API はほぼすべてのモダンブラウザでサポートされています（Firefox が最後でした）。ClientRouter は非対応ブラウザへのフォールバックも自動で提供します。
音楽プレーヤーのようにページを跨いで状態を維持したいなら ClientRouter が有効です。単にクロスフェードさせたいだけなら、ネイティブ CSS View Transitions でも十分かもしれません。

SEO 最適化の実践設定

ここが重要です。Astro が速いから SEO も万全、と思いがちですが、速度は評価の一部にすぎません。ページ構造の明確さやメタデータの正確さも、検索エンジンは見ています。
最初の設定でハマったポイントを含め、正しい手順を共有します。

Sitemap 設定

基本中の基本ですが、忘れがちなのが sitemap です。

npx astro add sitemap

astro.config.mjs にサイト URL を記述します：

import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
  site: 'https://yourdomain.com', // これを忘れないで！
  integrations: [sitemap()],
});

最初 site を設定し忘れ、生成された sitemap がすべて相対パスになり、Google に認識されませんでした。気づくまで数日かかりました。

Meta タグ管理

各記事に固有の title と description を設定しましょう。私は Markdown の frontmatter で統一管理しています：

---
title: "Astro 5 パフォーマンス最適化ガイド"
description: "Astro 5 の Island アーキテクチャと Content Layer を徹底解説..."
publishDate: 2025-11-20
ogImage: "/images/astro-5-cover.png"
---

レイアウトコンポーネントでこれらを読み込みます：

---
const { title, description, ogImage } = Astro.props.frontmatter;
---
<head>
  <title>{title}</title>
  <meta name="description" content={description} />
  <meta property="og:title" content={title} />
  <meta property="og:description" content={description} />
  <meta property="og:image" content={ogImage} />
  <link rel="canonical" href={Astro.url} />
</head>

canonical URL は重要です。同一コンテンツが重複ページと判断されるのを防ぎます。

構造化データ（JSON-LD）

意外と知られていませんが、SEO 効果の高い設定です。検索エンジンに「これは記事です」「著者は誰です」「公開日はいつです」と明確に伝えられます。

<script type="application/ld+json">
  {JSON.stringify({
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": title,
    "datePublished": publishDate,
    "author": {
      "@type": "Person",
      "name": "あなたの名前"
    }
  })}
</script>

Schema.org Validator で正しく設定できているか確認できます。

2025 年の SEO トレンド

今年特に重要な変化をいくつか：

LLM もページをクロールしている。検索エンジンも AI も構造化されたコンテンツを重視する。キーワードの羅列より、内容の明確さが重要。
内部リンクが重要。各ページに最低 3 つの内部リンクがないと、検索エンジンは価値が低いと判断しやすい。
E-E-A-T 原則。経験（Experience）、専門性（Expertise）、権威性（Authoritativeness）、信頼性（Trustworthiness）——精神論ではなく、Google の実際のランキング要因です。

SEO チェックリスト

設定後、このリストで確認してください：

sitemap.xml が生成され、アクセス可能
各ページに固有の title と description がある
すべての画像に alt 属性がある
JSON-LD 構造化データを追加した
robots.txt が正しく設定されている
各ページに 3 つ以上の内部リンクがある

画像最適化——見落としがちなパフォーマンスキラー

「画像を圧縮すれば十分」と思っていませんか？実際はもっと奥があります。
Astro には astro:assets モジュールと強力な Image コンポーネントが組み込まれています：

---
import { Image } from 'astro:assets';
import myImage from '../assets/hero.png';
---
<Image
  src={myImage}
  alt="Hero image"
  widths={[400, 800, 1200]}
  format="webp"
/>

このコードが行うこと：

画像の縦横比を自動推論し、レイアウトシフト（CLS）を防ぐ
複数サイズの画像を生成し、ブラウザが最適なサイズを選んで読み込む
軽量な WebP 形式に変換する

重要：画像は public ではなく src に置いてください。 src 内の画像は Astro が最適化しますが、public 内はそのまま配信されます。最初は public に置いていて、ファイルサイズが巨大なままでした。

リモート画像は inferSize でサイズを自動取得できます：

<Image
  src="https://example.com/image.jpg"
  alt="Remote image"
  inferSize
/>

効果は劇的です。AstroEdge という OSS プロジェクトのテストでは、画像が 4.2MB から 0.8MB に（82% 削減）、パフォーマンススコアが 79 から 100 に改善しました。
Astro 5 では実験的な画像クロップ機能と SVG コンポーネントのサポートも追加されています。

他フレームワークからの移行で知っておくこと

Astro 4 や他フレームワークから移行する方向けのメモです。

Astro 5 の主な変更点：

ViewTransitions → ClientRouter に名称変更
Astro.glob() が非推奨。import.meta.glob() または getCollection() を使用
Hybrid レンダリングモードが static 出力に統合
画像処理が Squoosh から Sharp に変更
CSRF 保護がデフォルトで有効化

移行コマンドはシンプルです：

npx @astrojs/upgrade

このコマンドが主要な互換性処理を行い、手動修正が必要な箇所も案内してくれます。
Next.js や Gatsby からの移行は少し骨が折れますが、Astro は React コンポーネントをそのまま使えるので、まずページを移してコンポーネントは徐々に置き換える戦略が取れます。

まとめ

要点を整理します：

Island アーキテクチャでページはデフォルト JS ゼロ。パフォーマンスが自然に向上
Content Layerですべてのコンテンツソースを統一管理
SEO 設定は数ステップだが、それぞれが重要
画像最適化は見落としがちな大きな改善ポイント
View Transitions（ClientRouter）でアプリのような操作感を実現

フレームワーク選びで迷っているなら、30 分だけ Astro の公式テンプレートを試してみてください。ビルド速度と Lighthouse スコアに驚くはずです。

npm create astro@latest -- --template blog

このテンプレートはすぐ使え、設定を少し変えれば公開できます。

参考リソース：

Astro 公式ドキュメント（英語ですが最も情報が早い）
Astro 日本語ドキュメント

次回は Astro + Tailwind + MDX で技術ブログを構築する実践チュートリアルを書く予定です。

あなたのブログはどのフレームワークを使っていますか？パフォーマンスに悩みはありますか？ぜひコメントで教えてください。

Next.js から Astro 5 への完全移行フロー

移行準備から SEO 設定まで。Lighthouse パフォーマンススコアを 68 から 98 に引き上げる手順

Estimated time: PT4H

1

Step 1: Island アーキテクチャとパフォーマンスの理解

Island アーキテクチャの要点：
2

Step 2: Content Layer でコンテンツを管理

Content Layer の核は Loader 機構：
3

Step 3: SEO 最適化を設定

Sitemap 設定：
4

Step 4: 画像パフォーマンスを最適化

Astro 組み込み astro:assets の Image コンポーネント：
5

Step 5: View Transitions を設定

Astro 5 では ViewTransitions コンポーネントが ClientRouter に名称変更。機能は同じで、クライアントサイドルーティングであることがより明確。使用：import { ClientRouter } from ‘astro:transitions’、<head> に <ClientRouter /> を追加。追加後はページ遷移にアニメーションが付き、体験が向上。2025 年、ネイティブ View Transitions API はほぼすべてのモダンブラウザでサポート（Firefox が最後）。ClientRouter は非対応ブラウザへのフォールバックも自動提供。ページを跨いで状態を共有したい場合（音楽プレーヤーなど）は ClientRouter が有効。単純な遷移アニメーションならネイティブ CSS View Transitions でも十分。
6

Step 6: 他フレームワークから移行

Astro 5 の主な変更：ViewTransitions → ClientRouter、Astro.glob() 非推奨（import.meta.glob() または getCollection() を使用）、Hybrid レンダリングが static 出力に統合、画像処理が Squoosh から Sharp に、CSRF 保護がデフォルト有効。移行コマンド：npx @astrojs/upgrade（互換性処理を自動実行、手動修正箇所も案内）。Next.js や Gatsby からの移行は作業量が多いが、Astro は React コンポーネントをサポートしているので、まずページを移してコンポーネントは徐々に置き換え可能。

FAQ

Next.js から Astro 5 に移行して、どれくらいパフォーマンスが向上しますか？

実プロジェクトの測定データ：
• ビルド時間：2 分 → 18 秒（85% 短縮）
• Lighthouse パフォーマンススコア：68 → 98（44% 向上）
• FCP：2.1 秒 → 0.8 秒（62% 高速化）
• TTI：4.5 秒 → 1.2 秒（73% 高速化）
• JS バンドル：280KB → 45KB（84% 削減）

State of JavaScript 2024 調査：
• Astro は関心度・継続利用率・満足度の 3 項目すべてで 1 位
• Astro サイトの 60% が Core Web Vitals 合格。WordPress と Gatsby は 38%

コンテンツ展示型サイトにとって、Astro はパフォーマンス面で明確な優位性があります。

Astro の Island アーキテクチャとは？どう理解して使えばいい？

Island アーキテクチャの要点：
• ページ全体を静的 HTML の海と想像し、カウンター、フォーム、コメント欄など本当にインタラクションが必要なコンポーネントだけが「島」として浮かび上がる
• 各島は独自に JavaScript を管理し、互いに干渉しない

コード例：
• <Counter client:visible />（スクロールして表示領域に入ったときだけ JS を読み込む）
• <Header />（常に純粋な静的 HTML。JS は読み込まない）

Astro のディレクティブ：
• client:visible（表示領域に入ったときにアクティブ化）
• client:load（ページ読み込み時にアクティブ化）
• client:idle（ブラウザがアイドル状態のときにアクティブ化）

Server Islands（Astro 5 の新機能）：
• まず静的 HTML の外枠を返し、動的な部分だけサーバーが注入
• 公式には「パフォーマンスとパーソナライズはもはや両立できないわけではない」

ページ全体がインタラクティブなコンポーネントで構成されている場合、Astro は最適とは限りません。コンテンツの大部分が静的なブログやドキュメントサイトにとっては、非常に強力な選択肢です。

Astro 5 の Content Layer はどう設定する？パフォーマンス向上は？

Content Layer の核は Loader 機構。どこからでもコンテンツを読み込めます：
• ローカル Markdown、Strapi、Contentful、Notion、自作 API など
• データソースが統一され、管理がすっきりする

設定例（astro.config.mjs）：
defineCollection({
loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
schema: z.object({
title: z.string(),
pubDate: z.date(),
tags: z.array(z.string())
})
})

この設定は ./src/content/blog からすべての Markdown を読み込み、各記事に title、pubDate、tags が必須という意味です。

パフォーマンス向上：
• Markdown ビルドが最大 5 倍、MDX が 2 倍高速化
• メモリ使用量 25〜50% 削減
• 実測：ビルド時間が 2 分から 18 秒に

現在は glob loader でローカル Markdown を読み込んでいます。今後 Notion と連携して執筆と公開を分ける予定です。

Astro 5 の SEO 最適化はどう設定する？重要ポイントは？

Sitemap 設定：
• npx astro add sitemap を実行
• astro.config.mjs に site: 'https://yourdomain.com' を追加（忘れると sitemap が相対パスになり Google に認識されない）

Meta タグ管理：
• 各記事に固有の title と description を設定
• Markdown frontmatter で title / description / publishDate / ogImage を統一管理
• レイアウトコンポーネントで title / meta / canonical URL を設定（canonical URL は重複コンテンツ対策として重要）

構造化データ JSON-LD：
• 記事、著者、公開日を検索エンジンに明示。SEO 効果が高い
• Schema.org Validator で検証

2025 年の SEO トレンド：
1) LLM もページをクロール。構造化されたコンテンツの質が重要
2) 内部リンクは各ページ最低 3 つ。孤立ページは評価されにくい
3) E-E-A-T 原則（経験、専門性、権威性、信頼性）は Google の実際のランキング要因

SEO チェックリスト：
• sitemap.xml が生成されアクセス可能
• 各ページに固有の title と description
• すべての画像に alt 属性
• JSON-LD 構造化データを追加
• robots.txt が正しく設定
• 各ページに 3 つ以上の内部リンク

Astro の画像最適化はどう設定する？重要なコツは？

Astro 組み込み astro:assets の Image コンポーネント：
• 画像の縦横比を自動推論し CLS を防止
• 複数サイズを生成し、ブラウザが最適なサイズを選択
• WebP 形式に変換してファイルサイズを削減

使用例：
import { Image } from 'astro:assets'
import myImage from '../assets/hero.png'
<Image src={myImage} alt="Hero image" widths={[400, 800, 1200]} format="webp" />

重要ポイント：
• 画像は src に置き、public には置かない
• src 内は Astro が最適化、public 内は最適化されない

リモート画像は inferSize でサイズを自動取得：
<Image src="https://example.com/image.jpg" alt="Remote image" inferSize />

効果：
• AstroEdge のテスト：4.2MB → 0.8MB（82% 削減）、スコア 79 → 100

Astro 5 では実験的な画像クロップ機能と SVG コンポーネントのサポートも追加。

他フレームワークから Astro 5 に移行する際の注意点は？

Astro 5 の主な変更：
1) ViewTransitions → ClientRouter
2) Astro.glob() 非推奨。import.meta.glob() または getCollection() を使用
3) Hybrid レンダリングが static 出力に統合
4) 画像処理が Squoosh から Sharp に
5) CSRF 保護がデフォルト有効

移行コマンド：
• npx @astrojs/upgrade（互換性処理を自動実行、手動修正箇所も案内）

Next.js や Gatsby からの移行：
• 作業量は多いが、Astro は React コンポーネントをサポート。まずページを移してコンポーネントは徐々に置き換え可能

フレームワーク選びで迷っているなら：
• 30 分 Astro 公式テンプレートを試す
• npm create astro@latest -- --template blog
• 設定を少し変えればすぐ公開できる

6分で読めます · 公開日: 2025年11月24日 · 更新日: 2026年6月8日

Easton

技術開発

シリーズの読書導線第 2 / 6 記事

フロントエンドフレームワーク比較

検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。

シリーズ全体を見る

2025年版ブログフレームワーク選定ガイド：Hugo、Astro、Hexo どれを選ぶ？

2025年最新のブログフレームワーク比較。実測データに基づき Hugo、Astro、Hexo など 9 大静的ブログフレームワークの性能・使いやすさ・エコシステムを徹底比較。3 分の決定マトリックスで初心者の 90% の落とし穴を回避し、最適な選択へ。

第 1 / 6 記事

React に疲れた？Svelte 5 でコード半減・性能 2 倍（完全チュートリアル付き）

Svelte 5 の Runes システムとコンパイル時最適化の考え方を深掘り。Todo プロジェクトで React/Vue と性能を比較し、フロントエンド開発者がこの高性能フレームワークを身につける手助けをします。1〜3 年程度の経験者向け。

第 3 / 6 記事

2025年11月23日技術開発

フロントエンド性能最適化の実践：Core Web Vitals満点攻略

GitHubアカウントでログインしてコメントできます

なぜ Astro に注目すべきか

Island アーキテクチャ——Astro が速い理由

Server Islands——Astro 5 の新機能

Content Layer——コンテンツ管理の新しいやり方

View Transitions——滑らかなページ遷移

SEO 最適化の実践設定

Sitemap 設定

Meta タグ管理

構造化データ（JSON-LD）

2025 年の SEO トレンド

SEO チェックリスト

画像最適化——見落としがちなパフォーマンスキラー

他フレームワークからの移行で知っておくこと

まとめ

Next.js から Astro 5 への完全移行フロー

Step 1: Island アーキテクチャとパフォーマンスの理解

Step 2: Content Layer でコンテンツを管理

Step 3: SEO 最適化を設定

Step 4: 画像パフォーマンスを最適化

Step 5: View Transitions を設定

Step 6: 他フレームワークから移行

FAQ

フロントエンドフレームワーク比較

2025年版ブログフレームワーク選定ガイド：Hugo、Astro、Hexo どれを選ぶ？

React に疲れた？Svelte 5 でコード半減・性能 2 倍（完全チュートリアル付き）

関連記事

React 19 のフォーム、まだ 30 行？Actions で一気に短縮、パフォーマンス 40% 向上

React 19 のフォーム、まだ 30 行？Actions で一気に短縮、パフォーマンス 40% 向上

Vue 3 + TypeScript ベストプラクティス：2025年版エンタープライズ構成ガイド

Vue 3 + TypeScript ベストプラクティス：2025年版エンタープライズ構成ガイド

フロントエンド性能最適化の実践：Core Web Vitals満点攻略

フロントエンド性能最適化の実践：Core Web Vitals満点攻略

コメント