第12回 Lighthouseでゆまラボを測定する―Performance・Accessibility・Best Practices・SEOを実測する

第11回では、Search Consoleのインデックス未登録を調査し、正常な除外と修正が必要なURLを切り分けた。ページネーションのcanonicalと記事内の架空URLを直し、公開後の再クロール依頼まで進めている。

検索側の確認が一段落したので、今度は公開中のゆまラボ自体をLighthouseで測ってみる。

対象はTOPページ。Mobile条件でPerformance、Accessibility、Best Practices、SEOの4カテゴリを実行した。

結果はPerformance 91、Accessibility 96、Best Practices 100、SEO 100。数字だけなら大きな問題は見えないが、Performanceを開くとLCP、TOP画像、CSS、アクセス解析用JavaScriptなど、まだ具体的な改善候補が残っていた。

この回では修正まで広げず、2026年9月17日時点の現在値を記録する。

LighthouseをMobile条件で実行する#

Chrome DevToolsでLighthouseを開き、https://bringain.com/を対象にした。

Mode
Navigation (default)

Device
Mobile

Categories
Performance
Accessibility
Best Practices
SEO

Agentic browsingは選択していない。

Chromeの公式ドキュメントでは、Navigationは新しいページ読み込みに対して監査するモードとして説明されている。DevTools版ではDeviceとカテゴリを選べるため、今回はMobileだけに固定した。

Desktopは測定していない。LighthouseはMobileとDesktopでPerformanceのスコア条件も異なるので、この91点をDesktop側の結果として扱わない。

また、Lighthouseは端末負荷、拡張機能、ネットワークなど実行環境の影響を受ける。ここで残すのは、この条件で測った1回分の実測値になる。

4カテゴリは91・96・100・100#

測定結果の上部には4カテゴリのスコアが並んだ。

カテゴリ	スコア
Performance	91
Accessibility	96
Best Practices	100
SEO	100

Performanceは91で緑。Lighthouseでは90～100が緑の範囲になる。

Best PracticesとSEOは100。Accessibilityは96だった。ただし、今回保存したキャプチャにはAccessibility側の減点項目を開いた画面がないため、残り4点の原因は推測して書かない。

4つのスコアを並べると、Best PracticesとSEOは100まで到達している。

ただし、LighthouseのSEO 100は検索順位を意味しない。そのページでLighthouseが確認するSEO監査項目を通過した結果として扱う。

Performance 91の中身を見る#

PerformanceのMetricsには5項目が表示された。

指標	実測値	画面上の判定
First Contentful Paint	2.0 s	オレンジ
Largest Contentful Paint	3.2 s	オレンジ
Total Blocking Time	20 ms	緑
Cumulative Layout Shift	0	緑
Speed Index	2.0 s	緑

引っかかったのはFCPとLCP。

特にLCPは3.2秒。ChromeのLighthouseドキュメントではMobileのLCPは2.5秒までが緑、2.5～4秒がオレンジ、4秒超が赤とされている。今回の値はそのままオレンジ帯に入る。

一方でTBTは20ms、CLSは0。今回の計測では、大きなブロッキングやレイアウト移動は目立っていない。

Performance全体は91まで出ている。それでもLCPを見ると改善余地があるため、Lighthouseが表示した指摘を確認した。

CloudflareのビーコンとTOP画像が指摘された#

最初に出たのはUse efficient cache lifetimes。

対象はCloudflareのstatic.cloudflareinsights.comから読み込まれるbeacon.min.js。

Cache TTL     1d
Transfer Size 10 KiB
Est Savings   4 KiB

これはゆまラボの自作JavaScriptではなく、Cloudflare側から配信されるビーコンになる。第3回ではCloudflare Web Analyticsを確認し、そのままアクセス解析として残している。

公式のPerformance Insightsでも、長いキャッシュ期間は再訪問時のネットワーク取得を減らせると説明されている。ただ、今回の対象は外部配信リソース。4 KiBという表示だけを見て、ゆまラボ側の設定で変更できるとは決めない。

同じ画面ではImprove image deliveryも出た。

Resource Size 36.7 KiB
Est Savings   31.0 KiB
実画像         960 x 549
表示サイズ     380 x 217

対象はTOPのヒーローに使っているWebP画像。形式はすでにWebPだが、Mobileで380×217として表示する場面に960×549の画像を取得しているため、表示サイズに対して大きいと判定された。

ここは少し意外だった。

旧連載の第27回では記事本文の画像をAstroの画像処理へ移し、WebP・srcset・sizes・遅延読み込みを追加している。今回指摘されたのは本文画像ではなくTOPのヒーロー側だった。

以前の画像最適化とは対象が別になる。

Lighthouseの公式説明でも、画面上の表示より大きすぎる画像は余分な転送量につながり、レスポンシブ画像で端末に合うサイズを配信する方法が案内されている。

31 KiBは今回の指摘の中でも分かりやすい。実際に直す回では、ヒーロー画像にsrcsetとsizesがどう付いているかを確認してから変更したい。

CSSはRender-blockingとして推定310ms#

別の指摘としてRender-blocking requestsも表示された。

Lighthouseが示した推定削減時間は310ms。

対象には、ゆまラボのCSSとPagefindのCSSが並んでいる。

/_astro/index....css
/_astro/SiteLayout....css
/pagefind/pagefind-component-ui.css
/_astro/TaxonomyBrowse....css

転送サイズの合計表示は15.0 KiB。極端に大きいファイルではないが、初期描画の経路上にあるためRender-blockingとして拾われている。

Chromeの公式説明では、最初の表示に不要なリクエストを遅延させる、必要な小さいCSSをインライン化する、初期表示に必要な内容へ絞る、といった方法が示されている。一方で、CSSのインライン化は実装によって不具合につながることもある。

310msだけを見て即変更するのはやめた。まず、どのCSSがファーストビューに必要なのかを確認する必要がある。

同じキャプチャにはLegacy JavaScriptもあり、推定削減量は10 KiB。対象は先ほどと同じCloudflareのbeacon.min.jsだった。

ここもAstro側の自作コードではない。第三者スクリプトを含め、ページで読み込んだものが同じレポートへ並ぶことが分かった。

Googleタグは74.3 KiBの未使用JavaScript#

最後に確認したのがReduce unused JavaScript。

対象はwww.googletagmanager.comから取得しているgtag/js。

Transfer Size 171.4 KiB
Est Savings   74.3 KiB

第4回でGA4をゆまラボへ導入し、GoogleタグをAstroへ追加した。現在はこのデータを使って記事別PVを取得し、TOPの人気記事表示まで動かしている。

その一方、Lighthouseでは初期ロード時に使われないJavaScriptが74.3 KiBあるという結果になった。

アクセス解析を外せば終わり、とはしない。GA4は今の運用で使っているため、機能を残したまま読み込み方法を変えられるのか、変更して計測漏れが起きないかを確認する必要がある。

サイトへ機能を足すと、ページ側のコストも増える。その差が数字で見えた。

今回は修正せず、現在値を残す#

Lighthouseを実行した結果、4カテゴリはこうなった。

Performance      91
Accessibility    96
Best Practices  100
SEO             100

Performance側では、FCP 2.0秒、LCP 3.2秒、TBT 20ms、CLS 0、Speed Index 2.0秒を確認できた。

改善候補として目立ったのは、TOP画像の推定31.0 KiB、Render-blocking CSSの推定310ms、Googleタグの未使用JavaScript 74.3 KiB。Cloudflareのビーコンもキャッシュ期間とLegacy JavaScriptで指摘されている。

ここで全部修正すると、Lighthouseを測る回なのかパフォーマンス改修の回なのか分からなくなる。今回は計測だけで終了する。

次に触るなら、まずTOPのヒーロー画像とCSSが候補になる。Googleタグは削減量が大きいものの、アクセス解析を壊さずに扱えるかを先に確認したい。

見た目だけでは気付かなかった「どこに転送量や待ち時間が残っているか」を、実際の公開ページから拾えた。2026年9月17日時点の基準値として、今回の結果を残しておく。

参考#

• Chrome for Developers - Lighthouse: Optimize your website
• Chrome for Developers - Lighthouse performance scoring
• Chrome for Developers - Largest Contentful Paint
• Chrome for Developers - Improve image delivery
• Chrome for Developers - Use efficient cache lifetimes
• Chrome for Developers - Render-blocking requests