「honu加藤珈琲店」トップページの表示速度ボトルネック研究

愛知県名古屋市のhonu加藤珈琲店株式会社が運営する、コーヒー豆の通販サイトです。カップ・オブ・エクセレンス受賞豆やスペシャルティコーヒー、オリジナルブレンド、ドリップバッグ、福袋のようなまとめ買いのセットまで、幅広いコーヒーを扱っています。スマートフォン向けのトップページには、セールのバナー、日替わりクーポン、おすすめ商品やタイムセールの一覧、営業日カレンダーが並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

本研究の Lighthouse は、記録した通信を再生する環境で、CPUの速度制限をかけない条件で計測しています。帯域も広い条件のため、観測時点から 総合スコア は100で、解消シミュレーション後も100のまま変わりませんでした。

一方で指標を見ると、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は1.5秒から0.4秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も1.5秒から0.4秒へと、いずれも約4分の1に短縮されています。SI（Speed Index = ビューの視覚的な表示進捗の速さ）も1.6秒から0.4秒へ変化しました。TBT（Total Blocking Time = メインスレッドのブロック時間）と CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は観測時点から0でしたが、後述するように、計測の条件次第で表面化するボトルネックが見つかっています。満点のスコアの裏側にも、表示速度に影響するボトルネックが残っていたことが読み取れます。

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

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

観測時点では真っ白な画面がしばらく続きます。一方、解消シミュレーション後はほぼ即座にヘッダーとバナーが表示されています。動画の計測条件では、ページの転送量が10.82MBから1.56MBへ、読み込み完了（onload）までの時間が9.08秒から1.86秒へ変化しました。

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

詳細レポート

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

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

観測時点のページの全121リソースのうち、サードパーティータグ由来のリソースは31件（約4分の1）でした。jQueryなどのライブラリは公開CDNではなくECプラットフォームのバンドルとして配信されており、タグ側の31件はすべてタグマネージャー、アクセス解析、広告計測、行動トラッキング、監視のためのものです。転送量は Google Tag Manager 配下だけで約754KB、New Relic のスクリプトが約129KB、直書きの Google Analytics が約136KBで、合計1MB近くに達していました。

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

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

New Relic Browser Agent は <head> 内で async や defer を付けずに同期で読み込まれていました。また、直書きの Google Analytics と Google Tag Manager 経由の Google Analytics は同じ計測IDで、2系統から読み込まれていました。

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

各段階の変化はいずれも±0.04秒以内で、計測の揺らぎの範囲に収まりました。タグのほとんどが非同期で読み込まれ、約1.5秒の初回描画より後に実行されていたためです。見た目の変化もなく、除去の前後でスクリーンショットの差分は0%でした。

サードパーティータグを全て除去した状態でも、この計測条件では 総合スコア は100のまま、LCP も1.5秒のままで、描画指標への影響は観測されませんでした。ただし、これは初回描画が約1.5秒と遅かったことで、タグの読み込みが描画の後ろに隠れていたという面もあります。後述のサイト固有のボトルネックを解消して初回描画が約0.4秒まで早まると、約1MBのタグのダウンロードと実行は、描画の前後と重なってきます。これはあくまで上限値の観測であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: 外部CSSがあるだけで初回描画が約1秒遅れる ​

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

観察された状況 ​

読み込みの経過を調べると、HTMLは約0.33秒、<head> で読み込む外部 CSS 3本は約0.5秒に到着していました。HTMLの解析と JavaScript の実行も約0.6秒までに終わっています。それにもかかわらず初回描画が始まるのは約1.5秒で、約1秒間、ブラウザは何も描画していませんでした。

3本の CSS は、HTML（www.katocoffee.net）とは別のECプラットフォームの配信用ドメインから読み込まれていました。そこで、まず CSS を同一ドメインから配信し、続いて3本を1本に結合するシミュレーションを行いましたが、FCP はどちらも1.5秒のまま変わりませんでした。

原因を切り分けるため、ページを最小限のHTMLに縮小して試したところ、次の結果が得られました。

レンダリングをブロックする外部 CSS が1本でもあると、その到着後も初回描画は約1秒遅れました。この現象は再現性をもって観測されています。ブラウザ内部の詳しい仕組みまでは特定できていませんが、配信元のドメインや本数ではなく、外部 CSS の存在そのものが描画の開始を遅らせていました。

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

1本に結合した CSS（約372KB）を、<link> と同じ位置に <style> として埋め込みました。CSS の内容は変えていません。埋め込みでHTMLの転送量が増えた分は、その後のシミュレーションでトップページに使われないルールを削除し、gzip後の67.0KBから25.4KBまで減らしています。

シミュレーション結果 ​

FCP は1.5秒から0.5秒へ、LCP も1.5秒から0.5秒へ短くなり、初回描画はHTMLの解析完了とほぼ同時に始まるようになりました。総合スコア は解消前から100のため変わっていません。

この後、<head> 内で同期読み込みされていたECプラットフォームの JavaScript（webstore-vg.js）をbody末尾へ移すシミュレーションでは、FCP がさらに0.50秒から0.36秒へ変化し、初回描画はHTMLの到着直後から始まりました。このシミュレーション結果から、外部 CSS による描画開始の遅れは、このページの初回描画を約1秒遅らせていた最大のボトルネックであったことが読み取れます。

ボトルネック2: body内のGoogle FontsのCSSがバナーの描画を止める ​

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

観察された状況 ​

FCP に関するシミュレーションを終えた時点で、FCP 0.37秒に対して LCP は0.55秒で、約0.19秒の差がありました。LCP 要素のセールバナー画像は約0.41秒に到着しているのに、実際に描画されるのは約0.55秒です。LCP の内訳では、この「要素の描画遅延」が145msを占めていました。

原因は、ヘッダーのロゴの直後、つまりbody内で読み込まれていたGoogle Fonts（Material Icons Outlined）の CSS でした。ヘッダーのアイコン5個を表示するためのアイコンフォントです。body内の <link rel="stylesheet"> はその CSS が届くまでHTMLの解析を止めるため、後ろにあるバナー画像は到着済みでも描画できませんでした。fonts.googleapis.com への新規接続と応答には約155msかかっていました。

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

Google Fontsの CSS（830バイト）を、同じ位置に <style> として埋め込みました。アイコンの見た目は変えていません。

シミュレーション結果 ​

LCP は0.55秒から0.43秒へ、要素の描画遅延は145msから27msへ縮まりました。FCP は0.37秒前後のまま揺らぎの範囲でした。

研究ではその後、5個のアイコンをインラインの SVG に置き換え、155KBのアイコンフォントの読み込みそのものをなくすシミュレーションも行っています。わずか830バイトの CSS でも、別ドメインからbody内で読み込まれることで、ページの主要コンテンツであるバナーの描画を待たせていました。このシミュレーション結果から、body内のGoogle Fontsの CSS が LCP に与えていた影響の大きさが読み取れます。

ボトルネック3: ファーストビューのバナー画像に寸法がない ​

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

観察された状況 ​

通常の計測では、観測時点から CLS は0.000でした。ところが、サードパーティータグの除去を進めている途中の1回の計測で、CLS 0.618・総合スコア 77 という大きなレイアウトのずれが発生しました。

原因は、ファーストビューのセールバナー画像に width と height の属性がなかったことです。画像の到着が初回描画より遅れると、バナーは高さ0のまま描画され、到着後に約247pxへ広がってメインコンテンツ全体を押し下げていました。通常の計測で CLS が0だったのは、画像がたまたま描画に間に合っていたからだったことになります。

後に FCP に関するシミュレーションで初回描画が約0.37秒まで早まると、約0.41秒に到着するバナー画像は、初回描画より後から届くことになります。寸法の指定がなければ、同じずれが起こりうる状態でした。

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

セールバナー画像、ヘッダーのロゴ、日替わりクーポンの画像18件（計20件）に、実寸の width と height の属性を追加しました。あわせて img[width][height] { height: auto; } の1行を CSS に加え、表示上の大きさは変えずに、読み込み前から縦横比どおりの領域が確保されるようにしています。

シミュレーション結果 ​

解消後の3回の計測では CLS 0.000が続き、Lighthouse の「サイズが指定されていない画像」の指摘は52件から50件に減りました。ファーストビュー以外の49件の画像にも、その後のシミュレーションで寸法を付け、指摘は0件になっています。

このボトルネックは、通常の計測では数値に表れません。しかし画像の到着がわずかに遅れるだけで、総合スコア が100から77まで下がるほどのずれを生んでいました。このシミュレーション結果から、寸法のないバナー画像が、回線の状況次第で表面化する潜在的なボトルネックであったことが読み取れます。

まとめ ​

honu加藤珈琲店のトップページは、観測時点で 総合スコア 100という高い評価を得ていました。本研究では、回線やCPUの速度制限をかけない条件で計測しながら、満点のスコアの裏側にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（31リソース・約1MB）: 全て除去しても、この計測条件では LCP 1.5秒のまま変化は観測されませんでした。タグの多くが非同期で、遅い初回描画の後ろに隠れていました。
• 外部CSSによる初回描画の遅れ: CSS をHTMLに埋め込むことで、FCP が1.5秒から0.5秒へ変化しました。同一ドメイン化や結合では変化しなかった点が特徴的でした。
• body内のGoogle FontsのCSS: 埋め込むことで、LCP が0.55秒から0.43秒へ変化しました。
• ファーストビューのバナー画像に寸法がない: 画像の到着が遅れた計測で CLS 0.618・総合スコア 77を生んでいたずれが、寸法の指定で0.000になりました。

このほか、<head> 内の同期 JavaScript（FCP 0.50秒→0.36秒）、CPUを4倍遅くした条件で表面化する50ms超の長いタスク2件、初期表示時に約70枚の画像を一斉に取得していたこと（遅延読み込みやWebP化などで初期表示時の総転送量が約10.1MBから約0.66MBへ）なども観測されています。すべての解消シミュレーションを終えた時点では、LCP（0.4秒）の約8割をHTMLのサーバー応答時間（約0.33秒）が占めていました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は100のまま、LCP と FCP は1.5秒から0.4秒へ、SI は1.6秒から0.4秒へと変化しました。とりわけ、外部 CSS の存在そのものが初回描画を約1秒遅らせていたこと、計測では0だった CLS が条件次第で0.618まで跳ね上がる構造だったことは、スコアだけを見ていては見えにくいボトルネックでした。これらの要素がこのページの表示速度に大きな影響を与えていたことが、この一連のシミュレーションによって読み取れます。