「ニコリオ」トップページの表示速度ボトルネック研究

NICORIO（ニコリオ）は、サプリメントや化粧品を取り扱う公式オンラインショップです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

観測時点	全ボトルネック解消シミュレーション後

総合スコア が71から100へと29ポイント変化するというシミュレーション結果が得られました。特に FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が2.2秒から0.1秒へ、CLS（Cumulative Layout Shift = レイアウトのずれの大きさ）が0.474から0.024へと大きな変化が観測されており、これらの指標に強く影響するボトルネックが存在していたことが読み取れます。

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

本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見て取れます。

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

詳細レポート

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

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

オリジナルページの全155リソースのうち、サイト固有のリソースは129件（約8割）、サードパーティタグ由来のリソースは26件（約2割）を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの2割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。

www.nicorio.co.jp で確認されたサードパーティータグは次のとおりです。

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

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

合計28件のサードパーティーリソースが読み込まれていました。

段階的除去によるスコア推移 ​

サードパーティータグを全て除去した状態では、総合スコア は71から72へ変化し、スクリプト転送サイズは1.53MBから190.5KBへ大幅に削減される結果が得られました。スコアへの直接的な影響は+1ポイントと限定的でしたが、28件のリソースによるネットワーク負荷は大きく、サードパーティータグの最適化には一定の改善ポテンシャルがあることが読み取れます。本サイトのパフォーマンス上のボトルネックは、サードパーティータグよりもCSS構成やCDN配信方法にあることが、この検証から明らかになりました。以降のセクションでは、タグ除去後の状態を起点としてサイト固有のボトルネックを観察していきます。

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

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

ボトルネック1: CSSが多数のファイルに分散している ​

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

観察された状況 ​

HTMLから18個の CSS ファイルが <link> タグで参照されており、さらにそのうちの import.css が @import で11個の CSS を追加で読み込む構造になっていました。合計約30個の CSS ファイルが存在し、特に @import による直列読み込み（ファイルをダウンロードしてパースし、そこで初めて次のファイルの存在が判明する連鎖構造）が FCP を大きく遅延させていることが観測されました。

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

約30個の CSS ファイルを1つのファイルに結合し、@import チェーンを完全に解消した状態を作りました。

<!-- 変更前: 18個の<link>タグ + @importによる11個の追加CSS -->
<link rel="stylesheet" href="/contents/css/common/font-awesome.min.css">
<link rel="stylesheet" href="/contents/css/common/animate.min.css">
<link rel="stylesheet" href="/contents/shop/uukan/css/slick.css">
<!-- ... 合計18個 -->

<!-- 変更後: 1つに結合 -->
<link rel="stylesheet" href="/contents/css/common/bundle.css">

シミュレーション結果 ​

約30個に分散していた CSS ファイルを1つに結合することで、FCP が0.8秒、LCP が1.4秒短縮されるというシミュレーション結果が得られました。特に @import による直列読み込みは、ファイル数に比例して遅延が累積する構造であり、これが FCP の大きなボトルネックであったことが読み取れます。

なお、CSSの統合・1ファイル化は、現在では HTTP/2 の普及などにより必ずしも有効なプラクティスとは限りません。今回のシミュレーションのように良好な結果が観測されることもありますが、参考程度にとどめてください。

ボトルネック2: CDNリソースが外部ドメインから配信されている ​

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

観察された状況 ​

cdnjs.cloudflare.com と maxcdn.bootstrapcdn.com という外部CDNドメインから、JavaScript 3ファイルと CSS 1ファイルが読み込まれている状態でした。外部ドメインへのリクエストでは DNS 解決と TLS ハンドシェイクが追加で必要になるため、同一ドメインからの配信と比べて接続確立に時間がかかります。Lighthouse の render-blocking-resources 診断でも、これらのリソースが指摘されていました。

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

外部CDNから配信されていた4つのリソースを、同一ドメイン（www.nicorio.co.jp）から配信するよう変更しました。

<!-- 変更前: 外部CDNから読み込み -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/iScroll/5.1.3/iscroll.min.js"></script>
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">

<!-- 変更後: 同一ドメインから読み込み -->
<script src="https://www.nicorio.co.jp/cdn/cdnjs.cloudflare.com/ajax/libs/iScroll/5.1.3/iscroll.min.js"></script>
<link rel="stylesheet" href="https://www.nicorio.co.jp/cdn/maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">

シミュレーション結果 ​

外部CDNから同一ドメインへの移管によって、FCP が1.2秒短縮されるというシミュレーション結果が得られました。DNS 解決と TLS ハンドシェイクの接続コストが排除されたことで、レンダリングブロックリソースの取得が高速化した結果です。外部CDNからのリソース配信が FCP に対して大きなボトルネックとなっていたことが読み取れます。

ボトルネック3: カルーセルがレイアウトシフトを発生させている ​

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

観察された状況 ​

ファーストビューに配置されたSlickスライダーが、JavaScript初期化前に全スライドが display: none となり非表示になった後、初期化完了時に突然表示されるという動作が観測されました。この表示/非表示の切り替わりによって大きなレイアウトシフトが発生しており、CLS が0.474という高い値を示していました。

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

CSSで最初のスライドをJavaScript初期化前から表示させ、さらにカルーセルの高さを aspect-ratio で事前に確保することで、初期化前後のレイアウト変化を抑制する変更を加えました。

/* 最初のスライドをJS初期化前から表示 */
.slick-slide:first-child {
  display: block;
}

/* カルーセルの高さを事前確保 */
.homevisual_wrapper {
  aspect-ratio: 1 / 1;
}

シミュレーション結果 ​

カルーセルのレイアウトシフトを抑制するシミュレーションにより、CLS が0.474から0.021へ、総合スコア が22ポイント変化するという結果が得られました。0.474というのは CLS の「不良」判定（0.25以上）を大きく超える値であり、このカルーセルの初期化挙動がページ全体のスコアに与えていた影響の大きさが読み取れます。

まとめ ​

ニコリオ公式ストア（www.nicorio.co.jp）の表示速度を観測したところ、総合スコア 71、FCP 2.2秒、CLS 0.474という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• CSSの多数分散と@importチェーン: 約30個のCSSファイルを1つに結合するシミュレーションで FCP が0.8秒、LCP が1.4秒短縮。直列読み込み構造が大きなボトルネックでした。
• 外部CDNドメインからのリソース配信: 同一ドメインへの移管で FCP が1.2秒短縮。DNS解決・TLSハンドシェイクの接続コストが影響していました。
• カルーセルのレイアウトシフト: Slickスライダーの初期化挙動の抑制で CLS が0.453低減、総合スコア が22ポイント変化。ファーストビューのスライダーが最大のCLSボトルネックでした。
• サードパーティータグ: 28件のリソース除去でスクリプト転送サイズが1.53MBから190.5KBに削減。ただしスコアへの影響は+1ポイントと限定的でした。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は71から100へ、FCP は2.2秒から0.1秒へ、CLS は0.474から0.024へと変化しました。CSS構成とカルーセルの初期化挙動という、サイト固有の構造的要因が表示速度の主要なボトルネックであったことが、この一連のシミュレーションによって確認できた形です。