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

1999年創業のホビー総合通販サイトです。フィギュア、ガンプラやミリタリーなどのプラモデル、鉄道模型、キャラクターグッズまで幅広い商品を扱い、トップページには新着商品一覧やランキングが大量に並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

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

ただし、本研究の Lighthouse はCPUの速度低下を行わない設定で計測しており、TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点から0msでした。また、LCP や FCP のシミュレーション値には、HTMLのサーバー応答時間（約0.97秒）がそのまま加算されません。そこで本研究では、計測中にブラウザが実際に描画した時刻（以下、実測値）もあわせて観測しました。

実測の LCP は2.1秒から1.1秒へとほぼ半分になる結果が得られました。CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は観測時点から小さな値でしたが、後述のとおり、初期画面の外に大きなずれが潜んでいたことも分かっています。スコアが100であってもボトルネックは存在しうることを、このサイトの研究結果は示しています。

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

通信速度約10Mbps、CPU 4倍の速度低下という条件で、ページ全体をスクロールしながら記録した読み込みの比較動画です。観測時点では画面が白いままの時間が長いのに対し、解消シミュレーション後はメインビジュアルやカテゴリ一覧が早い段階で表示されます。

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

詳細レポート

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

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

オリジナルページの全331リソースのうち、サイト固有のリソースは311件（約94%）、サードパーティタグ由来のリソースは20件（約6%）でした。jQueryやカルーセルのライブラリは自社サーバーから配信されていました。

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

明確な変化が観測されたのは A8.net でした。スクリプト自体は9.4KBと小さく async 付きでしたが、HTMLの解析中に読み込みが始まり、応答時間が0.5秒以上と遅い外部サーバーとの通信が読み込み完了の直前まで続いていました。一方、Google Tag Manager とその配下の Google Ads・Google Analytics 4、そして Microsoft Clarity は、CDN（Cloudflare）の Rocket Loader という機能によって読み込み完了後に実行されていたため、表示速度の指標への影響は限定的でした。

ただし、タグの転送量とCPU負荷は小さくありません。

サードパーティータグを全て除去した状態でも 総合スコア は100のままでしたが、A8.net の除去では LCP の0.6秒短縮という結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。小さなスクリプトであっても、応答の遅い外部サーバーから早い段階で読み込まれると表示の完了を遅らせる、という点がこのサイトでは明確に表れました。

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

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

総合スコア が観測時点から100だったため、以下では Lighthouse のシミュレーション値に加えて、実測値や転送量の変化もあわせて示します。

ボトルネック1: ファーストビューのカルーセルがJavaScriptの初期化まで表示されない ​

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

観察された状況 ​

メインビジュアルとヘッダーバナーのカルーセルは、カルーセルのライブラリ（Splide）のCSSによって visibility: hidden の状態で配信され、JavaScriptで初期化されるまで表示されない構造でした。このサイトでは初期化処理が Rocket Loader によって読み込み完了後まで遅れるため、LCP 要素であるメインビジュアルの1枚目も、画像自体は届いているにもかかわらず、スクリプトの実行を待ってから表示されていました。LCP の内訳のうち、描画待ち（Render Delay）が約0.57秒を占めていました。

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

初期化後のレイアウト（中央寄せ、左右のスライドのはみ出し、スライド間の余白）を、初期化前の状態に対してCSSで再現し、カルーセルを最初から表示させた状態を作りました。初期化の前後でスライドの位置は一致しており、見た目の変化や新たなレイアウトのずれは生じません。

シミュレーション結果 ​

実測の LCP が2.1秒から1.5秒へと約0.6秒短縮され、メインビジュアルが最初の描画とほぼ同時に表示される結果が得られました。シミュレーション値の変化は小さいものの、描画待ちの時間がほぼ消えたことから、「画像は届いているのに表示されない」という構造が表示速度に与えていた影響の大きさが読み取れます。本研究で最も大きな影響が観測されたボトルネックです。

なお、同じ Splide を使った「注目のアイテム」「新着商品一覧」の商品カルーセルでも、初期化の瞬間に高さが約283px縮む現象を観測しました。Lighthouse の初期画面の外で起きるため計測値には表れませんが、縦3000pxの画面で計測すると CLS は0.079に達しており、初期化後と同じスライド幅をCSSで指定したシミュレーションでは0.0003まで下がる結果が得られています。

ボトルネック2: Google Fontsの応答待ちを含む複数のCSSが最初の描画を止める ​

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

観察された状況 ​

レンダリングをブロックするCSS（全ての読み込みが完了するまでページの描画が停止するリソース）が4本あり、そのうち1本が fonts.googleapis.com から配信される Google Fonts のCSSでした。自社のCSS 3本は約50msで届いていた一方、Google Fonts のCSSは別ドメインへの接続と、Googleのサーバーがブラウザに合わせてCSSを生成する応答待ち（約360ms）のため、届くまでに約400msかかっていました。自社のCSSが揃ってからの約350ms、ブラウザは何も描画せずに待っていたことになります。

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

まず Google Fonts のCSSをHTMLと同一ドメインから配信する状態を作り、続いて4本のCSSを参照順のまま自社サーバーの静的なCSS 1本に結合しました。フォントファイル自体は引き続き fonts.gstatic.com から読み込む構成です。

シミュレーション結果 ​

シミュレーション値と実測値で、どの段階で大きく変化したかが異なる点が特徴的です。Lighthouse のシミュレーションは別ドメインへの接続を重く見積もるため、同一ドメイン化の段階で FCP が0.5秒から0.1秒へ大きく変化しました。一方、実測の FCP はこの段階ではほぼ変わらず（-0.02秒）、CSSを1本に結合して Google のサーバーの応答待ちが描画の経路から消えた段階で、1.5秒から1.1秒へと約0.37秒短縮されました。

自社のCSS 3本だけを結合した場合の変化は誤差の範囲だったことから、ボトルネックの本体はCSSの本数ではなく、外部サービスが動的に生成するCSSの応答待ちにあったことが、このシミュレーション結果から読み取れます。

ボトルネック3: 日本語Webフォント（Noto Sans JP）の読み込み ​

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

観察された状況 ​

Google Fonts の日本語Webフォント Noto Sans JP は、文字の範囲ごとに124個のファイルに分割されており、トップページの初期表示だけで54ファイル・約1.2MBを取得していました。これはページの転送量の約6割にあたります。フォント配信サーバーの応答時間は約450msと遅く、ファイルが届くたびに文書全体の再レイアウトも発生していました（最初の描画の後に8回）。さらに、価格や日付の表示に使われる数字・欧文用のWebフォント Outfit（約32KB）も Google Fonts から読み込まれ、その到着が読み込み完了を待たせていました。

デザインとして日本語Webフォントを使いたい意図は理解できますが、日本語フォントは収録文字数の多さから、英語フォントとは桁違いのデータ量になります。このシミュレーションは書体が変わることを前提に行いました。

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

Noto Sans JP の @font-face 宣言（124個）を削除し、font-family の指定をヒラギノ角ゴシックやメイリオなどのシステムフォントに変更しました。続いて Outfit の読み込みと fonts.gstatic.com への preconnect も削除し、数字・欧文も端末のフォントで表示する状態を作りました。

シミュレーション結果 ​

日本語Webフォントの除去によって総転送量が約1,980KBから約765KBへと6割以上減り、再レイアウトがなくなったことでメインスレッドの処理時間も約555msから約370〜410msへと3割ほど短縮される結果が得られました。数字・欧文用のフォントまで除去した段階では、読み込み完了が1.6秒から1.2秒へと約0.44秒早まり、SI も0.8秒から0.6秒へ変化しています。

一方、実測の FCP・LCP はほとんど変化しませんでした。その大半をHTMLのサーバー応答時間が占めているためです。表示の開始には表れにくいものの、転送量と読み込み完了までの時間の変化から、日本語Webフォントがページ全体の読み込みに与えていた影響の大きさが読み取れます。見た目の変化は日本語と数字・欧文の字形に限られ、要素の位置や画像は変わっていません。

まとめ ​

ホビーサーチ（1999.co.jp）の表示速度を観測したところ、総合スコア は100、TBT は0msと、Lighthouse の上では既に良好な値が計測されていました。一方、実測では最初の描画まで約1.5秒、メインビジュアルの表示まで約2.1秒かかっており、スコアに表れないボトルネックが残っていました。

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

• サードパーティータグ（5種類・20リソース）: A8.net の除去で LCP が0.6秒短縮。そのほかのタグは Rocket Loader により読み込み完了後に実行されていたため表示速度への影響は限定的でしたが、転送量は合計約525KB、CPU負荷は合計約150msありました。
• ファーストビューのカルーセルの非表示: 初期レイアウトをCSSにより再現したシミュレーションで、実測の LCP が2.1秒から1.5秒へ約0.6秒短縮。本研究で最も大きな影響が観測されました。
• Google Fonts のCSSの応答待ち: 自社のCSSとの結合で、実測の FCP が1.5秒から1.1秒へ約0.37秒短縮。シミュレーション値と実測値で変化する段階が異なる点も観測されました。
• 日本語・数字のWebフォント（約1.2MB）: 除去によって総転送量が6割以上減少し、読み込み完了が約0.44秒早まりました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は100のまま、実測の LCP は2.1秒から1.1秒へとほぼ半分になりました。

また、全ての解消シミュレーションを終えた後も、HTMLのサーバー応答時間が約0.97秒あり、解消シミュレーション後の実測 LCP の約9割を占めていました。HTMLはアクセスごとに生成されCDNでキャッシュされていない一方、同じサーバーの静的ファイルの応答時間は中央値で約51msでした。これはサーバー側の処理であり、本研究のシミュレーションの範囲外ですが、このサイトに残る最大のボトルネックとして観測されています。スコアが満点であっても、実際の表示までの時間には複数の要因が積み重なっていたことが、この一連のシミュレーションによって確認できた形です。