「ピーチ・ジョン」トップページの表示速度ボトルネック研究

ブラジャーやショーツなどの下着・ランジェリーで知られる PEACH JOHN（ピーチ・ジョン）の公式通販サイトです。ルームウエアやファッション、ビューティー商品まで幅広く取り扱い、人気ランキングやスタッフレビューなど、買い物に役立つ情報も発信しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。計測はモバイル（Moto G Power 相当・低速4G）の条件で行っています。

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

LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は7.7秒から0.1秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は12.3秒から1.7秒へと大きく変化しました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も1.3秒から0.1秒へ変化しています。TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点から70msと小さく、目立った変化は CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）でした。0.682という値は「良好」の目安である0.1の6倍以上にあたり、これが0.000になるシミュレーション結果が得られています。

リソース数は493件から148件へ、Lighthouse が計測した総転送量は636KiBまで減りました。

ただし、総合スコア には HTML の応答時間の差が現れません。このページの HTML は応答に約3.3秒かかっており、スコアが100に達した状態でも、実際のブラウザでは3.3秒間画面が白いままでした。この点はボトルネック3で扱います。

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

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

観測時点のページは白い画面のまま長く待たされ、その後も画像が届くたびにレイアウトが動き続けます。解消シミュレーション後は、最初の描画がすぐに完了し、その後のレイアウトのずれもありません。

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

詳細レポート

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

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

オリジナルページの全493リソースのうち、サイト固有のリソースは175件（約3.5割）、サードパーティタグ由来のリソースは318件（約6.5割）を占めていました。このうち240件（全体の約49%）は、Google Tag Manager 配下から連鎖的に読み込まれていました。

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

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

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

最も大きな変化が観測されたのは、Google Tag Manager のスニペット13行を除去した段階です。配下では63ドメインから240件のリソースが読み込まれており、その中には「サイト高速化」をうたう Repro Booster も含まれていました。Repro Booster はサイトの画像を自社の画像プロキシ経由に書き換えて読み込ませており、単体で103件のリソースと3つのドメインを追加していました。また、残りのタグのうち Rtoaster の連携スクリプトと GTM 用のデータ送信スクリプト、A8.net の3本は、defer と async のどちらも付かない同期スクリプトで、HTML の解析を直接止めていました。

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

なお、CLS だけは0.682から0.721へとわずかに悪化しました。タグが遅かったせいで計測時間内に描画されていなかった領域が描画されるようになり、寸法指定のない画像によるずれが表に出たためです。このずれは、次のボトルネック1で扱います。

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

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

ボトルネック1: 画像に寸法が指定されていない ​

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

観察された状況 ​

このページでは、<img> 要素の多くに width と height 属性が指定されていませんでした。Lighthouse の診断では、432要素が寸法未指定として報告されています。ブラウザは寸法の手がかりがない画像を、実際に届くまで高さ0の箱として扱います。画像が届いた瞬間に本来の高さに広がり、その下のコンテンツがすべて押し下げられていました。

サードパーティータグを除去した時点の CLS は0.721で、「良好」の目安である0.1の7倍以上でした。

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

最初に読み込まれる画像のうち、メインビジュアルのロゴ、ヘッダーのブランドロゴ6点、ヘッダーバナー、ブランドバナー6点など16件に、width と height 属性を付与した状態を計測しました。寸法は推測ではなく、画像ファイルのヘッダーから実寸を読み取って指定しています。16件すべてに、表示サイズを保つ style を併記しました。

シミュレーション結果 ​

16件の画像に属性を付けただけのシミュレーションで、CLS は約68%減り、総合スコア は12ポイント上がりました。このシミュレーション結果から、寸法の指定漏れがレイアウトのずれの最大の要因であったことが読み取れます。

このページのレイアウトのずれには、ほかにも要因がありました。遅延読み込みされる画像462件の寸法未指定、固定ヘッダーの高さ分の余白を JavaScript が後から付けていたことなどです。これらを含む6件の解消シミュレーションを重ねると、CLS は0.000に、総合スコア は76から100に達しました。

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

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

観察された状況 ​

このページは、欧文フォント Montserrat を Google Fonts から読み込んでいます。その CSS（fonts.googleapis.com）が head 内で通常の <link rel="stylesheet"> として読み込まれ、レンダリングをブロックしていました。この CSS が届くまで、ブラウザは1ピクセルも描画できません。そして届くまでには、別ドメインへの新しい接続（DNS・TCP・TLS）の確立が必要でした。

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

同じ内容の CSS を、自社ドメイン（www.peachjohn.co.jp）から配信した状態を計測しました。フォントの見た目は変わらず、HTML の取得時に確立済みの接続をそのまま使えるようになります。

シミュレーション結果 ​

この時点で 総合スコア はすでに100でしたが、FCP は約79%短縮され、FCP の短縮率としては本研究で最大の変化が得られました。Lighthouse の「レンダリングを妨げるリソース」の指摘も0件になっています。ファイルの中身を変えずに配信元のドメインを変えただけで、これだけの変化が生じたことから、1本の CSS のための別ドメインへの接続が、表示開始を大きく遅らせていたことが読み取れます。

なお、このフォントは後のシミュレーションで、システムフォントに置き換えた状態も計測しています。その場合は LCP がさらに約28%短縮される結果が得られました。

ボトルネック3: HTMLの応答に3秒以上かかっている ​

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

観察された状況 ​

全ボトルネックの解消シミュレーションを終えて 総合スコア が100に達したあとも、HTML 本体のサーバー応答時間（TTFB）は約3.3秒のまま残っていました。同じドメインから配信される CSS・JavaScript・画像の応答時間は15〜81msで、遅いのは ASP.NET で動的に生成される HTML 本体だけです。HTML は cache-control: private で配信されており、再訪問時にも毎回この待ち時間が発生します。

実際のブラウザで計測すると、最初の描画までにかかった3.3秒のうち約98%が、この応答待ちでした。サードパーティータグの除去以降、フロントエンド側のシミュレーションをどれだけ重ねても、実測の FCP は3.3秒前後から動いていません。

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

HTML の応答時間だけを約3.3秒から50msに置き換えた状態を計測しました。転送量・DOM 要素数・リクエスト数は一切変えていません。サーバー側の変更を前提とするシミュレーションのため、最終的な解消シミュレーション後のスコアには含めず、参考として計測しています。

シミュレーション結果 ​

実際のブラウザで計測した FCP と LCP は、いずれも3秒以上短縮されました。Lighthouse の SI の推定値も1.7秒から0.1秒へと大きく変化しています。それでも 総合スコア は1ポイントも動きませんでした。この時点で5つの指標がすべて、スコアの上限を超える速さに達していたためです。

総合スコア が100に届いたあとは、スコアはページの速さの変化を映さなくなります。スコアだけを見ていると気づけない位置に、このページで最大のボトルネックが残っていたことが、このシミュレーション結果から読み取れます。

まとめ ​

ピーチ・ジョンのトップページでは、観測時点で 総合スコア が43、LCP が7.7秒、CLS が0.682でした。観察の結果、次のようなボトルネックが表示速度に影響していました。

• サードパーティータグ（318リソース）: 除去によって 総合スコア が43から76へ、LCP が7.7秒から0.8秒へ、SI が12.3秒から2.5秒へ変化。Google Tag Manager 1つの配下だけで、ページの全リソースの約半分にあたる240件が読み込まれていました。
• 画像の寸法の指定漏れ: 16件の画像に width と height 属性を付けることで、CLS が0.721から0.229へ、総合スコア が12ポイント変化。レイアウトのずれの最大の要因でした。
• 別ドメインから配信されるWebフォントの CSS: 自社ドメインからの配信に置き換えることで FCP が約79%短縮。1本の CSS のための接続確立が、表示開始を遅らせていました。
• HTMLの応答時間（約3.3秒）: 50msに置き換えると、実測の FCP と LCP が3秒以上短縮。総合スコア が100に達したあとも残っていた、このページで最大のボトルネックでした。

この他にも、HTML の解析を止めるスクリプトに defer 属性を付けるシミュレーションで FCP が約28%短縮されました。高解像度の画面に必要な大きさの約4倍の寸法で配信されていた商品画像を縮小するシミュレーションでは、ページの転送量が1,414KiBから672KiBへと約半分になっています。一方で、script 要素の </body> 直前への移動は FCP をかえって遅らせ、async 属性の付与は変化が見られませんでした。一般に有効とされる手法の中にも、このページでは効果の見られないものがありました。