「こだわり安眠館」トップページの表示速度ボトルネック研究

「こだわり安眠館」は、高橋ふとん店が運営する寝具の公式通販サイトです。「ねごこち本舗」からリニューアルしたサイトで、羽毛布団やマットレス、枕、毛布、カバーなど、西川をはじめとする寝具を幅広く扱い、土日祝日の即日発送や会員向けのセールを打ち出しています。スマートフォンでトップページを開くと、会員限定セールなどのバナーが自動で切り替わるメインビジュアル、商品カテゴリのアイコン、ランキングや動画、お客様レビュー、読みものの一覧が縦に長く並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は80でした。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）はともに2.5秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は9.5秒、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.134でした。TBT（Total Blocking Time = メインスレッドのブロック時間）は、観測時点から全シミュレーションを通じて0msでした。

解消シミュレーション後の SI 0.3秒には、メインビジュアルの自動再生を止めるシミュレーションが含まれています。メインビジュアルが4秒ごとに切り替わり続けると、計測の最後まで画面が変化し続けるため、SI が大きく評価されます。自動再生を残した状態での SI は2.3秒でした。

また、計測に使用したヘッドレスのChromeでは、FCP が約0.4秒・1.5秒・2.5秒の段階的な値になりやすい傾向がありました。観測時点の FCP 2.5秒にはこの傾向の影響が含まれますが、各シミュレーションの前後比較は同じ環境で行っています。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感でも違いがはっきり分かります。動画は左が観測時点、右が解消シミュレーション後です。

動画の上部に表示されているとおり、ページの読み込みに伴う転送量は22.82MBから2.35MBへ、読み込み完了までの時間は18.98秒から2.05秒へ変化しました。

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

詳細レポート

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

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

観測時点のページの全404リソースのうち、サードパーティータグ由来のリソースは105件（約3割） でした。なお、公開CDNから読み込まれていたjQuery・Swiper・AOSとGoogle Fontsは、サードパーティータグには含めず、サイト固有のリソースとして扱っています。

導入されているタグ ​

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

変化が大きかったのは Microsoft Clarity の除去で、SI が8.2秒から4.1秒へ、総合スコア が81から86へ変化しました。スクリプト自体は約28KBと小さいものの、ページ全体の構造を記録し続けるタイプのツールです。次いで、ECプラットフォームに組み込まれ head 内で同期読み込みされていた New Relic Browser の除去で、SI が9.5秒から8.2秒へ変化しています。

サードパーティータグを全て除去した状態では、総合スコア は80から87へ、SI は9.5秒から4.1秒へ変化しました。一方で LCP・FCP（2.5秒）と CLS（0.134）はほとんど変わらず、これらはサイト自体の構成に起因するものでした。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルのあることが読み取れます。

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

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

ボトルネック1: 別ドメインのCSS 5本が最初の描画を待たせる ​

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

観察された状況 ​

HTML自体は約0.24秒で届いていましたが、最初の描画の前に、レンダリングをブロックする5本の CSS の到着を待つ必要がありました。5本のうち4本は画像なども配信している静的ファイル用のドメイン（futonten.itembox.cloud）から、1本はカルーセルのライブラリSwiperの CSS として公開CDN（cdn.jsdelivr.net）から配信されていました。

5本の合計は約309KBで、その大半はトップページでは使われていない共通のスタイルでした。ECプラットフォームの共通 CSS（fs_style.css）は99%、テーマの CSS（fs_original.css）は79%が未使用です。最後の1本が届くのは約0.5秒の時点で、最初の描画の機会に間に合わず、計測環境では FCP が約2.5秒まで後ろへずれていました。

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

CSS を段階的に整理しました。まず5本を HTML と同じドメイン（www.futonten.co.jp）から配信し、次に1本に結合しました。続いて、3つの画面幅と9つの表示状態のページと照合し、どの状態でも使われない規則を削除しました（309KB→102KB）。最後に、残った CSS を HTML の <style> 要素に埋め込み、CSS を取りに行く往復そのものをなくしました。全要素の計算済みスタイルを比較し、見た目に差がないことを確認しています。

シミュレーション結果 ​

同一ドメイン化・結合・未使用規則の削除の各段階では、FCP はほとんど動きませんでした。接続の確立が省けても、各ファイルのサーバー応答（約0.2秒）と取得の往復が残るためです。CSS を HTML に埋め込んだ段階で、FCP は2.4秒から0.4秒へ一気に変化し、3回の計測とも0.38秒前後で安定しました。

このシミュレーション結果から、別ドメインから配信される5本の CSS が、このページの最初の描画を待たせていた最大のボトルネックであったことが読み取れます。

ボトルネック2: カルーセルのスライド付け替えがずれとして計上される ​

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

観察された状況 ​

CLS 0.134の発生源はページの読み込み中ではなく、読み込みから約11秒後のメインビジュアルでした。カルーセルのライブラリSwiperは、ループ表示（loop モード）のために、端に近づくとスライドの要素を先頭と末尾の間で付け替え、transform で見た目の位置を補正します。画面上は何も動いていないように見えるものの、Chromeは各スライドの配置が1枚分（375px）移動したとみなし、レイアウトのずれとして計上していました。

このずれは4秒周期の自動再生の3回目以降、切り替えのたびに発生していました。Lighthouse の計測に限らず、実際の利用者がページに滞在している間にも加算されうるものです。

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

メインビジュアルの各スライドに will-change: transform を指定する1行を加え、スライドを独立した描画レイヤーとして扱わせました。transform の値自体は指定していないため、ループ表示や左右のスライドの見え方、自動再生の動きは変わりません。

シミュレーション結果 ​

CSS を1行加えるだけのシミュレーションで、CLS は「改善が必要」の範囲から0.000になりました。カルーセルの初期化前後の配置の違いや、アイコンフォント到着前の文字列の広がりなど、読み込み中のずれもあわせて観測されましたが、それらは Lighthouse の CLS を動かしていませんでした。このシミュレーション結果から、表示中に動き続けるカルーセルが、このページの CLS を押し上げていたボトルネックの正体であったことが読み取れます。

ボトルネック3: LCP画像が高品質JPEGで252KB ​

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

観察された状況 ​

LCP の要素はメインビジュアルの1枚目にある会員限定セールのバナー画像（スマートフォン用の sale-sp.jpg）です。画像は1300×975pxで、品質91のJPEGとして保存されたファイルが252KBありました。CSS の埋め込みとスクリプトの移動を経て、最初の描画は約0.3秒で行われるようになりましたが、そこから LCP までの約0.27秒の大半を、この画像の転送（約235ms）が占めていました。

CSS の段階を終えた後のページは LCP が0.6秒未満と速いため、このボトルネックの指標は小数点第2位まで示します。

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

バナー画像を、非可逆のWebP（品質75）に変換しました。ファイルサイズは252KBから72KBになっています。「会員限定SALE」「10%OFF」といった文字の周囲を拡大して比較し、目立つ劣化がないことを確認しました。

シミュレーション結果 ​

画像の転送時間が約235msから約69msへ短くなり、LCP が約3割変化しました。続けて、画面の表示サイズに合わせた幅720pxのWebP（34KB）を srcset で選ばせるシミュレーションでは、LCP は0.35秒になっています。このシミュレーション結果から、高品質のまま保存された1枚のバナー画像が、LCP を遅らせていたボトルネックであったことが読み取れます。

ボトルネック4: Webフォントだけで約8MB ​

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

観察された状況 ​

ここまでのシミュレーションで 総合スコア は100に達していましたが、ページの総転送量は依然として10MBを超えており、その大半がWebフォントでした。

• アイコンフォント: Google Fontsの Material Symbols Outlined は全アイコンを収録した約4.00MBのフォントでした。ページで使われていたアイコンは14種類です
• 和文フォント: 自社配信のNoto Sans JPが4ウェイトで、各約1MB、合計約3.96MBありました

観測時点では、和文フォントの preload と @font-face でURLのクエリが食い違っていたため、同じ4本（約4MB）を二重に取得してもいました。和文フォントは字形の数が多く、欧文のフォントと比べてファイルサイズが桁違いに大きくなります。読みやすさやブランドの印象を整えるために和文Webフォントを使いたい事情は理解できるものですが、ここではその転送量の大きさを数値として示します。

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

アイコンフォントを使用する14アイコンだけに絞り、和文フォントをページに使われる文字を含む3,739字に絞りました。最後にGoogle Fontsと和文Webフォントの読み込みをやめ、アイコンは同じ字形のSVGへ、文字は端末に内蔵されたフォントへ置き換えています。最後の段階はフォントの見た目が変わることを前提としたシミュレーションで、画面下部の固定ボタンの文言が2行に折り返すといった変化が観測されました。

シミュレーション結果 ​

「和文フォントを使用文字に絞る」と最後の段階の間には、他のシミュレーションによる総転送量の変化も含まれます。LCP・FCP・SI は各段階で計測の揺らぎの範囲にとどまりました。Lighthouse の計測条件では、フォントの到着がファーストビューの表示を待たせていなかったためです。読み込み完了までの時間はWebフォントをやめる2段階で約0.70秒から約0.48秒へ変化しました。

指標の値には表れなかったものの、このシミュレーション結果から、Webフォントがページの転送量の大半を占めるボトルネックであったことが読み取れます。通信量の多いモバイル回線では、この差が体感に表れうる大きさです。

まとめ ​

こだわり安眠館のトップページの表示速度を観測したところ、総合スコア 80、LCP・FCP 2.5秒、SI 9.5秒、CLS 0.134という値が計測されました。

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

• サードパーティータグ（8種類・105リソース）: 全て除去した状態では SI が9.5秒から4.1秒へ変化しました。その大半は Microsoft Clarity と New Relic Browser によるものでした。
• 別ドメインのCSS 5本: 同一ドメイン化・結合・未使用規則の削除を経て HTML に埋め込むことで、FCP が2.5秒から0.4秒へ変化しました。各段階では効果が見えにくく、往復をなくした段階でまとめて表れています。
• カルーセルのスライド付け替え: スライドを独立した描画レイヤーとして扱わせる1行で、CLS が0.134から0.000へ、総合スコア が87から92へ変化しました。
• LCP画像の高品質JPEG: WebPへの変換で、LCP が0.56秒から0.39秒へ変化しました。
• Webフォント: アイコンフォントと和文フォントで約8MBあり、絞り込みと置き換えで、ページの総転送量が10.21MBから2.10MBへ変化しました。

このほか、head と body の途中で同期読み込みされていたスクリプトを </body> の直前へ移すシミュレーションでは、FCP が0.4秒から0.3秒へ変化しました。全ボトルネックを解消した後も、FCP・LCP の約8割はHTMLのサーバー応答時間（約0.24秒）が占めています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は80から100へ、FCP・LCP は2.5秒から0.3秒へ、CLS は0.134から0.000へと変化しました。最初の描画を待たせていた CSS の配信構造と、表示中に動き続けるカルーセルが、このページの指標を大きく押し下げていたことが、この一連のシミュレーションによって読み取れます。