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.
Zie de verbinding voordat de pagina kan renderen
De Duitsland probe volgt HTTP-omleidingen, meet elke aanvraag en visualiseert vervolgens de uiteindelijke documentrespons zonder browser- of Core Web Vitals-gegevens uit te vinden.
Weet wat het resultaat bewijst
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. Bron
Novaverb's Germany probe or selected Globalping community probes. The result identifies where its evidence came from.
2. Grens
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. Volgende actie
Gebruik de bevinding om een probleem te verifiëren, verbind vervolgens een werkruimte wanneer je geschiedenis, monitoring of site-brede analyse nodig hebt.
Wat meet de Website Prestatie Test?
Het meet DNS, TCP, TLS, verzoek-tot-eerste-byte en documentoverdracht voor een publieke URL. Kies Novaverb's directe probe in Duitsland, één Globalping community-locatie, of vergelijk tien steden in Azië, Europa, de Amerika's, Afrika en Oceanië.
Meetmethoden, locaties en gratis limieten
Kies de Novaverb directe probe voor een gecontroleerde meting, één Globalping-stad voor een regionale controle, of alle tien steden voor een vergelijking van vijf regio's. De twee methoden blijven gescheiden omdat ze verschillende omleidingen, vastlegging en retentiegrenzen hebben.
🇩🇪 Duitsland locatie
- Draait op de Novaverb-infrastructuur over een verse HTTP/1.1-verbinding.
- Volgt tot vijf HTTP-omleidingen en toont de uiteindelijke responswaterval.
- Vangt de responsbody tot ongeveer 3 MB en houdt de verklaarde lengte apart.
- Verbruikt geen tests van derden.
🌍 Één stad of alle 10
- Een momenteel online probe in de geselecteerde stad vraagt de exacte ingediende URL aan.
- Geeft DNS, TCP, TLS, eerste byte, download en totale timing terug met stad en timing bewijs.
- Volgt de omleidingslus van Novaverb niet; test een teruggegeven 3xx-bestemming apart.
- Identiteitsmetadata van de probe is opzettelijk verborgen voor het publiek resultaat.
- Het doel en de meting worden verwerkt door Globalping en kunnen tot zeven dagen opvraagbaar blijven.
Hoe gratis gebruik is beperkt: één geselecteerde stad verbruikt één provider test; Vergelijk alle 10 verbruikt tien. Novaverb staat tot 10 enkele stadsruns of vijf 10-stadsvergelijkingen per bron per uur toe, en reserveert een gedeeld plafond van 200 provider tests per uur. De upstream niet-geauthenticeerde pool biedt momenteel 250 gratis tests per uur, dus capaciteit en live probe beschikbaarheid kunnen tijdelijk opraken.
Hoe de prestatiewaterval werkt
DNS-opzoeking
Los de hostnaam op, terwijl de verbinding aan het gevalideerde openbare IP blijft vastgehecht.
TCP connect
Open een verse verbinding; geen eerdere socket wordt hergebruikt.
TLS handshake
Onderhandel HTTPS met SNI en HTTP/1.1 wanneer de URL veilig is.
Eerste byte
Meet vanaf het verzenden van GET tot de eerste responsbytes aankomen.
HTML-overdracht
Meet vanaf het eerste byte door het vastgelegde documentlichaam, tot ongeveer 3 MB.
Hoe de TTFB-gidsbanden te lezen
web.dev geeft 800 ms of minder als een ruwe goede TTFB-doel en boven de 1.800 ms als slecht. Novaverb past die richtlijnen toe op de verbinding-tot-eerste-byte monster van de uiteindelijke respons, niet op de volledige omleidingsreis.
Herhaal vanuit gebruikersrelevante regio's voordat je concludeert dat de URL consistent snel is.
Gebruik de waterval om te identificeren of setup of verzoekwachttijd domineert.
Her-test, vergelijk cache-staten en onderzoek de grootste herhaalde fase.
Wat dit resultaat omvat - en wat het niet doet
Gemeten in deze run
- Verse DNS, TCP en TLS-instellingen voor elke aanvraag
- Verzoek-tot-eerste-byte en vastgelegde lichaamsoverdracht
- HTTP-omleidingen, status en uiteindelijke responsheaders
- Ontvangen bodybytes en verklaarde Content-Length apart gehouden
- Één meetgebied: EU, Duitsland
Niet gemeten of bewezen
- CSS, JavaScript, afbeeldingen, lettertypen of bronnen van derden
- Browserparsering, rendering, visuele voltooiing of interactie gereedheid
- LCP, INP, CLS, FCP of een Lighthouse prestatie score
- Echte gebruikerspercentielen, uptime of sustained-load gedrag
- Pure oorsprong uitvoeringstijd gescheiden van CDN en netwerklatentie
Hoe de dominante fase te verbeteren
Hoge DNS-tijd
Beoordeel autoritatieve DNS-latentie en betrouwbaarheid; vergelijk meerdere runs omdat de resolver cache-status varieert.
Hoge TCP-tijd
Verminder afstand met een edge of CDN en onderzoek routekwaliteit of pakketverlies.
Hoge TLS-tijd
Controleer certificaatketen, moderne TLS-ondersteuning en hergebruik van verbindingen in actuele browsers.
Hoge first-byte wachttijd
Inspecteer CDN-cachemissers, databasewerk, externe oproepen en applicatie- of oorsprongcontentie.
Hoge HTML-overdracht
Verminder documentgrootte en verifieer geschikte inhoudscodering, terwijl je je herinnert dat deze test alleen het document vastlegt.
Normen en meetrichtlijnen
Website prestatie testvragen
Is dit een complete pagina-snelheidstest?
Nee. Het meet alleen de timing van verbinding en documentrespons. Een complete browser test moet ook afhankelijkheden laden, scripts uitvoeren en de pagina renderen.
Waarom is dit anders dan Chrome of Lighthouse?
De probe draait vanaf een server in Duitsland over een verse HTTP/1.1-verbinding. Je browser kan een andere route, protocol, cache en hergebruikte verbinding gebruiken, en vervolgens renderingwerk uitvoeren dat deze test nooit probeert.
Volgt het omleidingen?
Ja, tot vijf HTTP-omleidingen. Elke hop wordt onafhankelijk gemeten met een verse aanvraag; de hoofdwaterval is de uiteindelijke respons.
Betekent totale tijd pagina-laadtijd?
Nee. Het is de som van verbindingsfasen en vastgelegde documentoverdracht voor één verzoek. Het sluit subresources, code-uitvoering, rendering en interactie gereedheid uit.
Waarom kunnen gedownloade bytes verschillen van Content-Length?
Content-Length is een server-verklaarde header. Ontvangen body is wat deze begrensde probe daadwerkelijk heeft vastgelegd; grote reacties kunnen stoppen nabij de 3 MB veiligheidslimiet.
Waarom veranderen resultaten tussen runs?
DNS- en CDN-cachestatus, oorsprong belasting, netwerkroutering en gedeelde infrastructuur variëren. Diagnoseer patronen over herhaalde monsters en echte gebruikersgegevens, niet één run.
Elk nummer is een enkele synthetische aanvraag van de geselecteerde probe; het meet geen browser-rendering, Core Web Vitals of echte gebruikers.
Wat in te dienen - en wat te vermijden
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.comElke adresvorm werkt. http of https, met of zonder www, een blote domein of een volledige pad - we normaliseren het voor je.A URL that redirectsPrima - we traceren elke hop eerst, en meten dan de uiteindelijke bestemming.Expecting full page-load / render timeDit meet de server- en verbindingsfasen (TTFB), niet de browser rendering van de hele pagina.Expecting your users' field numbersHet is één synthetische aanvraag vanuit een vaste locatie - gebruik Core Web Vitals voor echte gebruikersveldgegevens.Exact hoe dit resultaat wordt geproduceerd
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.
- We normaliseren het adres en volgen de omleidingsketen per HTTP-semantiek naar de uiteindelijke URL.
- We timen DNS, TCP, TLS, TTFB en contentoverdracht als standaard navigatietiming fasen.
- We vergelijken TTFB met openbare veldrichtlijnen en rapporteren elke fase zodat de trage fase zichtbaar is.
De internationale normen waarop deze controle van toepassing is.
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.
Rapporteert de aanvraag als de standaard DNS / TCP / TLS / TTFB / overdracht fasen.
Lees de specificatieVolgt de redirectketen volgens HTTP-semantiek voordat de uiteindelijke meting.
Lees de specificatieBant de gemeten TTFB tegen publieke veldrichtlijnen.
Lees de specificatieWebsite 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.