「PAL CLOSET」トップページの表示速度ボトルネック研究

株式会社パルが運営する、パルグループ公式のファッション通販サイトです。ラシット、ガリャルダガランテ、カスタネなど30以上のブランドを扱い、ポイントは店舗と共通で利用できます。トップページには特集のカルーセル、ランキング、スタッフのコーディネート、骨格タイプ別やパーソナルカラー別のコーデなどが並び、ブランド一覧やカテゴリーはモーダルで開く作りです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は43でした。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は12.6秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は10.1秒、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.510で、いずれも「低速」の範囲に入っていました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も2.0秒です。解消シミュレーション後は 総合スコア が100に達し、LCP は0.3秒、SI は0.4秒、CLS は0.000まで変化しました。

なお、本研究の Lighthouse は、記録した通信を再生する環境で、帯域の制限をかけずに記録時の通信タイミングをそのまま再現する条件で計測しています。TBT（Total Blocking Time = メインスレッドのブロック時間）が全期間で十数ms以下（最大14ms）なのも、解消シミュレーション後の FCP が0.1秒と実機より小さな値になるのも、この条件によるものです。参考として、解消シミュレーション後の状態をブラウザで実測すると、FCP は約0.6秒、LCP は約0.8秒でした。帯域制限のない条件では転送量の削減が時間に表れにくいため、本研究では回線の遅い利用者を想定した低速条件（CPU 4倍の減速・1.6Mbps・RTT 150ms）での計測もあわせて行っています。

また、このページは観測時点から、同じデータでも計測ごとに LCP が2〜25秒の範囲で揺れる状態が続いていました。この揺れ自体が、後述するボトルネックの症状の1つです。

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

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

動画は Lighthouse とは別の条件で記録しているため、表の値は先ほどの指標とは一致しません。観測時点では読み込み完了まで約20秒、22.5MBの転送が続いていたのに対し、解消シミュレーション後は約2.2秒・1.86MBで読み込みが終わっています。

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

詳細レポート

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

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

観測時点のページの全873リソースのうち、サードパーティータグ由来のリソースは300件（約3.4割）を占めていました。公開CDN経由のjQuery関連とGoogle Fontsは、サイト側で配信方法を変えられるため、サードパーティータグではなくサイト固有のリソースとして数えています。

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

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

Google Tag Manager の配下だけで約75ホスト・219リクエストが読み込まれていました。また、KARTE・STAFF START・PARTE・LINE LIFF SDK・c-ringsの5サービスは同期読み込みで、HTMLの解析と初回表示を止める位置に置かれていました。

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

サードパーティータグを全て除去した状態では、総合スコア は43から75へ、SI は10.1秒から2.7秒へ、FCP は2.0秒から1.0秒へ、LCP は12.6秒から8.2秒へ変化する結果が得られました。

途中の値が大きく上下しているのは、この時点のページが持っていた計測の不安定さによるものです。実測の初回表示が計測ごとに約0.8秒・約1.6秒・約2.6秒のいずれかになり、初回表示が早い回ほどその後のレイアウトのずれが CLS に計上されていました。総合スコア の上下の多くはこの CLS の変動によるもので、原因はサイト固有のボトルネックとして後述します。その中でも、同期読み込みのPARTEとc-ringsの除去では FCP がそれぞれ2秒以上短縮し、Google Tag Manager の除去では219件のリクエストがなくなって LCP が5.4秒短縮しました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

1秒未満の値が多くなるため、以下の表では1秒未満の値を小数点第2位まで示しています。また、このページの値は1回ごとに揺らぐため、本文では複数回計測の中央値もあわせて扱います。

ボトルネック1: head内の同期スクリプトが描画を止める ​

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

観察された状況 ​

head 内には、jQueryや共通スクリプトなど11本の外部スクリプトとインラインスクリプトが同期読み込みで置かれ、body の冒頭にもスクリプトがありました。ブラウザは同期スクリプトを見つけると、取得と実行が終わるまでHTMLの解析を止めます。トレースを分析すると、CSS は約0.58秒でそろっていました。それでも解析が head の中で止まったまま body に進まないため描画できる内容を持てず、画面への初回表示は約2.66秒まで遅れていました。

切り分けのため、Google Fontsの削除、body 内の CSS の削除、body 内のスクリプトだけの移動も試しましたが、いずれでも初回表示は早まりませんでした。head 内のスクリプトを body の開始タグより後ろに移したときだけ、描画の保留が解消しました。サードパーティータグの除去シミュレーションで値が大きく揺れていたのも、この保留が計測ごとに異なる長さで発生していたためです。

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

script 要素61個（外部20本、インライン41本）を、出現順を保ったまま </body> の直前へ移動しました。async や defer は付けていません。カルーセル、メニューの開閉、検索、レコメンドなどの動作は移動前と同じであることを確認しています。

シミュレーション結果 ​

実測の初回表示は2.66秒から0.62秒へ短縮し、総合スコア は83から100に達しました。それまで2〜25秒の範囲で揺れていた LCP も、3回の計測すべてで0.6秒前後にそろっています。SI はこの回では延びていますが、同じ状態を3回計測すると0.90〜2.47秒（中央値1.02秒）と揺れており、2.47秒はそのうち最も遅い回の値です。

一方、低速条件では、スクリプトの移動だけを行った状態の初回表示が2.3秒から約16秒へと大きく延びる結果も得られました。解析がすぐに body へ進むことで約180枚の画像が一斉に要求され、CSS と帯域を奪い合ったためです。この画像の問題が、次のボトルネックです。このシミュレーション結果から、head 内の同期スクリプトが、このページの初回表示を遅らせ、計測値を不安定にしていた最大の要因であったことが読み取れます。

ボトルネック2: 画面外・非表示の画像まで一斉に取得している ​

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

観察された状況 ​

このページの LCP 要素は、ファーストビューにあるカルーセルの1枚目の画像です。ところがHTMLの解析直後に、閉じているモーダルの中のブランドロゴ、ページ下部の画像、読み込み中を示すアニメーションGIFなど、約185枚・約9.8MBの画像が LCP 画像と同時に要求されていました。

ブランド一覧とカテゴリーのモーダルは、position: fixed・visibility: hidden・opacity: 0 で画面に重ねて配置されていました。見えてはいないものの、ブラウザからは「画面内」にあると判定されるため、中のロゴ58枚とアイコン29枚は loading="lazy" を付けても読み込まれる状態でした。サイトを回遊するためのモーダルを、すぐに開ける形で置いておきたいという作りの意図は理解できます。

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

読み込み4秒後の表示状態でHTMLの img 380個を分類し、非表示（モーダル・テンプレートなど）243個、画面外43個、3画面以内27個の計313個に loading="lazy" を付けました。ファーストビュー内の画像と1枚目のカルーセルの画像は対象から外しています。あわせて、閉じている間だけモーダルの中身の描画を省く CSS（content-visibility: hidden）を加え、モーダル内の画像が遅延読み込みの対象になる状態を作りました。

シミュレーション結果 ​

LCP より前に要求される画像は185枚から38枚へ減り、LCP 画像の取得開始の遅れは5回とも0msになりました。帯域制限のない条件でも LCP の中央値は0.79秒から0.63秒へ短縮しています。差が大きく表れたのは低速条件で、HTML・CSS と画像の帯域の奪い合いが減ったことで、LCP は16.8秒から5.4秒へ、読み込み完了は80.3秒から38.2秒へと変化しました。

この直前には、LCP 画像に fetchpriority="high" を付けるシミュレーションで LCP の中央値が1.48秒から0.79秒へ短縮しています。さらに、読み込み中のGIF（1枚362KB）の除去やカルーセル画像の縮小を重ねると、LCP より前に要求される画像は34枚・約532KBまで減り、低速条件の LCP は3.8秒まで変化しました。このシミュレーション結果から、画面外・非表示の画像の一斉取得が、LCP 画像の取得を妨げ、回線の遅い環境で表示を大きく遅らせていたボトルネックであったことが読み取れます。

ボトルネック3: カルーセルの初期化前に6枚が縦に並ぶ ​

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

観察された状況 ​

観測時点の CLS は0.510でしたが、サードパーティータグを除去した後の Lighthouse では0.000になっていました。調べたところ、レイアウトのずれ自体は残っていました。初回表示までにレイアウトの変化を終える回が多く、その場合は記録されないため0.000と出ていたのです。そこで、低速条件でページを読み込み、すべてのレイアウトのずれを記録する再現テストを行ったところ、CLS は0.509で、観測時点の0.510とほぼ一致しました。

その最大の要因が、ファーストビューのカルーセル（slick）でした。JavaScript で初期化されるまで6枚のスライドが縦に並んだ状態（高さ1,927px、opacity: 0 で非表示）になっており、初期化されると高さが321pxに縮みます。その下のコンテンツが約1,600px上へ移動し、これだけで CLS 0.352を生んでいました。

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

初期化前のカルーセル（.slick-initialized が付く前のリスト）に、初期化後と同じ横並びのレイアウトを CSS で与えました。HTMLと JavaScript には手を加えていません。JavaScript を無効にした状態でも、カルーセルの高さ、1枚目のスライドとキャプションの位置が初期化後と一致することを確認しています。

シミュレーション結果 ​

再現テストの CLS は0.509から0.156へ変化し、カルーセルによるずれ（0.352）は記録されなくなりました。初期化前からカルーセル画像が表示されるようになったことで、LCP と SI も短縮しています（この時点の LCP は計測ごとに数秒の揺れがあるため、短縮幅は参考値です）。

残る0.156は、ヘッダー上の帯バナー2枚が読み込み後に Ajax で挿入され、ページ全体を計129px押し下げていたことによるものでした。バナーをHTMLに直接記述して画像のサイズを指定したシミュレーションでは、再現テストの CLS は0.000になっています。このシミュレーション結果から、初期化前のカルーセルのレイアウトが、Lighthouse の値に表れたり表れなかったりしながら、このページの CLS の大半を生んでいたことが読み取れます。

まとめ ​

PAL CLOSETのトップページの表示速度を観測したところ、総合スコア 43、LCP 12.6秒、SI 10.1秒、CLS 0.510という値が計測されました。加えて、同じデータでも LCP が2〜25秒の範囲で揺れる不安定な状態でした。本研究では、これらの計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（300リソース）: 全て除去した状態では 総合スコア が43から75へ、SI が10.1秒から2.7秒へ変化。同期読み込みのタグが5サービスあり、Google Tag Manager の配下だけで約75ホスト・219リクエストが読み込まれていました。
• head内の同期スクリプト: body 末尾への移動によって、実測の初回表示が2.66秒から0.62秒へ短縮し、LCP の揺れもなくなりました。
• 画面外・非表示の画像の一斉取得: 遅延読み込みによって LCP より前に要求される画像が185枚・約9.8MBから38枚・約4.2MBへ減り、低速条件の LCP が16.8秒から5.4秒へ変化しました。
• 初期化前のカルーセルのレイアウト: 初期化後と同じ横並びを与えることで、再現テストの CLS が0.509から0.156へ変化。帯バナーの挿入とあわせると0.000になりました。

このほか、ページ読み込み時の同期 XHR（検証環境で計約1.3秒のメインスレッドの停止）、圧縮なしで配信されていた約536KBの自社 CSS、JPEG・PNGのままの画像458件、アイコンのために読み込まれていた約1.1MBのアイコンフォントなども観測されています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は43から100へ、LCP は12.6秒から0.3秒へ、SI は10.1秒から0.4秒へと変化しました。サードパーティータグに加え、head 内の同期スクリプト、大量の画像の一斉取得、初期化前のカルーセルのレイアウトといった要素が、このページの表示速度と計測値の不安定さに大きな影響を与えていたことが、この一連のシミュレーションによって読み取れます。