Free Global Website Performance Test
Test global website loading speed and TTFB waterfall timing across 10 locations worldwide. Measure DNS, TCP, TLS, and first-byte latency.
Voir la connexion avant que la page puisse se rendre
La sonde allemande suit les redirections HTTP, mesure chaque requête, puis visualise la réponse finale du document sans inventer de données de navigateur ou de Core Web Vitals.
Savoir ce que le résultat prouve
This check proves where the time went before a browser could start rendering: DNS lookup, TCP connect, TLS handshake, time to first byte and content transfer, each reported separately along the redirect chain to the final URL. It measures delivery, not rendering, so it locates the slow stage without claiming to describe the visitor's experience of the page.
1. Source
Novaverb's Germany probe or selected Globalping community probes. The result identifies where its evidence came from.
2. Limite
Each number comes from the selected probe. Novaverb's Germany mode follows redirects and captures up to about 3 MB; Globalping mode measures the exact submitted URL on community probes. Neither mode measures rendering, Core Web Vitals or real users.
3. Prochaine action
Utilisez la découverte pour vérifier un problème, puis connectez un espace de travail lorsque vous avez besoin d'historique, de surveillance ou d'analyse à l'échelle du site.
Que mesure le test de performance du site Web ?
Il mesure le DNS, TCP, TLS, le temps de la première requête et le transfert de documents pour une URL publique. Choisissez la sonde directe de Novaverb en Allemagne, un emplacement de la communauté Globalping, ou comparez dix villes à travers l'Asie, l'Europe, les Amériques, l'Afrique et l'Océanie.
Méthodes de mesure, emplacements et limites gratuites
Choisissez la sonde directe Novaverb pour une mesure contrôlée, une ville Globalping pour un contrôle régional, ou les dix villes pour une comparaison à cinq régions. Les deux méthodes restent séparées car elles ont différentes limites de redirection, de capture et de rétention.
🇩🇪 Emplacement en Allemagne
- Fonctionne sur l'infrastructure de Novaverb via une nouvelle connexion HTTP/1.1.
- Suit jusqu'à cinq redirections HTTP et montre la cascade de réponse finale.
- Capture le corps de la réponse jusqu'à environ 3 Mo et garde la longueur déclarée séparée.
- Ne consomme pas de tests de sonde tiers.
🌍 Une ville ou toutes les 10
- Une sonde actuellement en ligne dans la ville sélectionnée demande l'URL soumise exacte.
- Retourne DNS, TCP, TLS, premier octet, téléchargement et temps total avec des preuves de ville et de timing.
- Ne suit pas la boucle de redirection de Novaverb ; testez une destination 3xx retournée séparément.
- Les métadonnées d'identité de l'enquête sont intentionnellement cachées du résultat public.
- La cible et la mesure sont traitées par Globalping et peuvent rester récupérables pendant jusqu'à sept jours.
Comment l'utilisation gratuite est limitée : une ville sélectionnée consomme un test de fournisseur ; Comparer les 10 consomme dix. Novaverb permet jusqu'à 10 exécutions d'une seule ville ou cinq comparaisons de 10 villes par source par heure, et réserve un plafond partagé de 200 tests de fournisseur par heure. Le pool non authentifié en amont fournit actuellement 250 tests gratuits par heure, donc la capacité et la disponibilité des sondes en direct peuvent temporairement s'épuiser.
Comment fonctionne la cascade de performance
Recherche DNS
Résolvez le nom d'hôte, tandis que la connexion reste fixée à l'IP publique validée.
Connexion TCP
Ouvrez une nouvelle connexion ; aucun socket précédent n'est réutilisé.
Établissement TLS
Négociez HTTPS avec SNI et HTTP/1.1 lorsque l'URL est sécurisée.
Premier octet
Mesurez depuis l'envoi de GET jusqu'à l'arrivée des premiers octets de réponse.
Transfert HTML
Mesurez depuis le premier octet jusqu'au corps du document capturé, jusqu'à environ 3 Mo.
Comment lire les bandes directrices TTFB
web.dev donne 800 ms ou moins comme un objectif TTFB approximatif et au-dessus de 1 800 ms comme pauvre. Novaverb applique ces bandes directrices à l'échantillon de connexion au premier octet de la réponse finale, pas au parcours complet de redirection.
Répétez depuis des régions pertinentes pour l'utilisateur avant de conclure que l'URL est constamment rapide.
Utilisez le flux pour identifier si la configuration ou l'attente de requête domine.
Retestez, comparez les états de cache et enquêtez sur la plus grande phase répétée.
Ce que ce résultat inclut - et ce qu'il n'inclut pas
Mesuré lors de cette exécution
- Configuration DNS, TCP et TLS fraîche pour chaque requête
- Transfert de demande au premier octet et corps capturé
- Redirections HTTP, statuts et en-têtes de réponse finale
- Octets de corps reçus et Content-Length déclaré séparés
- Une région de mesure : UE, Allemagne
Non mesuré ou prouvé
- CSS, JavaScript, images, polices ou ressources tierces
- Analyse du navigateur, rendu, achèvement visuel ou préparation à l'interaction
- LCP, INP, CLS, FCP ou un score de performance Lighthouse
- Percentiles d'utilisateurs réels, temps de disponibilité ou comportement de charge soutenue
- Temps d'exécution d'origine pur séparé de la latence CDN et réseau
Comment améliorer la phase dominante
Temps DNS élevé
Examinez la latence et la fiabilité DNS autoritaires ; comparez plusieurs exécutions car l'état du cache du résolveur varie.
Temps TCP élevé
Réduisez la distance avec un edge ou CDN et enquêtez sur la qualité de la route ou la perte de paquets.
Temps TLS élevé
Vérifiez la chaîne de certificats, le support TLS moderne et la réutilisation de la connexion dans les navigateurs réels.
Attente de premier octet élevée
Inspectez les échecs de cache CDN, le travail de base de données, les appels externes et la contention d'application ou d'origine.
Transfert HTML élevé
Réduisez la taille du document et vérifiez l'encodage de contenu approprié, tout en gardant à l'esprit que ce test capture uniquement le document.
Normes et conseils de mesure
Questions de test de performance du site Web
Est-ce un test complet de vitesse de page ?
Non. Il mesure uniquement le temps de connexion et de réponse au document. Un test de navigateur complet doit également charger des dépendances, exécuter des scripts et rendre la page.
Pourquoi cela est-il différent de Chrome ou Lighthouse ?
Le probe fonctionne depuis un serveur en Allemagne via une nouvelle connexion HTTP/1.1. Votre navigateur peut utiliser un autre itinéraire, protocole, cache et connexion réutilisée, puis effectuer un travail de rendu que ce test n'essaie jamais.
Suit-il les redirections ?
Oui, jusqu'à cinq redirections HTTP. Chaque saut est mesuré indépendamment avec une nouvelle requête ; le flux principal est la réponse finale.
Le temps total signifie-t-il le temps de chargement de la page ?
Non. C'est la somme des phases de connexion et du transfert de document capturé pour une requête. Cela exclut les sous-ressources, l'exécution de code, le rendu et la préparation à l'interaction.
Pourquoi les octets téléchargés peuvent-ils différer de la longueur du contenu ?
Content-Length est un en-tête déclaré par le serveur. Le corps reçu est ce que cette sonde limitée a réellement capturé ; les réponses importantes peuvent s'arrêter près de la limite de sécurité de 3 Mo.
Pourquoi les résultats changent-ils entre les exécutions ?
L'état du cache DNS et CDN, la charge d'origine, le routage réseau et l'infrastructure partagée varient. Diagnostiquez les modèles à travers des échantillons répétés et des données d'utilisateurs réels, pas une seule exécution.
Chaque numéro est une seule requête synthétique provenant de la sonde sélectionnée ; il ne mesure pas le rendu du navigateur, les Core Web Vitals ou les utilisateurs réels.
Ce qu'il faut soumettre - et ce qu'il faut éviter
Submit any public address. Scheme, www, path and query are normalised, and redirects are followed to the final URL so the timings describe the page that is actually served. A private host is refused. A single run from one location is a sample and is best read alongside a second run rather than on its own.
yourdomain.comToute forme d'adresse fonctionne. http ou https, avec ou sans www, un domaine nu ou un chemin complet - nous le normalisons pour vous.A URL that redirectsBien - nous traçons chaque saut d'abord, puis mesurons la destination finale.Expecting full page-load / render timeCeci chronomètre les phases du serveur et de la connexion (TTFB), pas le rendu du navigateur de la page entière.Expecting your users' field numbersC'est une requête synthétique d'un emplacement fixe - utilisez Core Web Vitals pour des données de champ réelles.Exactement comment ce résultat est produit
The address is normalised and the redirect chain is followed per HTTP semantics to the final URL. DNS, TCP, TLS, time to first byte and content transfer are then timed as standard navigation-timing phases, and the TTFB is banded against public field guidance so the stage responsible for the delay is visible rather than averaged away.
- Nous normalisons l'adresse et suivons la chaîne de redirection selon les sémantiques HTTP jusqu'à l'URL finale.
- Nous chronométons DNS, TCP, TLS, TTFB et le transfert de contenu comme phases de navigation standard.
- Nous comparons le TTFB aux directives de terrain publiques et rapportons chaque phase afin que la phase lente soit visible.
Les normes internationales auxquelles cette vérification s'applique.
Three public references define this measurement. W3C Navigation Timing defines the phase model the timings follow, RFC 9110 defines the HTTP semantics used to walk the redirect chain, and Google's web.dev TTFB guidance supplies the band. The phases are reported individually because a single total hides which stage a fix belongs in.
Rapporte la requête comme les phases standard DNS / TCP / TLS / TTFB / transfert.
Lisez la spécificationSuit la chaîne de redirection selon les sémantiques HTTP avant la mesure finale.
Lisez la spécificationRegroupe le TTFB mesuré avec les directives de champ publiques.
Lisez la spécificationWebsite Performance Test FAQ
What does the Novaverb Website Performance Test measure?
It measures the full connection waterfall for a URL, DNS lookup, TCP connect, TLS handshake, Time To First Byte, and HTML transfer, from Novaverb's Germany probe or selected community probes placed across world regions.
How is this different from the single-location speed check?
The speed check runs only from Germany. This performance test can additionally run from community probes in multiple world regions, letting you compare connection timing across geographies rather than from one fixed vantage point.
Does this test measure Core Web Vitals or rendering?
No. Each number reflects network and server connection timing only. It does not run a browser, so it cannot measure Largest Contentful Paint, layout shift, interactivity, JavaScript execution, or anything about how the page visually renders.
What is the connection waterfall in this test?
It is the ordered breakdown of a request: DNS resolves the hostname, TCP establishes the connection, TLS negotiates encryption, TTFB captures server wait, and HTML transfer downloads the initial document. Each stage exposes where time is spent.
Why are timings different from each probe location?
Each probe is a separate physical location, so distance to your server and CDN edge changes DNS, connection, and transfer times. Regions far from your hosting or without nearby edge nodes will consistently show higher latency.
What is a good TTFB across regions?
Aim for under roughly 500 milliseconds in your primary markets and reasonably consistent numbers elsewhere. Large gaps between regions usually indicate missing CDN coverage or origin-only serving for distant users, which a content delivery network can flatten.
How do I improve performance for distant regions?
Put a CDN in front of your origin so static assets and cached HTML serve from edge nodes near users. Also enable modern protocols and caching so far-away regions are not paying full origin round-trips.
Is one probe measurement reliable on its own?
Treat each number as a single sample from one probe at one moment, subject to transient network conditions. Run repeated checks and compare trends across regions rather than drawing conclusions from any isolated measurement.
Does this test represent what real users experience?
Not exactly. Probes approximate network paths but are not your actual visitors on their devices, browsers, and connections. Use this for comparing server and network delivery across regions, and pair it with field data for true real-user performance.
Why does multi-region performance matter for SEO?
Search visitors and crawlers connect from many places, and slow delivery in a target market delays first byte and rendering there. Consistent low-latency delivery worldwide supports faster pages, better user experience, and the speed signals that aid rankings.