「ほぼ日ストア」トップページの表示速度ボトルネック研究

糸井重里さんが主宰するWebサイト「ほぼ日刊イトイ新聞」の通販コーナーで、株式会社ほぼ日が運営しています。「ほぼ日手帳」をはじめ、ウェアやファッション小物、生活雑貨、インテリアなど、オリジナル商品を中心に扱うECサイトです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

今回の研究は、Lighthouse のモバイル設定で、回線とCPUの追加の速度制限をかけずに計測しています。そのため観測時点から 総合スコア は99と高く、スコアの変化は+1にとどまりました。一方で指標を見ると、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が0.7秒から0.05秒へ、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が0.8秒から0.05秒へと、いずれも9割以上短縮される結果が得られました。SI（Speed Index = ビューの視覚的な表示進捗の速さ）も3.3秒から0.3秒へ短縮しています。高いスコアの裏側にも、表示速度に影響するボトルネックが残っていたことが読み取れます。

TBT（Total Blocking Time = メインスレッドのブロック時間）は今回の計測条件では観測時点から0msでした。CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）も観測時点で0.012と小さく、解消シミュレーション後は0になりました。

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

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

この動画はスマートフォンを想定し、回線速度 約10Mbps・CPUを4倍遅くした条件で記録しています。この条件では、ページの読み込み完了（onload）までの時間が4.78秒から1.23秒へ、通信量が3.99MBから0.89MBへ変化しました。

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

詳細レポート

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

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

オリジナルページの全221リソースのうち、サイト固有のリソースは173件（約8割）、サードパーティタグ由来のリソースは48件（約2割）を占めていました。なお、Google Fontsはサイト側で配信方法を変えられるため、サードパーティータグではなくサイト固有のリソースとして数えています。

1101.com のHTMLから直接、またはタグマネージャー経由などで読み込まれていたサードパーティータグは次のとおりです。

HTMLから直接読み込み、または自社JavaScriptから注入:

Google Tag Manager経由で読み込み:

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

サードパーティータグを全て除去した状態では、総合スコア は99から100へ、SI は3.3秒から1.2秒へと約63%短縮される結果が得られました。タグが使っていた転送量は約830KB、メインスレッドの処理時間は合計約240msです。タグの読み込みは最初の描画より後に始まるため、FCP（0.7秒）と LCP（0.8秒）への影響は限られていた一方、表示が落ち着くまでの時間には大きな影響が観測されました。特に Google Tag Manager のコンテナ本体を除去した段階で大きく変化しており、コンテナ経由で次々に読み込まれるタグの通信と実行によって、表示の進行が引き延ばされていたと読み取れます。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあると読み取れます。

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

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

なお、ここから先の解消シミュレーションでは FCP や LCP の値が小さく、同じ状態でも計測ごとに値が揺らぎます。そのため、各シミュレーションは3回計測し、中央値で比較しています。

ボトルネック1: Google FontsのCSSを別ドメインから読み込み ​

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

観察された状況 ​

FCP の内訳を分解すると、その約93%（約650ms）を、fonts.googleapis.com から読み込むGoogle Fontsの CSS 1本が占めていました。CSS はレンダリングブロックリソース（全ての読み込みが完了するまでページの描画が停止するリソース）です。別ドメインのリソースは DNS の名前解決・TCP 接続・TLS の確立が必要なうえ、Googleのサーバーが端末に合わせて CSS を動的に生成して返すため、応答にも時間がかかっていました（記録された応答時間は499ms）。

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

Google Fontsが返すものと同じ内容の CSS を、HTMLと同じドメイン（www.1101.com）のURLから配信する状態を作り、その影響を計測しました。フォントファイル本体は引き続き fonts.gstatic.com から読み込む構成です。

シミュレーション結果 ​

FCP が中央値で0.72秒から0.08秒へと約9割短縮される結果が得られました。LCP にあたるヒーロー画像の描画も CSS を待たなくなり、大きく短縮しています。さらに、同じ CSS を静的ファイルとして配信した場合の応答時間を再現すると、ブラウザで実際に最初の描画が行われた時刻は1,129msから657msへと約470ms早まりました。CSS の中身は同じで、配信元のドメインが変わっただけです。このシミュレーション結果から、別ドメインのレンダリングブロック CSS 1本が FCP のほとんどを決めていたこと、つまり本研究で最も影響の大きいボトルネックであったことが分かります。

ボトルネック2: ファーストビュー外の画像33枚をLCPより前に取得 ​

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

観察された状況 ​

LCP の対象はファーストビューのヒーロー画像（カルーセルの1枚目）です。この画像自体は画像CDNによって WebP・約24KBで配信されており、すでに軽量でした。ところが、ファーストビューより下にある特集カード31枚とピックアップ2枚の画像（約1.1MB）が、HTMLの解析時にすぐに要求され、LCP より前にダウンロードされていました。Lighthouse のシミュレーションでは、LCP より前に完了したリクエストが LCP までに必要な処理として見積もられるため、LCP 画像が小さくても、ほかの画像の分だけ LCP が遅く見積もられます。実際の回線でも、LCP 画像とほかの画像が帯域を奪い合う形で表示を遅らせる構造です。

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

ファーストビュー外にある特集カードとピックアップの画像33枚へ loading="lazy" を付け、画面へ近づいた時点で読み込まれる状態を作りました。ファーストビュー内の画像には付けていません。

シミュレーション結果 ​

LCP が中央値で0.24秒から0.15秒へと約4割短縮される結果が得られました。LCP 画像そのものには手を加えておらず、ほかの画像の読み込みタイミングを変えただけです。画面に表示されていない画像の先読みが、LCP の見積もりを大きく押し上げていたことがこの結果から読み取れます。

ボトルネック3: 表示されないヒーロー画像をLCPより前に取得 ​

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

観察された状況 ​

ヒーローはフェードによって切り替わるカルーセルであり、最初に表示されるのは1枚目だけです。しかし、2〜9枚目の原寸画像（800×1200px等、8枚・約690KB）も LCP より前にダウンロードされていました。原因は、ヒーローの下に並ぶサムネイル（40px角）が、ヒーローと同じURLの原寸画像を参照していたことです。画面内にある2〜5枚目のサムネイルは高い優先度で要求され、結果として表示されていないヒーロー画像まで先に取得されていました。ヒーロー側だけに loading="lazy" を付けても、サムネイルが同じ画像を即座に要求するため LCP は変わらず、サムネイルだけを縮小した場合も同様でした。ヒーローとサムネイルの2つの参照が重なって生じていた、このサイト固有のボトルネックです。

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

ヒーロー2〜9枚目の画像に loading="lazy" を付けたうえで、サムネイル2〜9枚目は表示サイズに合った縮小画像を参照する状態を作りました。このサイトは画像CDNを利用しており、URLに ?width=120 を付けるだけで縮小画像を得られます。縮小画像8枚の合計は約29KBです。

シミュレーション結果 ​

LCP が中央値で0.15秒から0.07秒へと約半分になる結果が得られました。ヒーロー2〜9枚目の原寸画像は、カルーセルの初期化後（読み込み開始から約0.6秒）に取得される形となり、最初の自動切り替え（5秒後）には間に合っています。ボトルネック2と合わせると、LCP 画像以外の画像約1.8MBの先読みを後回しにしたことで、LCP は中央値で0.24秒から0.07秒へと約7割短縮しました。LCP 画像そのものが軽量でも、同時に読み込まれる画像の構成によって LCP が大きく左右されていたことが、この結果から読み取れます。

まとめ ​

ほぼ日ストアのトップページの表示速度を観測したところ、総合スコア 99、FCP 0.7秒、LCP 0.8秒、SI 3.3秒という値が計測されました。スコアはすでに高い水準でしたが、本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（7種類・48リソース）: 除去によって SI が3.3秒から1.2秒へ約63%短縮。特に Google Tag Manager のコンテナとそこから読み込まれるタグが、表示が落ち着くまでの時間を引き延ばしていました。
• 別ドメインから読み込むGoogle FontsのCSS: 同一ドメインからの配信により、FCP が中央値で0.72秒から0.08秒へ約9割短縮。FCP の約93%をこの CSS 1本が占めていました。
• ファーストビュー外の画像33枚のLCP前の取得: 遅延読み込みによって LCP が中央値で約4割短縮。
• 表示されないヒーロー画像のLCP前の取得: サムネイルとの参照の重なりを解くことで、LCP がさらに約半分に短縮。

このほか、日本語Webフォント（Noto Sans JP、約730KB）の読み込みを除いた場合には、転送量が約760KiB、リクエストが42件減る結果も観測されています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は99から100へ、FCP は0.7秒から0.05秒へ、LCP は0.8秒から0.05秒へ、SI は3.3秒から0.3秒へと変化しました。一方、すべての解消シミュレーションの後も、ブラウザで実際に最初の描画が行われるまでには約605msかかっており、その大半はHTML自体の応答時間（約503ms）でした。Lighthouse のスコアが高いページであっても、別ドメインのレンダリングブロック CSS や画像の読み込み構成といった要素が表示速度に大きな影響を与えていたことが、この一連のシミュレーションによって確認できた形です。