要点
- 自社の5ページを携帯向けの条件で測定した結果は、実利用者の記録ではなくラボの値だ（出典: 自社の実測・2026-10-16）
- 静的ブログの独自ドメインではLCPが1.0秒、WordPressのトップでは7.9秒だった（出典: 自社の実測・2026-10-16）
- 学習ツールのサイトでは、読み込み後に現れる文字の塊が下の内容を押し下げていた（出典: 自社の実測・2026-10-16）
- 実利用者の記録は取得できず、「存在しない」ではなく「確認できなかった」と判断した（出典: 自社の実測・2026-10-16）
ページを速くしたいとき、何を確かめるか
自社のサービスを作る中で、静的ブログ、学習ツールのサイト、WordPressで構成したサイトを対象に、ページの性能を測った。確認したかったのは、ページごとの点数に加えて、表示が遅いのか、表示後に内容がずれるのかという違いだ。同じ測り方で数値を並べ、どの指標に問題が表れているかを見た。
Core Web Vitalsについては、最初に測定の区別を置く必要がある。今回の記録では、実利用者の記録である「フィールド」と、手元で行う「ラボ」を分けている。検索での評価に使われるのは実利用者の記録であり、今回取得できたのはラボの値だった。
ラボの値とは、手元で行った1回の測定によって得られた値のことだ。
したがって、この記事の数値を、そのまま実際の利用者が経験した速さとして扱うことはできない。測定結果を比較する前に、何を測れていて、何を確認できていないかを明らかにした。
公開APIで取得できず、手元のLighthouseで測った
最初に試したのは、PageSpeed InsightsのAPIを鍵なしで呼び出す方法だった。しかし、返ってきたのはHTTP 429で、クエリ数の日次上限を超えたことを示す応答だった。
今回上限に当たったのは、自分たちの利用枠ではなく、Google側の匿名利用者用の枠だった。鍵なしの枠は世界中の匿名利用者と共有されており、いつ利用できるかは分からない。そのため、この方法は実務で継続して測る手段として当てにできないと判断した。
この時点で、実利用者の記録は取得できていない。ただし、取得できなかったことと、記録が存在しないことは違う。今回確認できたのはAPIから取得できなかったという結果までであり、「自社サイトには実利用者の記録がない」とは判断していない。
そこで、手元のLighthouse 12.8.2を使い、Chromeをヘッドレスで動かして測定した。新しい課金リソースは作っていない。測定は既定の携帯向けの形態で、通信を遅く見せる計算であるsimulateが入る条件だった。
測り方を切り替えて数値は得られたが、それによってフィールドの記録まで取得できたわけではない。以降の比較も、同じ条件で行った1回のラボ測定として読む必要がある。
出典: 自社の実測（2026-10-16）
同じ条件で測った5ページの結果
携帯向けの条件で測った結果を、そのまま示す。性能の点数だけでなく、LCP、FCP、CLS、TBTを並べた。
| ページ | 性能 | アクセシビリティ | SEO | LCP | FCP | CLS | TBT |
|---|---|---|---|---|---|---|---|
| 静的ブログ（既定ドメイン） | 100 | 100 | 100 | 0.8s | 0.8s | 0 | 40ms |
| 静的ブログ（独自ドメイン） | 100 | 100 | 100 | 1.0s | 1.0s | 0 | 70ms |
| 学習ツールのサイト | 84 | 95 | 100 | 2.4s | 2.4s | 0.216 | 60ms |
| 会社サイトのトップ（WordPress） | 59 | 100 | 100 | 7.9s | 7.4s | 0 | 0ms |
| 会社サイトのブログ一覧（WordPress） | 64 | 91 | 100 | 9.0s | 3.5s | 0.006 | 130ms |
静的ブログの独自ドメインではLCPが1.0秒だったのに対し、WordPressのトップでは7.9秒だった。同じ運営主体のページを同じ測り方で比べても、表示までの時間には差があった。
ただし、ここから「WordPressは遅い」と一般化することはできない。今回測ったWordPressは、自社で使っている1テーマ・1構成に限られる。この比較が示しているのは、測定対象となったページと構成の結果であり、製品全体の性能ではない。
また、表のSEOの点数は全ページで100だったが、これは取得できなかった実利用者の記録を補うものではない。表にある測定値と、確認できていない項目は分けたまま扱う。
出典: 自社の実測（2026-10-16）
総合点から、直す対象を決めつけない
WordPressのトップは性能が59だった一方、CLSは0、TBTも0msだった。表示が遅いページであっても、すべての指標が悪くなるわけではなかった。
今回のトップについては、「重いJavaScriptで画面がガタガタする」という読み方ではなく、表示が出てくるのが遅いという問題として捉えた。総合点だけを見ていたら、こうした違いは分からない。低い点数を見つけることと、何を直すかを判断することは、別の作業になる。
一方、CLSが目安の0.1を超えたのは学習ツールのサイトだった。LCPは2.4秒で、今回の比較では中間に位置するページだが、CLSは0.216だった。記録では、読み込み後に現れる文字の塊が下の内容を押し下げており、ずれは0.1685と0.0476の2回確認された。
つまり、表示までの時間が最も長いページと、表示内容のずれを確認したページは一致していない。LCP、FCP、CLS、TBTは別々のことを測っているため、性能の総合点だけでは、改善対象を絞れないという判断になった。
今回の記録から示せるのは、ここまでの測定結果と判断だ。修正後の数値は記録されていないため、改善できたとは書けない。表示の遅さと内容のずれを分け、次に確認する対象を具体的にしたことが、今回の測定で得られた成果だった。
出典: 自社の実測（2026-10-16）
業務に置き換えると
業務で使うサイトについて「速くしたい」と相談するときも、今回の記録から点検できる項目はある。まず測定の種類をそろえ、そのうえで指標ごとの結果を確認すると、何が分かっていて、何が未確認なのかを共有しやすい。
- どの指標に問題があるかを分ける。 総合点だけで判断せず、LCP・CLS・TBTを確認する。表示の遅さと表示後のずれを、同じ問題として扱わない。
- ラボの値と実利用者の記録を区別する。 手元で得た数値には測定条件を添え、「ユーザー体験の実測」と呼ばない。
- 定期的に使える計測手段かを確かめる。 今回の鍵なしAPIは共有枠の上限で使えなかった。継続して測る手段としては、手元の道具を使う判断につながった。
- 取得できなかった項目を明示する。 確認できていない記録を「ない」と報告せず、測れた範囲と未確認の範囲を分けて伝える。
今回、測定方法を切り替えることでページ間の違いは確認できた。一方で、実利用者の記録は未確認のままだ。業務の報告でも、この両方を残すことが、測定結果を超えた結論を出さないための確認項目になる。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。