「ウェビック」トップページの表示速度ボトルネック研究

バイク用品・バイクパーツの通販サイトです。カスタムパーツや純正部品など300万点以上を扱い、中古パーツや新車・中古車探し、ツーリングなどのバイクライフ情報まで、ライダー向けの情報をまとめて提供しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

Core Web Vitalsにつながる指標の改善ポテンシャル ​

観測されたボトルネックを仮に解消した場合、Lighthouse の指標は以下のような変化を示しました。

観測時点	解消シミュレーション後

このサイトは、観測時点で 総合スコア が既に100に達していました。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）、SI（Speed Index = ビューの視覚的な表示進捗の速さ）にはシミュレーション上の大きな変化が見られるものの、スコアの上では差が表れません。

本研究の Lighthouse は、回線の往復遅延を0、帯域を無制限とみなし、CPUの速度低下も行わない条件で計測しています。そのため TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点から0msで、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）も0でした。また、この条件では個々のリクエストの応答待ち時間がシミュレーション値にほとんど反映されず、解消シミュレーション後の LCP 0.1秒は、HTMLのサーバー応答時間（約0.33秒）すら下回る値になっています。そこで本研究では、同じ環境のページをブラウザで5回読み込み、実際に描画された時刻の中央値（以下、実測値）もあわせて観測しました。

実測の FCP・LCP はいずれも約1.4秒から約0.4秒へ、読み込み完了は3.3秒から0.4秒へと短縮する結果が得られました。スコアが100であっても、実際の表示までの時間には大きなボトルネックが潜んでいたことを、このサイトの研究結果は示しています。

読み込みプロセスの変化を動画で体験 ​

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画はページ全体をスクロールしながら記録しているため、スクロール位置で遅延読み込みされる画像も含まれます。

サードパーティータグの影響 ​

詳細レポート

本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的でないものの、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。

本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。

オリジナルページの全225リソースのうち、サイト固有のリソースは128件（約57%）、サードパーティタグ由来のリソースは97件（約43%）でした。

HTMLから直接読み込まれているタグ ​

Google Tag Manager経由で読み込まれているタグ ​

除去シミュレーションの結果 ​

段階的に除去した際の指標変化は次のとおりです。

シミュレーション値は全体としては下がったものの、途中で上がる段階もありました。除去後の状態では同じページでも LCP が0.7〜1.3秒とばらついており、個々のタグの効果量は計測の揺らぎと区別しにくい結果でした。一方、実測値と転送量にははっきりとした変化が表れています。

サードパーティータグを全て除去した状態では、総合スコア は100のまま、読み込み完了は3.3秒から1.4秒へ、スクリプトの転送量は3.59MBから255KBへと変化する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。このページにはGTMコンテナが3つ設置されており、そのうち1つは中身が空でした。それでも展開後705KBのコンテナ本体は、毎回ダウンロード・実行されていました。

一方、実測の FCP・LCP はタグの除去前後で変わりませんでした。このページの最初の描画を遅らせていたのはタグではなくサイト自身の構成であり、タグを除去したことでその構造がはっきりと見えるようになりました。

サイト固有のボトルネック ​

サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究ではサードパーティータグを含む全26件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。

3件はいずれも、HTMLを配信する www.webike.net とは別の画像用ドメイン img.webike-cdn.net に関わるものです。HTMLの到着直後にこのドメインへ一斉に送られた最初のリクエスト群（CSS 3本、jQuery、メインバナー画像など）の応答は、一様に約0.9〜0.97秒待たされていました。同じドメインへの2回目以降のリクエストは中央値62msで返り、すべてCDNのキャッシュにヒットしていたことから、ファイルそのものではなく、別ドメインへの最初の接続と初回リクエストのコストと考えられます。

以下の同一ドメインへの移管のシミュレーションでは、移管後の応答時間を35msと仮定しています。録画時に www.webike.net の確立済みの接続で配信された静的ファイル（/favicon.ico）の応答時間です。

ボトルネック1: LCP画像が別ドメインから配信されている ​

詳細レポート 差分コミット

観察された状況 ​

LCP 要素のメインバナー画像（PNG、約124KB）は img.webike-cdn.net から配信されており、応答までに約0.96秒かかっていました。後述のボトルネック2を解消した時点で、実測の LCP 1.3秒のうち約72%をこの待ち時間が占めていました。Lighthouse の LCP の内訳でも、画像のリソース読み込み時間が約1.0秒と大半を占めていました。

解消シミュレーションの方法 ​

メインバナー画像の <img> と preload の参照先を、HTMLと同じ www.webike.net に変更しました。画像の中身・サイズと転送速度は録画時のままです。

シミュレーション結果 ​

実測の LCP が1.3秒から0.4秒へと約0.9秒（約69%）短縮する結果が得られました。シミュレーション値の変化は小さいものの、実測値の変化から、別ドメインからの配信が LCP に与えていた影響の大きさが読み取れます。本研究で最も大きな影響が観測されたボトルネックです。

なお、同じ画像に fetchpriority="high" を付与するシミュレーションや、可逆WebPへの変換（約124KBから約80KB）のシミュレーションも行いましたが、この計測環境では実測の LCP に変化は見られませんでした。この計測環境では、画像の優先度や容量よりも配信元のドメインの影響が支配的でした。ただし、帯域の取り合いが起きる実際のモバイル回線では、優先度や容量の影響も表れると考えられます。

ボトルネック2: body先頭の同期スクリプトと別ドメインのCSSが最初の描画を止める ​

詳細レポート 差分コミット

観察された状況 ​

<head> ではレンダリングをブロックするCSS（読み込みが完了するまでページの描画が停止するリソース）3本が img.webike-cdn.net から読み込まれていました。さらに <body> の先頭付近で、同じドメインの jquery.tools.min.js（jQuery本体）と jquery.unveil.js が同期読み込みされていました。それより前の <body> には表示要素がなかったため、この2本が約0.95秒後に届くまで、画面には何も描画されませんでした。

解消シミュレーションの方法 ​

まずCSS 3本をHTMLと同じ www.webike.net から配信する状態を作り、続いて外部・インライン合わせて28個の <script> 要素を、出現順を保ったまま全て </body> の直前へ移動しました。defer・async などの属性とスクリプトの中身は変えていません。

シミュレーション結果 ​

CSSの同一ドメイン化だけでは、実測の FCP は変わりませんでした（1.38秒から1.37秒）。同期スクリプトが引き続き描画を止めていたためです。スクリプトの移動が加わって初めて、最初の描画は「HTMLの到着とCSSの1往復」で決まるようになり、実測の FCP が1.4秒から0.4秒へと約1秒短縮する結果が得られました。

CSSとスクリプトの両方が描画の経路上にあり、どちらか一方だけでは効果の表れない構造だったと、このシミュレーション結果から読み取れます。なお、その後CSSをHTMLに埋め込むシミュレーションでは、実測の FCP は0.4秒のまま（0.40秒から0.36秒）で、残りの大半はHTMLのサーバー応答時間でした。

ボトルネック3: 別ドメインの同期スクリプトがページの準備完了を遅らせる ​

詳細レポート 差分コミット

観察された状況 ​

ボトルネック2のシミュレーションで </body> の直前へ移したことで、jquery.tools.min.js と jquery.unveil.js は最初の描画を止めなくなりました。しかし、この2本は依然として別ドメインへの最初のリクエスト群に含まれ、応答に約0.95秒かかっていました。そのため、HTMLの解析完了（DOMContentLoaded）と、jQueryを使うその後の処理（ヘッダー上部の帯バナーの挿入など）が約0.95秒待たされていました。

解消シミュレーションの方法 ​

この2本のスクリプトを、HTMLと同じ www.webike.net から配信する状態を作りました。

シミュレーション結果 ​

DOMContentLoadedと読み込み完了がともに1.4秒から0.4秒へ、画面の最後の変化も約0.43秒早まる結果が得られました。実測の FCP・LCP は変わらないものの、スクリプトに依存する表示や操作の準備がそろうまでの時間に、別ドメインの初回コストがそのまま上乗せされていたことが読み取れます。

まとめ ​

ウェビック（webike.net）のトップページを観測したところ、総合スコア は100、TBT は0ms、CLS は0と、Lighthouse の上では既に良好な値が計測されていました。一方、実測では最初の描画とメインバナーの表示まで約1.4秒、読み込み完了まで約3.3秒かかっており、スコアに表れないボトルネックが残っていました。

観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグ（5系統・97リソース）: 除去によって読み込み完了が3.3秒から1.4秒へ、スクリプトの転送量が3.59MBから255KBへ変化しました。最初の描画には影響していませんでした。
• LCP画像の別ドメイン配信: 同一ドメインからの配信をシミュレーションしたところ、実測の LCP が1.3秒から0.4秒へ約0.9秒短縮。本研究で最も大きな影響が観測されました。
• body先頭の同期スクリプトと別ドメインのCSS: 両方を描画の経路から外すことで、実測の FCP が1.4秒から0.4秒へ約1秒短縮しました。どちらか一方だけでは変化が表れない構造でした。
• 別ドメインの同期スクリプト（jQuery）: 同一ドメインからの配信をシミュレーションしたところ、DOMContentLoadedと読み込み完了が約1秒早まりました。

サイト固有の3件のボトルネックは、いずれも画像用ドメインへの最初の接続と初回リクエストに約0.95秒かかるという、このサイトに固有の1つの構造から生じていました。全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は100のまま、実測の FCP・LCP は約1.4秒から約0.4秒へ、読み込み完了は3.3秒から0.4秒へと変化しています。

全ての解消シミュレーションを終えた後も、HTMLのサーバー応答時間（約0.33秒）が実測 LCP（約0.39秒）の約8割を占めていました。HTMLはCDNでキャッシュされず、毎回オリジンサーバーまで往復しています。これはサーバー側の処理であり本研究のシミュレーションの範囲外ですが、このサイトに残る最大のボトルネックとして観測されています。