「ハニーズ公式オンラインショップ」トップページの表示速度ボトルネック研究

株式会社ハニーズが運営する、レディースファッションの公式通販サイトです。若い世代から大人まで幅広い世代に向けて、定番からトレンドまでの洋服・小物を扱っています。トップページには特集のメインビジュアル、カテゴリ導線、新着商品やセールアイテムの一覧、公式ブログの最新記事などが並んでいます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は19.8秒から0.1秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は7.8秒から0.3秒へと変化するシミュレーション結果が得られました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も1.8秒から0.1秒へ変化しています。TBT（Total Blocking Time = メインスレッドのブロック時間）と CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は、観測時点から一貫して0でした。

観測時点では、最初の描画から主要コンテンツの表示までに約18秒の開きがありました。メインビジュアルの画像そのものの読み込みは0.4秒ほどで終わっていたにもかかわらず、LCP の73%（約14.4秒）は、画像が届いてから描画されるまでの待ちに費やされていました。

なお、記録したページのスクリプト common.js には記録時点から文字化けによる構文エラーがあり、バナースライダーなどが動作しない状態で全段階を計測しています。スクリーンショット下部のCookie同意バナーの文字化けも、記録時点から発生していたものです。

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

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

動画の撮影時には、総転送量が約7.28MBから約744KBへ、load イベントまでの時間が8.18秒から1.52秒へと変化しました。

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

詳細レポート

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

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

観測時点のページの全715リソースのうち、サードパーティタグ由来のリソースは340件（約5割）を占めていました。Lighthouse の計測中には約120の外部ドメインとの通信が発生しています。

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

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

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

サードパーティータグを全て除去した状態では、総合スコア は66から100へ、LCP は19.8秒から0.4秒へ、SI は7.8秒から1.0秒へと変化する結果が得られました。リクエスト数も717件から230件へと減っています。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

変化の大半は最後の Google Tag Manager の段階で観測されました。約1.6MBのコンテナが20種以上のタグを読み込んでおり、除去すると LCP は16.0秒から0.4秒へと変化しています。それまでの段階では、同じ状態を計測し直しても LCP が約4〜19秒の範囲で揺らいでいましたが、Google Tag Manager の除去後は3回の計測がいずれも0.4秒台に揃いました。揺らぎそのものが、大量のタグによる帯域とメインスレッドの奪い合いから生じていたと考えられます。

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

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

この時点で 総合スコア はすでに100に達していたため、以降のシミュレーションでは Lighthouse の推定値に加えて、ブラウザのトレース上で計測した実際の描画時刻（実測 FCP）や転送量、リクエスト数も評価に用いています。実測値はいずれも3回計測の中央値です。

ボトルネック1: head内の同期スクリプト17本 ​

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

観察された状況 ​

このページの head には、jQueryやサイト共通のスクリプトなど、async や defer を持たない外部スクリプトが17本と、インラインスクリプトが5本並んでいました。body の途中にも外部スクリプト4本とインラインスクリプト15本があります。HTMLの解析はスクリプトのたびに止まり、ブラウザは head のスクリプトを読み込み・実行し終えるまで最初の描画を始められません。

Lighthouse の推定する FCP は0.2秒前後でしたが、トレース上で計測した実際の最初の描画は約1.5秒で、推定値との間に大きな開きがありました。ただしこの計測環境には、ページの内容と関係なく最初の描画が約1.5秒まで保留されることがあるという性質があり、head にスクリプトがある状態では計測したすべての回でこの保留が起きていました。

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

HTMLコメント内のものを除く41個のスクリプト（外部21・インライン20）を、出現順を保ったまま </body> の直前に移動しました。document.write を使うスクリプトがないこと、直前の要素を操作するインラインスクリプトが移動後も対象を見つけられることを確認しています。

スクリプトより先に最初の描画が行われるようになったことで、幅と高さを指定していないアイコン画像が読み込み後に伸び、CLS 0.180のずれが新たに表れました。シミュレーションでは、最終的な表示と同じ縦横比をCSSで確保して CLS を0に戻しています。

シミュレーション結果 ​

スクリプトの位置を変えただけで、実際の最初の描画は1.54秒から0.52秒へと約1秒早まるシミュレーション結果が得られました。Lighthouse の推定値でも LCP は0.34秒から0.18秒へ、SI は0.85秒から0.44秒へとほぼ半分になっています。

なお、この約1秒の差には計測環境の要因が含まれています。変更後も15回中4回は約1.5秒までの保留が起きており、別の方法（同じ記録を puppeteer で読み込む）では変更前でも約0.55秒で描画されていました。それでも、head の同期スクリプトをなくすことで保留がほとんど起きなくなり、Lighthouse の推定値も揃って短縮したことから、このスクリプト群が最初の描画を遅らせる要因になっていたことが読み取れます。

ボトルネック2: 描画を止めるGoogle FontsのCSS ​

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

観察された状況 ​

このページは、価格表示の数字に Google Fonts の欧文フォント Lato を使っていました。数字の見た目を揃えたいという意図は自然なもので、フォントのファイルも2件で計約29KBと小さなものです。

一方で、フォントを指定するCSSは fonts.googleapis.com から描画をブロックする形で読み込まれていました。もともとはサイトのCSSの中から @import で直列に読み込まれており、それを link 要素に置き換えた後の時点でも、Lighthouse が描画ブロックとして指摘していたのはこのCSSだけでした。外部ドメインへの新規接続が必要なぶん自社のCSSより到着が遅く、Lighthouse の推定上は、最初の描画がこのCSSを待つ形になっていました。

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

フォントのURLにはもともと display=swap が指定されており、フォントが届く前は代替フォントで表示しても崩れない作りでした。そこで、このCSSを描画をブロックしない形で読み込むように変更し、fonts.googleapis.com と fonts.gstatic.com への preconnect を加えました。フォントの見た目は変わりません。

シミュレーション結果 ​

Lighthouse の推定する FCP は0.34秒から0.17秒へと約半分になるシミュレーション結果が得られました。3回計測の中央値でも0.34秒から0.17秒と同じ傾向です。一方、トレース上の実際の最初の描画（約1.5秒）はこの変更では変わっておらず、前述の計測環境による保留が支配的でした。数字の字形だけに使われていた小さな欧文フォントでも、そのCSSが描画をブロックする形で読み込まれていれば、Lighthouse の評価では外部ドメインへの接続の分だけ最初の描画が待たされる扱いになることが読み取れます。

読み込みの優先度による違いも観測されています。描画をブロックしない読み込み方だけに変えた場合、CSSは約150枚の画像の後ろに回され、FCP は同様に短縮した一方で LCP は0.88〜1.12秒に悪化しました。rel="preload" で最高の優先度にした場合は、Lighthouse がそれを描画ブロックとして扱うため FCP が短縮しませんでした。fetchpriority="high" を併用して優先度を High にした場合にだけ、FCP の短縮と LCP の維持が両立しています。

その後、Google Fonts の読み込み自体をやめて価格表示をデバイスフォントにしたシミュレーションでは、FCP と LCP が0.13秒から0.11秒へ、SI が0.39秒から0.31秒へと変化しました。このとき価格の数字の字形と字幅はわずかに変わっています。

ボトルネック3: 画面外の画像233個の即時読み込み ​

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

観察された状況 ​

このページは商品画像の多くを遅延読み込みのライブラリで扱っていますが、その管理から外れ、loading 属性も持たない画像が233個ありました。お気に入りのアイコン、カラーチップ、NEWやセールのアイコン、ブログの画像、バナー、フッターのアイコンなどで、いずれもファーストビューより下にあるにもかかわらず、ページの読み込み直後にすべて取得されていました。商品一覧が縦に長く続くトップページでは、商品ごとの小さなアイコンでも数が積み重なります。

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

画面上の位置を実際に計測し、ページ上端から823px（ファーストビューの高さ）より下にある表示中の画像233個に loading="lazy" を付与しました。ファーストビュー内の画像とメインビジュアルには付けていません。このシミュレーションは、スクロールして画像が画面に近づいてから読み込みが始まることを前提に行いました。

シミュレーション結果 ​

属性を1つ加えただけで、リクエスト数と転送量はともに約半分になり、load イベントは0.26秒早まるシミュレーション結果が得られました。Lighthouse の LCP と FCP は0.14秒前後で、ほとんど変わっていません。スコアには表れない場所で、最初の表示に関係のない画像の取得がページの読み込みを重くしていたことが読み取れます。

この段階を含む一連の転送量に関するシミュレーション（ブログのサムネイル画像の縮小、非表示のランキング用 iframe の遅延、商品リストの遅延展開、Google Fonts の読み込み停止など）を重ねた結果、ページの転送量は920.1KBから234.2KBへ、リクエスト数は152件から69件へと変化しています。

まとめ ​

ハニーズ公式オンラインショップのトップページでは、観測時点の 総合スコア が66でした。FCP は1.8秒だった一方で LCP は19.8秒に達しており、メインビジュアルが描画されるまでの待ちが際立っていました。

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

• サードパーティータグ（340リソース）: 除去によって 総合スコア が66から100へ、LCP が19.8秒から0.4秒へ、SI が7.8秒から1.0秒へ変化しました。変化の大半は、20種以上のタグを読み込む Google Tag Manager の除去の段階で観測され、LCP の大きな揺らぎもこの段階で収まりました。
• head内の同期スクリプト17本: スクリプトを body 末尾に移したシミュレーションでは、実際の最初の描画が1.54秒から0.52秒へと約1秒早まりました（計測環境の要因を含む）。
• 描画を止めるGoogle FontsのCSS: 描画をブロックしない読み込みにしたシミュレーションで、Lighthouse の推定する FCP が0.34秒から0.17秒へと約半分になりました。
• 画面外の画像233個の即時読み込み: 遅延読み込みにしたシミュレーションで、リクエスト数が147件から76件へ、転送量が557.9KBから272.4KBへと約半分になりました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は66から100へ、LCP は19.8秒から0.1秒へと変化しました。最終的な状態でも、HTMLのサーバー応答時間（約0.38秒）が実際の最初の描画（約0.43秒）の大半を占めていたことが観測されています。観測時点の遅さの大部分はサードパーティータグに由来していましたが、それを切り離した後にも、スクリプトの配置やフォントのCSS、画面外の画像といったサイト自身の構成が、最初の描画と読み込みの重さに影響していたことが、この研究から読み取れます。