「SHIROHATO（白鳩）」トップページの表示速度ボトルネック研究
Google FontsのCSSによるレンダリングブロック、JavaScriptで確定するヘッダーの高さ、カルーセルの初期化前レイアウトの未定義などのボトルネックが観測され、解消シミュレーションではLighthouseスコアが96から最大100へ変化しました。Core Web Vitalsには隠れた改善余地があります。
詳細レポート 
ボトルネック一覧 
差分リポジトリ この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。
京都の株式会社白鳩が運営する、下着・ランジェリーの通販サイトです。ワコールやトリンプなどの人気ブランドのインナーから、ルームウェアやメンズ・キッズ向けのアイテムまでを幅広く取り扱っています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。
| 観測時点 | 解消シミュレーション後 |
|---|---|
 |  |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 96 | 100 | +4 |
LCP | 0.7秒 | 0.1秒 | -0.6秒 |
FCP | 0.6秒 | 0.1秒 | -0.5秒 |
SI | 3.2秒 | 0.8秒 | -2.4秒 |
TBT | 209ms | 0ms | -209ms |
CLS | 0.002 | 0.000 | -0.002 |
観測時点でも 総合スコア は96と高い水準にありましたが、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は3.2秒から0.8秒へ、TBT（Total Blocking Time = メインスレッドのブロック時間）は209msから0msへと大きく変化するシミュレーション結果が得られました。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も、いずれも0.1秒まで短縮されています。なお、解消シミュレーション後の値には、静的リソースの配信を高速なネットワーク環境に置き換えたシミュレーションも含まれています。
注目したいのは CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）です。観測時点の値は0.002と良好に見えますが、サードパーティータグを除去した状態で繰り返し計測すると、6回中5回で0.939という「悪い」判定の値が記録されました。スコアの高さの陰に、大きなレイアウトのずれが隠れていたことになります。詳しくは後述のボトルネック2で扱います。
読み込みプロセスの変化を動画で体験
観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。通信速度とCPU性能を制限した環境では、転送量は10.73MBから3.27MBへ、読み込み完了までの時間は19.91秒から4.15秒へと変化しました。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的でないものの、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。
オリジナルページの全543リソースのうち、サイト固有のリソースは388件（約7割）、サードパーティタグ由来のリソースは155件（約3割）を占めていました。HTMLに直接記述されていたタグは3つだけでしたが、Google Tag Manager が十数種類の広告・計測タグを読み込み、それらがさらに広告Cookie同期のリクエストを数十件発生させていました。
HTMLから直接読み込まれているタグ
| タグ名 | 種別 |
|---|---|
Google Tag Manager (GTM-59WDMH6) | タグマネージャー |
Google Analytics 4 | アクセス解析 |
Paidy アップセルウィジェット | 決済プロモーション |
Google Tag Manager経由で読み込まれているタグ
| タグ名 | 種別 |
|---|---|
IM DMP（AudienceOne、内包する GTM コンテナ2つ、Floodlight） | データ連携 |
Microsoft UET | 広告計測 |
Microsoft Clarity | ヒートマップ解析 |
Facebook Pixel | 広告計測 |
Google Ads | 広告計測 |
TikTok Pixel | 広告計測 |
Criteo | リターゲティング広告 |
RTB House | リターゲティング広告 |
LINE Tag | 広告計測 |
Yahoo!広告 | 広告計測 |
VALIS-Cockpit / Logicad | 広告配信 |
User Insight | アクセス解析 |
Yappli | アプリ連携 |
Buyee | 海外転送サービス |
| 広告Cookie同期ピクセル群 | 広告連携 |
除去シミュレーションの結果
| 除去段階 | 総合スコア | TBT | SI | 変化のポイント |
|---|---|---|---|---|
| 観測時点（タグあり） | 96 | 209ms | 3.2秒 | - |
IM DMP 除去 | 96 | 205ms | 3.4秒 | 影響軽微 |
Microsoft UET / Microsoft Clarity 除去 | 97 | 205ms | 2.5秒 | SI が0.9秒短縮 |
Facebook Pixel 除去 | 97 | 208ms | 2.2秒 | SI が0.3秒短縮 |
Paidy 除去 | 97 | 208ms | 2.1秒 | 影響軽微 |
Google Tag Manager と配下のタグを除去 | 100 | 5ms | 2.2秒 | TBT がほぼ解消 |
Google Analytics 4 除去 | 100 | 7ms | 2.2秒 | 影響軽微 |
サードパーティータグを全て除去した状態では、総合スコア は96から100へ変化し、TBT は209msから7msへ、SI は3.2秒から2.2秒へ短縮される結果が得られました。TBT のほぼ全ては、Google Tag Manager 経由で読み込まれる Google Ads のタグが生む約460msのロングタスクに由来しており、細かな処理に分かれたタグをいくら除去しても TBT はほとんど変わりませんでした。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。
サイト固有のボトルネック
サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究では全32件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。
ボトルネック1: Google FontsのCSSがレンダリングをブロックしている
観察された状況
<head> 内の <link rel="stylesheet"> で読み込まれる CSS は、全て届くまでページの描画を止めるレンダリングブロックリソースです。このページでは、別ドメイン（fonts.googleapis.com）から配信される Google Fonts の CSS（Noto Sans JP と Cabin）が最も遅く届く CSS になっていました。その結果、LCP 要素であるメインカルーセル1枚目の画像がすでに届いていても、この CSS の到着を待つまで描画できない状態が観測されました。
観測上は、LCP 画像が約1.50秒の時点で届いていたにもかかわらず、Google Fonts の CSS が届く約1.77秒まで描画が始まらず、LCP は約1.86秒でした。画像が届いてから描画されるまでに、約0.36秒の待ち時間が生じていたことになります。
解消シミュレーションの方法
Google Fonts の URL には display=swap が指定されており、フォントが届くまでは代替フォントで表示する設定になっていました。フォントの定義を描画の前提にする必要はないため、CSS を rel="preload" で取得し、取得完了時に stylesheet として適用する非同期の読み込みに置き換えた状態を計測しました。フォントそのものは変更前と同じく読み込まれ、最終的な見た目は変わりません。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 0.6秒 | 0.2秒 | -0.4秒 |
FCP | 0.6秒 | 0.2秒 | -0.4秒 |
SI | 1.8秒 | 1.5秒 | -0.3秒 |
CLS | 0.002 | 0.001 | -0.001 |
LCP は0.61秒から0.17秒へと約7割短縮される結果が得られました。観測上も、描画の待ち時間がほぼなくなり、LCP は約1.86秒から約1.52秒へと約0.34秒早まっています。<link> 要素1行の読み込み方を変えるだけのシミュレーションでこれだけの変化が生じたことから、別ドメインのフォント CSS が描画の開始を大きく遅らせていたことが読み取れます。
ボトルネック2: モバイルヘッダーの高さがJavaScriptで確定する
観察された状況
冒頭で触れたとおり、サードパーティータグを除去した状態でも、このページの CLS は計測するたびに0.002と0.939に分かれていました。トレースを解析すると、読み込み開始の約2.3秒後に、ページのメイン領域全体を大きく動かすレイアウトシフトが毎回発生していました。このページのシフトは、モバイル画面のエミュレーションの影響で「直前にユーザー入力があったシフト」として記録されます。Lighthouse はこの種類のシフトを、エミュレーション開始から500ms以内に発生したものだけ CLS に算入しますが、このシフトは境界の直前（約490ms）か直後（約500ms）で発生しており、そのわずかな差で記録される値が分かれていたのです。実際のユーザー環境ではこの除外は行われないため、シフトは毎回 CLS に算入されます。
原因の1つ目は、モバイル表示のヘッダーの高さでした。ヘッダーの高さは3つの CSS 変数の合計で指定されており、CSS だけの状態では52pxです。その後 JavaScript が各要素の実際の高さを測って変数に代入すると252pxになり、その下の main 要素全体が200px押し下げられていました。
| 状態 | ヘッダーの高さ |
|---|---|
JavaScript 実行前（CSS 変数の初期値） | 52px |
JavaScript 実行後（実測値を代入） | 252px |
解消シミュレーションの方法
モバイル表示のヘッダーに height: auto を指定し、中身の実際の高さに追従させた状態を計測しました。CSS 変数はメガメニューの位置計算などにも使われているため、変数の値や JavaScript は変更していません。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 76 | 95 | +19 |
CLS | 0.939 | 0.139 | -0.800 |
CLS が0.939の回を起点とすると、総合スコア は76から95へ、CLS は0.939から0.139へと変化する結果が得られました。ファーストビューのレイアウトが JavaScript の実行後にはじめて確定する構造が、「悪い」判定の CLS を生んでいたことが読み取れます。観測時点のスコアが96と高くても、トレースを追わなければ見落とされるボトルネックでした。
ボトルネック3: メインカルーセルの初期化前レイアウトが定まっていない
観察された状況
ヘッダーの高さを固定しても、CLS は0.139残っていました。原因の2つ目は、ファーストビューのメインカルーセル（jQuery プラグインの slick、14枚）です。slick が初期化されるまでの間、スライドは縦に積まれて高さ6,029pxの領域を占めていました（opacity: 0 で見えないだけの状態）。初期化されると高さは433pxに縮むため、その下のアイコンメニューなどが約5,600px上に移動し、大きなシフトになっていました。
| 状態 | カルーセルの高さ |
|---|---|
| slick 初期化前（14枚が縦に積まれる） | 6,029px |
| slick 初期化後（横1列に並ぶ） | 433px |
解消シミュレーションの方法
初期化前（.slick-initialized クラスが付く前）から、初期化後と同じ「横1列・1枚目を中央に表示」のレイアウトになるよう CSS を追加した状態を計測しました。JavaScript を無効にした状態でも、カルーセルの高さや各スライドの位置、その下のメニューの位置が初期化後と1px以内で一致することを確認しています。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 95 | 100 | +5 |
CLS | 0.139 | 0.002 | -0.137 |
CLS は0.139から0.002へ、総合スコア は95から100へと変化しました。以降の計測では0.939や0.139の値は一度も再発しておらず、ボトルネック2とあわせて、観測時点の不安定な CLS の原因がこの2つの構造に集約されていたことが確認できます。カルーセルライブラリの初期化を待つ間のレイアウトが、ページ全体のずれに直結していたことが読み取れます。
まとめ
SHIROHATO（白鳩）のトップページは、観測時点で 総合スコア 96という高い値を記録していました。一方で、スコアの内側を観察すると、次のようなボトルネックが表示速度に影響していました。
- サードパーティータグ（155リソース）: 除去によって
TBTが209msから7msへ変化。そのほぼ全てがGoogle Adsのタグが生む約460msのロングタスクに由来していました。 - Google FontsのCSSによるレンダリングブロック: 非同期の読み込みに置き換えることで
LCPが約7割短縮。届いていたLCP画像が、別ドメインのCSSを待って描画できずにいました。 - JavaScriptで確定するモバイルヘッダーの高さ:
CSSで高さを確定させることでCLSが0.939から0.139へ変化。計測の約半数で「悪い」判定になる不安定さの主因でした。 - メインカルーセルの初期化前レイアウト: 初期化前の配置を
CSSで固定することでCLSが0.139から0.002へ変化。残るずれを解消し、CLSの値が安定しました。
この他にも、ページ下部の動画ウィジェットとInstagram一覧を表示領域に近づいてから初期化するシミュレーションでは、SI が1.4秒から0.9秒へ短縮される結果が得られています。全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は96から100へ、SI は3.2秒から0.8秒へ、転送量はサードパーティータグ除去後の13,129KiBから2,729KiBへ（約8割減）と変化しました。
なお、HTML本体のサーバー応答時間（約1,260ms）はフロントエンドの変更では短縮できないため、今回のシミュレーションには含めていません。最終状態でも、観測上の LCP（約1.42秒）の約9割をこの応答時間が占めており、実際のユーザーの体感速度を左右する要因として残っていることが観測されました。
この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。
