Astroサイトの品質改善手順：速度・SEO・アクセシビリティを測って直す

2026年9月26日追記： この記事は2026年3月25日時点の改善記録です。「99点が上限」という当時の見立ては、その後の3月29日の再測定記事で100点を確認したため、現在の結論ではありません。数値は各測定時の結果であり、現在のスコアを示すものではありません。PageSpeed Insightsの公式説明のとおり、測定値には変動があります。

最初の改善は同じページの転送量から選ぶ

トップと記事の代表ページを同じ条件で測り、CSS・フォント・画像・外部JSの転送量を並べます。最も重いものを一つ変更して再計測し、フォームと検索も試してください。自動監査の100点はWCAG全項目への適合を証明しないため、キーボード操作や読み上げ確認は別に行います。

PageSpeed Insights：ラボ測定と実利用データの違い

はじめに

2026年3月にリニューアルした Acecore 公式サイトは、Astro 6 + UnoCSS + Cloudflare Pages の構成で公開しました。しかし、リニューアル直後のサイトはまだ「動く」だけのレベル。パフォーマンス・SEO・アクセシビリティ・UXのすべてに改善の余地がありました。

この記事では、150項目超の改善を経て PageSpeed Insights モバイル99点・デスクトップ全項目100点 を達成するまでの全体像をまとめています。

Web制作の費用や運用範囲の整理は、ホームページ制作の費用相場と見積もりで見るべきポイントでも扱っています。

---

PageSpeed モバイル99点の壁

まず伝えたいのは、PageSpeed Insights のモバイルスコアで高得点を出すのは、想像以上に難しい ということです。

Lighthouse のモバイルシミュレーション

PageSpeed Insights の裏側で動いているのは Lighthouse というツールで、モバイルのテストには以下のスロットリングが適用されます。

項目	設定値
ダウンロード速度	約 1.6 Mbps（slow 4G）
アップロード速度	約 0.75 Mbps
レイテンシ	150 ms（RTT）
CPU	4倍スローダウン

つまり、光回線で1秒で開くページでも、Lighthouse のシミュレーション上では 5〜6秒かかる 計算です。200 KiB のCSSを読み込むだけで、slow 4G では 約1秒 のブロッキングが発生します。

スコアの非線形性

PageSpeedのスコアは線形ではありません。

• 50 → 90：基本的な最適化（画像圧縮・不要スクリプト削除）で到達可能
• 90 → 95：CSS・フォント・画像の配信戦略の工夫が必要
• 95 → 99：ミリ秒単位のチューニング。CSSのインライン化 vs 外部ファイル化の判断が問われる
• 99 → 100：外部CDNの応答速度やLighthouse自体の計測揺れに左右される。AdSense・GA4を含むサイトでは安定達成が極めて困難

スコアの揺れ

同じサイトでも、計測するたびにスコアが 2〜5点 変動することがあります。原因は以下の通りです。

• Cloudflare Images などの画像変換基盤の応答速度
• Cloudflare Pages エッジサーバーのキャッシュ状態
• Lighthouse自体の計測誤差

このため、「1回で100点が出た」ではなく「繰り返し計測して安定的に高スコアが出る」ことを目標にすべきです。

---

最終スコア

上記の困難にもかかわらず、以下のスコアを安定して達成できるようになりました。

指標	モバイル	デスクトップ
Performance	99	100
Accessibility	100	100
Best Practices	100	100
SEO	100	100

---

改善の4つの柱

改善は大きく4つのカテゴリに分けて進めました。それぞれの詳細は個別の記事で解説しています。

1. パフォーマンス

モバイル99点の達成に最も寄与したのがパフォーマンス最適化です。CSSの配信戦略（インライン vs 外部ファイル）、フォントのセルフホスト、レスポンシブ画像の最適化、AdSense/GA4 の遅延読み込みなど、ひとつずつボトルネックを潰していきました。

特に効果が大きかったのは以下の3つです。

• CSS外部ファイル化：190 KiB のCSSをインライン展開していた状態から外部ファイルに切り替え、HTML転送量を最大91%削減
• フォント名の不一致修正：@fontsource-variable/noto-sans-jp が登録するフォント名 Noto Sans JP Variable と、CSSで参照していた Noto Sans JP が一致していなかった問題を発見・修正
• レスポンシブ画像：srcset + sizes をすべての画像に設定し、モバイル向けに適切なサイズを配信

2. SEO

Googleのリッチリザルトに対応するため、7種類のJSON-LD構造化データを実装しました。OGPメタタグ・canonical・サイトマップの最適化・RSSフィードの拡充も含め、検索エンジンにサイトの構造を正確に伝える基盤を整えています。

3. アクセシビリティ

PageSpeed Accessibility 100点は、axe DevTools やLighthouse の自動テストをクリアすることで達成しました。装飾アイコンの aria-hidden（30か所以上）、外部リンクのSR通知、コントラスト修正（text-slate-400 → text-slate-500）、focus-visible スタイルの全体適用など、地道な対応を積み重ねています。

4. UX・コード品質

View Transitions（ClientRouter）の導入によるスクリプト停止問題を全コンポーネントで解消し、Pagefind による全文検索も実装しました。コード面では TypeScript の型安全性向上、定数の一元管理（SITE定数にソーシャルURL・広告ID・GA4 IDを集約）を行い、保守性を大幅に改善しています。

---

技術スタック

技術	用途
Astro 6	静的サイト生成（ゼロJSアーキテクチャ）
UnoCSS (presetWind3)	ユーティリティファーストCSS
Cloudflare Pages	ホスティング・CDN・ヘッダー制御
@fontsource-variable/noto-sans-jp	日本語フォントのセルフホスト
Cloudflare Images	画像変換（AVIF/WebP自動変換）
Pagefind	静的サイト向け全文検索

---

まとめ

PageSpeed Insights でモバイル99点を達成するには、「不要なものを送らない」という原則を徹底することが重要です。CSSの配信戦略、フォントのセルフホスト、画像の最適化、外部スクリプトの遅延読み込み——ひとつずつはシンプルな施策ですが、組み合わせることで大きな効果が得られます。

同時に、SEO・アクセシビリティ・UXの改善を並行して進めることで、4項目すべてで高スコアを達成できます。100点にこだわるよりも、95点以上を安定して出せる状態を目指すのが現実的なゴールです。

各トピックの詳細は上のリンクカードからどうぞ。改善の進め方やコードへの反映については、AIと判断記録を共有した確定申告の事例も合わせてご覧ください。