veilletech.frCe qui se passe
Cloudflare publie BEACON (Browser Experience Across Cloudflare's Observed
Network), un jeu de données de Real User Monitoring tiré des 10 000 plus gros
sites de son réseau : des milliards de mesures, tous moteurs de navigation
confondus, mises à jour chaque jour dans Google BigQuery (projet
cf-open-web-performance, jeu rumarchive). Il suit le format de la RUM
Archive, dont il multiplie la couverture par cent.
Les trois Core Web Vitals (LCP, CLS, INP) y figurent en histogrammes complets, pas en moyennes : on peut lire n'importe quel centile, pas seulement le P75.
Ce que disent les sous-parties du LCP
BEACON découpe le LCP en quatre temps. Valeurs typiques selon que le LCP de la page vue est jugé bon, à améliorer ou mauvais :
| Sous-partie | Bon | À améliorer | Mauvais |
|---|---|---|---|
| TTFB du document | 598 ms | 1 015 ms | 1 891 ms |
| Délai de découverte | 76 ms | 1 049 ms | 1 485 ms |
| Téléchargement de la ressource | 119 ms | 199 ms | 119 ms |
| Délai de rendu | 157 ms | 437 ms | 2 002 ms |
La lecture va contre un réflexe courant : télécharger l'image, la police ou la vidéo est ce qui coûte le moins. Sur les pages qui dépassent le seuil « bon », le temps se perd avant (le navigateur découvre tard la ressource, souvent parce qu'elle dépend de JavaScript) et après (quelque chose bloque son affichage).
Même découpage pour l'INP : sur les interactions mauvaises, le délai d'entrée monte à 84 ms, le traitement à 284 ms et la présentation à 217 ms. Le JavaScript domine, mais la présentation, souvent du recalcul de mise en page CSS, pèse presque autant.
Monopage : rapide ensuite, lourd d'abord
Grâce à l'API Soft Navigations de Chrome, BEACON mesure le LCP des navigations côté client (Blink) :
| LCP | P50 | P75 | P90 | P95 |
|---|---|---|---|---|
| Navigation complète | 791 ms | 1 421 ms | 2 636 ms | 4 122 ms |
| Navigation côté client | 274 ms | 582 ms | 1 169 ms | 1 816 ms |
| Page d'arrivée | 1 370 ms | 2 681 ms | 5 397 ms | 8 940 ms |
Deux à trois fois plus rapide une fois l'application chargée, mais une page d'arrivée nettement plus lourde. Si vos visiteurs ne vont guère plus loin que la première page, l'architecture ne rembourse jamais son coût initial.
Autres constats
- WebKit, seul moteur sur iOS, est globalement le plus rapide, mais dans 46 pays où il dépasse 10 % du trafic, son LCP, son INP ou les deux sont au moins 10 % moins bons que ceux de Blink. Au Cambodge, 17,5 % des pages vues et un LCP 50 % moins bon.
- Par secteur, gouvernement, santé et sites pour enfants s'en sortent le mieux ; publicité, religion et météo le moins bien.
Comment s'y prendre
- Ouvrir le jeu de données dans BigQuery : les requêtes de l'article y sont enregistrées (« Global LCP Sub-parts », « Global INP Sub-parts », « Blink - Hard vs Soft Navigations », « Blink - Landing Pages », « CWVs by Industry »).
- Sur vos propres pages lentes, vérifier d'abord que la ressource du LCP est présente dans le HTML initial, et ce qui retarde son rendu, avant de recompresser quoi que ce soit.
Les limites
Le panel se limite aux gros sites clients de Cloudflare. Domaines et chemins sont retirés, les agrégats de moins de cinq mesures supprimés : impossible de se comparer nommément à un concurrent.
Source : How fast is the web? Explore billions of real-user measurements with BEACON, Cloudflare, 28 septembre 2026 ; travail de Chisara Duru et Tong Zhou.