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.
Zobacz połączenie przed renderowaniem strony
Niemiecka próba śledzi przekierowania HTTP, mierzy każde żądanie, a następnie wizualizuje ostateczną odpowiedź dokumentu bez wymyślania danych przeglądarki lub Core Web Vitals.
Wiedzieć, co dowodzi wynik
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. Źródło
Novaverb's Germany probe or selected Globalping community probes. The result identifies where its evidence came from.
2. Granica
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. Następna akcja
Użyj ustalenia, aby zweryfikować problem, a następnie połącz przestrzeń roboczą, gdy potrzebujesz historii, monitorowania lub analizy całej witryny.
Co mierzy Test Wydajności Strony?
Mierzy DNS, TCP, TLS, czas do pierwszego bajtu i transfer dokumentu dla publicznego URL. Wybierz bezpośredni sondę Novaverb w Niemczech, jedną lokalizację społeczności Globalping lub porównaj dziesięć miast w Azji, Europie, Amerykach, Afryce i Oceanii.
Metody pomiaru, lokalizacje i darmowe limity
Wybierz bezpośredni sondę Novaverb do kontrolowanego pomiaru, jedno miasto Globalping do regionalnego sprawdzenia lub wszystkie dziesięć miast do porównania pięciu regionów. Dwie metody pozostają oddzielne, ponieważ mają różne granice przekierowania, przechwytywania i zatrzymywania.
🇩🇪 Lokalizacja Niemcy
- Działa na infrastrukturze Novaverb przez świeże połączenie HTTP/1.1.
- Śledzi do pięciu przekierowań HTTP i pokazuje końcowy wodospad odpowiedzi.
- Zbiera treść odpowiedzi do około 3 MB i utrzymuje zadeklarowaną długość oddzielnie.
- Nie konsumuje testów prób trzecich stron.
🌍 Jedno miasto lub wszystkie 10
- Aktualnie online badanie w wybranym mieście żąda dokładnego przesłanego URL.
- Zwraca DNS, TCP, TLS, czas pierwszego bajtu, czas pobierania i całkowity czas z dowodami z miasta i czasu.
- Nie podąża za pętlą przekierowań Novaverb; przetestuj zwrócone miejsce 3xx osobno.
- Metadane tożsamości Proby są celowo ukryte przed publicznym wynikiem.
- Cel i pomiar są przetwarzane przez Globalping i mogą pozostać dostępne przez maksymalnie siedem dni.
Jak ograniczone jest darmowe korzystanie: jedno wybrane miasto zużywa jeden test dostawcy; Porównaj wszystkie 10 zużywa dziesięć. Novaverb pozwala na maksymalnie 10 pojedynczych uruchomień w jednym mieście lub pięć porównań 10-miastowych na źródło na godzinę, i rezerwuje wspólny limit 200 testów dostawcy na godzinę. Górny nieautoryzowany zbiornik obecnie zapewnia 250 darmowych testów na godzinę, więc pojemność i dostępność prób na żywo mogą tymczasowo się wyczerpać.
Jak działa wodospad wydajności.
Wyszukiwanie DNS
Rozwiąż nazwę hosta, podczas gdy połączenie pozostaje przypięte do zwalidowanego publicznego IP.
Połączenie TCP
Otwórz świeże połączenie; żaden poprzedni gniazdo nie jest ponownie używane.
Uzgodnienie TLS
Negocjuj HTTPS z SNI i HTTP/1.1, gdy URL jest bezpieczny.
Pierwszy bajt
Mierz od wysłania GET do momentu przybycia pierwszych bajtów odpowiedzi.
Transfer HTML.
Mierz od pierwszego bajtu przez uchwyconą treść dokumentu, do około 3 MB.
Jak czytać pasma przewodnie TTFB.
web.dev podaje 800 ms lub mniej jako przybliżony dobry cel TTFB, a powyżej 1,800 ms jako słaby. Novaverb stosuje te pasma przewodnie do próbki połączenia do pierwszego bajtu ostatecznej odpowiedzi, a nie do całej podróży przekierowania.
Powtórz z regionów istotnych dla użytkownika, zanim stwierdzisz, że URL jest konsekwentnie szybki.
Użyj wodospadu, aby zidentyfikować, czy dominują ustawienia czy oczekiwanie na żądanie.
Powtórz test, porównaj stany pamięci podręcznej i zbadaj największą powtarzaną fazę.
Co zawiera ten wynik - i czego nie zawiera
Mierzone w tej sesji
- Świeża konfiguracja DNS, TCP i TLS dla każdego żądania.
- Transfer od żądania do pierwszego bajtu i uchwyconego ciała
- Przekierowania HTTP, status i nagłówki ostatecznej odpowiedzi.
- Bajty ciała odebrane i zadeklarowana długość treści oddzielone
- Jeden region pomiarowy: UE, Niemcy
Nie zmierzono ani nie udowodniono
- CSS, JavaScript, obrazy, czcionki lub zasoby zewnętrzne
- Analiza przeglądarki, renderowanie, wizualne zakończenie lub gotowość do interakcji
- LCP, INP, CLS, FCP lub wynik wydajności Lighthouse
- Percentyle rzeczywistych użytkowników, czas działania lub zachowanie przy obciążeniu
- Czysty czas wykonania pochodzenia oddzielony od opóźnienia CDN i sieci
Jak poprawić dominującą fazę.
Wysoki czas DNS.
Przejrzyj autorytatywne opóźnienie DNS i niezawodność; porównaj wiele uruchomień, ponieważ stan pamięci podręcznej resolvera się zmienia.
Wysoki czas TCP.
Zredukuj odległość z krawędzią lub CDN i zbadaj jakość trasy lub utratę pakietów.
Wysoki czas TLS.
Sprawdź łańcuch certyfikatów, nowoczesne wsparcie TLS i ponowne użycie połączenia w rzeczywistych przeglądarkach.
Wysoki czas oczekiwania na pierwszy bajt.
Sprawdź błędy pamięci podręcznej CDN, pracę bazy danych, wywołania zewnętrzne oraz kontencję aplikacji lub pochodzenia.
Wysoki transfer HTML.
Zredukuj rozmiar dokumentu i zweryfikuj odpowiednie kodowanie treści, pamiętając, że ten test uchwyca tylko dokument.
Wytyczne dotyczące standardów i pomiarów
Pytania dotyczące testu wydajności strony internetowej
Czy to jest pełny test prędkości strony?
Nie. Mierzy tylko czas połączenia i odpowiedzi dokumentu. Pełny test przeglądarki musi również ładować zależności, wykonywać skrypty i renderować stronę.
Dlaczego to różni się od Chrome lub Lighthouse?
Proba działa z serwera w Niemczech przez świeże połączenie HTTP/1.1. Twoja przeglądarka może użyć innej trasy, protokołu, pamięci podręcznej i ponownie używanego połączenia, a następnie wykonać pracę renderującą, której ten test nigdy nie próbuje.
Czy śledzi przekierowania?
Tak, do pięciu przekierowań HTTP. Każdy skok jest niezależnie mierzony przy świeżym żądaniu; główny wodospad to ostateczna odpowiedź.
Czy całkowity czas oznacza czas ładowania strony?
Nie. To suma faz połączenia i transferu uchwyconego dokumentu dla jednego żądania. Wyklucza subzasoby, wykonanie kodu, renderowanie i gotowość do interakcji.
Dlaczego pobrane bajty mogą różnić się od Content-Length?
Długość treści to nagłówek zadeklarowany przez serwer. Odebrane ciało to to, co ten ograniczony próbnik faktycznie uchwycił; duże odpowiedzi mogą zatrzymać się blisko 3 MB limitu bezpieczeństwa.
Dlaczego wyniki zmieniają się między uruchomieniami?
Stan pamięci podręcznej DNS i CDN, obciążenie źródła, routowanie sieciowe i wspólna infrastruktura różnią się. Diagnozuj wzorce w powtarzanych próbkach i danych rzeczywistych użytkowników, a nie w jednym przebiegu.
Każda liczba to pojedyncze syntetyczne żądanie z wybranego probownika; nie mierzy renderowania w przeglądarce, Core Web Vitals ani rzeczywistych użytkowników.
Co przesłać - i czego unikać
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.comKażda forma adresu działa. http lub https, z www lub bez, pusta domena lub pełna ścieżka - normalizujemy to dla Ciebie.A URL that redirectsW porządku - śledzimy każdy skok najpierw, a następnie mierzymy ostateczny cel.Expecting full page-load / render timeTo mierzy czasy serwera i połączenia (TTFB), a nie renderowanie całej strony przez przeglądarkę.Expecting your users' field numbersTo jedno syntetyczne zapytanie z ustalonej lokalizacji - użyj Core Web Vitals dla danych z rzeczywistych użytkowników.Dokładnie jak ten wynik jest produkowany
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.
- Normalizujemy adres i śledzimy łańcuch przekierowań zgodnie z semantyką HTTP do ostatecznego URL.
- Mierzymy DNS, TCP, TLS, TTFB i transfer treści jako standardowe fazy pomiaru nawigacji.
- Porównujemy TTFB z publicznymi wytycznymi w terenie i raportujemy każdą fazę, aby wolny etap był widoczny.
Międzynarodowe standardy, do których odnosi się to sprawdzenie
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.
Raportuje żądanie jako standardowe fazy DNS / TCP / TLS / TTFB / transferu.
Przeczytaj specyfikacjęPodąża za łańcuchem przekierowań zgodnie z semantyką HTTP przed ostatecznym pomiarem.
Przeczytaj specyfikacjęPorównuje zmierzony TTFB z publicznymi wytycznymi w zakresie pola.
Przeczytaj specyfikacjęWebsite 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.