「自然大好き！ニッチ・リッチ・キャッチ」トップページの表示速度ボトルネック研究

岡山県津山市に店舗を構えるアウトドア専門店、株式会社ニッチの通販サイトです。テントやランタン、薪ストーブなどのアウトドア用品に加え、発電機や草刈機といったパワーツール、空気清浄機などの生活家電も扱っています。トップページには、店舗の写真を並べたスライダー、特集バナー、ブランドロゴの一覧、商品カテゴリー、営業日カレンダーなどが並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア を最も押し下げていたのは、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）の0.586でした。Core Web Vitalsで「良好」とされる0.1を大きく超える値です。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は1.1秒、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は1.3秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は1.5秒でした。解消シミュレーション後は CLS が0になり、総合スコア は100に達しています。

なお、本研究の Lighthouse はCPUの速度制限をかけない条件で計測しています。TBT（Total Blocking Time = メインスレッドのブロック時間）の0msはこの条件での値です。また、Lighthouse の FCP や LCP は記録した読み込みをもとにしたシミュレーション値で、解消シミュレーション後の0.1秒は、HTMLが返ってくるまでの時間（約585ms）よりも小さい値になっています。そこで、計測中にブラウザが実際に描画した時刻（以下、実測値）もあわせて示します。

このページの LCP 要素は画像ではなく、ページ本体の先頭にある紹介文のテキストです。テキストは最初の描画と同時に表示されるため、実測の LCP は実測の FCP とほぼ同じ時刻になります。実測値でも約0.4秒の短縮が見られましたが、解消シミュレーション後に残る約0.7秒の大部分は、HTMLが返ってくるまでの時間でした。

この計測環境では、ページの内容と関係なく最初の描画だけがランダムに遅れる現象がたびたび発生しました。以降の比較は、この現象が起きなかった計測どうしで行っています。

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

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

この動画はスマートフォンを想定し、回線速度 約10Mbps・CPUを4倍遅くした条件で記録しています。

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

詳細レポート

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

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

観測時点のページの全195リソースのうち、サードパーティータグ由来のリソースは12件（約6%）でした。Google Fontsと公開CDNから読み込むjQueryは、サイト側で配信方法を変えられるため、サードパーティータグではなくサイト固有のリソースとして数えています。

HTMLに直接記述されていたタグは次の3つです。

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

サードパーティータグを全て除去した状態では、総合スコア は78から77とほぼ変わらず、SI が1.5秒から1.1秒へ短縮する結果が得られました。タグの転送量は約217KBで、そのうち約189KBをGoogleタグの gtag.js が占めていました。メインスレッドの処理時間は合計約41msです。いずれのタグも非同期で読み込まれていたため、FCP や LCP への影響は小さく、総合スコア は CLS の大きさに抑えられたままでした。2023年に計測を終えている Google Analytics 旧版の除去では、SI に約0.3秒の短縮が見られ、段階の中で最も大きな変化となりました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: 画像の幅と高さが指定されていない ​

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

観察された状況 ​

ページ内の画像132個のすべてに height 属性がなく、width 属性があるのも5個だけでした。サイズが指定されていない画像は、読み込みが終わるまで高さ0で配置され、読み込み後に下のコンテンツを押し下げます。特に影響が大きかったのは、ページ本体の先頭にあるバナー画像（970×194、外部メディアの掲載記事への案内）です。読み込み時に約77px伸び、その下の紹介文や商品一覧をまとめて押し下げていました。

このページでは、ファーストビューのスライダーもずれの原因になっていました。スライダーは jQuery のライブラリで初期化されるまで6枚の画像が縦に積み上がった状態で、初期化後に1行のレイアウトへ縮みます。初期化前の見た目を CSS で最終形に合わせる解消シミュレーションを先に行ったところ、CLS は0.677から0.543へ減りました。残った0.543が、次に述べる画像のずれによるものです。

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

すべての画像に、画像ファイルの実際の幅と高さを width / height 属性として追加しました。既存の CSS で画像の幅を画面に合わせている箇所があるため、img[width][height] { height: auto; } を加え、属性が縦横比の確保にだけ使われるようにしています。見た目の変化はありません。

シミュレーション結果 ​

5回の計測すべてで CLS が0になり、総合スコア は78から100へ変化しました。スライダーの初期表示と合わせると、最初の描画がいつ行われてもレイアウトがずれない状態になっています。表示までの時間はほとんど変わっておらず、このページの 総合スコア を抑えていた要因は、表示の速さではなくレイアウトの安定性にあったことが分かります。画像の属性の有無だけで 総合スコア が22動いたこのシミュレーション結果から、本研究で最も影響の大きいボトルネックであったことが読み取れます。

ボトルネック2: Google FontsのCSSが別ドメインから描画を止める ​

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

観察された状況 ​

見出しやメニューには、日本語のWebフォント「M PLUS Rounded 1c」がGoogle Fontsから読み込まれていました。display=swap が指定されているため、フォントファイル本体の到着は描画を待たせません。しかし、フォントを定義する CSS そのもの（約31KB、@font-face が126個）は、レンダリングブロックリソース（読み込みが完了するまでページの描画が停止するリソース）として扱われます。fonts.googleapis.com は別ドメインのため新しい接続が必要で、さらに応答待ちに約420msかかっていました。この CSS が届く約1.05秒まで、最初の描画が始まらない状態でした。

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

同じ内容の CSS を、HTMLと同じドメイン（www.shop-niche.co.jp）から配信する状態を作りました。応答時間は、同時に読み込まれている自社の CSS の実測値（28ms）に置き換えています。フォントの見た目は変わりません。

シミュレーション結果 ​

FCP が1.1秒から0.5秒へと約半分になる結果が得られました。応答時間を置き換えず、URLを同一ドメインに変えただけの条件でも、5回中3回の計測で FCP は0.5秒前後まで短縮しています。別ドメインへの新しい接続と、そこからの応答待ちが描画を止めていたことが分かります。

一方、実測の FCP は約1.10秒のまま変わりませんでした。同じくHTMLの head 内で別ドメインから読み込まれている jQuery の到着が、次のボトルネックとして残っていたためです。

ボトルネック3: jQueryを公開CDNから同期読み込み ​

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

観察された状況 ​

jQuery 1.11.0が、Googleの公開CDN（ajax.googleapis.com）からHTMLの head 内で同期的に読み込まれていました。同期的な <script> は、取得と実行が終わるまでHTMLの解析を止めます。CDNの応答待ちは約377msで、続くスライダーや自社スクリプトもすべて jQuery に依存して head 内に並んでいるため、この待ち時間がそのまま最初の描画を遅らせていました。

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

同じファイルをHTMLと同じドメインから配信する状態を作りました。応答時間は、自社のスクリプトの実測値（56ms）に置き換えています。

シミュレーション結果 ​

FCP は0.5秒から0.2秒へ、実測の FCP も1.10秒から0.88秒へと短縮する結果が得られました。ボトルネック2では実測値が動かなかったのに対し、ここで初めて実際の描画時刻が早まっています。URLだけを同一ドメインに変え、応答待ちを外部サーバーの記録値のままにした条件では、実測の FCP は約1.07秒にとどまりました。HTMLの解析が jQuery の到着を待つ時間の長さが、実際の描画時刻を決めていたことが分かります。ボトルネック2と合わせると、別ドメインから読み込む2つのリソースだけで、FCP は1.1秒から0.2秒へと変化しました。このシミュレーション結果から、別ドメインのレンダリングブロックリソースが、このページの表示の立ち上がりを大きく左右していたことが読み取れます。

まとめ ​

自然大好き！ニッチ・リッチ・キャッチのトップページの表示速度を観測したところ、総合スコア 78、CLS 0.586、FCP 1.1秒、LCP 1.3秒、SI 1.5秒という値が計測されました。本研究では、これらの計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（3種類・12リソース）: 除去によって SI が1.5秒から1.1秒へ短縮。いずれも非同期で読み込まれており、FCP と LCP への影響は小さいものでした。
• 画像の幅と高さが指定されていない: 属性の追加によって CLS が0.543から0になり、総合スコア が78から100へ変化。スライダーの初期表示によるずれも合わせて、レイアウトの不安定さが 総合スコア を抑えていました。
• 別ドメインから描画を止めるGoogle FontsのCSS: 同一ドメインからの配信によって、FCP が1.1秒から0.5秒へ短縮。
• 公開CDNから同期的に読み込むjQuery: 同一ドメインからの配信によって、FCP が0.5秒から0.2秒へ、実測の FCP が1.10秒から0.88秒へ短縮。

このほか、@import で15本に分かれていた自社 CSS を1ファイルにまとめた場合には実測の FCP がさらに約0.1秒早まり、画面外の画像112枚を遅延読み込みにした場合には LCP と FCP がともに0.1秒弱短縮する結果も観測されています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は78から100へ、CLS は0.586から0へ、実測の FCP は約1.1秒から約0.7秒へと変化しました。残る約0.7秒の大部分はHTMLが返ってくるまでの時間（約585ms）で、実サイトでの計測ではその大半を DNS の名前解決（約500ms）が占めていました。画像の属性の不足と、別ドメインから読み込む2つのリソースという限られた要素が、このページの表示速度とレイアウトの安定性に大きな影響を与えていたことが、この一連のシミュレーションによって確認できた形です。