Lighthouseで4項目すべて100点を取った — 画像40枚・広告つきの記事ページで何が効いたのか、他サイトと同条件で測り直した

Chrome の採点で4項目すべてが100点になった

Chrome には Lighthouse という、開いているページを4つの観点で0〜100点に採点する機能が標準で入っています。開発者ツールのタブから実行するだけで、表示の速さ(Performance)、読み上げソフトや色のコントラストなどの使いやすさ(Accessibility)、Web としての作法(Best Practices)、検索エンジンから見た作り(SEO)を採点します。

このサイトの記事ページを測ったところ、4項目すべてが100点になりました。測ったのは、このブログの中でも画像を多めに使っているサーバーサイドGTMの記事です。ブラウザ拡張機能の影響を消すため、シークレットウィンドウで実行しています。

ただしこの数字は測り方で動きます。同じ記事をコマンドラインから測り直し、ついでに他サイトも同じ条件で測りました。

自分の手元で測り直した

スクリーンショットの100点は、開発者ツールから手で実行したものです。手動の1回きりでは信用しづらいので、同じ採点エンジンをコマンドラインから、画面を出さない Chrome で走らせました。使ったのは Lighthouse 12.8.2、実行場所は日本国内です。

PC 想定では Performance が100を再現しました。Best Practices は78まで落ちています。減点は広告と解析まわりの1項目だけです。後半に書きます。

PC 想定の内訳です。カッコ内はその数字が表すもの。

• ・最初に何かが映るまで 0.48秒(白い画面が終わるまでの時間)
• ・ファーストビューが出そろうまで 0.62秒(スクロールせずに見える範囲で一番大きい要素、この記事ではカバー画像が表示し終わるまで)
• ・操作を受け付けない時間の合計 0ミリ秒(表示直後にタップしても無反応になる時間)
• ・表示後のガタつき 0.000(あとから画像や広告が入って文字が下にずれる量。0が理想)

1記事だけの話ではない

ここまでの数字は特定の1記事のものです。いま読んでいるこの記事ページも、書き終えた時点で4項目すべて100点でした。

2本では偶然と区別がつきません。公開済みの739記事から無作為に7本を選び、同じ条件(PC 想定)で測りました。

Performance は7本中5本が100、残り2本が99。SEO は全部100。ファーストビューが出そろうまでの時間は0.55秒〜0.63秒の幅に収まり、操作を受け付けない時間は7本すべて0ミリ秒でした。記事ごとにチューニングした覚えはありません。

点数以外に、点数を作っている条件そのものも数えました。無作為に選んだ40記事の HTML を取得して調べた結果です。

CSS のサイズが記事の中身によらず 20 KB 前後に収まっているところが、この仕組みの効きどころです。本文が157 KB ある長い記事も、30 KB の短い記事も、そのページで実際に使う指定だけを集めるので同じくらいの大きさに落ち着きます。人が記事ごとに調整しているのではなく、公開時のビルドと CDN の設定でそうなります。

Accessibility が96で止まっている記事があるのも見えました。原因は本文に埋め込んでいるタイムライン部品の赤系の配色で、白背景に薄い赤(コントラスト2.63〜3.91)を使っている箇所です。この部品を持たない記事は100でした。ここは直せば全記事100になります。

ページの中身を数えたら、自分のサイトは全体の5%だった

この記事ページを開いたときブラウザが取りに行くデータを、送り主ごとに数え直しました。

ページ全体で 2.1 MB 流れているのに、私が書いたサイトが出しているのは 99 KB、全体の5%弱しかありません。残りは Web フォント(949 KB、51リクエスト)、広告関連(668 KB)、外部の CSS(126 KB)、それに計測用の仕組み(270 KB)です。

軽く作った結果ではありません。重いものを積んだまま、描画の邪魔にならない場所へ押しやってあります。サイト本体の99 KB の内訳です。

• ・HTML 30.7 KB(圧縮後)
• ・CSS 1本 18.6 KB
• ・JavaScript 2本で 4.5 KB(うち3.3 KB は表示後に実行する分)
• ・画像 32.6 KB(カバー画像が19.2 KB)
• ・その他(サイトアイコン、記事内で使う小さなデータ取得)12.8 KB

ファーストビューを占めるカバー画像は、横1200ピクセルのイラストで19.2 KBです。同じ絵を3形式で持っているので比べられます。

見た目は変わらずに JPEG の36%です。1枚で33 KB 違い、記事には40枚あります。

ページ側でやっていること

立ち上げのときから速さを前提に作っているので、「遅かった頃と比べてどれだけ良くなったか」の比較データは持っていません。いま入っている仕組みだけ書きます。

ページごとに、そのページで使う分だけの CSS と JS を作る

ブラウザは、HTML を読んでいる途中で CSS に出会うと、それを読み終わるまで画面を出しません。CSS の大きさは、そのまま「白い画面の長さ」になります。

このサイトは、記事を公開したタイミングでそのページの HTML を実際に組み立てて、そこに出てくる見た目の指定だけを集めた CSS を1本作るという作りにしました。サイト全部の見た目を1本にまとめた巨大な CSS を全ページに配るのではなく、ページごとに専用のものを持たせています。結果が18.6 KB です。JavaScript も同じように、そのページで使う分だけを2本にまとめています。

ファイル名には中身から計算した文字列が入っています(617-a4c6c032.css のような形)。中身が1文字でも変われば名前が変わるので、ブラウザに1年キャッシュさせて構いません。更新すれば名前が変わり、別ファイルとして取りに来ます。

HTML を最小化して配る

公開時に HTML から改行・余分な空白・不要な引用符・コメントを削っています。この記事ページの HTML は127,201バイトあり、その中に改行は39個しかありません。ほぼ1行の状態です。圧縮して転送すると30.7 KB になります。

コメントが消えるのは容量以外の意味もあります。テンプレートに書いた「ここは暫定対応」「本番では別の値」のようなメモが、そのまま読者のブラウザに届くことがなくなります。

画像は軽い形式を優先し、見えている分だけ読む

画像はすべて、ブラウザに「対応している形式を選ばせる」書き方にしています。新しくて軽い AVIF を第一候補、次に WebP、どちらも読めない環境には JPEG、という3段構えです。この記事ページの画像は全部で42枚、そのうち40枚がこの3段構えです。

42枚のうち38枚は「画面に入るまで取りに行かない」指定にしてあります。ページを開いた瞬間に必要なのは、最初に見えている数枚だけです。「画像が多い記事」なのに、最初に読み込む画像は合計32.6 KB で済んでいます。

最初から見えているカバー画像には遅延指定を付けていません。ここを遅延させると、ファーストビューが出そろうまでの時間がまるごと遅くなります。

重いもの(広告・計測・フォント)を描画の外に追い出す

このページの8割以上は外部から来ます。これらを普通に置くと、CSS と同じ理屈で画面が出るのを止めてしまいます。

• ・JavaScript は原則「HTML を読み終わってから実行」にする。読み込みの間ブラウザが止まらなくなります。
• ・Web フォントは画面を止めない読み方に変える。まず端末に元からあるフォントで文字を表示し、Web フォントが届いたら差し替えます。1 MB 近いフォントを読んでいますが、表示は待ちません。
• ・ページ下部にしか出ない情報(注目記事など)は、表示が終わってから取りに行く。最初の表示に要らないものを最初の表示に混ぜません。

差し替え方式には副作用があります。フォントが届いた瞬間に文字幅が変わり、レイアウトがガタつきやすくなります。実測したガタつきの指標は0.001(理想は0)でした。

42枚すべての画像タグに、縦と横のピクセル数を書いてあります(width=1200 height=675 のように)。ブラウザは画像が届く前から必要な場所を空けられるので、あとから画像が入っても下の文章が押し下げられません。片方だけだと、スクロールのたびに文章が飛び跳ねます。

採点の指摘をひとつずつ潰した

Lighthouse は減点理由を具体的に出すので、そのまま課題にしました。直したのは、Web フォントが表示を止めていた点、文字色と背景色のコントラストが基準(4.5:1)に足りていなかった点、見出しが h3 の次に h5 と飛んでいた点などです。Accessibility と SEO の100点は、この手の修正の積み上げです。

一番効果が高いのは CDN キャッシュ

記事ページは、世界中に置かれた配信用サーバー(CDN)にキャッシュしています。日本からアクセスすると東京のサーバーが応答するので、私のサーバーまで往復しません。ヘッダーを見ると、東京の拠点からキャッシュ済みの応答が返っています。

cache-control: public, s-maxage=31536000, max-age=0, stale-while-revalidate=60
x-cache: Hit from cloudfront
x-amz-cf-pop: NRT12-P8
content-encoding: gzip

この設定は「配信サーバーは1年持っていていい / ブラウザは毎回確認する」という意味です。記事本文はめったに変わらないので1年、順番が入れ替わる一覧ページは1時間、と保持期間を分けています。

1年キャッシュは素直に入れると事故ります。踏んだのは3つ。

公開前に踏まれた404が1年焼き付く

記事を公開する前の URL を誰かが踏むと、その「ページがありません」という応答が1年間キャッシュされます。あとから同じ URL で記事を公開しても、配信サーバーは1年前の「ありません」を配り続けます。原因に気づくまで、公開したはずの記事が読めません。エラー応答だけ保持期間を1分に分けて、放っておいても勝手に直るようにしました。

キャッシュ消去の無料枠を空振りで使い切る

記事を更新したらキャッシュを消す必要があります。当初は公開のたびに毎回消していました。この種の配信サーバーは「誰かが最初に見に来た瞬間に取りに行って覚える」方式なので、新規公開の時点ではまだ何もキャッシュされていません。存在しないものを消す操作を毎回投げていたわけです。

キャッシュ消去には月あたりの無料枠(1,000パス)があり、この空振りがそれを食い潰していました。いまは更新と非公開化のときだけ消すようにしています。新規公開では何もしません。一覧やトップの並び順が変わるのは、1時間の保持期間で自然に追いつきます。

管理者の自分だけが古いページを見てしまう

管理者としてログインした状態で自分の記事を確認すると、キャッシュ済みの古い内容が返ってきて、直したはずの箇所が直っていないように見えます。管理者にだけ専用の目印(Cookie)を配り、その目印が付いたアクセスは配信サーバーのキャッシュを素通りして毎回本体に届くようにしました。一般の読者には目印が付かないので、キャッシュは効いたままです。

「速い」と言われるサイトを、同じ条件で測った

100点がどのくらい珍しいのかを知るため、速さで評判のサイトや大手の技術系サイトを、まったく同じ道具・同じ条件(スマホ想定・日本から・1回ずつ)で測りました。それぞれ記事ページ1本です。

4項目すべてが90点以上だったのは、10サイト中1つ(astro.build)でした。Performance が高いサイトも、Accessibility が高いサイトも複数あります。4つを同時に高く保っているところはほとんどありません。速さ・使いやすさ・検索対策は別の作業で、どれかを頑張ってもほかは上がりません。このサイトも広告の Cookie で Best Practices が79なので、この基準には入っていません。

転送量と点数は相関しません。danluu.com は27 KB・5リクエストという極端に軽いサイトで99点ですが、SEO は73点です(検索エンジン向けの記述をほとんど持っていないため)。このサイトは2,142 KB 積んで94点でした。効くのは、最初の表示までに何を待たせるかです。

速さで有名な会社のサイトも、必ずしも速く出ません。表示速度を解説している Google の web.dev が43点、Vercel が58点でした。実装というより測り方の問題です。次に書きます。

番外: 阿部寛のホームページは Lighthouse で測れない

日本で「速いサイト」といえば、俳優の阿部寛さんの公式サイトが引き合いに出されます。「タップする前にもう開いている」と言われるほどで、速度の話題になるたびに名前が挙がります。同じ道具で測ってみました。

結果は測定不能でした。HTTP・HTTPS、スマホ想定・PC 想定の4通りすべてで、Lighthouse が NO_FCP(何も描画されなかった)を返して終わります。

理由は作りにあります。このサイトのトップページはフレームで組まれています。画面を左右に分割し、それぞれに別の HTML を読み込ませる、1990年代に使われていた方式です。トップページ自身の中身は538バイトの分割指定だけで、文字も画像も1つも持っていません。Lighthouse は「一番外側のページが何を描いたか」を見るので、何も描かないこのページには点を付けられません。

中身が入っているフレームを直接測ると、数字が出ます。

Performance は100です。転送量37 KB、リクエスト5本、操作を受け付けない時間0ミリ秒。速いという評判は正しいことになります。

残る3項目は高くありません。<html> に言語の指定がない、画像に代替テキストがない、説明文がない、拡大縮小の指定がない、文書型宣言がなくブラウザが旧式モードで描いている、といった指摘が並びます。速さと、使いやすさ・検索対策は別の作業だという話が、ここでもそのまま出ています。

速い理由も、この記事でやってきたこととは方向が逆です。単純に、送るものが少ない。トップ画像が26 KB の JPEG 1枚、あとは文字だけ。圧縮もしていませんし、通信も HTTP/1.1 のままです。それでも37 KB しかないので速い。こちらは2.1 MB 積んだ上で描画の外に追い出して速くしています。同じ「速い」でも中身が違います。

HTTPS 化は2025年10月に行われました。ただしサイト側が対応を迫られたのではなく、ホスティングを提供しているニフティが LaCoocan というサービス全体を HTTPS に対応させたためです。証明書を見ると *.la.coocan.jp のワイルドカード証明書で、サービス側が一括で用意したものだと分かります。サイトの HTML は何も変わっていません。

このとき遅くなったという話も出ましたが、手元の計測では再現しませんでした。暗号化の準備にかかる時間は実測で18ミリ秒ほど、スマホ想定では HTTPS のほうが速い回もありました。Best Practices は HTTPS のほうが16点高く出ます。暗号化していないこと自体が減点対象だからです。

LaCoocan は2026年7月以降 HTTPS に一本化すると告知していますが、この記事を書いた2026年8月2日時点では http:// でもそのまま表示されました。

この数字の弱いところ

比較は「日本から測った」ぶん、こちらが有利

すべて日本から測っています。このサイトは東京の配信サーバーから応答するので、応答が返り始めるまでがそもそも短いです。海外にサーバーがあるサイトは、その往復ぶん不利になります。web.dev や Vercel の点が低いのは、この地理的な差がかなり効いています。この表は日本から見たときの速さで、実装の優劣ではありません。

100点は毎回出るわけではない

同じページでも、測る機械・回線・そのときの外部サーバーの調子で点は動きます。手元のスマホ想定で同じ記事を3回測ったら、Performance は94・97・98とばらつき、100は一度も出ませんでした。ファーストビューが出そろうまでの時間も1.26秒〜2.23秒の間で動いています。

100点のスクリーンショットは撮れますが、常に100点ではありません。比較表の他サイトも各1回の計測なので、同じ幅のブレを含んでいます(Qiita だけは点が低かったので2回測り、51点と53点でほぼ同じでした)。

Best Practices の100点は、シークレットウィンドウの副作用

手元の計測では Best Practices が78まで落ちました。減点されている項目を開くと、ほぼ1項目だけです。広告と行動解析のツールが、他社ドメインの Cookie を使っている、という指摘でした。

シークレットウィンドウは、この種の Cookie を既定でブロックします。シークレットで測ると「Cookie を使っていない」ことになり、この減点が消えます。両者の差を説明できるのはこれだけですが、手元の自動計測でシークレット相当の状態を作れず、裏取りはできていません。どちらにせよ広告を載せている限り、普通のウィンドウで測ればここは減点されます。

検索順位や PV との関係は、このサイトでは検証できない

立ち上げの時点でこの構成にしてしまったので、「遅かった頃」のデータが存在しません。速くしたら順位が何位上がった、といった話はここには書けません。書けるのは「自分で読んでいて、他のサイトより露骨に快適」という体感と、上に並べた実測値だけです。

日本語フォントが1 MB 残っている

日本語 Web フォントが949 KB・51リクエストあります。ページ全体の44%で、単独では最大の項目です。

日本語フォントは文字数が多いので、細かく分割して「そのページに出てくる文字が入っている塊」だけを配る仕組みになっています。それでも51個も必要になったのは、記事の中に色々な漢字が出てくるからです。表示を止めない読み方にしてあるので体感は損なわれていませんが、通信量としては無駄が残っています。使う文字を絞り込んだフォントを自前で用意すれば減らせるはずですが、まだ手をつけていません。

スマホ想定では「操作を受け付けない時間」が277ミリ秒ありました。PC 想定では0です。中身は広告と解析のスクリプトです。これを削るには広告の載せ方そのものを見直す必要があり、収益との引き換えになります。

もう一度やるならこの順

上ほど、手間の割に効果が高いものです。

1. 1.配信サーバーにキャッシュさせる。応答が返り始めるまでの時間が縮み、全部の数字が底上げされます。設定だけで済むのに効果が一番大きい。
2. 2.画像を軽い形式にして、最初に見えないものは遅延させる。画像の多いページほど効きます。カバー画像だけは遅延させないこと。
3. 3.CSS を、そのページで使う分だけにする。白い画面の長さが直接縮みます。
4. 4.広告・解析・フォントを、描画を止めない置き方に変える。2 MB 積んでも100点が取れるかどうかは、ここで決まります。
5. 5.採点ツールの指摘を、面倒がらずに全部潰す。コントラストや見出しの順番といった地味な項目が、Accessibility と SEO の点をそのまま作ります。

重いものを載せたまま、最初の表示から追い出す。やったことはこれに尽きます。ページ全体の95%が外部から来ていて、それでもファーストビューは0.62秒で出そろいます。

計測条件と参考リンク

この記事の数字は、以下の条件で取得しました。

• ・採点ツール: Lighthouse 12.8.2(コマンドライン版)、画面を出さない Chrome
• ・スマホ想定は既定の設定(通信・CPU を遅くしたシミュレーション)、PC 想定は desktop プリセット
• ・実行場所は日本国内。各 URL につき1回ずつ。2026年8月2日時点
• ・冒頭のスクリーンショットのみ、Chrome 開発者ツールからシークレットウィンドウで実行したもの

CSS・JS をページ単位に切り出している仕組みは、自作のライブラリとして公開しています。CMS の公開操作をきっかけに、そのページの HTML から見た目の指定を集めて外部ファイル化するものです。

• ・wagtail-asset-publisher (PyPI) — 本文中の「ページごとの CSS/JS を公開時に作る」仕組み
• ・wagtail-asset-publisher (GitHub) — 実装とドキュメント
• ・Lighthouse 公式ドキュメント — 採点項目の定義
• ・Core Web Vitals — 本文で触れた「ファーストビューが出そろうまでの時間」などの指標の定義
• ・阿部寛のホームページ、“速度はそのまま”ついにHTTPS化 (ASCII.jp) — HTTPS化の時期と経緯
• ・阿部寛のホームページ (Wikipedia) — ホスティングの変遷とHTTPS一本化の予定
• ・サーバーサイドGTMをコスト効率よく導入 — 今回計測した記事