「北の快適工房」トップページの表示速度ボトルネック研究

「北の快適工房」は、「ビックリするほど良い商品ができた時にしか発売しない」をコンセプトに掲げる、健康食品・化粧品の公式通販サイトです。目の下専用のクリーム「アイキララII」や、マイクロニードルのパッチ、オリゴ糖、医薬品まで、さまざまな商品を販売しています。スマートフォンでトップURLを開くとスマートフォン版のページ（/sp/）へ移動し、注意喚起のバナー、新商品やブランドの考え方を紹介するメインスライダー、メディア掲載のスライダー、40を超える商品の一覧が縦に並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は80でした。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は0.44秒、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は0.34秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は1.71秒、TBT（Total Blocking Time = メインスレッドのブロック時間）は0msで、いずれも「良好」の範囲に入っていました。総合スコア を押し下げていたのは CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）の0.479で、「不良」とされる0.25を大きく超えていました。解消シミュレーション後は CLS が0.000になり、総合スコア は100に達しています。

本研究の Lighthouse は、記録した通信を、記録時の応答時間と転送速度のまま再生する環境（ページ本体のHTMLで約25Mbps）で計測しています。観測時点から LCP・FCP が0.5秒未満と速いページのため、本記事では秒で表す指標を小数点第2位まで示します。

このページの CLS は、計測のたびに約0.48と約0.22のどちらかの値になる不安定な状態でした。観測時点の0.479は高い側の値です。このため、レイアウトのずれを扱う段階以降は、各シミュレーションを5回ずつ計測して中央値で比べています。また、解消シミュレーション後に残る SI 1.38秒のうち約1.0秒は、メインスライダーの自動切り替えによるものです。計測の最後の画面が2枚目のスライドだったため、1枚目を表示している間が「未完成」と評価されていました。

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

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

動画の上部に表示されているとおり、ページの読み込みに伴う転送量は4.94MBから0.93MBへ、読み込み完了（onload）までの時間は4.50秒から0.77秒へ変化しました。

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

詳細レポート

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

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

観測時点のページの全177リソースのうち、サードパーティータグ由来のリソースは40件（約2割）でした。件数では2割ですが、JavaScriptの転送量で見ると約460KBのうち約370KB、約8割がサードパーティータグでした。なお、別ドメインのPublic CDNから読み込まれていたjQueryは、サードパーティータグには含めず、後述の同一ドメイン化として扱っています。

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

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

ChatPlusは2つのドメインから30リクエストを発生させており、件数では最大のタグでした。Yahoo!アクセス解析のタグは、HTTPSのページからHTTPのスクリプトを document.write で読み込む方式のため、ブラウザに混在コンテンツとしてブロックされ、通信自体が発生していませんでした。旧式の ga.js は、GA4と並んで残っていたものです。

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

総合スコア は最初の段階で80から89へ上がっていますが、これは前述した CLS の揺れで、低い側の値（約0.22）が出たことによるものです。タグの除去による変化ではありません。タグはほぼすべて非同期で読み込まれており、各段階の LCP は0.42〜0.43秒の範囲で上下するにとどまりました。

サードパーティータグを全て除去した状態では、LCP は0.44秒から0.42秒へ、FCP は0.34秒から0.32秒へ変化し、TBT は除去前から0msのままでした。このページでは、タグが表示速度の指標に与えていた影響は限定的だったことになります。一方で、JavaScriptの転送量の約8割を占めていたことは、回線やCPUの遅い端末では無視できない負担です。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルのあることが読み取れます。

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

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

ボトルネック1: 画像に寸法の指定がない ​

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

観察された状況 ​

ページ内の148個の img 要素のうち、height 属性を持つものは0個でした。CSS で img { max-width:100%; height:auto; } が指定されているため、画像が届くまでは高さ0として配置され、届いた時点で高さが確定して下の要素を押し下げていました。

影響が特に大きかったのは、メインスライダーの直上に並ぶ注意喚起のバナー4枚です。画像の到着前は103pxだった枠が到着後に229pxへ伸び、スライダー以下の全体を約126px押し下げていました。このずれだけで CLS は0.17〜0.25に達していました。サードパーティータグを除いた状態で同じ計測を6回繰り返すと、CLS は0.207〜0.513の範囲で揺れていました。

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

スライダー内の画像を除く135個の画像に、画像ファイルの実寸の width・height 属性を追加しました。width="75%" のようにパーセントで幅を指定していた画像は、実寸を属性に移し、パーセントの幅は style 属性で指定しています。表示サイズは従来どおり CSS によって画面幅に合わせて縮小されるため、見た目は変わりません。

シミュレーション結果 ​

CLS の中央値は0.225から0.040へ変化し、総合スコア は100に達しました。5回のうち1回だけ0.307になった回があり、これはメインスライダーの初期化に由来するずれでした。初期化前は7枚のスライドが縦に並び（高さ約1,262px）、画像が届く前に初期化されると54pxまで縮み、その後211pxへ伸びる、スライダーの高さの変化です。続けて初期化前のレイアウトを CSS で固定し、ヘッダーのお知らせのティッカーで置き換え前後の寸法をそろえたシミュレーションでは、CLS は5回とも0.000になり、揺れもなくなりました。

ページの見た目を変えずに属性を加えるだけのシミュレーションで、総合スコア が11上がったことになります。このシミュレーション結果から、寸法の指定がない画像は、このページの 総合スコア を押し下げていた最大の要因であったことが読み取れます。

ボトルネック2: head内の同期スクリプトが描画を止める ​

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

観察された状況 ​

<head> の中で、jQuery、スライダーのプラグイン BxSlider、サイトのスクリプトの3本が同期的に読み込まれていました。ブラウザは3本の取得と実行が終わるまで、<body> の解析と最初の描画を進められません。jQueryは観測時点では別ドメインのPublic CDN（ajax.googleapis.com）から配信されており、同一ドメインからの配信に置き換えるシミュレーションでは FCP が0.31秒から0.28秒へ変化しました。この置き換えの後も、CSS は約229msの時点で揃っていたのに、jQueryの到着（約248ms）とスクリプトの実行を待っていた状態です。以下の結果は、この置き換えを行った後の状態を起点にしています。

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

3本のスクリプトを、読み込む順序を保ったまま </body> の直前へ移動しました。3本は互いに依存しているため、async 属性は付けていません。スクリプトを後ろへ移すとスライダーの初期化より前に描画が始まりますが、ボトルネック1に続くシミュレーションでスライダーの初期化前のレイアウトを固定していたため、レイアウトのずれは発生しませんでした。

シミュレーション結果 ​

LCP が FCP より大きく変化したのは、注意喚起のバナーやスライダーの画像といったファーストビューの画像の描画が、スクリプトの実行を待たなくなったためです。観測時点から速いページのため絶対値は小さいものの、LCP は約3割短くなっています。このシミュレーション結果から、<head> の同期スクリプトがファーストビューの描画を待たせていたボトルネックであったことが読み取れます。

ボトルネック3: HTMLの後にCSSを取りに行く往復 ​

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

観察された状況 ​

スクリプトを移動した後、最初の描画は3本の CSS（style.css・style_d1.css・item.css）が全て揃うのを待って行われていました。3本を1本に結合するシミュレーションでは FCP が0.26秒から0.23秒へ変化しましたが、その後も「HTMLの取得完了（141ms）→ style.css の取得完了（198ms）→ 最初の描画」という順序が残りました。HTMLを受け取ってから CSS を取りに行く1往復（約57ms）が、描画の待ち時間になっていた状態です。

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

結合した style.css（圧縮後で約9KB）を、HTMLの <style> 要素に埋め込みました。CSS の中の相対パス58件は、基準の位置が変わるため絶対URLに書き換えています。全726要素の位置・サイズとスタイルが、変更前と一致することを確認しました。

シミュレーション結果 ​

CSS の取得待ちがなくなり、FCP はHTMLの取得完了の直後まで変化しました。LCP はファーストビューのスライダー画像の到着で決まるため、変化は小さくとどまっています。このシミュレーションでは、ページ間で CSS のブラウザキャッシュを共有できなくなることを前提にしています。このシミュレーション結果から、HTMLの後に CSS を取りに行く1往復をなくすことで、最初の描画までの時間を約2割短くできることが読み取れます。

まとめ ​

北の快適工房のトップページの表示速度を観測したところ、総合スコア 80、LCP 0.44秒、FCP 0.34秒、CLS 0.479という値が計測されました。時間の指標は観測時点から「良好」の範囲にあり、総合スコア を押し下げていたのは、計測のたびに揺れるレイアウトのずれでした。

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

• サードパーティータグ（40リソース）: JavaScriptの転送量の約8割を占めていた一方、全て除去した状態でも LCP は0.44秒から0.42秒への変化にとどまりました。ほぼすべてが非同期で読み込まれていたためです。
• 画像に寸法の指定がない: 実寸の width・height 属性を加えることで、CLS（5回の中央値）が0.225から0.040へ、総合スコア が89から100へ変化しました。スライダーとティッカーの初期化前後の寸法をそろえると、CLS は0.000になりました。
• head内の同期スクリプト: </body> の直前へ移動することで、LCP が0.39秒から0.28秒へ変化しました。
• HTMLの後にCSSを取りに行く往復: CSS をHTMLに埋め込むことで、FCP が0.23秒から0.18秒へ変化しました。

このほか、スマートフォンでトップURLを開くと、/sp/ へのリダイレクトがHTTPのURLを経由して行われていたことも観測されています。トップURLで直接スマートフォン版のHTMLを返すサーバー側のシミュレーションでは、LCP・FCP が0.18秒から0.15秒へ変化しました。また、ページ内の画像は全てJPEG・PNG・GIFで、WebPへの変換や遅延読み込みなどのシミュレーションでは、読み込み時の画像の転送量が4.41MBから約0.9MBへ減っています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は80から100へ、CLS は0.479から0.000へ、LCP は0.44秒から0.15秒へと変化しました。もともと速いページであっても、寸法の指定がない画像とスライダーの初期化によるレイアウトのずれが 総合スコア を大きく押し下げていたこと、そしてそのずれが計測のたびに揺れて見えにくくなっていたことが、この一連のシミュレーションによって読み取れます。