「ヤーマンオンラインストア」トップページの表示速度ボトルネック研究

美容機器メーカー、ヤーマン（YA-MAN Ltd.）の公式通販サイトです。美顔器やヘアケア機器などの美容機器と化粧品を扱い、トップページにはキャンペーンのメインビジュアル、ブランド一覧、トピックス、カテゴリー、新商品やランキングの商品スライダー、フッターの営業日カレンダーなどが並んでいます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。計測は Lighthouse のモバイル条件（回線速度の制限をシミュレーションし、CPUの処理速度は制限しない設定）で行っています。

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

総合スコア は79から100へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は5.9秒から0.4秒へと変化するシミュレーション結果が得られました。観測時点で 総合スコア を押し下げていたのは、5.9秒かかっていた SI と、Googleの「良好」の基準である0.1を大きく超えていた CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）の0.271です。TBT（Total Blocking Time = メインスレッドのブロック時間）は141msでした。

LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は、観測時点でもそれぞれ0.9秒と0.6秒でした。解消シミュレーション後の0.1秒は Lighthouse の推定値で、描画を妨げる別ドメインのリソースがなくなると、推定にHTMLのサーバー応答時間がほとんど含まれなくなります。そこで本研究では、ブラウザのトレースから読み取った実際の描画時刻（実測 FCP・実測 LCP）もあわせて記録しています。こちらは約0.3秒の短縮にとどまりました。

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

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

観測時点では、ページが表示された後もサードパーティタグの読み込みが長く続いていました。

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

詳細レポート

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

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

観測時点のページの全404リソースのうち、サードパーティタグ由来のリソースは188件（約5割）を占めていました。HTMLには3つの Google Tag Manager コンテナが直接書かれており、そのうちの1つは同一ドメイン経由と googletagmanager.com 経由の二重で読み込まれていました。

HTMLから直接読み込まれているタグ ​

Google Tag Manager経由で読み込まれているタグ ​

除去シミュレーションの結果 ​

サードパーティータグを全て除去した状態では、総合スコア は79から86へ、SI は5.9秒から3.0秒へ、TBT は141msから0msへと変化する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

TBT は、広告タグの大半を配信するコンテナを除去した段階で137msから0msへ変化しており、観測時点の TBT のほぼすべてがこのコンテナと配下の126件のリソースに由来していました。SI はタグを除去するたびに段階的に短くなっています。一方、LCP・FCP の変化は小さく、多くのタグが描画の開始後に非同期で動いていたことがうかがえます。なお、このページの CLS は同じ状態でも0.271と0.207の間で揺らいでおり、途中の 総合スコア の上下はこの揺らぎによるものです。

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

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

タグを除去した時点の 総合スコア は86で、残る主な減点要因は0.271の CLS でした。そのレイアウトシフトのほぼすべては、ファーストビューにある3つのスライダー（ブランド一覧・メインビジュアル・ヘッダーバナー）が、JavaScriptで初期化される瞬間に高さを変えることで生じていました。1件目と2件目は、このうち影響の大きかった2つのスライダーに関するボトルネックです。

ボトルネック1: ブランド一覧スライダーの初期化前レイアウトが未確定 ​

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

観察された状況 ​

メインビジュアルの下にあるブランド一覧は、スライダーのライブラリ Swiper で横に並べる作りです。初期化前はスライドの幅が width: 100% のままで、しかもロゴ画像6枚には width・height 属性がありませんでした。そのため、読み込み中に高さが2段階で変わっていました。

1. ロゴ画像が届くと、1枚のロゴが画面幅いっぱいに表示され、高さが0pxから約165pxへ伸びる
2. Swiper が初期化されて2.6枚並びになると、高さが約61pxへ縮む

この伸び縮みのたびに、直下の検索エリアから下のコンテンツが上下に動いていました。CLS 0.271の約半分を占める最大の要因です。

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

ロゴ画像に実寸の width・height 属性を付け、Swiper の初期化前だけに効く :not(.swiper-initialized) のCSSで、初期化後と同じスライド幅と余白を再現しました。初期化後の見た目は変わりません。

シミュレーション結果 ​

CLS は0.271から0.079へ、総合スコア は86から97へと変化するシミュレーション結果が得られました。それまでの「0.271と0.207の間の揺らぎ」もなくなり、2回の計測とも同じ値になっています。ブランド一覧という1つの部品の初期化が、このページのレイアウトシフトの半分以上を生んでいたことが読み取れます。

一方で LCP は0.7秒から1.8秒へと遅くなりました。それまでは画面幅いっぱいに引き伸ばされたブランドロゴがページ内で最も大きな要素となり、LCP の対象になっていたと考えられます。ロゴが本来の大きさで表示されるようになると、LCP の対象は、スライダーの初期化まで opacity: 0 で隠されるヘッダーバナー画像に移りました（画像が届いてから表示されるまでの待ちは約0.79秒）。それまでの LCP の速さは、不安定なレイアウトに支えられた見かけ上の値だったことになります。メインビジュアルも同じ作りで隠されており、これが次のボトルネックです。

ボトルネック2: 初期化まで隠されたメインビジュアル ​

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

観察された状況 ​

スマートフォン用のメインビジュアルは、スライダーのライブラリ slick で、左右に前後のスライドが少しのぞく表示（centerMode）を作っています。初期化前は1枚目だけが画面幅いっぱいに表示され、下に70pxの余白があり、しかも opacity: 0 で見えない状態でした。

slick の初期化は、HTMLの解析が終わった後の jQuery の ready で行われます。初期化されると表示が切り替わって高さが250pxに縮み、ブランド一覧から下が約69px上へ移動していました。画像そのものが届いていても、初期化が終わるまでは表示されていませんでした。見た目が崩れないよう初期化前は隠しておく作りは、スライダーでよく見られる自然な工夫です。

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

初期化前から初期化後と同じ寸法・配置になるように、centerMode の見た目を flexbox で再現するCSSを加え、初期化前の opacity: 0 を解除しました。パソコン用のメインビジュアルにも同じ方針のCSSを加えています。スライダーの動きや見た目は変わりません。

シミュレーション結果 ​

LCP は1.8秒から0.7秒へ、CLS は0.079から0.004へと変化し、総合スコア が100に達するシミュレーション結果が得られました。LCP の対象はメインビジュアルの1枚目の画像に替わり、画像が届いてから表示されるまでの待ちは約0.79秒（ヘッダーバナー）から約0.13秒へと短くなっています。

初期化前の配置がCSSで確定していれば、スライダーを隠しておく理由がなくなります。レイアウトシフトと主要コンテンツの表示待ちが、同じ1つの作りから生じていたことが、このシミュレーション結果から読み取れます。残るヘッダーバナーにも同じ考え方を当てはめたシミュレーションでは、CLS は0.000になりました。

ボトルネック3: 描画を止めるGoogle FontsのCSS ​

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

観察された状況 ​

このページは、英字の見出しやタブ、ランキングの順位などに Google Fonts の欧文フォント Montserrat を使っていました。見出しの英字に幾何学的な書体を使いたいという意図は理解できますし、フォントのURLには display=swap も指定されていました。

一方で、フォントを指定するCSSは fonts.googleapis.com から描画をブロックする形で読み込まれていました。公開CDNの同期スクリプトを自社ドメインへ移すなど、FCP に関わるほかのボトルネックを解消していった後に、Lighthouse が描画ブロックとして指摘する最後のリソースとして残ったのがこのCSSです（推定約277msの遅延）。実測でも、最初の描画がこのCSSの読み込み完了（約0.91秒）を待っていました。

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

CSSを media="print" で読み込み、読み込み完了後に media="all" へ切り替える形で、描画をブロックしない読み込みに変更しました。JavaScriptが無効な環境向けに、従来の読み込みも noscript で残しています。フォントは display=swap の指定どおり、代替フォントで先に表示され、届いた後に Montserrat へ差し替わります。

最初にこのシミュレーションを行った際には、パソコンの画面幅で0.0165の新たなレイアウトシフトが現れました。原因はパソコン用のメインビジュアル画像で、width・height 属性の比率（2.47:1）が実際の画像（2.13:1）と16%異なっていたことです。最初の描画が早まると、画像が届く前の状態まで描画されるため、それまで隠れていたずれが表面化していました。属性を実寸の比率に合わせたうえで、改めて計測しています。

シミュレーション結果 ​

Lighthouse の推定する FCP は0.4秒から0.1秒へ、実測 FCP は0.97秒から0.72秒へと変化するシミュレーション結果が得られました。描画を妨げるリソースは0件になり、HTMLを受信し終えてから約80msで最初の描画が行われるようになっています。英字の一部にだけ使われる欧文フォントでも、そのCSSが別ドメインから描画をブロックする形で読み込まれていれば、最初の描画を約0.25秒遅らせていたことが読み取れます。

その後、Google Fonts の読み込み自体をやめて英字を各OSのシステムフォントで表示したシミュレーションでは、LCP が0.13秒から0.08秒へ、実測の読み込み完了が1.38秒から1.20秒へと変化しました。このとき英字見出しなどの字形は変わっています（ファーストビューの画面差分は0.48%）。

まとめ ​

ヤーマンオンラインストアのトップページでは、観測時点の 総合スコア が79でした。LCP・FCP は1秒未満だった一方で、SI が5.9秒、CLS が0.271と大きく、この2つが 総合スコア を押し下げていました。

観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグ（188リソース）: 除去によって 総合スコア が79から86へ、SI が5.9秒から3.0秒へ、TBT が141msから0msへ変化しました。TBT のほぼすべては、広告タグの大半を配信する1つの Google Tag Manager コンテナに由来していました。
• ブランド一覧スライダーの初期化前レイアウトが未確定: ロゴ画像に寸法の属性を付け、初期化後と同じ配置をCSSで再現したシミュレーションでは、CLS が0.271から0.079へ、総合スコア が86から97へ変化しました。
• 初期化まで隠されたメインビジュアル: 初期化前から表示するシミュレーションで、LCP が1.8秒から0.7秒へ、CLS が0.079から0.004へ変化し、総合スコア が100に達しました。
• 描画を止めるGoogle FontsのCSS: 描画をブロックしない読み込みにしたシミュレーションで、実測 FCP が0.97秒から0.72秒へ変化しました。

このほか、ページ最下部の営業日カレンダーを読み込み時に構築していたことも、SI に大きく影響していました。フッターへ近づいたときに読み込むシミュレーションでは、SI が2.7秒から1.3秒へと変化しています。PageSpeed Insights と同じCPU 4倍の低速化をかけた計測では、カレンダーや商品スライダーの初期化などのロングタスクを分割・遅延させると、TBT に相当する値は175msから0msへと変化しました。

一方、全ての解消シミュレーションを終えた後も、HTMLのサーバー応答時間（約0.61〜0.62秒）が残っていました。HTMLはCDNでキャッシュされず、アクセスのたびにサーバーで生成されています。最終状態の実測 FCP（0.68秒）の約9割、実測 LCP（0.73秒）の約84%をこの応答待ちが占めていました。サーバー側の処理であるため本研究のシミュレーションの範囲外ですが、フロントエンドのボトルネックを解消し尽くした後に、このサイトに残る最大のボトルネックとして観測されています。