DNSRésoudre
Outil gratuit · aucun compte requis
Free Server Response Time (TTFB) Test
Measure server Time to First Byte (TTFB), DNS lookup, TCP connect, and TLS handshake latency in real time. Instant server response test.
Aussi connu sous le nom de: TTFB test · Time to First Byte · server response time
Preuve montrée avec sourceAucun compte requisAucune métrique inventée
Une URL · quatre phases mesurées
Voir ce qui se passe avant le premier octet
Entrez une URL HTTP ou HTTPS publique ci-dessus. Le résultat sépare la configuration de connexion de l'attente de demande afin que vous sachiez quelle partie mérite une enquête.
TCPConnecter
TLSNégocier
Premier octetRépondre
Cibles publiques uniquement · IP fixée après validation · pas de timing estimé
Modèle de preuve
Savoir ce que le résultat prouve
This check proves how long one server took to send the first byte of a response to one Novaverb server, split into DNS lookup, TCP connect, TLS handshake and request wait. It is a server measurement, not a page-speed measurement: no browser rendering happens, so it says nothing about Core Web Vitals or what a visitor on another network experiences.
1. Source
One live HTTP/1.1 request over a fresh connection from Novaverb's server in Germany. The result identifies where its evidence came from.
2. Limite
This is one synthetic server-side request from Germany. It is not a visitor's browser TTFB, field data, Core Web Vitals, uptime monitoring, or a global multi-location test.
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 Vérificateur de Temps de Réponse du Serveur ?
Il ouvre une nouvelle connexion HTTP depuis le serveur de Novaverb en Allemagne et mesure quatre phases avant que le premier octet de réponse n'arrive : recherche DNS, connexion TCP, poignée de main TLS et demande au premier octet. Leur somme est le temps de connexion synthétique au premier octet affiché dans le résultat.
Comment fonctionne le test de temps de réponse
Validez l'URL
Seules les cibles HTTP ou HTTPS publiques sont acceptées. Les adresses privées et réservées sont rejetées.
Résoudre et épingler l'IP
Le DNS est chronométré, tandis que la connexion utilise l'IP publique déjà validée pour prévenir le rebinding DNS.
Ouvrir une nouvelle connexion
La sonde mesure TCP et, pour HTTPS, TLS sans réutiliser une connexion précédente.
Lire le premier octet
Après l'envoi de GET, la sonde arrête l'horloge TTFB lorsque les premiers octets de réponse arrivent.
Comment interpréter les bandes directrices TTFB
web.dev présente 800 ms ou moins comme un bon objectif TTFB approximatif et au-dessus de 1 800 ms comme mauvais. Ces bandes sont conçues pour l'interprétation de l'expérience utilisateur ; ici, elles sont uniquement une orientation pour un échantillon synthétique.
Re-tester et comparer depuis des régions utilisateurs pertinentes avant de conclure que l'URL est constamment rapide.
Utilisez la répartition des phases pour voir si la configuration de la connexion ou le temps de demande au premier octet domine.
Répétez le test, comparez le comportement mis en cache et non mis en cache, puis enquêtez sur la phase mesurée dominante.
Ce que ce résultat inclut - et ce qu'il n'inclut pas
Mesuré lors de cette exécution
- Une recherche DNS depuis le serveur de Novaverb
- Une nouvelle connexion TCP à l'IP publique validée
- Une poignée de main TLS pour une URL HTTPS
- Temps écoulé entre l'envoi de la demande et le premier octet de réponse
- Statut HTTP, emplacement de redirection, protocole et en-tête de serveur visible
Non mesuré ou prouvé
- TTFB réel ou navigateur depuis les emplacements de vos visiteurs
- LCP, CLS, INP, FCP ou toute évaluation des Core Web Vitals
- Exécution JavaScript, rendu, achèvement visuel ou préparation à l'interaction
- Temps de disponibilité, distribution percentile ou performance sous charge soutenue
- Temps d'exécution de l'application pur séparé de la latence de retour réseau
Qu'est-ce qui rend le premier octet lent ?
Un DNS autoritaire lent, une distance de résolveur ou une recherche non mise en cache peuvent augmenter la première phase.
Une longue distance réseau et une perte de paquets ajoutent des allers-retours avant qu'une demande HTTP ne soit envoyée.
Une connexion HTTPS fraîche nécessite une négociation cryptographique ; la réutilisation et le TLS moderne peuvent réduire le coût répété.
Les requêtes de base de données, les appels API, le code d'application et la contention des ressources peuvent retarder la génération de réponse.
Un cache manqué peut forcer l'edge à contacter l'origine, tandis qu'un cache réussi peut retourner beaucoup plus rapidement.
Chaque redirection ajoute une autre demande et peut-être une autre configuration DNS, TCP et TLS avant la page finale.
Normes et conseils de mesure
W3C · Navigation Timing Level 2Définit responseStart comme le point immédiatement après la réception du premier octet de réponse.
web.dev · Optimize TTFBExplique les bandes directrices approximatives de 800 ms et 1 800 ms et pourquoi TTFB n'est pas un Core Web Vital.
RFC 9110 · HTTP SemanticsLe statut HTTP et la sémantique de réponse sous-jacents à la demande mesurée.
Questions sur le temps de réponse du serveur
Est-ce le même TTFB que mes visiteurs expérimentent ?
Non. C'est une demande synthétique d'un serveur en Allemagne. Un visiteur peut utiliser une région, un chemin réseau, un protocole, un état de cache et une connexion réutilisée différents.
Le TTFB est-il un Core Web Vital ?
Non. Le TTFB est une métrique diagnostique fondamentale, mais les Core Web Vitals sont LCP, INP et CLS.
La demande au premier octet équivaut-elle au temps de traitement backend ?
Non. Cela inclut le traitement de l'application ou du CDN plus le temps réseau pour que les premiers octets reviennent à la sonde.
Le vérificateur suit-il les redirections ?
Non. Il chronomètre l'URL soumise exacte. Si cette réponse redirige, la destination est affichée afin que vous puissiez la tester séparément.
Pourquoi le résultat change-t-il entre les exécutions ?
L'état du cache DNS et CDN, la charge d'origine, le routage réseau, la congestion et l'infrastructure partagée peuvent tous varier. Comparez plusieurs échantillons et données de terrain.
Que devrais-je corriger en premier ?
Commencez par la phase répétée la plus grande. Un temps d'attente de demande élevé indique un comportement d'origine ou de cache ; des phases de connexion élevées indiquent une distance, un DNS ou une configuration de transport.
Ceci est une mesure synthétique unique côté serveur à partir d'un emplacement (UE · Allemagne), pas le TTFB d'un vrai navigateur utilisateur ou les Core Web Vitals de terrain.
Obtenez la bonne réponse
Ce qu'il faut soumettre - et ce qu'il faut éviter
Submit any public address. A bare domain, a full URL with a path or a query string are all normalised before the request. A private host is refused. Remember that one measurement from one location is a sample, and a cached hit and a cold miss on the same URL can differ by an order of magnitude.
Utilisez-le comme ceci
yourdomain.comToute forme d'adresse est correcte. http ou https, avec ou sans www, un domaine nu ou un chemin complet - nous le normalisons pour vous.Run it a few timesLisez la tendance, pas un seul chiffre - une seule requête varie avec des caches froids.Évitez cela
Reading it as 'my users' real speed'Ceci est une requête synthétique depuis l'Allemagne, pas l'expérience de vos visiteurs - considérez-le comme une référence backend.Expecting Core Web Vitals hereCeci mesure le temps du serveur (TTFB), pas le rendu du navigateur - utilisez l'outil Core Web Vitals pour les données de terrain.Méthodologie publique
Exactement comment ce résultat est produit
The address is normalised and a fresh HTTP/1.1 connection is opened from one Novaverb server, with every phase timed separately: DNS lookup, TCP connect, TLS handshake, request wait and total Time To First Byte. The TTFB is then banded against public web.dev guidance of roughly 800 ms at the 75th percentile, as orientation rather than a verdict.
- Nous normalisons l'adresse, ouvrons une nouvelle connexion HTTP/1.1 depuis un serveur Novaverb et chronométrons chaque phase séparément.
- Nous enregistrons la recherche DNS, la connexion TCP, la poignée de main TLS, l'attente de requête et le temps total jusqu'au premier octet (TTFB).
- Nous comparons le TTFB aux directives de terrain publiques web.dev (≈800 ms au 75e percentile) - orientation, pas un verdict de réussite/échec.
- Nous excluons complètement le rendu du navigateur ; ceci mesure le serveur, pas les Core Web Vitals.
Construit sur des normes publiques
Les normes internationales auxquelles cette vérification s'applique.
Three public references define the measurement and the bar. W3C Resource Timing defines the phases that are timed, RFC 9110 defines the HTTP semantics the request follows, and Google's web.dev TTFB guidance supplies the threshold. Because that guidance describes a 75th-percentile field distribution, a single sample is compared to it for orientation only.
W3CResource Timing
Resource & Navigation Timing
Décompose la requête en phases DNS, TCP, TLS et d'attente (TTFB) du modèle de timing W3C.
Lisez la spécificationIETFRFC 9110
HTTP Semantics
Émet une requête HTTP conforme aux normes et lit le statut de réponse.
Lisez la spécificationGoogleweb.dev TTFB
Time to First Byte guidance
Oriente votre TTFB mesuré par rapport à la bande de guidance publique de 800 ms.
Lisez la spécificationNous listons un standard uniquement lorsque cet outil le lit ou le mesure réellement. Lorsqu'un signal est en dehors d'une vérification en direct, le résultat le dit plutôt que d'impliquer une couverture.
Questions courantes
Server Response Time Checker FAQ
What does the Novaverb Server Response Time Checker measure?
It measures your server-side connection timing for a URL: DNS lookup, TCP connect, TLS handshake, request wait, and total Time To First Byte (TTFB), from one Novaverb server in Germany over a fresh HTTP/1.1 connection.
What is TTFB (Time To First Byte)?
TTFB is the time from starting a request to receiving the first byte of the response. It captures DNS, connection setup, and server processing, reflecting how quickly your backend and network begin answering.
What is a good TTFB value?
As a server-side rule of thumb, under 200 milliseconds is excellent, under 500 milliseconds is acceptable, and above 800 milliseconds warrants investigation. Note web.dev field guidance targets 800 milliseconds at the 75th percentile for real users.
Is this the same as the TTFB my visitors experience?
No. This is one synthetic request from Germany, so it excludes your visitors' distance, devices, networks, and browser behaviour. Real-user TTFB varies by location and connection; treat this number as a clean backend baseline.
Why is my server response time slow and how do I improve it?
Common causes are slow database queries, no caching, and distant hosting. Improve it with server-side and full-page caching, a CDN to shorten network distance, faster backend code, and HTTP keep-alive or connection reuse.
Does this tool measure Core Web Vitals?
No. Core Web Vitals like Largest Contentful Paint and Interaction to Next Paint are browser-rendering and field metrics. This tool measures only server-side connection timing and TTFB, which precede and influence rendering but do not equal it.
Why does the DNS or TLS number vary between checks?
Each check opens a fresh connection, so cold DNS caches, certificate negotiation, and server load cause run-to-run variation. Run several checks and compare the trend rather than reading any single measurement as definitive.
What is the difference between TTFB and page load time?
TTFB measures when the first response byte arrives from the server. Page load time measures when the browser finishes downloading and rendering everything. A fast TTFB is necessary but not sufficient for a fast-feeling page.
Does response time from one location represent global performance?
No. This is a single measurement from Germany and does not reflect users in other regions. For worldwide visibility, use a multi-location or field-data tool; this check is best for tracking your backend from a consistent vantage point.
How does server response time affect SEO?
A slow TTFB delays every downstream metric Googlebot and users experience, from crawl efficiency to Core Web Vitals. Faster server responses help pages render sooner, improving perceived speed, which supports rankings and reduces abandonment.
Plus de vérifications gratuites
Explorer tous les outils gratuits de Novaverb
Vérificateur SEO de site webCouverture de crawl, pages indexables et liens internes
Keyword Research ToolFree AI keyword research tool for search volume, keyword difficulty, …
SERP CheckerCheck live organic search results and AI Overview rankings for …
Website Security CheckerAudit website security posture, TLS/SSL certificates, HTTP security headers, and …
Backlink CheckerExplore backlinks, referring domains, dofollow links, and domain authority for …
Robots.txt CheckerTest and validate robots.txt rules, User-Agent directives, blocked paths and …
Sitemap CheckerValidate XML sitemap structure, URL counts, reachability, and index type. …
Meta Tag CheckerCheck page title length, meta description, H1 heading structure, Open …
HTTP Status & Redirect CheckerTrace HTTP status codes (200, 301, 302, 404, 500) and …
Website MonitorMonitor website availability, HTTP status code, and server response time …
HTTP/2 TestCheck whether your web server supports HTTP/2 via TLS ALPN …
HTTP/3 TestTest whether your web server supports HTTP/3 over QUIC with …
Website Performance TestTest global website loading speed and TTFB waterfall timing across …
GEO CheckerAudit whether ChatGPT, Perplexity, Gemini, and Google AI Overviews can …
Core Web Vitals CheckerCheck real-user Core Web Vitals (LCP, INP, CLS) from Chrome …
PageSpeed CheckerRun a live Lighthouse performance audit to test PageSpeed, Core …
Website Safety CheckerCheck whether a domain or URL is flagged for malware, …
Knowledge Graph CheckerCheck whether a brand, person, product or organization is recognized …
Keyword Gap CheckerCompare your site against competitors to find missing high-traffic keywords, …
Competitor Top PagesFind top organic traffic-driving pages for any competitor domain. See …