「ドスパラ」トップページの表示速度ボトルネック研究
CSSの重複読み込み、head内CSSの分割読み込み、日本語Webフォント（Noto Sans JP）の読み込みなどのボトルネックが観測され、これらを解消するシミュレーションではLighthouseスコアが85から最大95まで変化する結果が得られました。Core Web Vitalsの顕著な改善が期待できます。
詳細レポート 
ボトルネック一覧 
差分リポジトリ 
株式会社サードウェーブが運営するパソコン通販サイトです。ゲーミングPCブランドGALLERIA（ガレリア）をはじめ、BTOパソコンやPCパーツ、周辺機器を幅広く取り扱っています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。
| 観測時点 | 解消シミュレーション後 |
|---|---|
 |  |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 85 | 95 | +10 |
LCP | 1.6秒 | 0.1秒 | -1.5秒 |
FCP | 1.5秒 | 0.0秒 | -1.5秒 |
SI | 3.6秒 | 1.0秒 | -2.6秒 |
TBT | 487ms | 0ms | -487ms |
CLS | 0.070 | 0.136 | +0.066 |
総合スコア が85から95へ変化し、特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が1.6秒から0.1秒へ、TBT（Total Blocking Time = メインスレッドの応答不能時間）が487msから0msへと大きな変化が観測されました。CLS（Cumulative Layout Shift = レイアウトのズレ）は一部シミュレーションの副作用として0.066増加しています。
読み込みプロセスの変化を動画で体験
本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見て取れます。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。
オリジナルページの全459リソースのうち、サイト固有のリソースは234件（約5割）、サードパーティタグ由来のリソースは225件（約5割）を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの約5割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。
dospara.co.jp のHTMLから直接、またはタグマネージャー経由で読み込まれていたサードパーティータグは次のとおりです。
HTMLから直接読み込み:
| タグ名 | 種別 |
|---|---|
Facebook SDK | ソーシャル連携 |
Synalio | チャットウィジェット |
Leeep | Web接客 |
Yahoo Retargeting | リターゲティング広告 |
CQuotient (Salesforce Einstein) | AIレコメンデーション |
Yahoo Tag Manager (YTM) | タグ管理 |
GTM (GTM-K9TGM3) 経由で読み込み:
| タグ名 | 種別 |
|---|---|
Google Ads | 広告 |
GA4 / Google Analytics | アクセス解析 |
TikTok Pixel | 広告計測 |
Twitter/X Pixel | 広告計測 |
Criteo | リターゲティング広告 |
SmartNews Ads | 広告 |
RTB House | リターゲティング広告 |
Bing UET | 広告計測 |
LOGICAD | 広告 |
n-analytics | 計測 |
MicroAd | SSP/DSP |
GMO SSP | SSP |
Ad-stir | SSP |
OpenX | SSP |
PubMatic | SSP |
BidSwitch | SSP |
Outbrain | 広告配信 |
Taboola | 広告配信 |
合計225件のサードパーティーリソースが確認されました。段階的に除去した際の指標変化は次のとおりです。
| 除去段階 | 総合スコア | TBT | SI | 変化のポイント |
|---|---|---|---|---|
| 観測時点（タグあり） | 85 | 487ms | 3.6秒 | - |
Facebook SDK 除去（65リソース） | 97 | 0ms | 3.4秒 | TBT が0msに |
Synalio / Leeep / Yahoo Retargeting 除去（43リソース） | 84 | 508ms | 3.3秒 | FCP が0.7秒短縮 |
CQuotient / YTM 除去（3リソース） | 84 | 516ms | 3.3秒 | 影響軽微 |
GTM 除去（114リソース） | 96 | 0ms | 2.0秒 | TBT 完全解消、SI 1.3秒短縮 |
サードパーティータグを全て除去した状態では 総合スコア は85から96へ変化し、TBT は487msから0msへ、SI は3.6秒から2.0秒へ短縮される結果が得られました。特に GTM 配下の30種以上の広告・計測タグと Facebook SDK が TBT に与えていた影響は非常に大きく、メインスレッドのブロック時間の全てがサードパーティータグに起因していたことが読み取れます。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが分かります。
サイト固有のボトルネック
サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究では全13件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。
ボトルネック1: CSSの重複読み込み
観察された状況
同一の CSS ファイルがHTML内の複数箇所で <link> 要素として重複して読み込まれている状態が観測されました。具体的には gronavi-contents.css が3箇所、grid-system.css が2箇所、swiper.css が1箇所で重複しており、さらに存在しない CSS ファイル（404レスポンス）へのリクエストも1件含まれていました。計7件の不要なHTTPリクエストが発生していたことになります。
解消シミュレーションの方法
2箇所目以降の重複 <link> 要素と、404を返すリソースへの <link> 要素を削除した状態を作り、その影響を計測しました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 2.2秒 | 0.9秒 | -1.4秒 |
FCP | 0.9秒 | 0.8秒 | -0.1秒 |
LCP が2.2秒から0.9秒へと約1.4秒短縮される結果が得られました。重複した CSS リクエストがネットワーク帯域を無駄に消費し、重要なリソースの読み込みを遅延させていたことが、このシミュレーション結果から読み取れます。特に404を返すリソースへのリクエストは完全に無駄な通信であり、影響が明確です。
ボトルネック2: head内CSSの分割読み込み
観察された状況
<head> 要素内で4つの CSS ファイル（swiper.css、base.css、spinner.css、tx-global.css）が個別の <link> 要素として読み込まれている状態が観測されました。CSS はレンダリングブロックリソース（全ての読み込みが完了するまでページの描画が停止するリソース）であるため、リクエストの分散がレンダリング開始を遅延させていました。
解消シミュレーションの方法
4つの CSS ファイルの内容を1ファイルに結合し、<link> 要素を1つにまとめた状態を作り、その影響を計測しました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 2.6秒 | 1.1秒 | -1.5秒 |
FCP | 0.9秒 | 0.8秒 | -0.1秒 |
SI | 1.9秒 | 1.6秒 | -0.3秒 |
LCP が2.6秒から1.1秒へと約1.5秒短縮される結果が得られました。HTTPリクエスト数の削減により CSS の取得・パース完了までの時間が短縮され、レンダリング開始が早まったことが数値に表れています。レンダリングブロックリソースの分割が LCP に与えていた影響の大きさが読み取れます。
なお、CSSの統合・1ファイル化は、現在では HTTP/2 の普及などにより必ずしも有効なプラクティスとは限りません。今回のシミュレーションのように良好な結果が観測されることもありますが、参考程度にとどめてください。
ボトルネック3: 日本語Webフォント（Noto Sans JP）の読み込み
観察された状況
日本語Webフォント Noto Sans JP（Variable Font）が CSS の @font-face 宣言を通じて読み込まれており、そのファイルサイズは1.75MB（1,830,364バイト）に達していました。日本語Webフォントは収録文字数の多さからデータ量が非常に大きくなります。このフォントファイルがネットワーク帯域を圧迫し、他のリソースの読み込みを遅延させている状態が観測されました。このシミュレーションではフォントの見た目が変わることを前提に計測を行っています。
解消シミュレーションの方法
@font-face 宣言を削除し、CSS の font-family 指定から Noto Sans JP を除去して、游ゴシック等のシステムフォントにフォールバックする変更を加えた状態を計測しました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 1.1秒 | 0.1秒 | -1.0秒 |
FCP | 0.8秒 | 0.0秒 | -0.8秒 |
SI | 1.4秒 | 1.0秒 | -0.4秒 |
1.75MBのフォントファイルを取り除いたことで、LCP が1.1秒から0.1秒へ、FCP が0.8秒から0.0秒へと劇的な変化が観測されました。総転送サイズも11.4MBから9.65MBへ大幅に削減されています。日本語Webフォントの利用はデザイン上の判断であり、その意図は理解できますが、1.75MBという単一ファイルが表示速度に与えていた影響の大きさは、この数値から明確に読み取れます。
まとめ
ドスパラ（dospara.co.jp）の表示速度を観測したところ、総合スコア 85、LCP 1.6秒、TBT 487msという値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。
観測されたボトルネックとその影響は次のように整理できます。
- サードパーティータグ（225リソース）: 除去によって
TBTが487msから0msへ完全に解消。SIは1.6秒短縮。メインスレッドのブロック時間の全てがサードパーティータグに起因していました。 - CSSの重複読み込み（7件の不要リクエスト）: 削除によって
LCPが1.4秒短縮。特に404を返すリソースへの無駄な通信が含まれていました。 - head内CSSの分割読み込み（4ファイル）: 1ファイルへの結合によって
LCPが1.5秒短縮。レンダリングブロックリソースの分散が描画開始を遅延させていました。 - 日本語Webフォント（Noto Sans JP、1.75MB）: 除去によって
LCPが1.0秒、FCPが0.8秒短縮。単一ファイルとしては最大級の帯域消費が観測されました。
全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は85から95へ、LCP は1.6秒から0.1秒へと変化しました。観測された各要素がそれぞれ独立して指標に与えていた影響の大きさが、この一連のシミュレーションによって確認できた形です。
