「キューサイ」トップページの表示速度ボトルネック研究
PC用キービジュアル画像が常にダウンロードされる、CSSが別ドメインから配信されている、Google Fontsの日本語Webフォント読み込みなどのボトルネックが観測され、これらを解消するシミュレーションではLighthouseスコアが77から最大100まで変化する結果が得られました。Core Web Vitalsの大きな改善が期待できます。
詳細レポート 
ボトルネック一覧 
差分リポジトリ 
青汁やコラリッチなどのスキンケア商品、健康食品を販売するキューサイの公式オンラインストアです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。
| 観測時点 | 全ボトルネック解消シミュレーション後 |
|---|---|
 |  |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 77 | 100 | +23 |
LCP | 4.8秒 | 1.4秒 | -3.4秒 |
FCP | 2.6秒 | 0.8秒 | -1.8秒 |
SI | 4.1秒 | 1.9秒 | -2.2秒 |
TBT | 32ms | 0ms | -32ms |
CLS | 0.001 | 0.000 | -0.001 |
総合スコア が77から100へと23ポイント変化するというシミュレーション結果が得られました。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が4.8秒から1.4秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が2.6秒から0.8秒へと大きな変化が観測されており、これらの指標に強く影響するボトルネックが存在していたことが読み取れます。
読み込みプロセスの変化を動画で体験
本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見て取れます。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。
オリジナルの全415リソースのうち、53.3%にあたる221件がサードパーティタグです。ページが読み込むリソースの過半数をサードパーティタグが占めており、ネットワーク帯域とメインスレッドの双方に大きな負荷を与えています。
導入されているサードパーティータグ
本サイトでは合計221件のサードパーティーリソースが読み込まれていました。
HTMLから直接読み込まれているタグ
| タグ名 | 種別 |
|---|---|
Google Tag Manager | タグ管理 |
New Relic APM | パフォーマンス監視 |
IM Apps DMP | データマネジメント |
Treasure Data SDK | データ収集 |
AD EBiS | 広告効果測定 |
Poplink / Popfind | サイト内検索・ポップアップ |
GTM経由で読み込まれているタグ
| タグ名 | 種別 |
|---|---|
Google Analytics | アクセス解析 |
Google Ads | 広告計測 |
Repro Booster | 高速化プロキシ |
Geniee Search | サイト内検索 |
LINE Tag | 広告計測 |
Flipdesk | Web接客 |
SiTest | ヒートマップ・分析 |
awoo | AI推薦 |
TikTok Pixel | 広告計測 |
Bing Ads | 広告計測 |
Yahoo Ads | 広告計測 |
Twitter/X Ads | 広告計測 |
SmartNews Ads | 広告計測 |
ONE's Data | データ収集 |
CPA Crowd | 広告計測 |
段階的除去シミュレーションの結果
| 除去段階 | 除去対象 | 総合スコア | LCP | FCP | TBT |
|---|---|---|---|---|---|
| 観測時点 | - | 77 | 4.8秒 | 2.6秒 | 32ms |
| 第1段階 | Repro Booster | 70 | 7.2秒 | 2.5秒 | 32ms |
| 第2段階 | New Relic APM | 66 | 8.5秒 | 3.2秒 | 34ms |
| 第3段階 | Geniee Search + IM Apps DMP + Treasure Data | 77 | 5.1秒 | 1.9秒 | 70ms |
| 第4段階 | GTM + Google Analytics + Google Ads | 70 | 11.7秒 | 2.0秒 | 35ms |
| 第5段階 | 残存タグ一括 | 71 | 9.7秒 | 1.8秒 | 0ms |
| 第6段階 | AD EBiS + Poplink/Popfind | 73 | 8.2秒 | 2.0秒 | 0ms |
途中段階で LCP が大きく悪化していますが、これはRepro Boosterのプロキシキャッシュ機能が除去されたことによるものです。サイト自体のボトルネック解消シミュレーションを経た最終的な LCP は1.4秒まで短縮されています。
サードパーティータグを全て除去した状態では、TBT が32msから0msに完全解消し、FCP が2.6秒から2.0秒に短縮される結果が得られました。特に IM Apps DMP と Treasure Data SDK はHTMLの <head> 内に同期的に読み込まれていたため、レンダリングを直接ブロックしており、この2つの除去だけで FCP が3.2秒から1.9秒へ大きく変化しました。サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。
サイト固有のボトルネック
サードパーティータグの影響を排除した上で、サイト固有のボトルネックを観察しました。全17件のボトルネック仮説を検証した中から、特に影響の大きかった3件を紹介します。
ボトルネック: PC用キービジュアル画像が常にダウンロードされる
観察された状況
キービジュアルスライダーの各スライドに、PC用とスマートフォン用の2つの <img> 要素が配置されていました。CSSの display:none クラスによる表示切替が行われていたため、モバイル環境でも非表示のPC用画像5枚（合計約2,499KB）がダウンロードされていました。これにより、LCP要素の読み込みに使える帯域幅が圧迫されている状態が観測されました。
解消シミュレーションの方法
CSSによる表示切替を <picture> 要素とメディアクエリに置き換え、デバイスに応じた画像のみがダウンロードされるようにしました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 73 | 94 | +21 |
LCP | 13.5秒 | 3.0秒 | -10.5秒 |
SI | 3.8秒 | 2.4秒 | -1.4秒 |
| 解消前 | 解消後 |
|---|---|
 |  |
LCP が13.5秒から3.0秒へと10.5秒短縮されるという、本研究で最も大きな変化が観測されました。CSSの display:none は要素を非表示にするだけで、ブラウザによるダウンロードは止められないという性質が、モバイル環境で大きなボトルネックとなっていたことがこの結果から読み取れます。
ボトルネック: CSSが別ドメインから配信されている
観察された状況
サイトで使用されている6つのCSSファイルが、HTMLとは異なるドメイン（d2w53g1q050m78.cloudfront.net）から配信されていました。CSSはレンダリングブロッキングリソースであり、その取得に外部ドメインへのDNS解決・TCP接続・TLSハンドシェイクが必要な状態が観測されました。
解消シミュレーションの方法
6つのCSSファイルをHTMLと同一のドメイン（www.kyusai.co.jp）から配信されるように変更しました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 74 | 80 | +6 |
FCP | 2.5秒 | 1.5秒 | -1.0秒 |
LCP | 6.5秒 | 5.1秒 | -1.4秒 |
| 解消前 | 解消後 |
|---|---|
 |  |
CSSをHTMLと同一ドメインから配信するだけで、FCP が約1秒短縮される結果が得られました。CSSはレンダリングブロッキングリソースであるため、その取得にかかる接続コストの差がそのまま描画開始時間に影響していたことが分かります。
ボトルネック: Google Fontsの日本語Webフォント読み込み
観察された状況
Google Fontsから3種類のWebフォント（Zen Kaku Gothic New、Parkinsans、Noto Sans JP）が読み込まれていました。特に日本語フォントであるZen Kaku Gothic Newは文字数の多さから60個のwoff2ファイルに分割されており、合計63リソース・約636KBの転送が発生していました。このシミュレーションはフォントの見た目が変わることを前提に行いました。
解消シミュレーションの方法
Google Fontsの読み込みを全て除去し、システムフォント（sans-serif）にフォールバックさせました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
総合スコア | 99 | 100 | +1 |
FCP | 1.4秒 | 0.8秒 | -0.6秒 |
LCP | 1.8秒 | 1.4秒 | -0.4秒 |
SI | 2.3秒 | 1.9秒 | -0.4秒 |
| 解消前 | 解消後 |
|---|---|
 |  |
Google Fontsを読み込む場合、fonts.googleapis.com と fonts.gstatic.com という2つの外部ドメインへの接続が必要であり、そこから63件のリソースをダウンロードする処理が発生します。日本語Webフォントは英語フォントと比べて文字数が桁違いに多く、データ量が大きいという特性があります。デザインとしてWebフォントを使いたい理由は理解できますが、FCP が0.6秒短縮されるというシミュレーション結果から、日本語Webフォントが表示速度に与えている影響の大きさが読み取れます。
まとめ
本研究では、キューサイ公式サイトのトップページにおける表示速度のボトルネックを観察しました。
最も大きな影響が観測されたのは、CSSの display:none によるPC用/スマートフォン用画像の切替でした。モバイル環境で不要なPC用画像が常にダウンロードされることで、LCP が10秒以上押し上げられていたことがシミュレーション結果から立証されました。
CSSの外部ドメイン配信も FCP に約1秒の影響を与えており、レンダリングブロッキングリソースの取得先が表示開始時間に直結するという事実が確認されました。
Google Fontsによる日本語Webフォントの読み込みは63リソース・約636KBの転送を伴い、FCP を0.6秒押し上げる要因となっていました。日本語フォント特有のデータ量の大きさが表示速度に影響している様子が読み取れます。
これらのボトルネックを含む全11件の解消シミュレーションにより、総合スコア は77から100へ、LCP は4.8秒から1.4秒へ変化する結果が得られました。
