Pilier Performance

5,5 Ko minifié.
2,4 Ko gzippé.

Un tracker si petit que vos visiteurs ne remarqueront pas qu'il s'est chargé. Plus faible surcharge LCP des 8 plugins d'analytics WordPress que nous avons benchmarkés. Transport sendBeacon. Le stub de cœur inline (~0,9 Ko gzippé) capture la pageview avant le chargement du tracker asynchrone.

k6 + Chromium • test synthétique en une seule exécution • sans cache de page • les résultats sont indicatifs, pas garantis en production

Surcharge LCP sous charge (plus bas = mieux)

Statnive
+260ms
Independent Analytics
+566ms
Jetpack
+776ms
MonsterInsights (GA4)
+964ms
WP Slimstat
+1030ms
WP Statistics
+1424ms
Koko Analytics
+2278ms
Burst Statistics
+3592ms
~7Ko Taille du tracker 1,7 Ko inline + 5,5 Ko async (brut)
async Chargement API strategy WP 6.3+
0,00 Score CLS Aucun décalage de mise en page
Beacon Transport sendBeacon non bloquant
Comparaison directe

Résultats du test de stress synthétique

Nous avons activé chaque plugin isolément sur le même site WooCommerce et mesuré les Core Web Vitals avec de vrais navigateurs Chromium pendant que 50 utilisateurs HTTP concurrents stressaient le serveur. Sans cache de page. Les chiffres sont les surcharges LCP/TTFB/FCP par rapport à une baseline sans analytics, en une seule exécution. Ce sont des résultats indicatifs, pas des garanties de production — voir la section limitations ci-dessous.

Plugin LCP Δ TTFB Δ FCP Δ Impact Type
#1 Statnive +260ms +290ms +256ms 6.7 Auto-hébergé
#2 Independent Analytics +566ms +568ms +574ms 14.2 Auto-hébergé
#3 Jetpack +776ms +785ms +784ms 19.5 Distant (WP.com)
#4 MonsterInsights (GA4) +964ms +963ms +964ms 24.1 Distant (Google)
#5 WP Slimstat +1030ms +1005ms +1010ms 25.4 Auto-hébergé
#6 WP Statistics +1424ms +1446ms +1432ms 35.9 Auto-hébergé
#7 Koko Analytics +2278ms +2229ms +2238ms 56.3 Auto-hébergé
#8 Burst Statistics +3592ms +3572ms +3576ms 89.6 Auto-hébergé

Baseline (sans analytics) sous charge : TTFB 2927ms, FCP 3030ms, LCP 3038ms. Test : 10 VU navigateur Chromium + 50 VU protocole HTTP par plugin, ~150 échantillons par configuration, exécution unique sur une machine de développeur (Local by Flywheel, macOS). Le score d'impact est un composite (0 = aucun impact, 100 = maximum). Ces chiffres proviennent d'un seul test de stress synthétique et ne représentent pas les conditions de production — voir la section méthodologie et limitations ci-dessous.

Transparence honnête

Ce que ce test montre et ce qu'il ne montre pas

Un benchmark digne de confiance expose ses limites. Voici exactement ce que nos chiffres signifient — et ce qu'ils ne signifient pas.

Ce qu'il montre

Les différences indicatives dans la façon dont l'architecture de chaque plugin gère le chemin PHP WordPress complet sous charge concurrente, sans cache de page. Utile pour comprendre quels plugins gardent le chemin de rendu critique dégagé et lesquels ajoutent du travail serveur par requête.

Ce qu'il ne montre pas

La performance réelle en production. La plupart des sites WordPress utilisent un cache de page (W3TC, WP Rocket, Cloudflare), qui contourne entièrement PHP pour les pages mises en cache. Avec le caching, l'écart entre la plupart des plugins se réduit drastiquement.

Une exécution, une machine

Les résultats proviennent d'une exécution unique d'environ 50 minutes sur un MacBook via Local by Flywheel. Nous n'avons pas effectué plusieurs itérations pour mesurer la variance, ni testé sur un serveur de production dédié. Une seconde exécution pourrait modifier le classement.

Effets d'ordre non contrôlés

Les plugins ont été testés dans un ordre fixe. L'état du serveur (pool de connexions MySQL, mémoire PHP, OPcache) dérive durant une longue exécution, ce qui peut pénaliser les plugins testés plus tard. Un benchmark correct randomiserait l'ordre sur plusieurs exécutions.

Biais d'auto-évaluation

Nous avons construit le framework de test, et nous avons construit Statnive. Nous pensons avoir été équitables, mais une vérification indépendante serait plus digne de confiance que tout ce que nous publions nous-mêmes. Le framework est open source — exécutez-le sur votre propre site et publiez ce que vous trouvez.

Pourquoi nous publions quand même

Même avec ces réserves, les patterns architecturaux comptent. Les trackers cœur inline, le chargement asynchrone, le transport via Beacon API et les endpoints REST safe pour la concurrence sont des bonnes pratiques documentées. Les chiffres précis varieront ; la direction est cohérente avec la conception de chaque architecture.

Ingénierie

Comment nous avons construit un tracker rapide

Trois décisions architecturales maintiennent l'impact de Statnive sur la performance à un niveau bas — appuyées par des recherches publiées de Google, du cœur de WordPress et de web.dev.

Cœur inline

~1,7 Ko brut / 0,9 Ko gzippé

Un minuscule bootstrap inline capture la pageview immédiatement. Aucun script externe nécessaire pour le hit critique.

Chargement asynchrone

Non bloquant

Le tracker complet se charge avec la stratégie async via l'API script de WordPress 6.3+. Ne bloque jamais le rendu.

Idle Callback

Zéro INP

Le suivi de l'engagement et les écouteurs d'événements sont reportés à requestIdleCallback. Les interactions de vos visiteurs passent en premier.

Pourquoi c'est important

Une analytics lente vous coûte de l'argent

Classement SEO

Google utilise les Core Web Vitals comme signal de classement. Un script d'analytics lent pousse votre LCP au-delà du seuil « bon » de 2,5 s, nuisant à votre position dans les résultats de recherche.

Taux de conversion

Chaque seconde supplémentaire de temps de chargement réduit les conversions jusqu'à 7 %. Une surcharge analytics de 300 ms sur chaque page se cumule sur tout votre funnel.

Bonus confidentialité

Une analytics auto-hébergée signifie zéro requête réseau externe vers des serveurs tiers. Chargements plus rapides et conformité au RGPD dans une seule décision d'architecture.

Méthodologie

Comment nous avons testé

Transparence totale. Chaque chiffre de cette page provient de tests automatisés reproductibles.

Outil

k6 avec module navigateur (vrai Chromium, pas du HTTP simulé)

Charge

10 VU navigateur mesurant les vitals + 50 VU HTTP générant une pression serveur réaliste

Isolation

Chaque plugin activé seul via l'API REST WordPress. Tous les autres désactivés.

Pages

Page d'accueil, article de blog, boutique WooCommerce + pages produit

Échantillons

~150 chargements de page par configuration de plugin avec préchauffage du cache avant la baseline

Métriques

TTFB, FCP, LCP, CLS, INP collectés via l'API PerformanceObserver

Commencez à tracker sans ralentir

Installez Statnive en moins d'une minute. Gratuit pour toujours sur WordPress.org.

Installer Statnive gratuitement