「トラノテ」トップページの表示速度ボトルネック研究
スライダー画像のeager読み込み、複数CSSの分散読み込み、Google Fontsによる日本語Webフォント読み込みなどのボトルネックが観測され、これらを解消するシミュレーションではLighthouseスコアが98から最大100まで変化する結果が得られました。Core Web Vitalsの改善余地が確認できます。
トラノテは、工具・塗料から日用品まで390万点以上の品揃えを誇る事業者向け通販サイトです。当日出荷点数18万点、3,000円以上のお買い物で送料無料と、現場とメーカーをつなぐECプラットフォームとして運営されています。本記事では、モバイル環境でのページ表示速度に関するボトルネック研究の観測結果を記録します。
Core Web Vitalsにつながる指標の改善ポテンシャル
| 観測時点 | 解消シミュレーション後 |
|---|---|
![]() | ![]() |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 98 | 100 | +2 |
LCP | 2.3秒 | 0.3秒 | -2.0秒(87%の変化) |
FCP | 0.3秒 | 0.2秒 | -0.1秒(36%の変化) |
SI | 1.5秒 | 1.0秒 | -0.5秒(33%の変化) |
CLS | 0.000 | 0.000 | 変化なし |
TBT | 0ms | 0ms | 変化なし |
本サイトは観測時点で 総合スコア 98と非常に高いパフォーマンスを示しており、CLS(Cumulative Layout Shift = レイアウトのずれ)は0.000、TBT(Total Blocking Time = メインスレッドのブロック時間)は0msでした。一方で LCP(Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間)には2.3秒という観測値が記録されており、ここに表示速度のボトルネックが存在していることが読み取れます。本研究ではボトルネックを解消した場合の影響を計測することを目的としており、各種シミュレーションの結果として LCP が0.3秒まで変化するという観測が得られました。
読み込みプロセスの変化を動画で体験
観測時点と解消シミュレーション後のページ読み込みを動画で比較できます。左が観測時点、右が解消シミュレーション後です。スコアが大きく変わっていない割に、体感的な速度は改善できている様子がわかります。
サードパーティータグの影響
本研究ではまず、サードパーティータグ(広告・アクセス解析・トラッキングなど外部サービスのスクリプト)を除去したシミュレーションを行い、タグ全体が表示速度に与える最大改善ポテンシャルを観測します。同時に、以降のサイト本体のボトルネック観察におけるノイズ除去も兼ねています。なお、サイト運営上必要なタグも含まれるため、完全な除去は現実的ではありません。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。

オリジナルページの全376リソースのうち、サイト固有のリソースは326件(約87%)、サードパーティタグ由来のリソースは50件(約13%)を占めていました。なお、公開CDN(cdnjs等)やGoogle Fontsは「サードパーティタグ」には含めていません。これらはセルフホスト化等で直接最適化できるため、後続のFCP/LCP改善フェーズで個別に対処しています。
トラノテで確認されたサードパーティータグは以下の通りです。Google Tag Manager 経由では33ドメイン・49件のリソース(GA4、Microsoft Clarity、Google Ads、Criteo、Facebook Pixel、Yahoo広告、Bing Ads、各種Cookie Sync 16社など)が読み込まれていました。
| タグ名 | 種別 |
|---|---|
Criteo dataLayer | リターゲティング広告 |
Google Tag Manager | タグ管理 |
GTM 経由の残存リソース(49件・33ドメイン) | 広告・解析・Cookie Sync |
すべてのサードパーティータグを除去した場合の変化は以下の通りです。
| 指標 | 観測時点 | タグ除去後 | 変化量 |
|---|---|---|---|
総合スコア | 98 | 99 | +1 |
LCP | 2.3秒 | 2.1秒 | -0.2秒 |
SI | 1.5秒 | 1.3秒 | -0.2秒 |
観測時点で 総合スコア 98という高水準にある本サイトでは、サードパーティータグ全体の最大改善ポテンシャルは 総合スコア で+1、LCP で-0.2秒と限定的でした。なお、サイト運営上必要なタグも含まれるため、すべてを除去することは現実的ではありません。
サイト固有のボトルネック
サードパーティータグの影響を切り分けた上で、サイト本来の実装に起因するボトルネックを順次解消しながら観測を進めます。本研究では全10件の解消シミュレーションを実施しました。その中から、特に影響が大きかった3つのボトルネックを紹介します。
1. スライダー画像のeager読み込み — LCPが26.1%変化
観察された状況
トップページのメインスライダーには複数の画像が配置されていますが、すべての画像に loading="eager" が指定されており、画面に表示されていないスライダー画像も初期読み込みの対象となっていました。その結果、LCP 画像(1枚目のスライダー画像)のリソース取得が他の画像と競合し、表示タイミングが遅延しているという状況が観測されました。
解消シミュレーションの方法
スライダーの1枚目(LCP 画像)はそのまま維持し、2〜4枚目の画像に loading="lazy" を付与しました。PC版・SP版あわせて計6要素の属性を変更しています。
<!-- 変更前 -->
<img src="toranote_pitin_01.png" loading="eager" />
<img src="toranote_about.png" loading="eager" />
<img src="cainz_top.jpg" loading="eager" />
<!-- 変更後 -->
<img src="toranote_pitin_01.png" loading="lazy" />
<img src="toranote_about.png" loading="lazy" />
<img src="cainz_top.jpg" loading="lazy" />シミュレーション結果
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
LCP | 1.7秒 | 1.3秒 | -0.4秒(26.1%の変化) |
SI | 1.1秒 | 1.1秒 | -0.0秒 |
loading 属性値の変更のみで LCP が0.4秒変化したという観測結果が得られました。スライダー内の非表示画像と LCP 画像が同時にリソースを奪い合っていた状況がここから立証されます。この数値は、初期表示に不要な画像の eager 読み込みがどの程度ボトルネックとなり得るかを示すデータとして記録します。
2. 複数CSSの分散読み込み — FCPが0.1秒、LCPが0.3秒の変化
観察された状況
ページでは CSS ファイルが9つに分散して読み込まれていました。CSS はレンダリングブロックリソース(読み込みが完了するまでページの描画が停止するリソース)であり、ファイル数が多いほどHTTPリクエストのオーバーヘッドが蓄積し、描画開始が遅延します。観測時点ではこれがボトルネック要因のひとつとなっていました。
解消シミュレーションの方法
Google Fonts以外の外部 CSS 9ファイルを1ファイルに結合しました。CSS 内の相対パス(画像参照等)は絶対URLに変換しています。
結合前: mCustomScrollbar.min.css, top.css, login.css, common.css,
common2024.css, history_search.css, category_dropdown.css,
footer.css, top2024.css(計9ファイル)
結合後: 1ファイル(CSSリクエスト数が10から2に減少)シミュレーション結果
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
FCP | 0.3秒 | 0.2秒 | -0.1秒 |
LCP | 2.0秒 | 1.7秒 | -0.3秒 |
Score | 99 | 100 | +1 |
CSS の結合によりHTTPリクエスト数が削減され、レンダリングブロックの待ち時間が短縮されるという変化が観測されました。総合スコア も100に到達しています。分散した CSS 読み込みが FCP と LCP の両方に対してボトルネックとなっていたことが、この数値から読み取れます。
なお、CSSの統合・1ファイル化は、現在では HTTP/2 の普及などにより必ずしも有効なプラクティスとは限りません。今回のシミュレーションのように良好な結果が観測されることもありますが、参考程度にとどめてください。
3. Google Fontsによる日本語Webフォント読み込み — LCPが85%の変化
観察された状況
サイトでは Google Fonts から日本語Webフォント(BIZ UDPGothic)を読み込んでおり、fonts.googleapis.com からの CSS 1件、fonts.gstatic.com からの woff2 フォントファイル64件、webfont.js 1件の合計66リソース(約615KB)がページ読み込み時に取得されているという状況が観測されました。
日本語Webフォントは文字数の多さからデータ量が非常に大きく、英語フォントとは比較にならない規模のリソースがネットワーク経由で取得される点が特徴です。
解消シミュレーションの方法
Google Fonts に関連する66リソースの読み込みを廃止し、CSS の font-family 指定をシステムフォント(OSに標準搭載されたフォント)に変更しました。
/* 変更前 */
font-family: 'BIZ UDPGothic', sans-serif;
/* 変更後 */
font-family: 'メイリオ', Meiryo, 'ヒラギノ角ゴ ProN', sans-serif;シミュレーション結果
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
LCP | 1.9秒 | 0.3秒 | -1.7秒(85%の変化) |
FCP | 0.2秒 | 0.2秒 | -0.1秒 |
SI | 1.1秒 | 1.0秒 | -0.1秒 |
66リソース・約615KBの読み込みがなくなることで、LCP が85%変化するという観測結果が得られました。本研究で扱った全ボトルネックの中で最大の影響量であり、日本語Webフォントがこのサイトにおける表示速度の最大のボトルネックとして機能していたことが数値的に立証されます。
まとめ
トラノテ(torano-te.jp)の表示速度ボトルネックの実例研究では、Lighthouse スコアで98から100、LCP で2.3秒から0.3秒という変化が観測されました。
観測時点で既に 総合スコア 98と高い水準にあったサイトにおいても、スライダー画像のeager読み込み・分散CSS・Google Fonts による日本語Webフォント読み込みという3種類のボトルネックが存在していたことが、解消シミュレーションの数値として立証されました。特にGoogle Fonts による日本語Webフォントの影響量は LCP で-1.7秒と際立って大きく、日本語Webフォントが表示速度に与えうる影響のスケールを示すデータとして記録に値します。
本研究の目的はボトルネックの存在とその影響量を可視化することにあり、観測された数値はサイトに実際どのような改変を行うべきかを示すものではありません。研究結果として残すデータが、Web表示速度におけるボトルネックの性質の理解の一助となれば幸いです。

