「ナチュラム」トップページの表示速度ボトルネック研究

釣り具とアウトドア用品を専門に扱う通販サイトです。20万点以上のアイテムをそろえ、釣り用品、キャンプ用品、アパレル、アウトドア防災などのカテゴリから商品を探せます。トップページには、キャンペーンのカルーセルや告知のポップアップ、セール情報のバナーが並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点では、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が9.7秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）が10.1秒と見積もられていました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）、TBT（Total Blocking Time = メインスレッドのブロック時間）、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は観測時点から良好な値でした。

ただし、本研究の Lighthouse は回線とCPUの速度制限をかけずに計測しています。この条件では、Lighthouse のシミュレーション値にネットワークの遅延がほとんど反映されず、HTMLのサーバー応答時間（約0.97秒）も含まれません。FCP が0.1秒と表示されているのはそのためで、研究の後半では LCP の内訳の計算にも矛盾が生じていました。そこで本研究では、計測中にブラウザが実際に描画した時刻（以下、実測値）を主な指標として観測しました。

実測の LCP は4.1秒から1.1秒へと約7割短縮し、解消シミュレーション後は FCP とほぼ同じ時刻に主要コンテンツが表示される状態になりました。一方、実測の FCP はほとんど変わっていません。その約86%をHTMLのサーバー応答時間が占めており、フロントエンドのボトルネックを解消しても動かない部分だったためです。なお、TBT の0msもCPUの速度低下をかけない条件での値です。

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

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

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

詳細レポート

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

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

観測時点のページの全448リソースのうち、サードパーティータグ由来のリソースは203件（約45%）を占めていました。なお、このサイトはjQueryやSwiperなどのライブラリを自社ドメインから配信しており、Google Fontsも後続の段階で別に扱うため、いずれもサードパーティータグには数えていません。

HTMLに直接記述されていたタグは次のとおりです。

タグマネージャーを経由して、または他のタグから連鎖して読み込まれていたタグは次のとおりです。

HTMLに書かれていたGTMのコンテナは2つでしたが、DMPのタグを経由してさらに2つのコンテナが入れ子で読み込まれており、合計4つのコンテナが動いていました。段階的に除去した際の指標変化は次のとおりです。

大きな変化が観測されたのは、GTM-PWVZ9BR のコンテナを除去した段階でした。この1段階だけで 総合スコア が75から98へ変化しています。このコンテナからは Google Analytics 4 と Google Ads の gtag.js（展開後2.7MB・1.7MB）が、入れ子のコンテナからは Floodlight などの計測タグ（各約1MB）が連鎖して読み込まれていました。一方、Google Ads の gtag.js を除去した段階では、転送量が1.5MB減ったにもかかわらず 総合スコア は変わりませんでした。データ量の大きさと表示速度への影響は必ずしも比例しないことが、この推移から読み取れます。

サードパーティータグを全て除去した状態では、総合スコア は66から99へ、読み込み完了は10.4秒から4.3秒へと変化し、転送量は6割減る結果が得られました。一方で、実測の LCP は4.1秒から3.9秒とほとんど動いていません。主要コンテンツの表示を遅らせていた要因は、タグを除去した後のサイト自身の側に残っていたことになります。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

前述のとおり、サードパーティータグの除去後は 総合スコア が99〜100でほぼ一定になりました。以下では実測値の変化を示します。1秒未満の差を扱うため、値は小数点第2位まで記載しています。

ボトルネック1: 自社アクセス解析JavaScriptの同期読み込み ​

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

観察された状況 ​

HTMLの末尾に、自社のアクセス解析スクリプト（access.js）が、async と defer のどちらの属性も付かない同期スクリプトとして置かれていました。同期スクリプトは、ダウンロードと実行が終わるまでHTMLの解析を止めます。このスクリプトの配信元のサブドメインは応答に約2.8秒かかっており、ページ内の全リソースの中で最も遅い応答でした。同じドメインから配信される他のリソースの中央値（69ms）の約40倍です。

その結果、HTMLの解析は約2.8秒のあいだ止まり、DOMContentLoaded と LCP の確定はいずれも3.8〜3.9秒まで遅れていました。サードパーティータグの除去では、サイトの運営者が自らコードを変更できる自社ドメインのリソースとして対象外にしていたものです。タグを除去した後に残ったリソースの中で、最も大きな影響を持つボトルネックでした。

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

access.js が他のスクリプトから参照されていないことを確認したうえで、async 属性を付け、直後に書かれていた送信処理（naLog.Send()）を読み込み完了時に実行する形へ移しました。スクリプトの内容と配信元は変えていません。

シミュレーション結果 ​

実測の LCP が3.90秒から1.38秒へと約65%短縮される結果が得られました。本研究で観測されたサイト固有のボトルネックの中で、最も大きな変化です。FCP は変わっておらず、最初の描画の後、主要コンテンツが表示されるまでの2.5秒が、スクリプト1本の応答待ちに費やされていたことになります。サードパーティータグではない自社のスクリプトであっても、同期読み込みが表示速度に大きな影響を与えていたことが、このシミュレーション結果から読み取れます。

ボトルネック2: CSSの読み込みが直後のインラインスクリプトを待たせる ​

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

観察された状況 ​

ボトルネック1の解消後、このページの LCP 要素はファーストビューに表示されるキャンペーン告知のポップアップ画像でした。この画像は FCP（1.13秒）より前の1.09秒時点でダウンロードを終えていたにもかかわらず、LCP が確定したのは1.39秒でした。約0.3秒の差のあいだ、メインスレッドはほぼ何も処理していない状態でした。

描画を待たせていた要因の1つは、描画を止めるスタイルシートの直後にインラインスクリプトが置かれていたことです。Google Fontsの CSS を読み込む <link> の直後に、$(document).ready を登録するインラインスクリプトが置かれていました。HTMLの仕様では、先行するスタイルシートの読み込みが終わるまで、このようなインラインスクリプトの実行は保留されます。この CSS の応答には約0.3秒かかっており、その分だけ DOMContentLoaded と、そこから実行されるポップアップの表示処理が遅れていました。

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

Google Fontsの CSS を読み込む <link> に media="print" を指定し、読み込み完了時に media を all へ戻す形にしました。これにより、この CSS はスクリプトの実行と描画を止めなくなります。欧文フォントが適用されるのは、この CSS の読み込み完了後になります。

シミュレーション結果 ​

実測の LCP と DOMContentLoaded がそれぞれ約13〜14%短縮される結果が得られました。CSS の中身には手を加えておらず、読み込み方を変えただけです。なお、同じ <link> をhead内へ移す案も検証しましたが、実測の FCP が約0.23秒遅くなりました。スクリーンショット上の見た目は1ピクセルも変わらず、Lighthouse のレンダリングブロックの監査も変化を検出しませんでした。インラインスクリプトを <link> の前へ移す案では効果が見られず、スタイルシートの読み込み方と置き場所が、見た目や監査結果には表れない形で描画のタイミングを左右していたことが、この結果から読み取れます。

ボトルネック3: LCP要素がJavaScriptの実行まで表示されない ​

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

観察された状況 ​

ボトルネック2で遅れていたポップアップの表示処理そのものにも、ボトルネックがありました。ポップアップは CSS で opacity: 0 と visibility: hidden の状態から始まり、is-show クラスが付いたときに初めて表示されます。このクラスを付けるのは $(document).ready の中のJavaScriptだけで、HTMLの初期状態には付いていませんでした。

Chromeは opacity: 0 の要素を LCP の候補に含めません。画像のダウンロードがどれだけ早く終わっても、JavaScriptがクラスを付けるまで LCP は確定しない構造でした。本研究では画像の WebP 化、fetchpriority="high" の指定、表示サイズに合わせたリサイズも検証しましたが、いずれも実測の LCP に変化は観測されていません。遅れの原因が画像の取得ではなく、描画の開始を待つ時間にあったためです。

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

HTMLのポップアップ要素に、初めから is-show クラスを付けた状態を作りました。JavaScript側でクラスを付ける処理はそのまま残しており、閉じるボタンなどの動作は変わりません。このシミュレーションは、ポップアップがJavaScriptの実行を待たずに表示されることを前提に行いました。

シミュレーション結果 ​

実測の LCP が FCP と同じ1.13秒になる結果が得られました。最初の描画と同時に主要コンテンツが表示される状態で、現在のサーバー応答時間のもとでの下限にあたります。SI も約16%短縮しています。ボトルネック2と合わせると、LCP は1.38秒から1.13秒へと変化しました。HTMLにクラスを1つ加えただけの差であり、JavaScriptで表示する作りがファーストビューの描画を遅らせていたことが、このシミュレーション結果から読み取れます。

まとめ ​

ナチュラムのトップページの表示速度を観測したところ、総合スコア 66、実測の FCP 1.1秒、LCP 4.1秒、読み込み完了10.4秒という値が計測されました。本研究では、回線とCPUの速度制限をかけない条件で計測し、ブラウザで実際に記録された時刻を主な指標として、ボトルネックを順に解消するシミュレーションを実施しました。

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

• サードパーティータグ（203リソース）: 除去によって 総合スコア が66から99へ、読み込み完了が10.4秒から4.3秒へ変化。入れ子を含む4つのGTMコンテナのうち、GTM-PWVZ9BR 1つの除去で 総合スコア が23変化しました。一方で実測の LCP はほとんど動きませんでした。
• 自社アクセス解析JavaScriptの同期読み込み: async 化によって実測の LCP が3.90秒から1.38秒へ約65%短縮。応答に約2.8秒かかるスクリプト1本が、HTMLの解析を止めていました。
• CSSの読み込みが直後のインラインスクリプトを待たせる構造: 読み込み方の変更によって実測の LCP が約13%短縮。
• JavaScriptの実行まで表示されないLCP要素: HTMLに初期状態を持たせることで、LCP が FCP と同じ時刻に到達しました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は66から100へ、実測の LCP は4.1秒から1.1秒へ、読み込み完了は10.4秒から3.8秒へと変化しました。残る実測の LCP 1.1秒の大半は、HTMLのサーバー応答時間（約0.97秒）が占めています。サードパーティータグの影響が大きいページでも、それを取り除いた後には、自社のスクリプトの読み込み方やHTMLの並び順といったサイト自身の構造が、主要コンテンツの表示を数秒単位で左右していたことが、この一連のシミュレーションによって確認できた形です。