- 公開日:
表示速度ボトルネックの「実例研究」ブログを始めました
- Authors
- Name
- 代表取締役 宮永
実際のサイトを題材に、フロントエンドの本当のボトルネックを掘り下げるリサーチブログを始めました。
なぜこのブログを始めたのか
ページスピードの改善やCore Web Vitalsの向上を目指して、PageSpeed Insightsのアドバイスに従ってサイト改善を図るケースは非常に多く見かけます。しかし残念ながら、このアプローチで目立った成果を得られることはほとんどありません。
もちろんPageSpeed Insightsのアドバイスが無意味なわけではないのですが、本当に大きなボトルネックを放置したまま小さなテクニックを積み重ねても、焼け石に水になってしまいます。
では、その大きなボトルネックとは何か。商用サイトの場合、実はサードパーティータグの使い方が本質的なボトルネックになっていることがほとんどです。
このブログでは、実在するサイトを題材に、個別のボトルネックをパフォーマンスタイムラインで確かめ、それらを解消したらどこまで速くなるかをシミュレーションで検証し、その結果を共有していきます。
PageSpeed Insightsには、サイトスピードに対する意識を社会全体で押し上げた大きな功績があると思います。一方で、「頑張って改善してみたけれど成果が見えない」「何が効いているのかよく分からない」という声もよく耳にします。せっかくサイトスピード改善に意欲を持ってくれたサイト運営者や開発者の努力が、一般論の積み重ねで徒労に終わってしまうのはもったいない話です。
次に私たちができることは、リアルなサイトでの「本当のボトルネック」の事例を数多く共有することだと考えています。Web全体のサイトスピード改善の取り組みが、もっと有意義で成果の出るものになってほしい。そんな思いでこのブログを始めました。
サイボウズ式トップページでの検証
具体例がないとイメージが湧きにくいので、1本ご紹介します。
検証記事: 「サイボウズ式」トップページの表示速度ボトルネック研究
本事例について（重要） 本研究は、サイボウズ株式会社様からのご依頼に基づくものではなく、当社が自主的に研究目的で調査・検証し、公表しているものです。検証は外部から観測可能な情報のみを対象としており、運営側の内部事情は考慮していません。掲載の取り下げ希望はお問い合わせフォームからご連絡いただければ、異議なく対応します。
動画で見るBefore／After
次の動画を再生してみてください。左がスピード改善前、右がボトルネック解消後のシミュレーションです。
読み込みから約1秒後
右のページスピード改善後は、読み込みから約1秒後にはファーストビューの表示がほぼ完了しており、ページのかなりの部分が描画されています。一方、改善前はまだほとんどが真っ白、プレースホルダーの灰色ブロックが並んでいるだけの状態です。
読み込みから約3.64秒後
読み込み開始から3.64秒後、右のページスピード改善後はこの時点で読み込みが完了します。改善前はまだLCP画像をはじめ、いくつかの画像が表示されていない状態です。
このようにボトルネックを解消して読み込みプロセスをシミュレーションしてみると、体感的にも1テンポ、2テンポ早い表示完了が確認できます。
Lighthouseスコアは72 → 100
このように体感スピードが速くなったとともに、Lighthouseのスコアにも改善が見られ、パフォーマンスの総合スコアは72点から100点に到達しています。
Before
After
| 指標 | 観測時点 | シミュレーション後 | 変化量 |
|---|---|---|---|
| 総合スコア | 72 | 100 | +28 |
| LCP | 6.3秒 | 0.1秒 | -6.2秒 |
| FCP | 2.5秒 | 0.1秒 | -2.4秒 |
| Speed Index | 4.3秒 | 0.5秒 | -3.8秒 |
このことから分かるのは、サイト自体の作りは非常に速いということです。そのうえで、サードパーティータグ、外部ドメインのパブリックCDNの利用、そして日本語Webフォントが足を引っ張ることで、総合スコアが72点まで低下していたということが読み取れます。
ではどのように改善するか
サードパーティータグの棚卸しと遅延読み込み
サードパーティータグはビジネス要件に紐づいているものが多く、単純に全部取り外すというわけにはいきません。ただ、多くのサイトを観察していると、古いサードパーティータグが放置されていたり、実際には積極的に活用されていないタグが保険的に残されていたり、というケースが非常に多く見受けられます。まずは徹底的に棚卸しを行い、本当に必要なサードパーティータグだけに絞り込むのが第一歩です。
もうひとつ有効なのが、サードパーティータグの読み込みタイミングを大きく遅延させることです。サードパーティータグは基本的にエンドユーザーのために用意されているものではなく、サイト運営者の都合で入っているものです。したがって、できる限り後回しにしてもユーザー体験への実害は少なく、その分エンドユーザーが必要とするリソースの配信を優先できます。このメリハリをつけることが、ユーザー体験の向上には非常に重要です。
外部ドメインのパブリックCDN
jsDelivrのようなパブリックCDNからJavaScriptを読み込んでいるサイトも多く見られます。もちろんトラフィック分散の観点では有用な面がありますが、サイトスピードという観点で見るとデメリットが上回ることが多いです。
HTMLのドメインと異なるドメインからCSSやJavaScriptを配信すると、ブラウザ側でDNSルックアップやSSLハンドシェイクといった処理が事前に挟まります。一回一回の処理自体は非常に高速なのですが、人間の「待たされている」という感覚もまた非常に高感度です。ここで消費される0.数秒の時間が、離脱率に影響を与えている可能性は十分にあります。
日本語Webフォント
日本語Webフォントは見た目の安心感を得やすい一方で、ユーザー体験としてはむしろ低下につながることが多い要素です。日本語は文字数が多いという言語的な宿命から、Webフォントのファイルサイズが英語と比べて桁違いに大きくなってしまいます。見た目を安定させるメリットはあるものの、体感スピードの面では基本的にデメリットしかない、というのが実情です。
読み物系のサイトであれば、システムフォントで提供することに割り切る、あるいは日本語Webフォントの使用を避ける、ないし最小限にとどめるという判断が現実的です。この割り切りができると、スピード改善のインパクトは非常に大きくなります。
機能追加は「スピードとの天秤」で判断する
結局のところ、機能やタグ、フォントはどれも「追加するとスピードを引き換えに差し出す」という宿命を持っています。どれを外すかどうか、ひとつの正解があるわけではありません。
重要なのは、何かを追加するときに、得られるメリットと失うスピード体験を必ず天秤にかけて判断するという姿勢です。この天秤を意識するかしないかで、同じサイトのユーザー体験が大きく変わります。
検証の仕組み
「実装せずに改善効果を数値で出す」のがこのブログの肝です。3ステップで進めます。
1. 表示プロセスをまるごと録画
HTTPプロキシを録画モードで動かしてページを開くと、通信内容とタイミングが丸ごと保存されます。
2. 同じプロセスを忠実にプレイバック
再生モードに切り替えると、実サーバーに触れずに同じ表示プロセスを何度でも再現できます。
3. 解消仮説を当ててシミュレーション
録画データに「このタグを外したら」「このCSSをまとめたら」といった解消仮説を当ててLighthouseで計測します。サイトを改修せずに、改修後のスコアが読める仕組みです。
効果の大きかった仮説が、そのページにとっての本当のボトルネックです。
特許技術とオープンソース
このシミュレーション手法は、以下の特許に基づいています。
- 日本国特許 第7120694号「ページ表示速度改善処理システム」（2022年8月8日登録）
- 米国特許 US Patent 12,346,648 B2「Page Display Speed Improvement Processing System」（2025年7月1日登録）
基盤のフレームワークは 「PageSpeed Quest」 としてオープンソースで公開しており、同じ検証を誰でも再現できます。
https://github.com/ideamans/pagespeed-quest
掲載ジャンルと今後
現在は次の2ジャンルを中心に進めています。
- EC（通販サイト・ECサイト）
- メディア（ニュースサイト・オウンドメディア）
今後、以下のジャンルも追加を検討しています。
- コーポレート（企業のコーポレートサイト）
- LP（ランディングページ・キャンペーンサイト）
掲載事例はすべて自主的な研究目的で調査・検証したもので、対象サイト運営企業からのご依頼に基づくものではありません。取り下げ希望があれば、異議なく対応します。
表示速度ボトルネックの実例研究 - https://vigilante.sitespeed.info/
自社サイトで同じように本丸を特定したい方には、弊社 「ページスピード改善リハーサル」 をご検討ください。同じ手法でサイト固有のボトルネックを特定し、実装前に改善効果を数値と動画で証明してから進める提案型サービスです。十分な改善が見込めない場合は料金をいただきません。