「板前魂本店」トップページの表示速度ボトルネック研究

おせち料理専門店「板前魂」の公式通販サイトです。盛付済みの新春おせち料理のほか、好みの料理を組み合わせられる「マイおせち」、ずわい蟹やローストビーフなどの特選商品を扱っています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア が57から100へと43ポイント変化するシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は38.7秒から0.1秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は19.0秒から0.7秒へと、極めて大きな変化が観測されています。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も4.2秒から0.1秒へ短縮されました。

なお、解消シミュレーション後の値には、静的ファイルをCDNから配信した場合の配信環境の試算が含まれます。HTML・CSS・JavaScript・画像の変更だけの段階でも、総合スコア は100、LCP は0.1秒、SI は1.1秒に達していました。

CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は表の上では変化していません。しかし実サイトにアクセスした計測では CLS 0.410が記録されており、この数値に表れないずれについては後述のボトルネック1で取り上げます。TBT（Total Blocking Time = メインスレッドのブロック時間）は、本研究の計測条件では観測時点から0msでした。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。観測時点では最初の描画が遅く、描画された後もメインビジュアルなどの画像が遅れて表示されます。解消シミュレーション後は、メインビジュアルを含むファーストビューが早い段階で一度に表示されます。読み込み中の転送量は10.42MBから0.92MBへ、読み込み完了までの時間は12.16秒から1.45秒へと変化しました。

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

詳細レポート

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

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

オリジナルページの全254リソースのうち、サイト固有のリソースは138件（54.3%）、サードパーティタグ由来のリソースは116件（45.7%）と、約半数を占めていました。なお、公開CDNから読み込まれている jQuery・lazysizes・Font Awesome や、Google Fonts の日本語Webフォントは、サイト側で読み込み方を変えられるものとしてサイト固有のリソースの側に数えています。

1osechi.com では14種類のサードパーティータグが検出されました。GTMの中から読み込まれるタグや、タグがさらに別のタグを読み込む連鎖も含まれています。

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

GTM経由で読み込まれているタグ ​

このほか、HTMLに直書きされた Google Analytics 4 と同じ測定IDが、GTMのコンテナ内でも設定されていました。

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

サードパーティータグを全て除去した状態では、総合スコア は57から67へ変化し、LCP は38.7秒から9.9秒へ、SI は19.0秒から4.1秒へと短縮される結果が得られました。タグが多数の外部ドメインへの接続と通信を発生させ、LCP画像と帯域を奪い合っていたことが、主に LCP と SI の変化として表れています。特に Criteo は転送量こそ約25KBと小さいものの、約20の広告事業者とのCookie同期を連鎖的に発生させており、その除去だけで LCP が6.4秒短縮しました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルの存在が読み取れます。以降のセクションでは、この状態を起点としてサイト固有のボトルネックを観察していきます。

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

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

ボトルネック1: メインビジュアルに寸法の指定がない ​

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

観察された状況 ​

ファーストビューのメインビジュアル（LCP 画像）の <img> に、width / height 属性が指定されていませんでした。画像の先頭部分が届いてサイズが判明するまで高さ0で描画され、判明した瞬間に高さ約393pxの領域が確保されるため、その下のセクション以降がまとめて押し下げられていました。実サイトにアクセスして計測した Lighthouse の結果では、このずれ1回で CLS が0.410に達していました。CLS は0.1以下が「良好」、0.25超が「不良」とされる指標です。

興味深いのは、このずれが当初はシミュレーションの計測に表れなかったことです。観測時点では最初の描画が遅く、画像のサイズが判明してレイアウトが確定した後に描画が始まっていたため、ずれが描画前に済んでいました。描画を遅らせていた CSS への対処で FCP が0.1秒まで早まった段階で、実サイトと同じ要素・同じ大きさのずれが計測に現れ、総合スコア は76から58へ下がりました（FCP の対処を終えた時点では56）。表示が速くなるほど、隠れていたレイアウトのずれが表に出てくることを示す経過です。

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

メインビジュアルの <img> に、画像の実寸である width="1000" と height="955" を指定しました。あわせて style="height: auto;" を付け、表示幅に合わせて縦横比を保ったまま縮小されるようにしています。画像の到着前に、ブラウザがこの比率から表示領域を確保できる状態を作り、その影響を計測しました。

シミュレーション結果 ​

属性を2つ加えただけで CLS が0.410から0.000になり、総合スコア が19ポイント変化する結果が得られました。全画像を読み込んだ後の最終的なレイアウトは変わっておらず、なくなったのは読み込み途中の押し下げだけです。この時点の LCP は同じ状態でも6.5〜16秒の間で揺らいでいたため、LCP の変化は評価の対象外としています。本研究で 総合スコア への影響が最も大きかったボトルネックであり、寸法の欠落が表示の安定性に与えていた影響の大きさが読み取れます。

ボトルネック2: LCP画像が約2MBのPNG ​

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

観察された状況 ​

LCP 要素は、金屏風を背景に人物とおせちを写したメインビジュアルの写真です。この写真が可逆圧縮の PNG 形式で保存されており、ファイルサイズは2,081,962バイト（約2MB）ありました。実寸1000×955pxに対し、スマートフォンでの表示は412×393pxです。レイアウトのずれへの対処を終えた時点で、LCP の86%（約7.8秒）がこの画像のダウンロード時間で占められていました。

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

同じ画像を品質80の非可逆 WebP に変換した状態を作り、その影響を計測しました。形式ごとのファイルサイズは次のとおりです。見た目の差分は0.025%でした。

シミュレーション結果 ​

画像形式を変えただけで LCP が5.4秒短縮し、総合スコア が16ポイント変化する結果が得られました。Lighthouse のトレース上で観測された実際の LCP も、9.9秒から3.2秒へ短縮しています。写真を可逆形式のまま配信していたことが、LCP に対して極めて大きなボトルネックとなっていたことがこの結果から読み取れます。

ボトルネック3: JavaScriptによる遅延読み込みが機能していない ​

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

観察された状況 ​

このサイトでは、DOMContentLoaded のタイミングでJavaScript（img_lazyload.js）が画面外の画像の src を仮画像に差し替え、lazysizes で後から読み込む方式の遅延読み込みが実装されていました。しかしブラウザは、HTMLを受け取った直後、JavaScriptが実行されるより前に、HTMLに書かれた src から画像のダウンロードを始めます（プリロードスキャナ）。そのため、この方式は遅延読み込みとして機能しておらず、画面外の画像約1.45MBが最初に全量ダウンロードされ、ほかに9件がダウンロードの途中で取り消されていました。これらの通信が LCP 画像と帯域・接続を奪い合っている状態が観測されました。

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

ヘッダーロゴとメインビジュアル（LCP 画像）を除く49件の画像に、ブラウザ標準の loading="lazy" 属性を付け、img_lazyload.js と lazysizes を削除した状態を作り、その影響を計測しました。HTMLの時点で遅延を指示できるため、プリロードスキャナの段階から画面外の画像が後回しになります。

シミュレーション結果 ​

最初に読み込まれる画像は画面から一定の距離内の26件に絞られ、途中で取り消される通信も9件から0件になりました。その結果、LCP が1.6秒短縮し、総合スコア が100に到達するシミュレーション結果が得られました。遅延読み込みの仕組み自体は用意されていたものの、ブラウザの読み込みの順序と噛み合っておらず、画面外の画像が LCP 画像の足を引っ張っていたことがこの結果から読み取れます。

まとめ ​

板前魂本店（1osechi.com）のトップページの表示速度を観測したところ、総合スコア 57、LCP 38.7秒、SI 19.0秒という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（14種類・116リソース）: 除去によって 総合スコア が+10、LCP が28.8秒短縮、SI が14.9秒短縮。GTMから読み込まれる Criteo が約20の広告事業者とのCookie同期を連鎖的に発生させていたことが特に目立ちました。
• メインビジュアルの寸法指定の欠落: 属性の追加で CLS が0.410から0.000へ、総合スコア が+19。表示が速くなるにつれて顕在化した、隠れたボトルネックでした。
• 約2MBのPNGで配信されるLCP画像: 非可逆 WebP への変換でファイルサイズが88%減少し、LCP が5.4秒短縮、総合スコア が+16。
• 機能していないJavaScriptの遅延読み込み: ブラウザ標準の loading="lazy" への置き換えで LCP が1.6秒短縮し、総合スコア が100に到達。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は57から100へ、LCP は38.7秒から0.1秒へと変化しました。サードパーティータグと約2MBの LCP 画像がそれぞれ LCP に大きな影響を与えていたことに加え、計測条件によっては数値に表れないレイアウトのずれが潜んでいたことも、この一連のシミュレーションによって確認できた形です。なお、最終的に残った実測の LCP の大半は、HTML本体のサーバー応答時間（約1.2秒）が占めていました。