ページ速度の週次チェック

先に結論を書きます。PageSpeed Insights の指摘を消しても、このサイトは速くなりませんでした。 速くならなかった原因は、指摘の一覧の上のほうには出ていない、1ページで30個を超える日本語フォントのファイルでした。

このことに気づけたのは、ページの速さを毎週、同じ条件で測って、記録に残すワークフローを作ったからです。1回だけ測っていたら、数字が回ごとに大きく振れることにも、その振れが何から来ているのかにも、気づけませんでした。

この記事は、PageSpeed Insights や LCP を、ふだんから仕事で見ている人に向けて書いています。

	直す前（2026-10-16）	4回直したあと（2026-10-17）
Performance スコア（mobile）	59〜70	92〜99
LCP	6.2〜7.1秒	1.7〜2.7秒
CLS	0〜0.07	0

測ったのは、このサイトの4ページ（トップ、記事、運営者、料金の記事）です。条件は、PageSpeed Insights API v5、strategy=mobile、category=performance、Lighthouse 13.5.0 です。ラボの値だけで、フィールドデータ（CrUX）はまだありません。PageSpeed 側の端末と回線の想定（スロットリングの設定）の中身は、確かめていません。

weekly-pagespeed-check.json をダウンロード

n8n 公式のテンプレートには、まだ出していません（審査中の枠が空いたら出す予定です）。出したら、結果をこの記事に書きます。

このワークフローがすること

1. 毎週月曜の8時（か Run now）に、設定に書いたページを、1ページずつ PageSpeed Insights で測る（1ページで10〜60秒かかる）
2. コードが、スコア、LCP、CLS、TBT を、決めた基準（初期値はスコア90以上、LCP 2.5秒以下、CLS 0.1以下、TBT 200ミリ秒以下）と比べて、印を付ける。スプレッドシートの記録と比べて、前回からの変化も出す
3. 記録をスプレッドシートに残す。 AI を呼ぶ前に保存するので、AI の呼び出しが失敗しても、数字は消えない
4. 基準を下回ったページだけ、Claude（Haiku 4.5）が、不合格だった項目の直し方を書く（1ページ3つまで）
5. コードが、直し方を確かめる。 不合格だった項目を引用しているか。数字は、引用した測定値にあるか。設定に書いていないサイトの作り（WordPress など）を決めつけていないか。通らなかったものは、⚠ と理由を付けて残す
6. Slack に1通送る。コードが出した数字を先に、確かめた直し方をあとに並べる

どのページが基準を下回ったかを決めるのは、コードです。Claude は、ページの良し悪しを判定しません。

自分のサイトを4回直した記録

ワークフローができてすぐ、このサイトを測りました。4ページとも、スマホのスコアは59〜70、LCP は6.2〜7.1秒でした。PageSpeed が挙げた一番大きな項目は、render-blocking requests（見積もりで3〜7.4秒の短縮）でした。

	何をしたか	結果
1回目	Google Fonts の CSS（約349KB、@font-face が386個）を、rel="preload" から onload で stylesheet に切り替える読み込み方に変えた（noscript で従来の読み込みも残した）	render-blocking の指摘は消えた。LCP は変わらなかった（6.2〜7.1秒）
2回目	トップの LCP 要素が、一覧の先頭の loading="lazy" のサムネイルだったので、先頭の1枚だけ loading="eager" と fetchpriority="high" にした	16回中7回が、2.0〜3.9秒になった。残りの9回は、直す前とほぼ同じ値（6.2〜7.1秒）のまま
3回目	日本語の Web フォント（Noto Sans JP）をやめ、端末の日本語フォントにした（英数字の Inter だけ残した）	12回とも、スコア93・LCP 2.6秒・CLS 0。 振れが消えた
4回目	サイトの CSS（約30KB）を、各ページの HTML に埋め込んだ（Astro の build.inlineStylesheets: 'always'。HTML は gzip で約20KB）	12回中5回が、スコア99・LCP 1.7秒。残りの7回は、スコア92〜96・LCP 2.6〜2.7秒

1回目で分かったのは、指摘が消えることと、速くなることは別だということです。2回目のあとに network-requests を見ると、記事のページでは、Noto Sans JP の woff2 を38個（約880KB）読んでいました（unicode-range で分割されたサブセット）。どれも priority が VeryHigh で、LCP の画像や本文と帯域を取り合います。

日本語の Web フォントをやめると、日本語の字形が端末ごとになります（Mac はヒラギノ、Windows は Meiryo、Android は Noto Sans CJK）。最初は、Windows で「Yu Gothic UI」が選ばれて、仮名が詰まって本文が窮屈に見えました。そこで Meiryo を先にしました。

測るたびに、数字が2つに分かれた

1回目の修正のあとから、同じページを数分おきに測ると、ほとんどの回が「2.0秒・97〜99点」か「6〜7秒・58〜76点」のどちらかになりました。2回目の修正のあとの16回のうち、その間に入ったのは1回（3.9秒）だけです。記事のページは、ある回は58点・7.1秒、その2分ほど後は98点・2.0秒でした。

もし1回だけ測って「98点になった、直った」と書いていたら、間違いでした。毎週同じ条件で測って記録を残すのは、この振れを見えるようにするためです。

作っている途中で見つけた落とし穴

キーなしでは、実際には使えない

公式の説明には、「キーなしでも使えるが、自動で何度も呼ぶならキーを推奨」とあります（PageSpeed Insights API の始め方）。実際にキーなしで呼ぶと、1回目からエラー（429、1日の上限超え）でした。キーなしの呼び出しは、使う人全員で1日の枠を分け合っているためです。Google Cloud で PageSpeed Insights API を有効にして、API キーを作ってください。n8n には、「Query Auth」の認証情報（名前は key）で入れます。

続けて測っても、新しく測ってはくれない

同じページを数秒のうちに3回呼ぶと、3回とも同じ結果（測った時刻まで同じ）が返りました。1分ほどあけると、新しく測り直しました。「3回測って平均する」なら、間をあける必要があります。

404 のページにも、点数が付く

わざと存在しないページを入れて測ると、73点が付きました。エラーにはなりません。404 だと分かるのは、PageSpeed の結果の中の「実行時の警告」と、通信の記録にある応答コードだけです。そこで、応答コードが 400 以上なら「測れなかったページ」として扱い、Slack にそう書くようにしました。消えたページや移動したページを、速いページと取り違えないためです。

Claude が、サイトの作りを決めつけた

1回目の実行で、Claude は、このサイト（Astro で作っています）に「WordPress のテーマとプラグインを見直してください」と書きました。数字は合っていたので、数字の確かめでは止まりませんでした。

そこで、設定に site_notes（サイトの作り。例：「Astro static site hosted on Vercel」）を足し、そこに書いていない CMS や、サービスの名前が出たら、印を付けるようにしました。2回目の実行では、Astro と Google Fonts しか出てきませんでした。

速いサイトでは、1秒の振れを「悪化」と判定した

前回より LCP が1秒以上遅くなったら「悪化」と判定する設定（初期値）にしています。4回目の修正のあとは、1.7秒と2.7秒の間を行き来したので、測定の振れを悪化と判定しました。 数字が安定していないうちは、悪化の基準を広げるか、何週か続けて見てください。

使うための設定

1. PageSpeed Insights のキー： Google Cloud で PageSpeed Insights API を有効にし、API キーを作る（使える API を PageSpeed Insights だけに制限しておくと安全）。n8n で「Query Auth」の認証情報を作り、名前を key、値をキーにする
2. スプレッドシート： 空のシートを作り、ID を Spreadsheet ID に貼って、Run once を1回実行する（PageSpeed のタブができる）。2つの Google スプレッドシートのノードで、そのシートを選ぶ
3. 認証情報： Google スプレッドシート、Anthropic、Slack（Slack のアプリを、送るチャンネルに入れておく）
4. Config： 測るページ（1行に1つ、https:// から）、mobile と desktop のどちらで測るか、基準、site_notes、言語を決める
5. Run now で一度動かし、Slack とスプレッドシートを見てから、公開する

手元のパソコンの n8n で動かす場合は、月曜の8時に n8n が起動していないと、その週は動きません。私は、作業を始めるときに、前回から7日以上たっていたら手で実行しています。

確かめたこと

• 本物の PageSpeed Insights API と Claude Haiku 4.5 で、このサイトの4ページを、2026年10月16日〜17日に、合わせて60回あまり呼んだ（数秒以内に同じページを呼んで、前の結果が返った分を含む。上の表の数字）
• 404 のページは、1回目は73点が付き、直したあとは「測れなかった」と報告された
• コードの単体テストを23通り（測定値と直し方の項目の分け方、見積もりの大きい順、KiB、エラーの応答、点数の付いた 404、転送、基準、前回との比較、でっち上げたスコア、不合格の項目を引用していない直し方、存在しない項目、間違ったサービス名、「database」をサービス名と間違えないこと、読めない出力、Slack の文面）

確認していないこと

• 実際の利用者のデータ（フィールドデータ）。 このサイトは、まだ PageSpeed に実際の利用者のデータがありません。ワークフローは、データがあれば表示する作りですが、動いたところは見ていません
• 4回の修正の、それぞれの効果を切り分けた比較。2回目と3回目は、順に重ねて測ったので、3回目だけの効果は測っていません
• Mac、iPhone、Android での見た目（Windows の Chrome でだけ確かめました）
• desktop での計測

次に読む

• 自動化そのものの、認証の期限切れや実行回数を毎週調べるなら 自動化の診断書
• HTTP Request ノードの使い方は n8n HTTP Request ノードの使い方
• 毎週動かす設定は n8n Schedule Trigger の使い方
• AI の答えを、コードで確かめる考え方は 引用つきの議事録
• テンプレートを n8n 公式に出した記録は n8n テンプレート投稿と審査