WordPress アナリティクスプラグインのパフォーマンス: ストレステスト比較
ページキャッシュなしの並行負荷下で 8 つの WordPress アナリティクスプラグインをストレステストしました。Statnive が最も低い LCP オーバーヘッドでした。方法論、数値、そして正直な限界をご紹介します。
すべてのアナリティクスプラグインにはパフォーマンスコストがある
WordPress サイトにアナリティクスプラグインを追加することは、すべてのページロードに作業を加えることを意味します。一部のプラグインはブラウザでダウンロード、パース、実行される JavaScript を加えます。他はサーバー上で動く PHP を加えます。ページキャッシュ付きの軽負荷下では、ほとんどのプラグイン間の差は小さく見えます。合成ストレステスト下では — 並行ユーザー、キャッシュなし、すべてのリクエストが PHP にヒット — アーキテクチャ的な差が可視化されます。
私たちはそのストレステストを 8 つの人気 WordPress アナリティクスプラグインに対して走らせました。以下の結果は、各プラグインのアーキテクチャが並行負荷をどう扱うかの方向性的な差を示します。これらは本番運用の保証ではありません — それらが意味すること・しないことを、最後の率直な方法論限界セクションも含めて正確に歩いていきます。1 つだけ覚えるなら: 単一実行のストレステストで Statnive は最も低い LCP オーバーヘッドでしたが、これらのプラグインのいずれかを動かす適切にキャッシュされた本番 WordPress サイトは、これらの数値が示唆するよりも劇的に良いパフォーマンスを示します。
テスト方法: 合成負荷下での本物のブラウザ
各アナリティクスプラグインを分離する自動テストフレームワークを構築しました。プロセスは:
- WordPress REST API 経由ですべてのアナリティクスプラグインを無効化
- すべての設定の前に同一のウォームアップで OPcache と MySQL を準備
- 1 つのプラグインを一度に有効化
- 4 つのページタイプ (homepage、post、product、shop) にわたり、50 並列 HTTP ユーザーがサーバーにストレスをかけながら、〜150 件の本物の Chromium ブラウザページロードを実行
- PerformanceObserver 経由で Core Web Vitals (TTFB、FCP、LCP、CLS、INP) を収集
- 各プラグインで繰り返し、その後 8 つすべてを組み合わせてテスト
ベースライン計測はアナリティクスプラグインがゼロ有効の状態で実行されます。各プラグインのオーバーヘッドはこのベースラインからの差として計測されます。
テスト環境: WordPress 6.9.4、Local by Flywheel (macOS) 上、PHP 8.2、20 のサンプル製品を持つ WooCommerce、k6 v1.6.1 と Chromium ブラウザモジュール、設定あたり 10 ブラウザ VU + 50 プロトコル VU。ページキャッシュプラグインはインストールされていません — すべてのリクエストが完全な WordPress PHP パスにヒットしました。これは本番 WordPress サイトの典型的な運用ではありません。ほとんどの本番サイトは、キャッシュされたページに対して PHP を完全にバイパスする W3TC、WP Rocket、または CDN を使います。
ストレステスト結果: 並行負荷下での 8 プラグイン
以下の表は、当社の単一実行ストレステストで各プラグインがベースラインに加えたオーバーヘッドを示します。すべての値はミリ秒単位の差です — Time to First Byte、First Contentful Paint、Largest Contentful Paint にどれだけ加えたかをアナリティクスなしのベースラインに対して示します。Impact 列は複合スコア (0 = 影響なし、100 = 最大) です。低いほど良好です。
| 順位 | プラグイン | LCP Δ | TTFB Δ | FCP Δ | Impact |
|---|---|---|---|---|---|
| 1 | Statnive | +260ms | +290ms | +256ms | 6.7 |
| 2 | Independent Analytics | +566ms | +568ms | +574ms | 14.2 |
| 3 | Jetpack Stats | +776ms | +785ms | +784ms | 19.5 |
| 4 | MonsterInsights (GA4) | +964ms | +963ms | +964ms | 24.1 |
| 5 | WP Slimstat | +1030ms | +1005ms | +1010ms | 25.4 |
| 6 | WP Statistics | +1424ms | +1446ms | +1432ms | 35.9 |
| 7 | Koko Analytics | +2278ms | +2229ms | +2238ms | 56.3 |
| 8 | Burst Statistics | +3592ms | +3572ms | +3576ms | 89.6 |
| — | 全 8 件の組み合わせ | +4002ms | +3924ms | +4010ms | 99.5 |
| — | ベースライン (アナリティクスなし、負荷下) | 3038ms | 2927ms | 3030ms | — |
ストレステストでは、Statnive が最も低い LCP オーバーヘッドでした。特定の倍率は注意して扱ってください — キャッシュなしの単一マシンでの単一実行は、順序効果、外れ値リクエスト、WP-Cron バッチ処理のようなプラグイン固有の癖の影響を受け得ます。2 回目の実行で順位がずれる可能性があります。Koko Analytics と Burst Statistics の数値は、特に大きく、当社の合成負荷下での特定のサーバー側書き込みシリアライズ問題を反映していると疑われ、定常状態のオーバーヘッドではないと考えられます。結論を出す前に、自分のサイトでの挙動を調べてください。
プラグインごとの分析
Statnive (テストでの順位 #1: +260ms LCP)
Statnive の 2 段階読み込みアーキテクチャは、クリティカルレンダリングパスを清潔に保つことを目指します。1.1KB のインラインコアトラッカーが、外部リソースの読み込みより前に navigator.sendBeacon() 経由でページビューを発火します。〜4KB のフルトラッカーは WordPress 6.3 以降の strategy: 'async' パラメータで非同期に読み込まれ、レンダリングをブロックせずにエンゲージメント追跡、イベント、同意管理を扱います。サーバー側処理は、訪問者あたり 1 回の軽量な REST エンドポイント書き込みです。
こんなサイトに最適: パフォーマンスとプライバシーの両方を気にする任意の WordPress サイト。セルフホスト型のデータ、クッキーゼロ、同意バナー不要。
Independent Analytics (テストでの順位 #2: +566ms LCP)
Independent Analytics はクライアント側 JavaScript ではなくサーバー側 PHP フックを使います。このアプローチは JS のパース時間を完全に排除し、デスクトップよりパースコストが 2〜5 倍高いモバイルで助けになります。トレードオフはリクエストあたりの PHP 作業が増えることで、それが当社の合成負荷テストで Statnive の後ろにランクした理由です。
こんなサイトに最適: JavaScript の実行が懸念される (重い広告セットアップ、多数のサードパーティスクリプト) サイト。
Jetpack Stats (テストでの順位 #3: +776ms LCP)
Jetpack は WordPress.com のリモートサーバーへ追跡データを送ります。そのアーキテクチャ的な選択がアナリティクス処理をサーバーから移しますが、トラッカーは依然として目立つローカルオーバーヘッドを加えます — Jetpack モジュールが stats コードと並んで多めの JavaScript を読み込みます。
こんなサイトに最適: すでに Jetpack エコシステムを使っており、訪問者データを WordPress.com に送ることを受け入れるサイト。
MonsterInsights / Google Analytics (順位 #4: +964ms LCP)
MonsterInsights は WordPress を Google Analytics 4 に接続します。GA4 タグ (134KB 圧縮) はかなりのフロントエンド重量を加えます。実際のアナリティクス処理は Google のクラウドで行われますが、gtag.js を読み込むだけでも、ほとんどのセルフホスト型トラッカーより大きな負担です。
こんなサイトに最適: 特に Google Analytics を必要とし、パフォーマンスのトレードオフを受け入れるサイト。
WP Slimstat (順位 #5: +1030ms LCP)
Slimstat はリアルタイム表示を含む詳細な訪問者追跡を提供します。JS トラッカーは REST ベースの送信と広範なリクエストごとの PHP 処理と組み合わさり、負荷下で約 1 秒の LCP オーバーヘッドを加えます。
こんなサイトに最適: 生のページ速度より詳細な訪問者単位の追跡を優先するサイト。
WP Statistics (順位 #6: +1424ms LCP)
WP Statistics は完全にセルフホスト型で、成熟した機能セットを持ちます。トラッカーはデータ送信に admin-ajax を使い、これは REST エンドポイントや Beacon API 呼び出しより重いです。並行負荷下では、すべてのヒットが完全な WordPress 管理ブートストラップを通るため、admin-ajax がボトルネックになります。
こんなサイトに最適: 包括的なセルフホスト型アナリティクスを必要とし、目立つパフォーマンスオーバーヘッドを受け入れられるサイト。
Koko Analytics (テストでの順位 #7: +2278ms LCP)
Koko Analytics は驚くほど小さな 468 バイトのインライントラッカーを持ち — アーキテクチャ的にはセルフホスト型オプションの中で最も軽いものの 1 つです。しかし当社のストレステストでは、非常に大きな LCP 差で #7 にランクしました。私たちはこれが、特定の合成負荷下でのサーバー側書き込み競合を反映しており、定常状態のオーバーヘッドではないと疑っています。Koko はページビューごとにデータベースに書き込み、キャッシュ層なしの 50 並列ライターは、ページキャッシュ付きの実本番サイトでは決して経験しない病的な競合を生みます。この数値はおそらくテスト固有のアーティファクトです — 結論を出す前に自分のサイトで Koko を評価することをお勧めします。
こんなサイトに最適: 低トラフィックサイトとアーキテクチャ的なミニマリズムを重視する人。
Burst Statistics (テストでの順位 #8: +3592ms LCP)
Burst はトラッカーを async 属性で読み込み、データ送信に Beacon API を使います — どちらも良い選択です。当社のストレステストでの非常に大きな LCP 差は、おそらく並行負荷下での Beacon API エンドポイント書き込みシリアライズ、またはテストウィンドウ中に WP-Cron バッチ処理が動き出したことを反映しています。Koko 同様、この数値は当社の特定のテスト条件によって膨らんでいると疑っており、実世界のオーバーヘッドを代表するものではないと考えます。自分でテストしてください。
こんなサイトに最適: 成熟した機能セットを持つプライバシー重視のアナリティクスオプションを求めるサイト。
Statnive を試す: 高速、プライベート、セルフホスト型のアナリティクス
Statnive は軽量トラッカーのパフォーマンスとフルアナリティクススイートの機能を提供します。すべてのデータがあなたのサーバーに留まります。クッキーなし、同意バナー不要。WordPress.org から無料インストール。
詳細比較: あなたのサイトにとって何が重要か
サーバー応答速度別 (TTFB オーバーヘッド)
Time to First Byte は、サーバーがどれだけ素早く応答するかを計測します。差が小さいほど、ホスティングリソースがアナリティクス処理に消費されていません。
| プラグイン | TTFB Δ | サーバーへの影響 |
|---|---|---|
| Statnive | +290ms | 最小 |
| Independent Analytics | +568ms | 低 (サーバー側追跡) |
| Jetpack Stats | +785ms | 中 (ローカル JS + リモート処理) |
| MonsterInsights | +963ms | 中 (gtag.js を読み込む) |
| WP Slimstat | +1005ms | 高 |
| WP Statistics | +1446ms | 高 (admin-ajax) |
| Koko Analytics | +2229ms | 負荷下で高 (ヒットごとの DB 書き込み) |
| Burst Statistics | +3572ms | 負荷下で最悪 (書き込みバックプレッシャ) |
フロントエンド描画速度別 (LCP オーバーヘッド)
Largest Contentful Paint は、メインコンテンツが見えるようになる時点を計測します。これが Google が Core Web Vitals ランキングで最も重く使う指標です。
| プラグイン | LCP Δ | レンダリングへの影響 |
|---|---|---|
| Statnive | +260ms | 非常に低 (インラインコア + 非同期フル) |
| Independent Analytics | +566ms | 低 (クライアント側 JS なし) |
| Jetpack Stats | +776ms | 中 |
| MonsterInsights | +964ms | 高 (134KB gtag.js) |
| WP Slimstat | +1030ms | 高 |
| WP Statistics | +1424ms | 高 (admin-ajax のブロッキング) |
| Koko Analytics | +2278ms | 負荷下で高 |
| Burst Statistics | +3592ms | 負荷下で最悪 |
プライバシーモデル別
| プラグイン | データ保管場所 | クッキー | 同意の必要性 |
|---|---|---|---|
| Statnive | あなたのサーバー | なし | なし |
| Koko Analytics | あなたのサーバー | 任意 | なし |
| WP Statistics | あなたのサーバー | なし | なし |
| Burst Statistics | あなたのサーバー | 任意 | 場合による |
| Independent Analytics | あなたのサーバー | なし | なし |
| WP Slimstat | あなたのサーバー | セッション | 場合による |
| Jetpack Stats | WordPress.com | あり | あり |
| MonsterInsights | Google サーバー | あり | あり |
どのプラグインがあなたのサイトに最適か
プライバシー重視のサイトに最適
Statnive。完全にセルフホスト型、クッキーゼロ、同意バナー不要、そしてベンチマークで圧倒的に最速のプラグインです。最小限のトラッカー以上の機能 (エンゲージメント追跡、カスタムイベント、WooCommerce 収益) を、アーキテクチャ的に軽量に保ちながら提供します。
高トラフィック WordPress サイトに最適
Statnive。50 並列ユーザー下での 260ms LCP オーバーヘッドは、当社が計測した中で最も低く — 次に良いプラグインの 2.2 倍少ないものでした。インラインコアトラッカーがサーバー側作業の前にページビューを発火し、REST エンドポイントは並行書き込みスケール向けに設計されています。
初心者に最適
Statnive。設定ゼロで有効化と同時に動作し、リアルタイムダッシュボードとソースアトリビューションを含み、サイトを遅くしません。
WooCommerce ストアに最適
Statnive (Professional 層) は訪問者あたりの収益、商品ビュー、カートイベントを追跡します。MonsterInsights も WooCommerce をサポートしますが、Google Analytics を必要とし、約 3.7 倍のパフォーマンスオーバーヘッドがあります。
方法論の限界 (お読みください)
ベンチマークはその方法論ほどに信頼できます。このテストが制御していないことの正直なリストです。
単一実行、単一マシン。 ヘビーティアテストを 1 回、Local by Flywheel 経由で MacBook 上で実行しました。適切なベンチマークはランダム化された順序で 3〜5 回実行し、中央値と四分位範囲を報告します。2 回目の実行で順位がずれる可能性があります。
ページキャッシュなし。 すべてのリクエストが完全な WordPress PHP パスにヒットしました。ほとんどの本番 WordPress サイトは、キャッシュされたページに対して PHP を完全にバイパスする W3TC、WP Rocket、または CDN を使います。キャッシュ有効では、アナリティクス書き込みがキャッシュミスまたは非同期 JavaScript 経由でしか発生しないため、ほとんどのプラグイン間の差は劇的に縮みます。
オブジェクトキャッシュなし。 Redis なし、Memcached なし。オブジェクトキャッシュ付きの本番サイトは、まったく異なるデータベース競合特性を持ちます。
合成負荷パターン。 50 並列 HTTP VU は粗いです。実トラフィックには到着スパイク、セッションの分散、そしてほとんどがキャッシュされたページがあります。当社の負荷は月曜の朝より DDoS に近いです。
順序効果は制御されていない。 プラグインは固定順序でテストされました。サーバー状態 (MySQL 接続プール、PHP メモリ、OPcache) は 〜50 分の実行で漂流し、後の設定にペナルティを与え得ます。
サンプル数の変動。 高速なプラグインは設定あたり 〜156 サンプルを得ました。遅いプラグインは反復がタイムアウトしたために 117 サンプルしか得られませんでした。サンプル数が少ない = 分散が大きい = 中央値の信頼性が低い。
外れ値の疑い。 Koko Analytics (+2278ms) と Burst Statistics (+3592ms) の結果は非常に大きいです。これらが WP-Cron バッチ処理、並行負荷下での特定のプラグインバグ、または滞ったデータベース書き込みに起因しないことを独立に検証していません。「あなたのサイトで経験すること」ではなく「当社のテストでこのプラグインに何か悪いことが起きた」と扱ってください。
自己テストバイアス。 フレームワークは私たちが構築し、Statnive も私たちが構築しました。良い意図があっても、ページ選択、指標選択、テスト構造にバイアスが入り得ます。独立検証は当社が公開する何よりも信頼できます。 フレームワークはオープンソースです — ぜひ自分で実行してください。
テストが示すこと
限界にもかかわらず、テストはアーキテクチャパターンを有用に明らかにします。
- クリティカルレンダリングパスに JavaScript やサーバー作業を置くプラグインは、どんな負荷下でも計測可能な LCP オーバーヘッドを加える
- リクエストごとのデータベース書き込みを持つプラグインは、それらの書き込みがキャッシュできないと急激に劣化する
- インラインコア + 非同期トラッカーアーキテクチャ (Statnive、Koko の最小インライン、Burst の非同期読み込み) はクリティカルパスを清潔に保つ
- リモート処理プラグイン (Jetpack、MonsterInsights) は、処理がオフサイトであっても依然としてローカルの JavaScript 重量を加える
これらのパターンは Google、WordPress Core、web.dev からの公開研究と整合します。当社のテストの具体的な数値は、決定的なランキングではなく 1 つのデータポイントとして見るべきです。
よくある質問
アナリティクスプラグインは本当に SEO に影響しますか
原則として、はい。Google は Core Web Vitals (LCP を含む) をランキングシグナルとして使います。意味のある JavaScript パース時間を加えるか、レンダリングをブロックするプラグインは、ページを「良好」から「改善が必要」へ押し上げ得ます。実際には、ページキャッシュを設定していれば、キャッシュされたページがプラグインの PHP コードを走らせないため、この影響の大半が消えます。
複数のアナリティクスプラグインを動かせますか
技術的にはイエスですが、足し算になります。各追加プラグインはパースする JavaScript とリクエストごとのサーバー側作業を加えます。当社の「全プラグインの組み合わせ」テストは、予想どおり非常に高いオーバーヘッドを示しました。複数のデータソースが必要なら、よく設計された 1 つのセルフホスト型プラグインに集約し、可能なら他のツールはサーバー側で連携してください。
サイトのパフォーマンスはどれくらいの頻度でベンチマークすべきですか
プラグイン更新、テーマ変更、WordPress コアアップグレードのたびに。実世界のデータには Google PageSpeed Insights、スクリプトごとのプロファイリングには Chrome DevTools、比較テストには当社のような合成ベンチマークを使ってください。
セルフホスト型アナリティクスは本当に Google Analytics より速いですか
当社の合成テストでは、はい。134KB の gtag.js ライブラリは、キャッシュに関係なくかなりのパースコストです。セルフホスト型トラッカーははるかに小さくなり得ます (Statnive は 〜5KB、Koko は 1KB 未満)。キャッシュ付きの実本番サイトでも差は依然として存在しますが、絶対値では小さくなります。
Statnive 固有のパフォーマンスコストは
当社のストレステストで、Statnive はベースラインに対して +260ms の最も低い LCP オーバーヘッドでした。ページキャッシュをインストールした実本番サイトでは、キャッシュされたページが Statnive の PHP コードを実行しないため、そのオーバーヘッドの大半が消えます — 残るのは非同期で読み込まれる 〜5KB のクライアント側 JavaScript だけです。
これらの具体的な数値を信じるべきですか
方向性的な指標としては、はい。サイトのパフォーマンスの正確な予測としては、いいえ。 数値はキャッシュなしの 1 回の合成実行からです。キャッシュ付きの本番サイト、特定のホスティング上では、異なる絶対数値が出るでしょう。一般化するのはアーキテクチャパターン (インラインコア vs ブロッキング JS、非同期 vs 同期、同一オリジン vs リモート) であり、特定のミリ秒ではありません。
方法論と再現性
すべてのテストは当社のオープンソース perf-impact テストフレームワークを使って実行されました。テストスクリプト (perf-impact-runner.sh) はプラグインの切り替え、キャッシュ準備、ウォームアップ、k6 ブラウザテストを自動化します。結果は履歴比較のために JSON として保存されます。
自分の WordPress インストールでこの結果を再現するには:
cd statnive
./tests/perf/run.sh perf-impact heavy生データファイルは tests/perf/results/perf-impact/ で利用可能です。
個別の競合相手のより深い分析については、当社の比較ページをご覧ください: Statnive vs Google Analytics、Statnive vs MonsterInsights、Statnive vs Jetpack Stats、Statnive vs WP Statistics、Statnive vs Plausible。最適化の背後にあるエンジニアリングストーリーを読むか、Statnive のすべての機能を探索してください。