「夢展望」トップページの表示速度ボトルネック研究

DearMyLove、Lilymel、Whip、Diable baiser、bohmalなどのブランドを展開する、レディースファッション通販サイト「夢展望」の公式オンラインストアです。量産型・地雷系・ガーリー・ギャル・カジュアルまで幅広いテイストの服を扱っており、サイトはShopifyで構築されています。スマートフォン向けのトップページには、ヘッダーのバナーカルーセル、ファーストビューのメインカルーセル、「New arrival」の商品一覧、カテゴリ別ランキング、コーディネート紹介などが並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は71でした。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）はともに2.6秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は7.5秒、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.299で、SI と CLS は「低速」の範囲に入っていました。TBT（Total Blocking Time = メインスレッドのブロック時間）は0msです。解消シミュレーション後は 総合スコア が100に達し、SI は0.7秒、CLS は0.000まで変化しました。読み込み時の転送量も、サードパーティータグを除いた時点の約20MBから約2.7MBへ減っています。

なお、本研究の Lighthouse は、記録した通信を再生する環境で、CPUの速度制限をかけない条件で計測しています。TBT が観測時点から0msなのはこのためです。また、この計測環境では、ページの内容とは関係なく、画面の更新の約1秒の停止が一定の割合で発生しました。この回は LCP・FCP が約1秒長く記録されます。上の表の解消シミュレーション後の値は止まらなかった回のもので、最終状態で6回計測したうち止まった2回は、LCP 約1.6秒・総合スコア 99でした。

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

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

この動画は、CPUの速度を1/4に落とし、通信速度を10.5Mbpsに制限した条件で撮影しています。この条件では、転送量が21.86MBから2.51MBへ、読み込み完了（onload）までの時間が18.27秒から2.40秒へ変化しました。観測時点ではカルーセルの画像の表示が大きく遅れているのに対し、解消シミュレーション後はファーストビューのカルーセル画像と商品一覧がすぐに表示されています。

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

詳細レポート

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

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

観測時点のページの全931リクエストのうち、サードパーティータグ由来のリクエストは354件（約4割）でした。転送量は26.50MBから20.23MBへ、約6.3MB減っています。なお、レビュー（Judge.me）、お気に入り（Swym）、後払い決済（Paidy）などのEC機能アプリと、公開CDNから読み込まれていたjQueryなどのライブラリは、サイトの機能を構成するものとして除去の対象外としました。

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

ShopifyのWebピクセル・Google Tag Manager経由で読み込まれているタグ ​

HTMLに直接書かれた Google Tag Manager とは別に、Shopifyの管理画面に登録されたカスタムピクセル2つが、それぞれのiframeの中で同じコンテナを読み込んでいました。同じコンテナが1ページで3回読み込まれ、gtm.js（192KB）や Google Analytics の gtag.js（184KB）などが、それぞれ3回ダウンロード・実行されていたことになります。

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

総合スコア を大きく動かしたのは2つの段階でした。<head> で同期的に読み込まれていた Google Optimize の除去では、CLS が0.299から0.000へ変化し、総合スコア が71から86へ上がりました。Google Optimize はすでにサービスが終了しており、読み込んでも機能しないタグです。もう1つは、カスタムピクセル経由で重複していた Google Tag Manager の除去で、SI が7.3秒から5.3秒へ変化しました。awoo除去後の SI 7.9秒は、次の段階で元の水準に戻っている計測の揺らぎです。

サードパーティータグを全て除去した状態では、総合スコア は71から89へ、SI は7.5秒から5.3秒へ、CLS は0.299から0.000へ変化する結果が得られました。一方で LCP・FCP は約2.6秒のまま動かず、この2つを遅くしていたのはサイト自体の構成であったことも分かります。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: カルーセルが初期化まで表示されない ​

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

観察された状況 ​

このページの LCP 要素は、ファーストビューのメインカルーセルの1枚目の画像です。LCP の内訳を調べると、画像そのものは約0.57秒で取得し終えているのに、描画されるまでの遅延（要素の描画遅延）が1,017msと、LCP の63%を占めていました。

原因は、カルーセルライブラリ Splide の CSS にある .splide { visibility: hidden; } というルールでした。初期化後に付く .is-initialized クラスで表示に切り替わる仕組みのため、DOMContentLoaded の後に JavaScript でカルーセルを初期化する約1.29秒まで、取得済みのLCP画像が描画されていませんでした。LCP画像に fetchpriority="high" を付けるシミュレーションも先に行いましたが、取得開始が約35ms早まっただけで、LCP は変わりませんでした。

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

初期化前のカルーセルの寸法は、この前の工程で CSS により確保していました。そのうえで、ファーストビューの2つのカルーセル（メインカルーセルとヘッダーのバナー）を、初期化前（.is-initialized が付く前）から visibility: visible で表示する CSS のルールを1つ追加しました。初期化前の配置は初期化後と同じになるため、表示が早まってもレイアウトはずれません（ループ用の複製スライドとページネーションのドットは初期化時に追加されます）。

シミュレーション結果 ​

LCP画像は FCP の約40〜50ms後のフレームで描画されるようになり、カルーセルの初期化を待たなくなりました。解消前の値には、前述した画面の更新が止まる回の影響が含まれます。止まった回と止まらなかった回を混ぜた6回計測の中央値で比べても、LCP は約1.33秒から約0.65秒へ、約半分になっています。表示を早めても CLS は0.000のままでした。

JavaScript で初期化するカルーセルでは、ライブラリの CSS で初期化前の要素を非表示にしている例がよく見られます。このシミュレーション結果から、初期化を待つ非表示の指定が、取得済みのLCP画像の描画を約0.7秒遅らせていたボトルネックであったことが読み取れます。

ボトルネック2: head内の同期スクリプトがHTMLの解析を止める ​

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

観察された状況 ​

サードパーティータグを除いた時点の <head> には、レンダリングブロックリソース（読み込みが完了するまでページの描画が停止するリソース）が多数並んでいました。Adobe Fonts、Google Fonts、jsDelivr（slick・Splide）から読み込む別ドメインの CSS と、Google Hosted Librariesから読み込む jQuery、Sign in with Apple の appleid.auth.js などの同期スクリプトです。別ドメインの資源はそれぞれ接続の確立から始める必要があり、応答開始までに約280〜290msかかっていました。

本研究では、これらを1つずつ同一ドメインからの配信や非同期読み込みに切り替えるシミュレーションを重ねました。個々の資源の取得完了は早まったものの、FCP は約2.6秒のまま動きませんでした。別ドメインの CSS を全て同一ドメインにしても、<head> には jQuery と、それに依存するインラインスクリプト（テーマの設定、レビューアプリ関連など）が残り、HTMLの解析を止めていたためです。

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

jQuery以降にある実行可能なスクリプト56個を、元の出現順のまま </body> の直前へ移動しました。Shopifyが自動で挿入するスクリプトや、データ用のスクリプトは移動していません。

この移動で描画を早めると、ヘッダーのバナーとメインカルーセルが初期化の瞬間に現れて本文を押し下げ、CLS が0.494〜1.200まで悪化することも観測されました。そのため、初期化前から初期化後と同じ寸法の領域を CSS で確保したうえで、このシミュレーションを行っています。

シミュレーション結果 ​

最初の描画の準備が整う時刻は、約1.6秒から約0.58秒へ早まりました。表の FCP が1.6秒にとどまっているのは、前述の画面の更新が止まる回に当たったためで、6回計測のうち止まらなかった回では FCP は0.7秒でした。別ドメインの資源が残っていた段階で同じ移動を試したときは、FCP が短縮したのは6回中2回だけで、その回は CLS が悪化していました。

別ドメインの CSS と同期スクリプトの片方だけを外しても FCP は変わらず、両方が揃って初めて動いたのがこのページの特徴です。このシミュレーション結果から、<head> の同期スクリプトと別ドメインの資源が組み合わさって、最初の描画を約1秒遅らせていたことが読み取れます。

ボトルネック3: カルーセルの自動再生で表示が完成しない ​

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

観察された状況 ​

ボトルネック1と2を解消した時点で 総合スコア は98となり、減点されていたのは SI の3.9秒だけでした。読み込みの過程のスクリーンショットを時系列で調べると、ページの読み込みは約1.3秒で終わっているのに、ヘッダーのカルーセル（4秒間隔）とメインカルーセル（5秒間隔）の自動再生によって、約13.8秒まで画面が変わり続けていました。

SI は、計測の最後のフレームを「完成した画面」とみなし、そこへ近づく速さを評価します。最後のフレームでは別のスライドが表示されていたため、読み込みが終わった後も表示が完成していないと評価されていました。読み込み完了時点の画面と最後のフレームの差は約42%ありました。

ファーストビューで複数のビジュアルを次々に見せたいという意図は、ファッション通販のトップページとしてよく理解できます。

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

カルーセルの自動再生の開始を、ユーザーの最初の操作（スクロール、タッチ、クリック、キー入力）の後まで待つように変更しました。最初の操作の後は、従来どおり4秒・5秒間隔で切り替わります。このシミュレーションは「操作するまでスライドが自動で切り替わらない」というUXの変化を前提に行いました。

シミュレーション結果 ​

SI は3.9秒から0.8秒へ変化し、総合スコア は100に達しました。画面の更新が止まる回どうしで比べても、SI は約4.6秒から約1.6秒へ、総合スコア は96から99へ変化しています。LCP・FCP は変わっていません。

この変化は読み込みそのものが速くなったことによるものではなく、SI が読み込み後の画面の変化を未完成と評価する性質によるものです。それでも、読み込みが終わった後の画面の変化が、SI の値を大きく押し上げていたことになります。このシミュレーション結果から、ファーストビューのカルーセルの自動再生が SI に与えていた影響の大きさが読み取れます。

まとめ ​

夢展望のトップページの表示速度を観測したところ、総合スコア 71、LCP 2.6秒、SI 7.5秒、CLS 0.299という値が計測されました。本研究では、これらの計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（354リクエスト）: 全て除去した状態では 総合スコア が71から89へ、SI が7.5秒から5.3秒へ、CLS が0.299から0.000へ変化。同じ Google Tag Manager のコンテナが3回読み込まれていたことと、サービス終了済みの Google Optimize が主な要因でした。
• カルーセルが初期化まで表示されない: 初期化前から表示することで、LCP（6回の中央値）が約1.33秒から約0.65秒へ変化しました。
• head内の同期スクリプト: 別ドメインの資源を解消したうえで </body> の直前へ移動することで、FCP が2.6秒から1.6秒へ、総合スコア が89から96へ変化しました。
• カルーセルの自動再生: 自動再生の開始を最初の操作の後にすることで、SI が3.9秒から0.8秒へ変化しました。

このほか、ページ下部のコーディネートセクションで表示されない画像416件が一斉に取得されていたことも観測されています。遅延読み込みにするシミュレーションでは、読み込み時の画像が335件・13.40MBから35件・764KBへ減り、LCP（6回の中央値）も約1.6秒から約1.3秒へ変化しました。また、日本語Webフォント（KintoSans、約3.3MB）が転送量の約57%を占めていたことも観測されています。こちらは今回の計測環境では指標が変わらなかったものの、帯域の限られたモバイル回線では無視できない量です。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は71から100へ、LCP は2.6秒から0.6秒へ、SI は7.5秒から0.7秒へと変化しました。とりわけ、取得済みのLCP画像がライブラリの CSS によって初期化まで隠されていたこと、<head> の同期スクリプトと別ドメインの資源が揃って解消されるまで FCP が動かなかったことは、個々の指摘を1つずつ見るだけでは見えにくいボトルネックでした。これらの要素がこのページの表示速度に大きな影響を与えていたことが、この一連のシミュレーションによって読み取れます。