「イトーヨーカドーネットスーパー」トップページの表示速度ボトルネック研究

イトーヨーカドーの食料品や日用品を、自宅まで届けてもらえるネットスーパーです。トップページでは、お届け先の郵便番号に応じた店舗の商品が表示され、特集のバナーやセール、売れ筋の商品が並びます。会員サービス「ONIGO+」の案内もファーストビューに置かれています。このページは、アプリ本体がAPIから商品やバナーのデータを取得して描画するSPA（シングルページアプリケーション）です。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

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

ただし、本研究の検証環境は記録時の高速な通信を再現しています。また Lighthouse のモバイル計測は、実際の読み込みのトレースから低速回線での値を推定するシミュレーション値を報告します。このページは初回描画がJavaScriptの処理の流れに依存し、表示に必要なデータをAPIのサーバー処理を待って受け取る作りのため、シミュレーション値と実際の描画タイミングが大きく食い違いました。そこで本研究では、計測中にブラウザが実際に描画した時刻（以下、実測値）もあわせて観測しています。

実測の FCP は2.6秒から0.5秒へ、LCP は4.1秒から1.5秒へと変化しました。観測時点のユーザーは、2.6秒のあいだ真っ白な画面を見ていたことになります。Lighthouse の FCP が0.07秒と報告されていたのとは、大きな開きがありました。なお、CLS はデータの到着前から同じ寸法の枠（スケルトン）を表示する作りのため、観測時点から一貫して0.000でした。

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

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

動画は load イベントまでを記録しています。観測時点のページは、load イベントの1.78秒の時点でもまだAPIの応答を待っており、灰色のスケルトンのまま記録が終わっています。実際のバナーや商品が表示されたのは、その後の約4.1秒でした。解消シミュレーション後は、動画の記録では0.61秒の時点でカルーセルと特集のバナーが表示されています。

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

詳細レポート

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

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

観測時点のページの全607リソースのうち、サードパーティータグ由来のリソースは67件（約11%）でした。件数では1割程度ですが、ページの転送量の約19%（約1.56MB）、メインスレッドの処理時間の約35%（約458ms）を占めていました。

このページのHTMLには外部の <script src> が1つも書かれておらず、すべてのタグは、アプリ本体のJavaScriptが挿入する Google Tag Manager のコンテナを経由して読み込まれていました。

段階的に除去した際の指標変化は次のとおりです。

最も大きな変化が観測されたのは Microsoft Clarity の除去でした。転送量は約27KBと小さいタグですが、この1段階で LCP が1.8秒短縮し、総合スコア が12ポイント変化しています。ページの読み込み直後からDOM全体の記録と計測データの送信を始める処理が、アプリ本体のAPIの応答処理やバナーの描画と重なっていたと考えられます。転送量の大きさと表示速度への影響は必ずしも比例しないことが、この推移から読み取れます。

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

一方で、実測の LCP は、タグの除去と TBT のボトルネック2件の解消を終えた時点でも約4.0秒で、観測時点の4.1秒からほとんど動いていませんでした。総合スコア が100に達しても、主要コンテンツの表示を遅らせていた要因はサイト自身の側に残っていたことになります。

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

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

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

ボトルネック1: LCPのデータを最も遅いAPIから取得している ​

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

観察された状況 ​

このページの LCP 要素は、ファーストビューのプロモーションのカルーセル（1枚目のバナー画像）です。カルーセルの表示データはAPIから取得されており、描画されるまでには、複数のAPIが直列に呼び出されていました。

実測の LCP 約4秒のうち、約3.5秒がAPIの応答待ちでした。カルーセルのデータ（banners）は、このうち最後に届く top の応答から取り出されていました。ところが、約1.7秒早く届く guest/me の応答にも、JSONとして完全に同一の banners（13件）が含まれていました。

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

ゲスト閲覧時は、guest/me の応答に含まれる banners からカルーセルを描画する形に変えました。ログイン時のユーザー情報APIは banners を含まないため、従来どおり top の値を使います。APIの内容や画面の見た目は変えていません。

シミュレーション結果 ​

実測の LCP が4.04秒から2.32秒へと約43%短縮される結果が得られました。本研究で観測されたサイト固有のボトルネックの中で、最も大きな変化です。3回の計測値はいずれも2.31〜2.33秒に収まっており、揺らぎの小さい変化でした。

一方、Lighthouse の LCP は解消前後とも0.3〜0.7秒の範囲で揺らいでおり、この変化をほとんど捉えていません。APIのサーバー処理の待ち時間がシミュレーションに十分に反映されないためです。同じデータを持つ2つのAPIのうち、遅いほうの応答を待っていたという取得元の違いだけで、主要コンテンツの表示が1.7秒遅れていたことが、このシミュレーション結果から読み取れます。

ボトルネック2: 外部CSSがローディング画面の描画を止めている ​

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

観察された状況 ​

このページのHTMLには、インラインの <style> だけで作られたローディング画面（自転車のイラストの GIF）が用意されていました。ところが、ブラウザのトレースを確認すると、このローディング画面は一度も描画されていませんでした。

原因は2つ重なっていました。1つは、head内の外部 CSS（styles-*.css）がレンダリングをブロックしており、この CSS が届くまではローディング画面も描画できなかったことです。もう1つは、CSS が届くころにはアプリの起動処理が始まり、document.body.innerHTML = '' でローディング画面を消去していたことです。その結果、最初の描画はアプリ本体の表示までずれ込み、ユーザーはその間、真っ白な画面を見ていました。Lighthouse の FCP は0.1秒未満と報告されていましたが、このボトルネックの検証を始めた時点の実測の FCP は約1.5秒でした。

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

外部 CSS を media="print" で読み込み、読み込み完了時に media を all へ戻す形にしました。アプリ本体は、CSS の適用完了を待ってから描画するようにしています。ローディング画面に必要なスタイルはすでにインラインで揃っているため、見た目は変わりません。

なお、このシミュレーションは、ローディング画面の GIF を別ドメインからの配信からHTMLへの埋め込みに置き換えた状態の上で行っています。GIF の埋め込みだけでは、実測の FCP は変化しませんでした。

シミュレーション結果 ​

実測の FCP が1.54秒から0.47秒へと約7割短縮される結果が得られました。HTMLのパース直後にローディング画面が描画されるようになったためです。解消後の0.47秒のうち約0.45秒はHTMLのサーバー応答時間（TTFB）で、パースと描画にかかっていたのは約0.02秒でした。

Lighthouse の FCP は解消前から0.1秒未満で、この1秒以上の差を映していません。用意されていたローディング画面が CSS 1本の読み込み待ちと起動処理の順序によって表示されず、真っ白な時間を生んでいたことが、このシミュレーション結果から読み取れます。

ボトルネック3: アプリの起動が終わるまでAPIの要求が始まらない ​

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

観察された状況 ​

ボトルネック1の解消後、カルーセルは guest/me の応答から描画されるようになりました。しかし、その guest/me の要求は、アプリ本体のモジュール約370個の取得と評価が終わる約0.8秒の時点まで始まっていませんでした。guest/me はサーバー処理に約0.95秒かかるため、アプリの起動を待つ時間が、そのまま LCP に上乗せされていました。

既定の店舗情報をHTMLに初期値として持たせ、店舗を解決するAPIの応答待ちを省いたシミュレーションの上では、初回訪問のゲストが要求するURLとヘッダーはアプリの起動前から確定しています。

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

HTMLのインラインスクリプトで、初回訪問のゲスト向けの guest/me と店舗情報の要求を先に開始し、アプリ側でその結果を1回だけ再利用する形にしました。ログイン済みの場合や、配送先を保存済みの場合は対象外とし、従来どおりアプリが要求します。要求の回数は変わらず、重複もしていません。

シミュレーション結果 ​

guest/me の要求開始が約0.82秒から約0.45秒（HTMLの受信直後）に早まり、実測の LCP が約20%短縮される結果が得られました。アプリの起動とAPIのサーバー処理が並行して進むようになったためです。Lighthouse の LCP は横ばいでしたが、SI には約15%の短縮が表れています。

解消後の実測の LCP 1.49秒の内訳は、HTMLの TTFB が約0.45秒、guest/me のサーバー処理が約0.95秒、LCP 画像のダウンロードが約0.06秒です。アプリの起動を待つ時間はクリティカルパスから消え、残りの大部分はサーバー側の処理時間になりました。SPAの起動を待ってからデータを取りにいく順序が、主要コンテンツの表示を遅らせていたことが、このシミュレーション結果から読み取れます。

まとめ ​

イトーヨーカドーネットスーパーのトップページの表示速度を観測したところ、総合スコア 79、実測の FCP 2.6秒、LCP 4.1秒という値が計測されました。本研究では、記録時の高速な通信を再現した環境で、Lighthouse のシミュレーション値に加えて、ブラウザで実際に記録された時刻を観測しながら、ボトルネックを順に解消するシミュレーションを実施しました。

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

• サードパーティータグ（67リソース）: 除去によって 総合スコア が79から100へ、LCP が5.5秒から1.0秒へ変化。転送量約27KBの Microsoft Clarity 1つの除去で 総合スコア が12ポイント変化しました。一方で、タグの除去と TBT のボトルネック2件の解消を終えた時点でも、実測の LCP は約4.0秒でした。
• LCPのデータを最も遅いAPIから取得する構造: 取得元を同じデータを持つ早いAPIに切り替えることで、実測の LCP が4.04秒から2.32秒へ約43%短縮。
• 外部CSSに描画を止められるローディング画面: CSS の非同期読み込みによって、実測の FCP が1.54秒から0.47秒へ約7割短縮。用意されていたローディング画面が、一度も表示されていませんでした。
• アプリの起動を待つAPIの要求: HTML内で要求を先に開始することで、実測の LCP が約20%短縮。

この他にも、既定の配送先でも店舗を解決するAPIの応答を待っていた構造を解消するシミュレーションでは、実測の LCP が約0.43秒短縮しました。画像の縮小やDOMの削減を重ねたシミュレーションでは、ページ全体の転送量が約6.07MBから約1.22MBへ、DOM要素数が1,528から613へ変化しています。

全ボトルネックの解消シミュレーションを重ねた結果、実測の LCP は4.1秒から1.5秒へ、FCP は2.6秒から0.5秒へと変化しました。サードパーティータグを除去した時点で 総合スコア は100に達していましたが、タグの除去と TBT のボトルネック2件の解消を終えた時点でも、実測の LCP は約4.0秒でした。APIの取得元や要求の順序といった、Lighthouse のシミュレーションには表れにくいSPAの構造が、主要コンテンツの表示を秒単位で左右していたことが、この一連のシミュレーションから読み取れます。