BtoB EC表示速度の改善手順｜計測から対策まで

◆監修・編集責任者　小園 将隆　2026年8月24日

B2B EC-COLUMN

BtoB EC表示速度改善の全体像 ― 合格ラインは3指標の75パーセンタイル

BtoB ECの表示速度改善は、LCP2.5秒・INP200ミリ秒・CLS0.1をいずれも実ユーザーの75パーセンタイルで満たすことを合格ラインとします^*1。計測・内訳分解・サーバー側・フロント側・維持の5手順で進める取り組みです。

BtoB ECの表示速度改善とは、ログイン後の受発注画面を対象にした取り組みです。表示の速さ（LCP＝Largest Contentful Paint、主要な要素が表示されるまでの時間）を実測します。あわせて測るのが、操作の反応（INP、操作から画面が反応するまでの時間）です。表示の安定（CLS、レイアウトのずれの量）も同様に確認する必要があります。Googleが示す基準まで数値を引き上げるため、計測・内訳分解・対策・再計測を順に回します^*1。Core Web Vitalsは検索のランキングシステムで使用されており^*2、合格ラインに届かない状態は検索経由の流入にも関わる要因です。

合格ラインはLCP2.5秒・INP200ミリ秒・CLS0.1

Googleの公式ドキュメントは、LCPは2.5秒以内、INPは200ミリ秒以内、CLSは0.1以内を「良好」の目安として示しています^*1。判定は1回の計測ではなく、実ユーザーの計測値を集めた分布の75パーセンタイルで見ることが推奨されています^*1。

75パーセンタイルとは、計測した全アクセスのうち遅い方から数えて25%の地点を指します。平均値ではなく75パーセンタイルを使う理由は、通信環境や端末が不利なユーザーの体験まで含めて基準を満たすことを求めているためです^*1。

改善は「計測→内訳分解→サーバー側→フロント側→維持」の5段で進める

表示速度改善は施策を思いついた順に試すのではなく、原因の特定を先に済ませてから対策に進める順序が有効です。計測でスコアを確認し、内訳分解で原因の所在を切り分け、サーバー側とフロント側の対策を分けて実施し、最後に維持の仕組みを設けます。

この順序を踏まないと、原因がサーバー側にあるにもかかわらず画像圧縮のようなフロント側の施策だけを試み、効果が出ないまま工数を消費する事態につながります。

BtoB ECではフロント側より先にサーバー側を疑う理由

公開されたECサイトの表示速度改善では、CDNによるページ全体のキャッシュが定番の対策として扱われます。しかしBtoB ECの受発注画面はログインが前提であり、取引先ごとに表示内容が異なるため、この定番策がそのまま効きにくいという制約があります。

取引先別の価格や在庫の算出は、画面を表示するたびにサーバー側で計算する設計になっている場合が少なくありません。この処理にかかる時間（TTFB＝Time to First Byte、最初の応答が届くまでの時間）が表示速度全体を左右します^*3。そのためBtoB ECでは、フロント側の見た目の調整より先に、サーバー側の応答時間を疑って調べる進め方が合理的です。

BtoB ECで表示速度が落ちる固有の要因

ログイン必須のためフルページキャッシュが効かない

フルページキャッシュとは、生成済みのHTML全体をそのまま配信する仕組みです。公開ページでは有効ですが、BtoB ECの受発注画面は取引先ごとに表示が変わるため、画面全体を一括でキャッシュすると誤った価格や在庫を表示するおそれがあります。

そのため、共通部分だけを部分的にキャッシュし、取引先固有の情報は都度取得する設計が必要になります。

取引先別価格・数量割引の都度計算がサーバー応答を押し上げる

取引先ごとの掛け率や数量割引の計算をリクエストごとに実行する設計では、計算処理の分だけサーバー側の応答時間が延びます。この応答時間の遅れは、LCPの内訳のうちTTFBの割合を押し上げる主因になります^*3。

サーバー側の応答遅延を放置すると、LCPの内訳におけるTTFBが推奨配分の目安（約40%）を大きく超えたまま固定化します。この状態ではフロント側の対策だけでは合格ラインに届きません^*3。

リアルタイム在庫・基幹システムへの同期問い合わせ

画面表示のたびに基幹システムへ在庫を問い合わせる設計も、応答時間を延ばす要因になります。特に外部システムとの通信が同期処理（応答が返るまで次の処理を待つ方式）になっている場合、通信の遅延がそのまま画面表示の遅延に直結します。

型番検索・大量SKUという重い資産

SKU（在庫管理上の最小単位）を数万件規模で保有するBtoB ECでは、型番検索やカタログの検索処理が重くなりやすい傾向があります。この処理の重さが検索結果画面の応答時間に影響します。

可視化した要因を自社の数字で確かめるには、無料相談で要件を整理するのが近道です。

手順1：現状を計測する

フィールドデータとラボデータの役割の違い

計測には、実ユーザーの実際のアクセスを集計した「フィールドデータ」と、制御された環境で1回計測する「ラボデータ」の2種類があります。フィールドデータは実際の利用環境を反映する一方、原因の切り分けにはラボデータでの再現計測が役立ちます^*5。

ログイン後ページは公開データセットに現れない

CrUXが収集する実測値は、公開されている一般的なページのアクセスが中心です^*6。ログインが必要な受発注画面は対象に含まれにくいため、BtoB ECでは公開データセットに頼らず、自前で実測データを仕込む必要があります。

具体的には、ラボデータを取得するツールを社内の検証環境やログイン済みの実環境に向けて実行し、定期的に記録する仕組みを用意します。

計測対象は受注導線の主要画面に絞る

計測対象を全画面にすると工数が増えるため、受注導線上の主要な画面に絞って優先順位をつけます。

手順2：LCPを内訳分解して原因を特定する

4つの内訳と推奨配分

Googleの公式ドキュメントは、LCPを4つの内訳に分解する方法を示しています^*3。TTFB（最初の応答が届くまでの時間）、リソース読み込み開始の遅れ、リソースの読み込み時間、要素の描画の遅れの4つです。

推奨配分の目安は、TTFBが約40%、読み込み開始の遅れが10%未満、読み込み時間が約40%、描画の遅れが10%未満とされています^*3。

配分から読む典型パターン

実測した内訳を推奨配分と比べると、原因の所在を絞り込めます。TTFBの割合が大きければ、疑うべきはサーバー側の処理です。読み込み時間の割合が大きい場合は画像や配信の方式、描画の遅れが大きい場合はスクリプトの処理を疑います。

分解結果をベンダーへの依頼文に変換する

「遅い」という感覚的な依頼では、対応の見積もりが立ちません。内訳分解の結果を使えば、対象と目的を具体的に示した依頼文に変換できます。例えば「TTFBが推奨配分を超えているため、価格計算のキャッシュ設計を確認してほしい」という依頼文です。

手順3：サーバー側（TTFB）の応答を短縮する

価格・在庫の算出を事前計算とキャッシュに寄せる

取引先別価格や在庫の算出をリクエストごとに実行する設計から、変更があったタイミングで事前計算し結果を一時的に保持する設計へ寄せると、都度計算の負荷が下がります。画面全体でなく、価格や在庫の部分だけをキャッシュ対象にする点が、BtoB EC特有の工夫になります。

基幹システム・外部APIの同期呼び出しを画面表示から外す

画面の表示処理から基幹システムへの同期問い合わせを外します。あらかじめ取得しておいた値を参照する設計にすれば、外部システムの応答時間に画面表示が引きずられません。

この設計変更を内製で行うには、既存の基幹連携の仕様理解とキャッシュ機構の設計知識の両方が必要になり、相応の工数がかかります。

通信層の見直し（HTTP/3の採用・レスポンス圧縮・接続の再利用）

通信の方式そのものを見直す対策もあります。従来のHTTP/2では、1本の接続を複数の通信で共有しているため、途中でパケットが失われると同一接続上の全ての通信が影響を受けて停止します^*7。

後継のHTTP/3が使うQUICという方式では、通信ごとに信頼性を確保する仕組みのため、こうした停止の範囲を1本の通信に留められます^*7。レスポンスの圧縮や接続の再利用も、通信量と接続確立の手間を減らす対策として有効です。

手順4：フロント側（LCP・CLS・INP）を整える

主要画像の先読み（preload）と寸法指定で初期表示を早める

preloadは、現在のページ表示に必要なリソースを、ブラウザが先回りして取得・保持しておく仕組みです^*8。商品画像など主要な要素にpreloadを指定すると、読み込み開始の遅れを縮められます。画像には幅と高さを指定し、読み込み前の領域を確保しておくことも欠かせません。

レイアウトのずれ（CLS）を止める

CLSは、ページ読み込み中に要素の位置が予期せずずれる量を示す指標です^*1。あとから追加される通知バナーや広告枠のような要素は、事前に領域を確保しておくことでずれを防げます。

操作の反応（INP）を上げる

INPは3区間に分けて考えます^*4。入力待ち（Input delay）、処理時間（Processing duration）、描画待ち（Presentation delay）の3つです。入力待ちは他の処理でブラウザが混んでいる状態、処理時間はイベントの処理そのものにかかる時間、描画待ちは処理後に画面へ反映されるまでの時間を指します^*4。どの区間が長いかによって、対処すべき箇所（重い処理の分割・不要なスクリプトの見直しなど）が変わります。

手順5：改善を維持する

性能予算を決めてKPIに載せる

一度改善しても、機能追加や仕様変更によって表示速度は再び悪化します。LCP・INP・CLSの合格ラインを性能予算として定め、既存のKPIと並べて定期的に確認する仕組みを持つことが、改善を定着させる前提になります。

リリース時の回帰検知と繁忙期の負荷集中への備え

機能を追加するたびに表示速度を計測し、性能予算を超えていないかを確認する運用にすると、劣化を早期に見つけられます。月末や繁忙期のようにアクセスが集中する時期は、通常時と分けて計測しておくと変化を捉えやすくなります。

事業側とベンダーの分担を決める

性能予算や計測の運用は事業側が主体となり、価格・在庫算出の設計やインフラ構成の変更はベンダー側が担う、という分担を事前に決めておきます。こうしておくと、劣化の発見から対処までの動きが速くなります。システムのリプレイスを検討している場合は、RFP（提案依頼書）に合格ラインと計測条件を性能要件として明記しておくのも有効です。

内製での対応と専門パートナーへの依頼では、担う範囲が異なります。事業側だけで対応する場合、担当範囲の中心は計測・運用です。価格・在庫算出の設計変更や通信層の見直しまで踏み込むには、パッケージシステム側の実装知識を持つ専門パートナーとの連携が現実的な選択になります。

まとめ ― 表示速度改善を進める3つの判断軸

本稿では、BtoB EC表示速度の改善手順を計測から維持まで5段で整理しました。要点を3つに集約すると次の通りです。第一に、合格ラインはLCP2.5秒・INP200ミリ秒・CLS0.1を実ユーザーの75パーセンタイルで満たすことです^*1。第二に、BtoB ECでは取引先別価格やリアルタイム在庫の都度計算が原因になりやすく、フロント側より先にサーバー側を疑う必要があります。第三に、改善は一度で終わらせず、性能予算とKPIによって維持する仕組みまで含めて設計することです。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

BtoB ECの表示速度は、どのくらいを目標にすればよいですか。

LCP2.5秒以内・INP200ミリ秒以内・CLS0.1以内を、実ユーザーの75パーセンタイルで満たすことが目標です^*1。この3指標はGoogleが良好な体験の目安として示している基準です。

ログインが必要なページの速度は、どうやって測ればよいですか。

公開ページ向けの計測ツールが参照する実測データは、ログイン後の画面を含めにくい仕組みです^*6。ログイン済みの実環境や検証環境に対してラボ計測し、自前でフィールドデータに近い記録を蓄積する必要があります。

画像を軽くしても速くならないのは、なぜですか。

LCPの内訳のうちTTFBが推奨配分（約40%）を超えている場合、原因はサーバー側の応答遅延にあり、画像の軽量化は読み込み時間の内訳にしか効きません^*3。内訳分解で原因の所在を確認してから対策を選ぶ必要があります。

表示速度の改善は、どこから着手するのが現実的ですか。

まず現状を計測し、LCPを内訳分解して原因の所在を特定することから始めます^*3。原因がサーバー側にあると分かった場合は、価格・在庫算出のキャッシュ設計から着手するのが現実的です。

表示速度は検索順位に影響しますか。

Core Web Vitalsは検索のランキングシステムで使用されています^*2。ただし順位を決める要因の一つであり、表示速度だけで順位が決まるわけではありません。

1. *1　出典：Google「Web Vitals」（web.dev / Articles、2024年10月更新）https://web.dev/articles/vitals
2. *2　出典：Google「Understanding page experience in Google Search results」（Search Central、2025年12月更新）https://developers.google.com/search/docs/appearance/page-experience
3. *3　出典：Google「Optimize Largest Contentful Paint」（web.dev / Articles、2025年3月更新）https://web.dev/articles/optimize-lcp
4. *4　出典：Google「Optimize Interaction to Next Paint」（web.dev / Articles、2025年9月更新）https://web.dev/articles/optimize-inp
5. *5　出典：Google「About PageSpeed Insights」（Google for Developers）https://developers.google.com/speed/docs/insights/v5/about
6. *6　出典：Google「Overview of the Chrome UX Report」（Chrome for Developers）https://developer.chrome.com/docs/crux
7. *7　出典：IETF「RFC 9114: HTTP/3」（2022年6月）https://datatracker.ietf.org/doc/html/rfc9114
8. *8　出典：WHATWG「HTML Living Standard」link type “preload”（2026年8月更新）https://html.spec.whatwg.org/multipage/links.html#link-type-preload