「マキアレイベル」トップページの表示速度ボトルネック研究

株式会社JIMOSが運営する、スキンケア・メイクアップブランド「マキアレイベル」の公式オンラインショップです。美容液ファンデーションの「薬用クリアエステヴェール」や、バブル化粧水の「薬用マイクロバブルローション」などを扱っています。トップページには新商品やキャンペーンのカルーセル、BEST ITEMS、トピックス、シリーズ紹介、ランキングなどが並び、メニューは画面の右から引き出すドロワー形式です。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は24でした。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は15.6秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は7.8秒、TBT（Total Blocking Time = メインスレッドのブロック時間）は811ms、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.880で、いずれも「低速」の範囲に入っていました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は1.2秒です。解消シミュレーション後は 総合スコア が100に達し、LCP は0.1秒、SI は0.2秒、CLS は0.000まで変化しました。転送量も22.64MBから3.80MBへ、リソース数も460件から202件へ減っています。

なお、本研究の Lighthouse は、記録した通信を再生する環境で、CPUの速度制限をかけない条件で計測しています。そのため LCP や FCP は PageSpeed Insights のモバイル計測で見る値より小さく出ます。解消シミュレーション後の FCP 0.1秒は、HTMLのサーバー応答時間よりも小さい推定値です。また、解消シミュレーション後の値には、HTMLと静的ファイルのサーバー応答を高速な環境に置き換えた2件のシミュレーションが含まれます。サーバー側のシミュレーションを適用する前の時点で、総合スコア はすでに100、LCP は0.45秒、FCP は0.42秒、SI は1.04秒に達していました。

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

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

観測時点では再生開始から数秒経ってもほとんどの領域が白いままで、読み込み完了まで20秒以上かかっています。解消シミュレーション後は、ごく早い段階でファーストビューの表示が完成しています。Webフォントと画像の意匠は、解消シミュレーション後も維持しています。

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

詳細レポート

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

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

観測時点のページの全460リソースのうち、サードパーティータグ由来のリソースは253件（約5.5割）を占めていました。展開後のデータ量では40.49MBのうち22.74MB（約56%）がタグ側です。jQueryなどのライブラリは自社サーバーから配信されており、日本語Webフォントの配信（morisawafonts.net）と公開CDNの1ファイルは、サイト側で配信方法を変えられるためサイト固有のリソースとして数えています。

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

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

KARTEは </head> の直前に、async と defer のどちらも付かない同期スクリプトとして置かれており、ファーストビューの直下に表示される「定期キャンペーン」のバナーは、HTMLではなくこのツールが後から挿入していました。このバナー画像が観測時点の LCP 要素でした。

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

KARTEの除去だけで LCP は15.6秒から0.9秒へ変化し、総合スコア は24から50へ上がりました。TBT は Google Ads と Google Tag Manager の除去で514ms、0msと段階的に減り、観測時点の811msのほぼ全量が、HTML直書きとタグマネージャー経由の Google Ads（gtag.js）を中心とする広告タグによるものであったことが分かります。CLS が2.051へ増えているのは、読み込みが速くなり、それまで計測区間の外で起きていたページ本来のレイアウトのずれが計測されるようになったためです。これは後述するサイト固有のボトルネックです。

サードパーティータグを全て除去した状態では、総合スコア は24から75へ、LCP は15.6秒から0.8秒へ、SI は7.8秒から1.4秒へ、TBT は811msから0msへ変化する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

1秒未満の値が多くなるため、以下の表では時間の値を小数点第2位まで示しています。

ボトルネック1: カルーセルの初期化前に5枚が縦に積まれる ​

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

観察された状況 ​

サードパーティータグを除去した時点の CLS は2.051で、Core Web Vitalsの「良好」の基準（0.1）の20倍を超えていました。その最大の要因が、ファーストビューのカルーセル（slick）です。JavaScript で初期化されるまで、5枚のスライドが縦に積まれた状態（約2,195px）で表示され、初期化と同時に1枚分（439px）へ畳まれていました。この約1,760pxの縮みが、その下のコンテンツをまとめて引き上げていました。

さらに、カルーセルの CSS と JavaScript は </body> の直前に置かれていたため、この畳み込みは読み込みの最終盤まで起きません。ユーザーがBEST ITEMS以降を見始めたころに、ページ全体が跳ね上がる状態でした。

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

初期化前のカルーセルに対して、CSS だけで「1枚目のみを表示し、画像の縦横比（750:800）で高さを確保する」指定を加えました。後から挿入されるページ送りのドットの領域も、初期化前に限って確保しています。HTMLと JavaScript には手を加えていません。JavaScript を無効にした状態でも、1枚目だけが表示され、以降のコンテンツが正しい位置に並ぶことを確認しています。

シミュレーション結果 ​

CLS は2.051から0.311へ変化し、総合スコア は75から85へ上がりました。LCP が延びているのは、レイアウトのずれが止まってファーストビューに収まる要素が変わり、LCP 要素の確定するタイミングが動いたためです。

残った0.311の大半は、img 要素に寸法が指定されていないことによるずれでした。HTML内の158個の img のうち height 属性を持つものは0個で、151個に実寸の width と height 属性を付けるシミュレーションでは、CLS は0.311から0.045へ、総合スコア は85から100へ変化しています。このシミュレーション結果から、初期化前のカルーセルのレイアウトが、このページの CLS の大半を生んでいたボトルネックであったことが読み取れます。

ボトルネック2: Webフォントの定義CSSが別ドメインから届く ​

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

観察された状況 ​

このページは、日本語Webフォントをフォント配信サービスから読み込んでいます。ブランドの世界観を表現するうえで、書体にこだわりたい気持ちはよく分かります。ネットワークのタイムラインを再構成したところ、その定義CSS（mf.css）が、最初の描画を待たせている最後のリソースになっていました。

mf.css は別ドメイン（morisawafonts.net）から配信されるため、TCP接続に16.9ms、TLSのハンドシェイクに13.3ms、サーバーの応答（TTFB）に238msがかかっていました。受信完了は約1.49秒で、同じドメインから配信される最も遅いリソース（jQuery、約1.27秒）より約0.22秒遅く、その到着を待って描画が始まっていました。

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

mf.css と、そこから参照されるwoff2フォント18本を、HTMLと同じドメインから配信する形に置き換えました。mf.css 内のフォントの参照先はルート相対パスのため、フォントファイルも同時に移しています。フォントは1書体も減らしておらず、見た目の差分がないことを確認しています。

シミュレーション結果 ​

LCP は1.24秒から0.64秒へ、FCP は0.85秒から0.64秒へ変化しました。CSS 自体の応答待ちに加え、そこから連なるフォント18本の取得も、すでに確立している同一ドメインの接続にまとまったためです。

続いて、公開CDN（cdn.jsdelivr.net）から同期読み込みされていた数KBの js.cookie.min.js を同一ドメインに移すシミュレーションでは、FCP と LCP がともに0.64秒から0.44秒へ変化し、Lighthouse のレンダリングブロックの指摘は0件になりました。2つの別ドメインを解消しただけで、FCP は0.85秒から0.44秒へ約半分になっています。

研究の途中では、日本語Webフォントの読み込み自体をやめるシミュレーションも行いました。別ドメイン配信のままの時点では LCP が約0.56秒短くなりましたが、同一ドメインに移した後では、フォントをやめた状態のほうが FCP と LCP のいずれでも遅いという結果になっています。このシミュレーション結果から、このページではWebフォントの容量そのものよりも、定義CSSが別ドメインから届くことが、最初の描画を遅らせるボトルネックであったことが読み取れます。

ボトルネック3: 画面外のメニューが画像とDOMを先に読み込む ​

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

観察された状況 ​

ハンバーガーボタンで開くドロワーメニューと検索のサブメニューは、position: fixed; right: -100% で画面の外に退避されているだけで、display: none にはなっていませんでした。ブラウザから見ると、これらは「表示中」の要素です。そのため、研究の途中でメニュー内の画像に loading="lazy" を付けても遅延の判定が効かず、画像56本・約700KBが初回表示時にダウンロードされていました。

HTMLの静的なDOM 1,031要素のうち、357要素（34.6%）もこの2つのメニューが占めていました。メニューを開かないユーザーの場合でも、これらの取得と解析は毎回発生していたことになります。メニューをすぐ開ける状態で前もって組み立てておきたい、という作りの意図は理解できます。

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

2つのメニューの中身を <template> 要素に移し、ハンバーガーボタンが初めて押されたときにDOMへ注入する形にしました。<template> の中身はDOMに含まれず、中の画像も取得されません。メニューとサブメニューが従来どおり開閉することを確認しています。

シミュレーション結果 ​

短縮の割合は LCP で約70%、FCP で約74%です。Lighthouse のDOMサイズと総転送量の監査も、合格に変わりました。これより前に画像をWebPへ変換したシミュレーションでは、画像の転送量を約39%減らしても LCP はほとんど動きませんでしたが、このメニューの扱いを変えたときには LCP と FCP が大きく動いています。このシミュレーション結果から、画面外に置かれたメニューが、見えないにもかかわらず初回表示の取得と処理を押し広げていたボトルネックであったことが読み取れます。

まとめ ​

マキアレイベルのトップページの表示速度を観測したところ、総合スコア 24、LCP 15.6秒、SI 7.8秒、TBT 811ms、CLS 0.880という値が計測されました。本研究では、これらの計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（253リソース）: 全て除去した状態では 総合スコア が24から75へ、LCP が15.6秒から0.8秒へ、TBT が811msから0msへ変化。特に、ファーストビュー直下のバナーを描画していたWeb接客ツールの除去だけで LCP が15.6秒から0.9秒へ変化しました。
• 初期化前のカルーセルのレイアウト: CSS で1枚目の領域を先に確保することで、CLS が2.051から0.311へ変化。img の寸法指定とあわせると0.045となり、総合スコア は100に達しました。
• 別ドメインから届くWebフォントの定義CSS: 同一ドメインからの配信に置き換えることで、LCP が1.24秒から0.64秒へ変化。公開CDNのライブラリとあわせると、FCP は0.85秒から0.44秒へ約半分になりました。
• 画面外に置かれたメニュー: 初回タップ時の注入に置き換えることで、LCP が0.25秒から0.08秒へ、初期DOMが1,171要素から816要素へ変化しました。

このほか、約1.19秒かかっていたHTMLのサーバー応答、HTMLの58.6%を占めていた __VIEWSTATE の値、PNG・JPEGのまま配信されていた約14.7MBの画像、unload ハンドラによって無効になっていたバックフォワードキャッシュ、キャッシュ設定のない171件のリソースなども観測されています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は24から100へ、LCP は15.6秒から0.1秒へ、SI は7.8秒から0.2秒へと変化しました。サードパーティータグに加え、初期化前のカルーセルのレイアウト、別ドメインから届くWebフォントの定義CSS、画面外に置かれたメニューといった要素が、このページの表示速度に大きな影響を与えていたことが、この一連のシミュレーションによって読み取れます。