「FABIUS」トップページの表示速度ボトルネック研究
CSS・JS・画像の外部ドメイン配信、LCP画像のlazy loading、Splideカルーセルの初期非表示によるレイアウトシフトなどのボトルネックが観測され、これらを解消するシミュレーションではLighthouseスコアが47から最大100まで変化する結果が得られました。Core Web Vitalsの大幅な改善が期待できます。
詳細レポート 
ボトルネック一覧 
差分リポジトリ 
FABIUSは、美容・健康関連の商品を取り扱う公式オンラインショップです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。
| 観測時点 | 全ボトルネック解消シミュレーション後 |
|---|---|
 |  |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 47 | 100 | +53 |
LCP | 13.9秒 | 1.2秒 | -12.7秒 |
FCP | 2.4秒 | 0.3秒 | -2.1秒 |
SI | 4.4秒 | 1.4秒 | -3.0秒 |
TBT | 42ms | 0ms | -42ms |
CLS | 0.632 | 0.047 | -0.585 |
総合スコア が47から100へと53ポイント変化するというシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = 最大コンテンツの描画完了時間）が13.9秒から1.2秒へ、CLS（Cumulative Layout Shift = レイアウトのずれの大きさ）が0.632から0.047へと大きな変化が観測されており、これらの指標に強く影響するボトルネックが存在していたことが読み取れます。
読み込みプロセスの変化を動画で体験
本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見て取れます。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。
オリジナルページの全177リソースのうち、サイト固有のリソースは127件（約7割）、サードパーティタグ由来のリソースは50件（約3割）を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの3割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。
myfabius.jp で確認されたサードパーティータグは次のとおりです。
HTMLから直接読み込まれているタグ
| タグ名 | 種別 |
|---|---|
New Relic | APM監視 |
Yahoo Tag (ytag) | 広告計測 |
Sitest | ヒートマップ解析 |
Adobe Fonts (Typekit) | Webフォント配信 |
AD EBiS | コンバージョン計測 |
b-dash | CDP / マーケティング |
UGC Creative | レビューウィジェット |
tracker-ec-force | ECトラッキング |
GTM経由で読み込まれているタグ
| タグ名 | 種別 |
|---|---|
Google Tag Manager | タグマネージャー |
Google Analytics | アクセス解析 |
Google Ads | 広告タグ |
合計53件のサードパーティーリソースが読み込まれていました。
段階的除去によるスコア推移
| 除去段階 | 主な除去対象 | 総合スコア | 変化量 |
|---|---|---|---|
| 観測時点 | - | 47 | - |
| 第1段階 | New Relic | 44 | -3 |
| 第2段階 | Yahoo Tag, Sitest, Adobe Fonts, AD EBiS, b-dash, UGC Creative, tracker-ec-force | 52 | +8 |
| 第3段階 | Google Tag Manager, Google Analytics, Google Ads | 50 | -2 |
個別の段階ではスコアが上下するケースも見られましたが、これはサードパーティータグがレンダリングタイミングに影響を与えていたためと考えられます。
サードパーティータグ除去後の指標変化
| 指標 | 観測時点 | 全タグ除去後 | 変化量 |
|---|---|---|---|
総合スコア | 47 | 50 | +3 |
LCP | 13.9秒 | 8.4秒 | -5.5秒 |
FCP | 2.4秒 | 1.8秒 | -0.6秒 |
SI | 4.4秒 | 3.2秒 | -1.2秒 |
TBT | 42ms | 0ms | -42ms |
CLS | 0.632 | 0.690 | +0.058 |
サードパーティータグを全て除去した状態では、TBT が42msから0msへ完全に解消され、LCP は5.5秒短縮する結果が得られました。TBT のブロッキングはサードパーティータグが唯一の原因であったことが分かります。総合スコア の変化は+3ポイントにとどまりましたが、これは CLS のわずかな悪化（後続のボトルネック解消で対処）がスコアに影響しているためです。実際にはサードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。
サイト固有のボトルネック
サードパーティータグの影響を排除した上で、サイト固有のボトルネックを観察しました。全9件のボトルネック仮説を検証した中から、特に影響の大きかった3件を紹介します。
ボトルネック: CSS・JS・画像の外部ドメイン配信
観察された状況
ページで使用されるCSS、JavaScript、画像が複数の外部ドメインから配信されていました。メインのCSS/JSファイルはCloudFrontドメイン（d2w53g1q050m78.cloudfront.net）から、約物半角フォント（yakuhanjp）は cdn.jsdelivr.net から、stickyfill.min.js は cdnjs.cloudflare.com から、それぞれ読み込まれていました。
外部ドメインからリソースを取得する場合、DNS解決とTLSハンドシェイクに100〜300msの接続コストが発生します。特にレンダリングブロックリソース（CSS・同期的なJavaScript）が外部ドメインにある場合、この接続コストがそのまま FCP の遅延に直結します。
解消シミュレーションの方法
パブリックCDN（cdn.jsdelivr.net, cdnjs.cloudflare.com）およびCloudFront（d2w53g1q050m78.cloudfront.net）、Font Awesome（use.fontawesome.com）から配信されていたリソースを、全て同一ドメイン（myfabius.jp）から配信するよう変更しました。あわせて、stickyfill.min.js に defer 属性を追加してレンダリングブロックを解除し、preload 要素のURLをクエリパラメータ付きの実URLと一致させる修正も行いました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 50 | 94 | +44 |
FCP | 1.8秒 | 0.3秒 | -1.5秒 |
LCP | 8.4秒 | 3.0秒 | -5.4秒 |
SI | 3.2秒 | 1.4秒 | -1.8秒 |
| 解消前 | 解消後 |
|---|---|
 |  |
FCP が1.8秒から0.3秒へ、LCP が8.4秒から3.0秒へと大きく変化し、総合スコア は44ポイント上昇しました。このシミュレーション結果から、複数の外部ドメインからのリソース配信が表示速度に与えていた影響の大きさが読み取れます。
ボトルネック: LCP画像のlazy loading
観察された状況
LCP 対象要素であるメインビジュアルのカルーセル画像（kv_cellplus_sp.jpg、72.9KB）に loading="lazy" が設定されていました。loading="lazy" はビューポート外の画像に対して使用する属性ですが、ファーストビューに表示される LCP 画像に設定されていたため、ブラウザが画像のリクエスト開始を遅延させていました。
Lighthouse の LCP 内訳分析では、Load Delay（リクエスト開始までの遅延）が999ms（LCP 全体の33%）を占めており、この遅延が loading="lazy" に起因するものでした。
解消シミュレーションの方法
LCP 画像の loading 属性を loading="eager" に変更し、fetchpriority="high" を追加しました。これにより、ブラウザがHTMLパース時に即座に最高優先度で画像をリクエストする状態をシミュレーションしました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 94 | 100 | +6 |
LCP | 3.0秒 | 1.2秒 | -1.8秒 |
| 解消前 | 解消後 |
|---|---|
 |  |
LCP が3.0秒から1.2秒へと1.8秒短縮し、総合スコア は100に到達しました。HTML属性の変更のみで LCP が約60%短縮するという結果から、loading="lazy" がファーストビュー画像に設定されていたことの影響の大きさが分かります。
ボトルネック: Splideカルーセルの初期非表示によるレイアウトシフト
観察された状況
メインビジュアルにはSplideカルーセルライブラリが使用されています。Splideはデフォルトで初期状態のカルーセルを visibility: hidden にしており、JavaScriptの初期化が完了した時点で visibility: visible に切り替えます。この切り替えが発生する瞬間、ファーストビューの大部分を占めるメインビジュアルのレイアウトが大きくずれ、CLS が0.690という非常に高い値を示していました。
解消シミュレーションの方法
<head> 内にインラインCSSを追加し、JavaScript初期化前でもカルーセルの1枚目のスライドが正しく表示されるようにしました。visibility: visible !important でカルーセルを即座に表示し、overflow: hidden で2枚目以降のスライドを隠す構成です。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 50 | 77 | +27 |
CLS | 0.690 | 0.051 | -0.639 |
LCP | 8.4秒 | 5.8秒 | -2.6秒 |
SI | 3.2秒 | 2.5秒 | -0.7秒 |
| 解消前 | 解消後 |
|---|---|
 |  |
CLS が0.690から0.051へと大幅に変化し、総合スコア は27ポイント上昇しました。カルーセルライブラリの初期表示の仕組みがレイアウトシフトの主要因であったことが、このシミュレーション結果から明確に読み取れます。LCP も2.6秒短縮しており、レイアウトの安定化が描画タイミングにも波及していたことが分かります。
まとめ
FABIUSトップページでは、総合スコア 47から100への変化がシミュレーションで観測されました。
最も影響が大きかったのは、CSS・JS・画像が複数の外部ドメインから配信されていたことで、同一ドメインへの集約シミュレーションにより 総合スコア は44ポイント上昇しました。次に、Splideカルーセルの初期非表示が CLS 0.690という大きなレイアウトシフトの原因となっており、CSS修正のシミュレーションで27ポイントの変化が得られました。さらに、LCP 画像への loading="lazy" 設定が1.8秒の描画遅延を生んでおり、属性変更のみで LCP が約60%短縮する結果が得られました。
一方、TBT の42msはサードパーティータグが唯一の原因であり、サイト自体のJavaScriptはメインスレッドをブロックしていませんでした。サイト固有のボトルネックは、外部ドメイン配信・カルーセルの初期表示・画像の読み込み優先度といった、リソース配信とレンダリングの構成に集中していたことが、今回の研究から読み取れます。
