Astroサイトの品質改善ガイド 続編 ― PageSpeed Insights 全項目100点を達成した最終調整

はじめに

前回の Astroサイトの品質改善ガイド では、リニューアル後の Acecore サイトに対して行った大規模な改善をまとめました。今回の記事はその続編です。

今回は、前回記事の公開後に残っていた細かな課題を順に整理し、最終的に PageSpeed Insights のモバイル / デスクトップともに 4 指標すべて 100 を確認できる状態まで持っていきました。さらに、単なるスコア調整にとどまらず、GA4 と検索UIの読み込み順序の見直し、Search Console のパンくずと索引方針の整理、アイコン描画の安定化、そして「どこまでやれば十分か」という判断基準の言語化まで含めて仕上げています。

PageSpeed Insights 全項目100の結果

2026年3月29日時点で、Acecore トップページは以下の結果を確認できました。

計測面	Performance	Accessibility	Best Practices	SEO
携帯電話	100	100	100	100
デスクトップ	100	100	100	100

以下に、実際の PageSpeed Insights のスクリーンショットとレポートURLをまとめて置いています。前回は「モバイル 99 / その他 100」が現実的な上限だと見ていましたが、不要な第三者 beacon を整理し、残診断の意味を精査したことで、今回は 100 まで到達しました。

計測レポートURL

スクリーンショットだけでなく、あとから同じ結果ページを直接確認できるように、今回の計測に使ったレポートURLも残しておきます。

• モバイルのレポート
• デスクトップのレポート

実際の計測スクリーンショット

画像をクリックすると、該当する PageSpeed Insights のレポートをそのまま開けます。

モバイル	デスクトップ

100 点がどのくらいすごいのか

100 点と聞くと、機能を減らし、見た目を簡素にし、外部要素を削れば Performance はいくらでも上げられるのでは、と思うかもしれません。実際、静的サイトは削るほど速くしやすい面があります。

ただ今回は、GA4、広告、検索、ClientRouter、共通 CSS など実運用に必要な要素を残したまま、モバイル / デスクトップの 4 指標すべてを 100 に揃える必要がありました。単に軽くするだけではなく、何を残し、何を切り、何は無理に触らないかまで含めた調整が必要でした。

もちろん、100 点は現実世界で絶対最速を意味しません。実ユーザーの体感は回線、端末、地域、キャッシュ状態に左右されます。それでも、必要な運用要素を残したまま Lighthouse が見る主要監査で大きな取りこぼしがない という意味では、かなり高い完成度に入ったと言ってよい状態です。

100 点に到達するまでの最終調整

1. Cloudflare Web Analytics を停止し、計測の役割を整理した

Cloudflare Web Analytics は privacy-first で軽量な RUM としては便利ですが、Acecore ではすでに GA4 側で CTA、検索、問い合わせ、lead 生成などのイベント計測を広く実装済みでした。

そのため今回あらためて役割を見直し、Cloudflare 側は PageSpeed 上の不要な beacon 注入としてのコストが勝つと判断。ダッシュボードから RUM を無効化し、本番 HTML から static.cloudflareinsights.com/beacon.min.js が消えたことを確認しました。

ただし、計測を全部捨てたわけではありません。CTA、外部リンク、検索、問い合わせ完了などのビジネスイベントは引き続き把握したかったので、GA4 は残す前提で次の調整に進みました。

2. GA4 は残しつつ、初期ロードから外した

ここで効いたのが、GA4 を「残すか消すか」の二択ではなく、「残したまま、いつ読むかを変える」という整理です。

実装としては、gtag の呼び出し口は先に定義してイベント送信を受けられるようにしつつ、実際の gtag/js スクリプト本体は requestIdleCallback とユーザー操作をトリガーに後から読み込む構成へ変更しました。さらにトップページは 12 秒、それ以外は 4 秒の fallback を持たせて、計測が永遠に読まれないケースも避けています。

これで、問い合わせや検索などの計測は維持しながら、初期表示フェーズに第三者スクリプト実行を押し込まない形にできました。今回の 100 点は、単に Cloudflare beacon を止めただけでなく、GA4 側も読み込み順序まで詰めたうえでの結果です。

3. 検索 UI と Pagefind をオンデマンド化した

検索機能も、存在しているだけで初期ロードを重くしやすい代表例です。Acecore では全文検索に Pagefind を使っていますが、今回ここも「最初から読む必要はない」と割り切りました。

具体的には、検索モーダルを開いたときにだけ pagefind-ui.js と CSS を読む構成へ変更し、Promise をキャッシュして二重ロードも防いでいます。Ctrl+K やクエリパラメータ経由の起動にも対応しつつ、使われるまで検索UIの JavaScript を抱え込まないようにしました。

この変更は Lighthouse のスコアだけでなく、日常的な初回表示の軽さにも効きます。検索は残す、でも初期ロードには乗せない、という線引きを入れられたのは今回の大きな改善点でした。

4. PageSpeed の残診断を読み解いた

スコアを 100 にした後も、PageSpeed には ネットワークの依存関係ツリー や render-blocking resources の診断が見えることがあります。ここを全部消すべき警告と誤解すると、費用対効果の低い最適化に入りがちです。

今回のクリティカルチェーンはおおむね以下でした。

1. /en/
2. ClientRouter.js
3. BaseLayout.css
4. BaseLayout.js

この中で実際に render-blocking として残っていたのは BaseLayout.css 1 本です。ただしサイズは小さく、モバイル 100 を維持できているため、現時点では「残っているが許容する診断」と整理しました。この判断を言語化しておくこと自体が、次回以降の改善で迷わないための大きな収穫でした。

5. Search Console のパンくずと索引方針も整理した

PageSpeed で 100 点が出ても、検索面の整合が崩れていれば「仕上がった」とは言いにくい状態です。今回その後の確認で、Search Console 側にはパンくずリストの invalid item が 6 件残っていました。一方、FAQ は 24 件有効で、こちらは問題なしでした。

そこで、BreadcrumbList の JSON-LD を一覧ページ側から明示的に渡せるようにし、item を必ず持つ形へ整理しました。あわせて内部 URL 生成の末尾スラッシュをそろえ、canonical と hreflang と breadcrumb の URL が食い違わないように調整しています。

さらに、tag / archive / author / pagination のような一覧ページは、検索導線としては useful でも正規インデックス対象としては重複や薄い一覧になりやすいため、noindex, follow と sitemap 除外で役割を明確にしました。Search Console の クロール済み - インデックス未登録 や duplicate 系を完全にゼロにできるわけではありませんが、少なくとも「何をインデックスさせ、何をさせないか」の意思はコードで表現できる状態になりました。

6. アイコン描画を shared SVG コンポーネントへ統一

今回の改善の途中で、UnoCSS の icon utility から shared SVG ベースの Icon コンポーネントへ移行する流れがありました。その過程で ProcessFigure や StatBar に残っていた動的 icon class が取り残され、記事中で丸だけ表示される箇所が出ました。

ここは component 側の描画を Icon に統一し、さらに legacy 名の check-circle を circle-check に吸収する alias も追加しました。

結果として、

• dynamic class の取り残しで表示が消える問題を防げる
• aria-hidden などアクセシビリティ属性を SVG 側で統一できる
• UnoCSS の静的解析に依存しないので運用が安定する

という 3 つのメリットが得られました。

また、このタイミングでブログの日時パースと表示も JST 基準でそろえ、日付だけ・時分付き・更新日時付きの扱いがぶれないようにしました。これは PageSpeed の主題ではありませんが、同日投稿の順序や構造化データの日時精度を安定させる意味では、地味に効いている改善です。

7. 試したが採用しなかったこと

100 点が出たあとにやりがちなのは、診断欄に残る項目を片っ端から潰しにいくことです。今回はそこもいくつか比較しましたが、以下は採用しませんでした。

• BaseLayout.css をさらに細かく分割する案: 診断の見た目は少しきれいになる可能性がありますが、現状でもモバイル 100 を維持できており、複雑さのわりに実益が薄いと判断しました。
• network dependency tree の表示自体を消すことを目標にする案: 診断が残ることと、実害があることは別です。説明可能な残り方なら十分だと整理しました。
• GA4 まで削って third-party を極小化する案: PageSpeed だけを見るなら軽くなる余地はありますが、ビジネスイベント計測を失うデメリットの方が大きいため採用しませんでした。

この整理が入ったことで、今回の最終調整は「無理に削り切らない」ところまで含めて完了と判断できるようになりました。

今回の改善で得た実務上の学び

今回いちばん大きかったのは、100 点を取ることそのものよりも、何を消すべきで、何は残してよいかを説明できる状態になった ことです。

たとえば Cloudflare Web Analytics は、なんとなく入っているだけなら切る価値がある一方、GA4 はビジネスイベント計測の中核なので残すべきです。ただし、残すなら初期ロードにそのまま乗せるのではなく、遅延ロードで役割を分ける方がよい。また network dependency tree は、表示されること自体が失敗ではなく、その中身を見て「今の残り方は妥当か」を判断する必要があります。

同じことは検索や SEO にも当てはまります。検索機能は残すが初期ロードには乗せない、一覧ページは残すが正規インデックス対象にはしない、といった線引きができて初めて、速度・機能・検索性のバランスが取れます。今回の最終調整は、PageSpeed だけで終わらず Search Console まで含めて整合を取りに行ったことで、かなり実務的な完成度まで持っていけました。

今回は AI と一緒に候補をかなり広く洗い出しましたが、最終的な採用基準は「実測が改善するか」「運用コストが増えすぎないか」「必要な計測を壊さないか」の 3 点でした。AI を使うと試行の幅は広がりますが、最後に必要なのは実測と判断基準だとあらためて分かりました。

スコアだけを追うと最適化は行き過ぎます。今回はその線引きまで含めて整理できたので、Acecore サイトの改善はいったん「完了」と言える状態まで来ました。

まとめ

前回記事の続編として、今回は以下を仕上げました。

• PageSpeed Insights のモバイル / デスクトップ全項目 100 を確認
• Cloudflare Web Analytics を停止し、GA4 は残しつつ遅延ロード化
• 検索 UI と Pagefind をオンデマンド化し、初期ロード負荷を削減
• 残るネットワーク診断を読み解き、受け入れるべき残課題を明確化
• Search Console のパンくずエラーと一覧ページの索引方針を整理
• shared SVG Icon への統一で表示欠落を解消
• 効果の薄い追加最適化は見送り、止めどころを明確化

Acecore サイトは、少なくとも Lighthouse / PageSpeed Insights の観点では 最速級を狙えるところまで詰め切った と言ってよい状態になりました。一方で、スコアは目的ではなく結果です。今後もこの状態を壊さないよう、運用と改善の両方を継続していきます。