「シェルターウェブストア」トップページの表示速度ボトルネック研究

バロックジャパンリミテッドが運営する公式通販サイトです。MOUSSY、SLY、RODEO CROWNS WIDE BOWL、rienda、AZUL BY MOUSSYなど十数ブランドのウィメンズ・メンズ・キッズのファッションアイテムを扱い、毎日更新されるスタッフスナップや、店舗と共通で貯まるポイント、店舗在庫の確認といったサービスも提供しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア は68から100へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は16.3秒から0.9秒へと変化するシミュレーション結果が得られました。観測時点で 総合スコア を押し下げていたのは、16.3秒かかっていた SI と、Googleの「良好」の基準である0.1を大きく超えていた CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）の0.507です。TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点から2msでした。

一方、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）の解消シミュレーション後の0.1秒は、実際にユーザーが待つ時間を表していません。計測環境の回線は高速で、描画を妨げるリソースが同一ドメインの軽いものだけになると、Lighthouse の推定にHTMLのサーバー応答時間がほとんど含まれなくなるためです。そこで本研究では、ブラウザのトレースから読み取った実際の描画時刻（実測 FCP・実測 LCP）もあわせて記録しています。こちらは2.7秒から1.7秒へと変化しました。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画は回線速度とCPU性能を制限したモバイル環境での再生です。

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

詳細レポート

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

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

観測時点のページの全464リソースのうち、サードパーティタグ由来のリソースは251件（約5割強）を占めていました。とくに Google Tag Manager は、1つのコンテナから20以上のベンダーのタグと入れ子の別コンテナを読み込み、141件・約4.6MBのリクエストの起点になっていました。

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

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

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

サードパーティータグを全て除去した状態では、総合スコア は68から91へ、SI は16.3秒から5.7秒へ、CLS は0.507から0.109へと変化し、転送量は15.21MBから6.26MBへと約59%減る結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

最初に除去したvisumoだけで 総合スコア が16ポイント、SI が5.1秒変化しており、CLS も0.507から0.142へ動いています。動画・画像など約7.9MBの読み込みとメインスレッドの占有が、ファーストビューの描画の確定を遅らせていたと考えられます。一方で、LCP・FCP はタグをすべて除去しても1.6〜1.7秒とほとんど変わりませんでした。初回表示の遅さの主因が、サイト自体の構成にあることを示す結果です。

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

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

タグ除去と CLS・TBT の対処を終えた時点でも、HTMLを受信してから初回描画までには約0.96秒かかっていました。ブラウザのトレースを調べると、そこには2段階の直列の待ちがありました。1件目と2件目は、そのそれぞれに対応するボトルネックです。

ボトルネック1: CSS内の@importによる直列読み込み ​

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

観察された状況 ​

自社のCSSファイル sb_base.css の2行目で、英数字用のGoogle Fonts（Lato）のCSSを @import で読み込んでいました。@import は親のCSSを取得・解析するまでブラウザに発見されないため、「HTML → sb_base.css → LatoのCSS → フォント」という直列の読み込みチェーンになります。LatoのCSSの取得には約0.47秒かかり、その間、後続の同期 <script> がHTMLの解析を止めていました。

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

@import を削除し、同じURLをHTMLの <link> 要素として、sb_base.css の直前（カスケード上の同じ位置）に記述しました。読み込むフォントも、スタイルの適用順も変わらないシミュレーションです。

シミュレーション結果 ​

ブラウザがHTMLの受信直後にLatoのCSSを発見できるようになり、要求の開始は約1.69秒へと約0.44秒早まりました。HTMLの解析が止まっていた時間は469msから43msへと変化し、実測 FCP は2.6秒から2.2秒へ、SI は5.7秒から4.1秒へと変化する結果が得られました。CSSファイルの中のわずか1行が、初回描画を約0.4秒遅らせるボトルネックであったことが、このシミュレーション結果から読み取れます。

ボトルネック2: 公開CDNから配信されるCSS・JavaScript ​

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

観察された状況 ​

<head> で読み込むjQuery 3.5.1・jQuery UI 1.12.1のJavaScriptと、jQuery UIのテーマCSS・Font Awesome 4.7.0のCSSを、公開CDN（ajax.googleapis.com、maxcdn.bootstrapcdn.com）から読み込んでいました。別ドメインへの新規接続（DNS・TCP・TLS）が必要な分、自社ドメインのファイルより約330〜420ms遅れて届き、その間HTMLの解析が止まっていました。

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

同じファイルを自社ドメインに置き、HTMLの参照先を書き換えました。CSS内の相対パスで参照される画像は、元のURLを基準とした絶対URLへ変換しています。自社ドメインから配信した場合の応答待ち時間は、自社サーバーで実測された静的ファイルの中央値（約41〜42ms）と仮定しました。JavaScriptとCSSは段階を分けて検証しています。

シミュレーション結果 ​

JavaScriptだけを自社ドメインにした段階では、jQueryの到着は早まったものの、実測 FCP は変わりませんでした。jQueryの <script> が、その前にある公開CDNのCSS 2本の到着を待っていたためです。CSSも自社ドメインにした段階で、HTMLの解析が止まっていた時間は421msから73msへ、実測 FCP は2.2秒から1.8秒へと変化し、描画をブロックするリソースの指摘は0件になりました。JavaScriptとCSSが互いに律速を隠し合っていたことが、この段階的なシミュレーション結果から読み取れます。

ボトルネック1と、その間に行ったLatoの読み込みを描画をブロックしない形にする対処（実測 FCP -26ms）を含めると、一連の対処で実測 FCP は2.6秒から1.8秒へと変化しています。HTML受信後から初回描画までの約0.96秒の大半を、この2段の直列の待ちが占めていたことが分かります。

ボトルネック3: 読み込み中から自動再生するメインスライダー ​

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

観察された状況 ​

ここまでのボトルネックを含め、各フェーズの解消シミュレーションを重ねた時点で、総合スコア は99でした。FCP・LCP・TBT・CLS の点数はすべて満点で、100に届かない原因は SI だけでした。ところが、ブラウザのトレースに記録された画面を時系列で調べると、ファーストビューの読み込みは約1.9秒で完了しているのに、最後の見た目の変化は約10.8秒でした。

原因は、ファーストビューの大部分を占めるメインスライダーです。ページを開くと操作しなくても4秒ごとにスライドが切り替わり、5.8秒と10.3秒に画面が大きく変わっていました。SI は読み込み中の各時点の画面を「最後の画面」と比べて完成度を測るため、3枚目のスライドが「最後の画面」になり、1〜2枚目を表示していた時間がすべて「未完成」と判定されていました。複数のキャンペーンを見せるためのスライダーとして自然な作りですが、計測上はこの動きが表示の完了を大きく先送りしていました。

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

メインスライダーの自動再生を初期状態では止め、最初のスクロール・タッチ・クリック・キー入力で自動再生（4秒ごと）を始めるようにしました。操作しない間は1枚目のまま表示されます。このシミュレーションは、読み込み直後のスライダーの動きが変わることを前提に行いました。

シミュレーション結果 ​

SI は3.1秒から1.1秒へと変化し、総合スコア は3回の計測すべてで100となる結果が得られました。転送量やリクエスト数はほとんど変わっておらず、変化したのは画面の動きだけです。ファーストビューで動き続けるスライダーが、SI を約2秒押し上げるボトルネックであったことが、このシミュレーション結果から読み取れます。

その後に残った最後の見た目の変化は、検索窓のカメラアイコンのアニメーション（約2.6秒）でした。これを静止画に置き換えたシミュレーションでは、最後の見た目の変化が4.6秒から2.6秒へと変化しています。

まとめ ​

SHEL'TTER WEBSTOREのトップページでは、観測時点の 総合スコア が68でした。SI が16.3秒、CLS が0.507と大きく、実測の FCP・LCP は約2.7秒でした。

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

• サードパーティータグ（251リソース）: 除去によって 総合スコア が68から91へ、SI が16.3秒から5.7秒へ、CLS が0.507から0.109へ変化し、転送量は約59%減りました。UGC・動画ギャラリーのvisumoと、Google Tag Manager 配下のタグの影響がとくに大きく観測されました。
• CSS内の@importによる直列読み込み: <link> 要素に置き換えたシミュレーションで、実測 FCP が2.6秒から2.2秒へ、SI が5.7秒から4.1秒へ変化しました。
• 公開CDNから配信されるCSS・JavaScript: 同じファイルを自社ドメインに置いたシミュレーションで、実測 FCP が2.2秒から1.8秒へ変化しました。JavaScriptとCSSの両方がそろって初めて変化が現れています。
• 読み込み中から自動再生するメインスライダー: 最初の操作で再生を始めるシミュレーションで、SI が3.1秒から1.1秒へ変化し、総合スコア が100に達しました。

このほか、ヘッダーの帯バナーの表示枠が確保されていないことによるレイアウトシフト（タグ除去後の CLS の約77%）や、サブセット化されていない日本語Webフォント（約1.23MB、その時点の総転送量の約40%）も観測されています。全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は68から100へと変化し、総転送量は15.21MBから0.54MBへと約96%減る結果となりました。

一方、全ての解消シミュレーションを終えた後も、HTMLのサーバー応答時間（約1.66秒）が残っていました。HTMLはCDNを経由しているもののキャッシュされず、毎回オリジンサーバーで生成されています。最終状態の実測 LCP（約1.75秒）の約95%をこの応答待ちが占めていました。参考として応答時間だけを200msにした計測では、実測 FCP・LCP が約0.3秒になっており、サーバー側の処理であるため本研究のシミュレーションの範囲外ですが、このサイトに残る最大のボトルネックとして観測されています。