ECサイトのパフォーマンスバジェットとCore Web Vitals
パフォーマンスバジェットとは、機能開発の前にチームが合意するページ重量・リクエスト数・Core Web Vitalsスコアの上限値です。リリースのたびに確認することで、ECサイトを意図的に高速に保ち、速度低下を顧客に届く前に検知します。
ソリューションレビューを予約する 関連ソリューションを見る著者： Netbase Commerce and Platform Engineering Desk · 監修： David (CEO) · 更新日 · 1 分で読める
このガイドは、ECサイトのページ速度を担当するECマネージャー、エンジニアリングリード、マーケティングリードを対象としています。対象は、カスタムECプラットフォームガイドで取り上げる大規模な再構築の一環として取り組む場合も、ECサイト開発がプラットフォーム移行なしに実行できる単独の速度改善施策として取り組む場合も含みます。
このガイドの目次
- パフォーマンスバジェットに含めるべき内容とは？
- 状況に合ったアプローチの選び方
- パフォーマンスバジェットの設定と運用方法
- パフォーマンスバジェットにおけるAIの役割
- 実績として存在するものと、存在しないもの
- 代替アプローチ：正式なバジェットなしにチームが対応する方法
- このガイドの限界
- よくある質問
- 次のステップ
パフォーマンスバジェットに含めるべき内容とは？
バジェットには2種類の数値が必要です。1つ目はGoogleの3つのCore Web Vitals指標です：Largest Contentful Paint（LCP）2.5秒以下、Interaction to Next Paint（INP）200ミリ秒以下、Cumulative Layout Shift（CLS）0.1以下。いずれも実際の訪問の75パーセンタイルで計測し、これがGoogleが「良好」と定義するラインです。2つ目は、1つ目の指標をクリアし続けるためのビルド時の上限値です：ページ重量の上限、リクエスト数の上限、ページが読み込んでよいサードパーティスクリプトのドメイン数の上限です。Googleのweb.devガイダンスも同様の枠組みを示しています。任意のサイトに対して、サンプルの上限値（例：Lighthouseパフォーマンススコア、JavaScriptサイズ上限、描画時間の目標値）を合意し、それをビルドプロセスで強制する——一度チェックするだけでなく継続的に。数値は推測ではなく、計測したベースラインから設定してください。代表的な商品ページをコールドキャッシュ状態でブラウザのネットワークパネルを使って開き、転送バイト総数・リクエスト数・サードパーティドメイン数を記録します。この3つがバジェットの初期上限値となり、時間とともに緩めるのではなく、引き締めていきます。
状況に合ったアプローチの選び方
| オプション | 強み | リスク | 選ぶべき状況 |
|---|---|---|---|
| バジェットとリリースゲートのみ（再構築なし） | 導入コストが最も低く、最速 | 現在のアーキテクチャの限界がそのまま残る | プラットフォームは十分だが、サードパーティスクリプトやアセットの管理が緩んでいる場合 |
| ターゲット最適化スプリント（画像・JavaScript・サードパーティ監査） | アーキテクチャを変えずに目に見える改善が得られる | バジェットによる継続的な管理がなければ改善は元に戻る | 現在Core Web Vitalsが不合格だが、プラットフォーム自体がボトルネックではない場合 |
| ヘッドレスまたはアーキテクチャ変更 | プラットフォームレベルのレンダリング上限を取り除ける | 新しいフロントエンドを持つ大きなプロジェクトになる | ヘッドレスコマース比較で、現在のプラットフォームのレンダリング（コンテンツやスクリプトではなく）が上限であることが示されている場合 |
| 完全なプラットフォーム移行 | パフォーマンスを含むすべてをリセットできる | コスト最大、プロジェクト期間最長 | パフォーマンスがカスタムECプラットフォームガイドの「修正できないパフォーマンス」行に挙げられる複数の理由の1つである場合 |
パフォーマンスバジェットの設定と運用方法
-
代表的なページのベースラインを計測する。
コールドキャッシュ状態でネットワークパネルを使い、ページ重量・リクエスト数・サードパーティドメイン数、およびLCP・INP・CLSを実ユーザーまたはラボツールで記録します。
-
バジェットをオーナー付きのポリシーとして文書化する。
Core Web Vitalsの3つの合格ラインとビルド時の3つの上限値、各項目の変更を承認する担当者、ポリシーの保管場所を明記します。一時的なターゲットではなく、継続的なポリシーとして扱います。
-
すべてのリリースを出荷前にバジェットに照らしてゲートする。
出荷後ではなく出荷前に、ビルド時チェックまたはリリース前チェックリストで確認します。バジェットを超えたリリースはブロック・修正するか、日付と担当者を明記した例外として扱い、暗黙の了解で出荷しません。
-
テーマ・アプリ・タグマネージャー・サードパーティスクリプトの変更後は必ず再計測する。
四半期ごとのスケジュールではなく、変更のたびに実施します。ほとんどの回帰は、コードの書き直しではなく、善意のマーケティングや分析ツールの追加1件によってもたらされます。
-
最新値だけでなく、トレンドを報告する。
複数の小さなリリースにわたる緩やかな悪化を、バジェットを明確に超える前に把握できるようにします。
パフォーマンスバジェットにおけるAIの役割
Netbaseは、主要な商用・オープンソースのAIツールおよびモデルを活用しており、特定のベンダーに縛られず、プロジェクトごとに最適なものを選択します。
AIの機能も他のスクリプトと同様に扱います。バジェット内での枠を確保するものであり、バジェットから免除されるものではありません。
-
成長機能：AIを活用した画像・アセット最適化。
モデルベースの圧縮とフォーマット選択により、固定プリセットでは対応しきれないページ重量の削減が可能です。ただし、これはNetbaseの公開済みケースにはまだ紐付いていません。
-
実績：商品レコメンドエンジン。
Netbaseが4over4のオンライン印刷ストアに、閲覧・購買履歴をもとに構築したものです。ページのメインコンテンツより後に読み込まれる設計になっていますが、ページ重量やCore Web Vitalsへの影響を単独で示す公開数値はありません。
実績として存在するものと、存在しないもの
NetbaseのECクライアントであるUSticker社は、デザインツール利用者のページ読み込み時間が21%短縮され、同時にコンバージョン率が40%増加、完成デザイン数が32%増加、6カ月間の継続率が25%上昇したことを計測しています。このページ読み込みの数値は、フロントエンドの速度改善をコマース成果に結びつけた、Netbaseの唯一の登録済み結果です。これは1クライアント自身の計測によるページ読み込みのパーセンテージであり、Core Web VitalsスコアやLighthouseの数値ではありません。
存在しないもの：プロジェクトの前後を問わず、クライアントのLCP・INP・CLSスコアを公開したNetbaseの記録はなく、いずれのクライアントについてもLighthouseスコアは公開されていません。このガイドで説明するCore Web Vitalsのベースライン計測とゲート運用を必要とする事業者は、それが既存の記録としてではなく、新規のディスカバリー作業として見込む必要があります。
代替アプローチ：正式なバジェットなしにチームが対応する方法
-
Search Consoleや順位下落が問題を検知するまで待つ
- 強み
- 事前のプロセス構築が不要
- 選ぶべき状況
- 遅延対応と、コンバージョン損失の未計測期間を許容できる場合
-
継続的なガバナンスなしの一回限りの監査
- 強み
- すぐに目に見える成果が得られる
- 選ぶべき状況
- 改善が元に戻ることを受け入れられる場合。Googleの調査では、バジェットなしで速度改善を行ったブランドの40%が6カ月以内に回帰しています
-
このガイドで説明する正式なバジェットとリリースゲート
- 強み
- 監査で得た改善を維持できる
- 選ぶべき状況
- ポリシーを担当できる人材がおり、ゲート運用できるリリースプロセスが存在する場合
このガイドの限界
- ここで示すCore Web Vitalsのしきい値とバジェットの数値例は、GoogleおよびWeb.devの公開ガイダンスに基づくものであり、Netbase独自のベンチマークではありません。実際の目標値は、自社のトラフィック・デバイス比率・カタログ規模によって異なります。
- 以下に引用するDeloitte-Googleのコンバージョン調査は、業界横断・複数ブランドを対象とした研究です。速度とコマース成果の相関を示すエビデンスであり、個々のストアへの保証ではありません。
- NetbaseクライアントのCore Web Vitalsスコアは公開されていないため、このガイドはNetbaseの前後比較のVitalsケースを示すことができません。代わりに、バジェット設定の方法と1件のページ読み込み結果（USticker）を示しています。
Netbaseコンサルタントと次のステップを計画する
よくある質問
Googleが公開している「良好」の基準は、実際の訪問の75パーセンタイルで計測した場合、Largest Contentful Paintが2.5秒以下、Interaction to Next Paintが200ミリ秒以下、Cumulative Layout Shiftが0.1以下です。
そのリリースは修正されるまでブロックされるか、日付と担当者を明記した例外として出荷し、再計測と期日内の回帰修正を約束します。違反しても何も起きないバジェットは、バジェットではなくダッシュボードに過ぎません。
いいえ。バジェットは現在のアーキテクチャをいかに活かすかを管理するものです。カスタムECプラットフォームガイドで「修正できないパフォーマンス」として説明しているように、プラットフォーム自体のレンダリングが上限である場合、バジェットはその上限を把握する助けにはなりますが、取り除くことはできません。
次のステップ
最も負荷の高い商品ページの現在のページ重量・リクエスト数・Core Web VitalsスコアをNetbase JSCにお知らせください。書面によるバジェットとリリースゲートの策定をご支援します。まずはソリューションレビューをご予約ください。プラットフォーム全体の判断の一部としてバジェットをご検討の場合はECマーケットプレイスソリューションを、ベンダーやカタログ規模も検討事項に含まれる場合はマーケットプレイスプラットフォームアーキテクチャガイドも合わせてご参照ください。
このガイドに関連する実績
キプロスの印刷・デザインサービス会社Geo-Tek IT Solutionsは、あらゆるデバイスで動作し、既存システムと連携するオンラインデザインプラットフォームを必要としていました。Netbase JSCは、アップロードおよびカスタマイズツールを備えたレスポンシブECサイトを構築・統合し、遠隔で納品しました。ローンチ後の最初の四半期で売上が36%増加しました。
続きを読む
スイスのラベル・締結・収縮技術サプライヤーであるNetztech Handels AGは、多くの注文を処理するオンラインストアをMagento 1 Community EditionからMagento 2 Commerceへ移行する必要がありました。Netbase JSCがリモートで移行を実施し、全店舗データの移行・11モジュールの再構築・新デザインの適用を35営業日で完了しました。
続きを読む関連サービスとソリューション
テンプレートを卒業したマーチャント向け、AI対応ECサイト開発
Netbaseは、テンプレートを卒業したマーチャント向けにカスタムECサイト開発を提供し、AIを活用した検索、レコメンデーション、カタログ作業で既存トラフィックを注文に変え、手作業を削減します。WooCommerce、Magento 2、Laravelおよびヘッドレス構成で構築し、AIレコメンデーションエンジンを導入した4over4は6カ月以内に売上82%増を報告しています。
詳しく見る
マルチベンダーマーケットプレイス開発：ベンダー・カタログ・支払い・AIサーチを一基盤に統合
マルチベンダーマーケットプレイスとは、多数の独立した販売者が一つのストアフロントで商品を出品・販売し、売上を受け取るコマースプラットフォームです。Netbaseのマーケットプレイスソリューションは、ベンダーオンボーディング・共有カタログ・分割決済・支払いをカバーし、検索・出品情報の補完・不正検知にAIを活用します。あるEUファッションテックマーケットプレイスでは、GMVが47%成長し、ベンダーオンボーディング時間が60%短縮されました。
詳しく見る
Netbaseにリモートで依頼する
Netbase JSCのすべての案件はリモートで納品されるため、どの国・業界のクライアントともお取引できます。これまで80カ国のクライアントと実績があります。契約・請求書はNetbase JSCが発行し、お支払いはNetbase JSCの口座への銀行振込またはPayPal Businessで行います。CEOのHuy Nguyen（David）にWhatsAppまたはメールでお問い合わせください。
プロジェクトを相談する
Netbase JSCは、デジタルプロダクトおよびAI活用ビジネスシステムの設計・構築・モダナイゼーション・運用を支援します。project@netbasejsc.com
+84 937 869 689
91 Nguyen Chi Thanh, Dong Da, Hanoi, Vietnam
お問い合わせ
構築・モダナイゼーション・運用したいものをお知らせください。