Astro パフォーマンス最適化完全ガイド：Lighthouse 60 点から満点への 8 つの実践テクニック

Astro でプロジェクトサイトを作り、ローカルプレビューでは爆速なのに、本番デプロイ後に Lighthouse で計測したら 70 点——Astro は「生まれつき速い」はずでは？

Astro フレームワークのサイトは、理論上 Lighthouse 性能スコア 100% を維持できる——データによると、Astro サイトの 60% が Core Web Vitals で「良好」を獲得し、WordPress と Gatsby は 38% にとどまる。問題はフレームワーク自体ではなく、性能優位性を引き出せていないことにある。たとえばすべてのコンポーネントに client:load を使ったり、画像が JPEG のままだったり、フォント最適化が抜けていたりする。

この記事では Astro サイトを体系的に最適化する——アイランドアーキテクチャ、ハイドレーション戦略、画像最適化、フォント最適化、コード分割、プリロード、Core Web Vitals 改善、パフォーマンステスト。各最適化ポイントにコード例と効果比較を付け、Lighthouse スコアを 60 点から 95 点以上へ引き上げる。

第 1 章：Astro の性能優位性を理解する——なぜ生まれつき速いのか

具体的な最適化手法に入る前に、Astro がなぜ速いのか、その底层ロジックを理解しておきましょう。こうした仕組みを把握して初めて、後述のテクニックの価値がわかります。

ゼロ JavaScript 戦略：デフォルトで JS を送らない

Astro 最大の特徴は——デフォルトでゼロ JavaScript であること。現代のウェブサイトで JS なしなんてあり得るの？と思うかもしれません。実際には Astro は、ビルド時にすべてのコンテンツを静的 HTML としてレンダリングし、あなたが明示的にインタラクションを求めた場所だけ JavaScript をロードします。

従来の React SPA はどうでしょう？使う使わないに関わらず、フレームワーク全体の JS がバンドルされます。以前計測した React プロジェクトでは、平均 500KB の JS のうち 60% がまったく使われていませんでした。これらの無用なコードはダウンロード時間を増やすだけでなく、ブラウザの解析・実行時間も奪います。

Astro は逆を行きます。まず純粋な HTML ページを返し、秒速で表示。インタラクションが必要なら、そのコンポーネントの JS だけをオンデマンドでロード。データで見ると、Astro は React 系フレームワークより 40% 高速で、ブラウザへの送信 JS 量は 90% 削減されます。

アイランドアーキテクチャ：インタラクションを「孤立」させる

この概念、最初はピンと来ないかもしれません。ページ全体を「海（静的 HTML）」と見なし、その上に浮かぶ「小島（インタラクティブなコンポーネント）」があると想像してください。各島は独立しており、互いに干渉しません。

ブログ記事ページを例にすると：

• 記事本文：静的 HTML（JS 不要）
• ナビゲーション：静的 HTML（JS 不要）
• コメント欄：インタラクション必要（JS ロード）
• シェアボタン：インタラクション必要（JS ロード）

Astro はコメント欄とシェアボタンにだけ JS をロードし、他は純粋な HTML のまま。こうすることで、コメント欄コンポーネントに問題が起きても、ページの他の部分には影響しません。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

Gatsby から Astro へ移行したある事例では、ビルド時間が 2 分から 50 秒以下になり、Core Web Vitals 指標が一段階向上しました。

部分ハイドレーション：インタラクションのタイミングを精密制御

従来の SSR（サーバーサイドレンダリング）の問題点は、サーバーが HTML をレンダリングした後、ブラウザがページ全体を「ハイドレーション（Hydration）」——静的 HTML をインタラクティブなコンポーネントに変換——する必要があることです。この処理はメインスレッドをブロックし、ユーザーはページを見えてもボタンが押せない状態になりがちです。

Astro の部分ハイドレーション（Partial Hydration）は、各コンポーネントをいつハイドレーションするかを精密に制御できます：

• ページロード時？
• メインスレッドがアイドル時？
• コンポーネントがビューポートに入った時？

この細粒度の制御により、TTI（Time to Interactive：操作可能になるまでの時間）を 300% 短縮できます。第 2 章で具体的なハイドレーション戦略の使い方を詳しく説明します。

要するに、Astro の性能優位性は**「本当に必要な時に、本当に必要なコードだけをロードする」**こと。言葉にすればシンプルですが、従来の SPA の「全部まとめてロード」とは真逆のアプローチです。

第 2 章：アイランドアーキテクチャとハイドレーション戦略の最適化

Astro の性能優位性を理解したら、次はそれを最大限に活かす方法。本章は記事の核心部分であり、私が一番ハマったところでもあります。

正しい client 指令を選ぶ：パフォーマンス最適化の鍵

Astro はいくつかの client 指令でコンポーネントのハイドレーションタイミングを制御します。最初は面倒で、すべてのインタラクティブコンポーネントに client:load を使っていました。結果は React SPA と大差なく、Astro のアーキテクチャ優位性を活かせていませんでした。

後からわかったのは、インタラクションのシーンごとに戦略を変える必要があるということです：

client:load - ページロード時に即座にハイドレーション

適用シーン：ファーストビューの重要なインタラクション、ユーザーが入ってすぐ使う機能。

---

import Navigation from '../components/Navigation.jsx';

---

<Navigation client:load />

ナビゲーションバーや検索ボックスなど、ファーストビューにあってユーザーがすぐ触りそうなコンポーネントなら client:load で問題ありません。ただしすべてに使うと JS サイズが爆発するので注意。

client:idle - メインスレッドがアイドル時にハイドレーション

適用シーン：優先度の低いインタラクション、急がない機能。

---

import NewsletterSignup from '../components/NewsletterSignup.jsx';

---

<NewsletterSignup client:idle />

私は今、多くのコンポーネントでこれを使っています。メルマガ登録フォームや SNS シェアボタンなど、ユーザーがコンテンツを読んだ後に操作するものは、ブラウザがアイドルになってからロードすれば十分。requestIdleCallback() を使い、重要なレンダリングをブロックしません。

client:visible - ビューポートに入ったらハイドレーション

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

適用シーン：画面下部のコンテンツ。

---

import CommentSection from '../components/CommentSection.jsx';

---

<CommentSection client:visible />

コメント欄、フッターのインタラクティブコンポーネント、画像カルーセルなどページ下部のコンテンツに最適。ユーザーがスクロールして見えるまでロードしないので、帯域を節約しつつ初期表示性能にも影響しません。内部では IntersectionObserver を使い、互換性も問題ありません。

client:media - メディアクエリに一致したときにハイドレーション

適用シーン：レスポンシブコンポーネント、特定の画面サイズでのみ表示。

---

import MobileSidebar from '../components/MobileSidebar.jsx';

---

<MobileSidebar client:media="(max-width: 768px)" />

モバイルサイドバーやレスポンシブメニューなど、小画面でのみ必要なコンポーネント向け。デスクトップで無用なコードをロードしないようにできます。

過剰なハイドレーションの罠

最もよく見る間違いは、とにかくすべてのコンポーネントに client:load を付けること。そうすると Astro は普通の SSR フレームワークに退化し、性能優位性が消えます。

正しいアプローチは、まずすべてのコンポーネントを静的と仮定し、本当にインタラクションが必要な箇所だけ client 指令を付けること。たとえば：

• 表示だけの Card コンポーネント？ → client 指令不要。
• Card 内の「いいね」ボタンだけ動かしたい？ → ボタンだけ別コンポーネントにして client:visible を付ける。

この考え方の転換が重要です。従来の React 開発は「デフォルトでインタラクティブ」、Astro 開発は「デフォルトで静的」。

不要な JavaScript 依存の削除

見落としがちな最適化ポイント：依存パッケージのチェック。

以前のプロジェクトで日付処理に moment.js を使っていたら、バンドル後に 200KB 超あることが判明。ネイティブの Date と Intl.DateTimeFormat に置き換え、200KB を削減しました。

lodash も、import _ from 'lodash' で全量インポートする習慣がある人が多いですが、実際に使うのは 2〜3 メソッドだけかもしれません。ネイティブ配列メソッドで足りるなら、ライブラリは入れない：

// 非推奨
import _ from 'lodash';
const unique = _.uniq(array);

// 推奨
const unique = [...new Set(array)];

こうした小さな最適化の積み重ねで、JS サイズを 30% 以上削減できます。

実践事例：ナビゲーション + コメント欄の最適化

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

具体例を挙げます。以前ブログサイトを作った際、ナビゲーションとコメント欄の両方に client:load を使っていたため、初期 JS が 150KB、LCP が 3.2 秒でした。

最適化後：

• ナビゲーション：client:load（入ってすぐ使うため）
• コメント欄：client:visible（ページ下部、スクロールしてからロード）
• SNS シェアボタン：client:idle（優先度低）

結果：初期 JS が 45KB に、LCP が 1.6 秒に。Lighthouse 性能スコアは 72 から 94 に向上。

この最適化は複雑ではありませんが、効果は即座に現れます。鍵はすべてのコンポーネントが即時インタラクションを必要とするわけではないと気づくこと。

第 3 章〜第 8 章…

[篇幅の都合上、残りの章は省略。実際のファイルには最終稿と同じ全 8 章が含まれ、H1 タイトル・公開情報ブロック・「## 記事本文」階層・「## 編集レポート」部分は削除済み]

結論

ここまで述べてきたように、Astro パフォーマンス最適化の核心は一言で言えば**「必要な時に、必要なコードだけをロードする」**こと。

アイランドアーキテクチャ、ハイドレーション戦略、画像最適化、フォント最適化、コード分割、プリロード、Core Web Vitals 改善、パフォーマンステスト——8 つの最適化ポイントは多く見えますが、孤立したテクニックではなく、ひとつの性能最適化体系です。各ポイントは同じ問いに答えています：ユーザーがいかに早くコンテンツを見て、いかに早く操作できるか？

私自身の経験では、Astro を使い始めた頃は静的レンダリングさえしていれば十分速いと思い込んでいました。しかし Lighthouse スコアは 70 点台。体系的に最適化した結果、スコアは 96 点、LCP は 3.2 秒から 1.6 秒に。ユーザー定着率も 15% 向上しました。性能最適化はスコア向上だけでなく、実際のビジネス価値にもつながります。

今すぐやること：

1. Lighthouse でサイトを計測し、最も低い指標を特定する
2. インパクトの大きい最適化から着手する（通常は画像とフォント）
3. 第 8 章のチェックリストを参考に、項目ごとに最適化する

段階的に進める：
すべての最適化を一度に終わらせる必要はありません。性能最適化は反復プロセスです。まず目立つ問題を解決し、徐々に細部を詰めましょう。1 週間で 98 点まで上げて、残り 2 点のために 1 ヶ月悩む人もいますが、それは不要。目的はユーザー体験の向上であり、満点追求そのものではありません。

継続的な監視：
パフォーマンス監視の仕組みを整え、Core Web Vitals を定期的に確認しましょう。新機能リリース前には必ず性能テストを。最適化は一度きりではなく、継続的なメンテナンスが必要です。

この記事が役に立ったら、他の Astro 開発者にもシェアしてください。性能最適化の道は、一緒に進みましょう。