URL à mesurer
Mesure depuis un Worker Cloudflare en Europe, approximation rapide, pas le vrai TTFB navigateur final.
Trois indicateurs perf serveur en un seul fetch : TTFB, protocole HTTP, compression Brotli/gzip. Détecte rapidement les serveurs mal configurés.
Mesure depuis un Worker Cloudflare en Europe, approximation rapide, pas le vrai TTFB navigateur final.
Google considère < 800 ms comme "bon", 800-1800 ms comme "à améliorer", > 1800 ms comme "mauvais", c'est l'un des Core Web Vitals secondaires. Le TTFB dépend du serveur d'origine + du CDN. Si vous êtes derrière Cloudflare avec cache HIT, le TTFB descend sous 100 ms. Sans CDN ou avec cache MISS sur un PHP-FPM lent, ça monte vite à 500-1500 ms.
Brotli compresse 15-25% mieux que gzip sur du HTML/CSS/JS. Sur une page de 100 Ko gzip, on gagne 15-25 Ko en passant à Brotli, direct visible sur la latence mobile. Tous les navigateurs récents supportent Brotli depuis 2017. Si votre serveur sert encore du gzip, c'est une 2-line config update sur Apache/Nginx/Cloudflare.
HTTP/2 multiplexe les requêtes sur une seule connexion TCP. HTTP/3 fait pareil sur QUIC (UDP) et survit mieux aux changements de réseau (passage WiFi→4G typiquement). Gain perceptible sur mobile et perdu en réseau bruyant. Sur Cloudflare, HTTP/3 est activable en 1 click. Pratiquement obligatoire en 2025.
La mesure ici est faite depuis un Worker Cloudflare en Europe. Le TTFB que vit un utilisateur final dépend en plus de : sa connexion réseau (4G vs fibre), sa distance géographique au CDN, son OS et le DNS lookup. Pour le TTFB "vrai" : Search Console > Core Web Vitals (mesures CrUX = utilisateurs Chrome réels) ou PageSpeed Insights. Cet outil donne une mesure rapide approximative pour pré-flag les problèmes flagrants.
Notre catalogue de sites du réseau est consultable sans inscription. Prix éditeur affiché, sans commission ni intermédiaire.