「デンタルフィット」トップページの表示速度ボトルネック研究

石川県能美市に拠点を置く、歯科医院専売品の通販サイトです。歯ブラシや歯磨き粉、歯間ブラシ、デンタルフロス、洗口液といったオーラルケア用品を中心に、歯科医師と歯科衛生士がチームを組んで開発した商品も取り扱っています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア は79から100へ、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は4.9秒から0.1秒へと変化するシミュレーション結果が得られました。SI（Speed Index = ビューの視覚的な表示進捗の速さ）も4.1秒から1.8秒へ短縮されています。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）、TBT（Total Blocking Time = メインスレッドのブロック時間）、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は、観測時点から良好な値でした。

なお、今回の Lighthouse の計測は、記録したページを再現した環境で、通信遅延・帯域・CPU性能の制限を加えずに行っています。そのため LCP や FCP は実際の閲覧環境より小さく出ます。解消シミュレーション後の LCP 0.1秒は、この計測条件での値です。実際の閲覧環境に近い値として、ヘッドレスChromeでページを読み込んだ実測値や、CPUを低速化した条件での値も補助的に計測しました。

Slow 4G相当は、RTT 150ms・1.6Mbpsの低速なモバイル回線を想定した条件です。Lighthouse のスコアの頭打ち後も、低速な回線では LCP の値は大きく変化しており、回線が遅いほど今回のボトルネックの影響は大きく表れることが読み取れます。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画の計測では、転送量は1.89MBから0.31MBへ、読み込み完了までの時間は3.09秒から1.17秒へと変化しました。

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

詳細レポート

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

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

オリジナルページの全94リソースのうち、サイト固有のリソースは70件（約7.5割）、サードパーティタグ由来のリソースは24件（約2.5割）を占めていました。タグは4種類ですが、Microsoft Clarity と Google Analytics 4 はHTMLへの直書きと Google Tag Manager 経由の両方で読み込まれる二重設置になっていました。

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

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

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

サードパーティータグを全て除去した状態では、総合スコア は79から97へ変化し、LCP は4.9秒から2.5秒へ、SI は4.1秒から2.1秒へ短縮される結果が得られました。TBT は除去の前後とも0msで、これらのタグはメインスレッドを占有するのではなく、LCP 画像と同じ時間帯に通信帯域を消費することで表示を遅らせていました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

このページのボトルネックの多くは、Lighthouse のスコアが100近くに達したあとの段階で見つかっています。そのため、各ボトルネックの影響は Lighthouse の値に加えて、ヘッドレスChromeで計測した実測値（回線制限なし、およびSlow 4G相当）でも示します。

ボトルネック1: LCP画像が別ドメインから配信されている ​

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

観察された状況 ​

LCP 要素は、ファーストビューのカルーセル1枚目に表示されるセールのバナー画像（PNG、1080×1350ピクセル）でした。loading="eager" と fetchpriority="high" はすでに指定されており、優先して読み込む設定自体はできていました。

一方で、この画像はHTML（www.dental-fit.com）とは別のドメイン（gigaplus.makeshop.jp、HTTP/1.1）から配信されていました。新しい接続の確立を含めて応答まで約800msかかっており、回線制限なしで実測した LCP の内訳でも、LCP 画像のダウンロードが大半を占めていました。

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

バナー画像をHTMLと同じドメインに置き、すでに確立しているHTMLの接続で取得できるようにした状態を計測しました。画像の内容や、src 以外の <img> の属性は変えていません。

シミュレーション結果 ​

Lighthouse の LCP は0.11秒から0.09秒への小さな変化に留まりましたが、実測の LCP は回線制限なしで1.3秒から0.5秒へ、Slow 4G相当で4.4秒から2.9秒へと短縮される結果が得られました。LCP 画像そのものには手を加えず、配信元のドメインを変えただけのシミュレーションです。回線制限なしの実測では、別ドメインへの接続確立の待ちが LCP の半分以上を占めていたことが読み取れます。

ボトルネック2: カルーセルのCSSが別ドメインから配信されている ​

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

観察された状況 ​

カルーセルに使われているライブラリ Swiper の CSS（swiper-bundle.min.css）は、<head> で読み込まれるレンダリングブロックリソースです。この CSS も LCP 画像と同じ別ドメイン（gigaplus.makeshop.jp）から配信されていました。他の CSS 4本は読み込み開始から約50msで届いていたのに対し、この1本だけが約850ms後に届き、その間ブラウザは画面を一切描画できない状態でした。Lighthouse の「レンダリングを妨げるリソースの除外」でも、最大の要因として指摘されていたリソースです。

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

CSS ファイルをHTMLと同じドメインに置き、読み込み先のURLだけを変えた状態を計測しました。CSS の中に相対パスで参照するリソースがないことを確認したうえで、内容は変更していません。

シミュレーション結果 ​

Lighthouse の FCP は0.09秒から0.06秒へと変化し、レンダリングを妨げるリソースの指摘がなくなりました。実測では、回線制限なしで1.3秒から0.5秒へと、描画の開始が約0.8秒早まる結果が得られています。この0.8秒は、別ドメインへの接続確立にかかっていた時間とほぼ一致します。わずか1本の CSS の配信元が、ページ全体の初回描画を待たせていたことが読み取れます。

このページでは、同じ別ドメインからSwiperの JavaScript も同期読み込みされており、HTMLの解析を止めていました。こちらを同一ドメインから配信するシミュレーションでも、Slow 4G相当の実測 FCP が2.4秒から1.4秒へと約1秒短縮されています。

ボトルネック3: 画面外の画像がLCP画像と同時に読み込まれている ​

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

観察された状況 ​

ファーストビューの外にある商品画像20枚、セールカレンダーの画像、サイドナビの画像などが、ページの読み込み直後に LCP 画像と同時にダウンロードされていました。スマートフォンでは「もっと見る」を押すまで表示されないカテゴリアイコン6枚も含まれていました。Slow 4G相当の実測では LCP が7.8秒まで遅れ、LCP 画像のダウンロードが終わるまでの間に、ほかの画像44枚・約1.28MBが並行してダウンロードされていました。

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

ファーストビューの外にある31箇所の <img> に loading="lazy" を付与し、表示位置に近づくまで読み込みを遅らせた状態を計測しました。スクロールや商品リストの横スワイプで画像が表示位置に来たとき、正しく読み込まれることも確認しています。

シミュレーション結果 ​

Lighthouse の LCP は1.6秒から0.9秒へ、Slow 4G相当の実測 LCP は7.8秒から5.7秒へと、約2秒短縮される結果が得られました。回線制限なしの実測で変化がないのは、帯域に余裕がある条件では画像どうしの帯域の奪い合いが起きないためです。属性を1つ加えただけのシミュレーションで、帯域の限られた環境ほど大きな変化が表れたことから、画面外の画像の一斉読み込みが LCP 画像の帯域を奪っていた影響の大きさが読み取れます。

このページではさらに、カルーセルのライブラリが初期化時に2枚目以降のスライド画像9枚（約490KB）を先読みしていました。この先読みを止めるシミュレーションでも、Slow 4G相当の実測 LCP が5.7秒から4.5秒へと約1.2秒短縮されています。

まとめ ​

デンタルフィットのトップページでは、LCP 画像の優先度指定はすでに行われていた一方で、LCP 画像が取得される経路と、同時に流れる通信の量に次のようなボトルネックが観測されました。

• サードパーティータグ（24リソース）: 除去によって 総合スコア が79から97へ、LCP が4.9秒から2.5秒へ変化。Microsoft Clarity と Google Analytics 4 の二重設置を含むタグが、LCP 画像と同じ時間帯に帯域を消費していました。
• 別ドメインから配信されるLCP画像: 同一ドメインからの配信に置き換えることで、実測 LCP が回線制限なしで1.3秒から0.5秒へ変化。回線制限なしの実測では、接続確立の待ちが LCP の半分以上を占めていました。
• 別ドメインから配信されるカルーセルのCSS: 同一ドメインからの配信に置き換えることで、実測 FCP が回線制限なしで1.3秒から0.5秒へ変化。1本の CSS が初回描画を約0.8秒待たせていました。
• LCP画像と同時に読み込まれる画面外の画像: 遅延読み込みにすることで、Slow 4G相当の実測 LCP が7.8秒から5.7秒へ変化。帯域の限られた環境ほど影響が大きく表れました。

この他にも、LCP 画像をWebPに変換するシミュレーションではSlow 4G相当の実測 LCP が2.9秒から1.5秒へ、表示サイズに合った600px版を配信するシミュレーションでは1.5秒から1.0秒へと短縮される結果が得られています。全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は79から100へ、Slow 4G相当の実測 LCP は LCP 関連の検証開始時の7.8秒から0.8秒へと変化しました。

なお、HTML本体のサーバー応答時間（約380ms）はフロントエンドの変更では短縮できないため、今回のシミュレーションには含めていません。最終状態では、回線制限なしの実測 LCP（約0.5秒）の大部分をこの応答時間が占めており、実際のユーザーの体感速度を左右する要因として残っていることが観測されました。