「ヒラキ公式通販サイト」トップページの表示速度ボトルネック研究

靴の通販で知られるヒラキの公式通販サイトです。大人から子どもまでの定番シューズを低価格で扱い、上履きや体操服などの学校用品、インナー、雑貨もそろえています。トップページには、キャンペーンのメインビジュアルとサムネイルのスライダー、カテゴリ別のタブ、商品のカルーセルが縦に長く並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点では、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は良好な値でした。一方で SI（Speed Index = ビューの視覚的な表示進捗の速さ）が9.4秒、TBT（Total Blocking Time = メインスレッドのブロック時間）が502ms、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）が0.163と、3つの指標が 総合スコア を押し下げていました。表の数値は複数回の計測の中央値で、スクリーンショットは単回の実行のため、表示がわずかに異なります。

なお、本研究の計測環境では、HTMLのサーバー応答時間（591ms）が Lighthouse のシミュレーション値に反映されません。LCP・FCP が実際の閲覧時より小さく算出されるのはそのためです。サーバー応答時間の影響は、ブラウザが実際に描画した時刻（以下、実測値）で別に観測しており、まとめで触れます。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。

観測時点では、ファーストビューの描画自体は比較的早いものの、その後も背後で広告・計測タグと画像のダウンロードが続き、ページが落ち着くまでに約19秒かかっていました。

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

詳細レポート

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

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

観測時点のページの全448リソースのうち、サードパーティータグ由来のリソースは205件（約5割）、ドメイン数にして100ドメインを占めていました。このサイトはライブラリを自社ドメインから配信しており、Webフォントも使っていないため、205件はすべてタグ系のリソースです。

HTMLに直接記述されていたタグは、次の5つでした。

Google Tag Manager を経由して読み込まれていたタグは次のとおりです。このコンテナだけで90ドメイン・195リソースが連鎖的に読み込まれていました。

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

FCP と LCP に変化が表れたのは、Yappli SDK を除去した段階でした。転送量は3KB程度と小さなタグですが、</head> より前に async と defer のどちらも付けずに置かれていたため、読み込みが終わるまで後続のHTMLの解析が止まっていました。SI が9.4秒から0.8秒へと大きく変化したのは、Google Tag Manager を除去した段階です。

サードパーティータグを全て除去した状態では、総合スコア は72から81へ、SI は9.4秒から0.8秒へと変化し、転送量は14.64MBから10.32MBへ減る結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。一方で、TBT と CLS はタグの除去ではほとんど変化せず、ページ自身に原因があることも分かりました。

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

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

ボトルネック1: カート合計金額の取得が同期通信 ​

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

観察された状況 ​

サードパーティータグの除去と CLS の対処を終えた時点でも、TBT は497ms残っていました。ブラウザのトレースで50msを超えるタスクを探すと、該当するのは547msのタスク1本だけでした。2位以下のタスクはいずれも16ms未満です。

このタスクの中身は、カート内の商品点数と合計金額をサーバーから取得する処理でした。jQueryの $.ajax に async: false を指定した同期通信で、サーバーの応答（約540ms）を待つ間、メインスレッドがそのまま止まっていました。TBT は「50msを超えた分の合計」なので、547msから50msを引いた497msは、Lighthouse が報告した TBT と一致します。TBT の全量が、この1か所の同期通信で説明できることになります。

Lighthouse の診断では、この時間はjQuery本体の実行時間として計上されていました。実際にはJavaScriptの計算ではなく、通信の応答待ちでした。

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

通信を async: true の非同期通信に変え、応答を受け取った後の処理をコールバックから呼ぶ形にしました。表示の判定ロジックや処理の順序は変えず、実行のタイミングだけを変えています。

シミュレーション結果 ​

async: false という指定1つで、TBT の全量が生まれていたことが分かります。解消後は50msを超えるタスクがなくなり、総合スコア は100に達しました。本研究のシミュレーションの中で、総合スコア の変化が最も大きかったボトルネックです。

ボトルネック2: JavaScriptの初期化後にしか一致しないCSSセレクタ ​

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

観察された状況 ​

CLS 0.163は、1回のレイアウトのずれだけで生じていました。ずれていたのは、メインビジュアルの直下にあるサムネイルのスライダーです。トレースでは、スライダーの上端が10px下がり、高さが20px縮んでいました。

原因は common.css にある次のようなセレクタでした。

.swiper-container.thumbs-slider.swiper-container-initialized.swiper-container-horizontal.swiper-container-thumbs {
  padding: 10px 0;
}

swiper-container-initialized などのクラスは、スライダーのライブラリ（Swiper）がJavaScriptでの初期化時に付けるものです。そのため、このルールは初期化までは一致せず、初期化の瞬間に上下10pxの余白が突然加わります。これがレイアウトのずれとして記録されていました。

Lighthouse は原因として「画像のサイズ指定がないこと」を挙げていましたが、画像に width と height を付けるシミュレーションでは CLS は変化しませんでした。

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

セレクタから、JavaScriptが付けるクラスを外しました（.swiper-container.thumbs-slider）。CSSを読み込んだ時点で余白が決まる形です。スマートフォン用のメディアクエリにある同様のルールも同じように変更しました。

シミュレーション結果 ​

CSSのセレクタ1つで、CLS の約9割が生まれていたことが分かります。残る0.020も同じスライダーによるもので、サムネイルの格子をCSSで固定し、スライダー用のCSSを <head> へ移すシミュレーションで0.000になりました。

ボトルネック3: 画像203枚をすべて即時にダウンロード ​

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

観察された状況 ​

HTMLには loading="lazy" の指定が1件もなく、JavaScriptによる遅延読み込みも使われていませんでした。203枚の画像は、HTMLの受信直後、わずか1.2msの間でまとめてリクエストされていました。

実際のブラウザで各画像の表示位置を調べると、初期画面に見えているのは10枚だけでした。

画像の総量の93.6%にあたる177件・約8.0MBが、見えないまま最初にダウンロードされていたことになります。LCP の対象であるメインビジュアルの1枚目も、この一斉のリクエストの中に埋もれていました。

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

初期画面の外にある画像と、表示されない画像の177件に loading="lazy" を付けました。初期画面の10件には loading="eager" を明示しています。スクロールしたときに画像の表示が後から始まることを前提としたシミュレーションです。

シミュレーション結果 ​

最初のダウンロードの量は6.17MB（73.3%）減り、LCP と FCP はどちらも3割以上短くなる結果が得られました。すでに 総合スコア が100に達した後の段階でも、見えない画像が初期表示の帯域を奪っていたことが、このシミュレーション結果から読み取れます。

なお、この後の段階で、メインビジュアルのスライダー（Swiper）が既定の設定で画像を先に読み込み、loading="lazy" を打ち消していたことも見つかっています。

まとめ ​

ヒラキ公式通販サイトのトップページを観測したところ、総合スコア は72で、SI・TBT・CLS の3つの指標が足を引っ張っていました。それぞれの原因は、次のようにほぼ1か所に集中していました。

• サードパーティータグ（205リソース・100ドメイン）: Google Tag Manager の除去で SI が9.4秒から0.8秒へ変化しました。転送量3KB程度の Yappli SDK も、同期読み込みのために FCP を遅らせていました。
• カート合計金額の同期通信: TBT 497msの全量を生んでいました。非同期にするシミュレーションで 総合スコア は87から100へ変化しました。
• JavaScriptの初期化に依存するCSSセレクタ: CLS 0.163の約9割を生んでいました。
• 画像203枚の一斉ダウンロード: 177件・約8.0MBの見えない画像が最初に読み込まれていました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は72から100へ、SI は9.4秒から0.5秒へ変化しました。

一方で、Lighthouse のスコアには表れないボトルネックも観測されました。最も大きかったのはHTMLのサーバー応答時間（591ms）です。200msに短縮するシミュレーション（FCP と LCP の各段階で1回ずつ）では、実測の FCP が0.74秒から0.34秒へ、実測の LCP が0.78秒から0.39秒へと変化しました。この時点の実測 LCP の7割以上がサーバー応答の待ち時間で、フロントエンド側の解消シミュレーションを重ねてもその割合はほとんど変わりませんでした。HTMLに付いた cache-control: no-store のために、ブラウザの「戻る」操作でも毎回ページを読み込み直しており、戻る操作にかかる時間は、この指定を外すシミュレーションで757msから55msへと変化しています。スコアが100に達した後も、表示速度を左右する要因が残っていたことが確認できた形です。