DNSGiải quyết
Công cụ miễn phí, không cần tài khoản
Free Server Response Time Checker: DNS, TCP, TLS and TTFB
The Novaverb server response time checker sends one live HTTP/1.1 request from a server in Germany and times DNS lookup, TCP connect, TLS handshake and the wait for the first byte.
Còn được gọi là: Kiểm tra TTFB, Thời gian đến Byte đầu tiên, thời gian phản hồi máy chủ
Bằng chứng được hiển thị với nguồnKhông cần tài khoảnKhông có chỉ số nào được tạo ra.
Một URL, bốn giai đoạn đo được
Xem điều gì xảy ra trước byte đầu tiên
Nhập một URL HTTP hoặc HTTPS công khai ở trên. Kết quả tách biệt thiết lập kết nối khỏi thời gian chờ yêu cầu để bạn biết phần nào cần điều tra.
TCPKết nối
TLSĐàm phán
Byte đầu tiênPhản hồi
Chỉ mục tiêu công khai, IP được gán sau khi xác thực, không có thời gian ước tính
Định nghĩa
What is a server response time checker?
A server response time checker measures how long a web server takes to begin answering one request. The Novaverb Server Response Time Checker opens one fresh HTTP/1.1 connection from a server in Germany and reports Time to First Byte, split into DNS lookup, TCP connect, TLS handshake and request wait.
Phạm vi
What does the server response time checker measure?
The server response time checker measures four phases before the first response byte arrives: DNS lookup, TCP connection, TLS handshake for an HTTPS address, and request to first byte. Alongside the timings, the tool reads the HTTP status, the protocol and TLS version, the visible server header and any redirect location.
Dành cho ai
Who is the server response time checker for?
The server response time checker is for anyone who must decide whether a slow page starts at the server. A developer runs it after a deploy or a cache change, a site owner runs it before blaming a host, and an SEO specialist runs it to separate backend delay from rendering problems.
Vì sao quan trọng
Why use a server response time checker?
A server response time checker catches a slow first byte before it delays everything the browser loads afterward. Splitting the total into connection setup and request wait shows whether time is lost to distance, DNS or TLS, or to origin and cache behavior, so the repair goes to the right layer.
Phương pháp
How does the server response time checker work?
The server response time checker works in four steps. The address is validated as a public HTTP or HTTPS target. DNS is timed while the connection stays pinned to the validated public IP. A fresh TCP connection opens, with TLS for HTTPS. GET is sent and the clock stops at the first response bytes.
- Chúng tôi chuẩn hóa địa chỉ, mở một kết nối HTTP/1.1 mới từ một máy chủ Novaverb và đo thời gian từng giai đoạn riêng biệt.
- Chúng tôi ghi lại thời gian tra cứu DNS, kết nối TCP, bắt tay TLS, thời gian chờ yêu cầu và tổng thời gian đến byte đầu tiên (TTFB).
- Chúng tôi xếp TTFB vào dải theo hướng dẫn công khai của Google trên web.dev ở bách phân vị 75 - để định hướng, không phải kết luận đạt hay không đạt.
- Chúng tôi hoàn toàn loại trừ việc trình duyệt hiển thị; điều này đo máy chủ, không phải Core Web Vitals.
Đầu vào
What do you enter into the server response time checker?
Enter any public address into the server response time checker, either a bare domain or a full URL with a path or query string. The address is normalized before the request, and private or reserved hosts are refused. Redirects are not followed, so a redirecting address reports only the timing of its redirect response.
Sử dụng nó như thế này
yourdomain.comBất kỳ hình thức địa chỉ nào cũng tốt. http hoặc https, có hoặc không có www, chỉ tên miền hay một đường dẫn đầy đủ - chúng tôi chuẩn hóa cho bạn.Run it a few timesHãy đọc xu hướng, đừng đọc một con số - một yêu cầu đơn lẻ có thể sai lệch khi bộ nhớ cache còn nguội.Tránh điều này
Reading it as 'my users' real speed'Đây là phép đo mô phỏng từ Đức, không phải trải nghiệm thực tế của người truy cập. Hãy dùng kết quả này làm mốc tham chiếu cho hệ thống máy chủ.Expecting Core Web Vitals hereĐiều này đo thời gian máy chủ (TTFB), không phải việc trình duyệt hiển thị - sử dụng công cụ Core Web Vitals cho các chỉ số thực địa.Kết quả
What does a server response time checker report contain?
A server response time checker report contains the connection to first byte total with its guide band, a split between request wait and connection setup with each share of the total, and one card per measured phase. Further rows show HTTP status, protocol, server header, redirect target and, when response headers reveal it, a cache hit or miss.
Cách đọc
How do you read a server response time result?
Read a server response time result by finding the largest phase first. A high request wait points toward origin or cache behavior, while high DNS, TCP or TLS phases point toward distance or transport setup. The guide band is orientation for one synthetic sample, so run the test several times and compare the trend.
Trình kiểm tra Thời gian Phản hồi Máy chủ đo lường điều gì?
Nó mở một kết nối HTTP mới từ máy chủ của Novaverb ở Đức và đo bốn giai đoạn trước khi byte phản hồi đầu tiên đến: tra cứu DNS, kết nối TCP, bắt tay TLS và yêu cầu đến byte đầu tiên. Tổng của chúng là thời gian kết nối đến byte đầu tiên tổng hợp được hiển thị trong kết quả.
Cách kiểm tra thời gian phản hồi hoạt động
Xác thực URL
Chỉ chấp nhận các mục tiêu HTTP hoặc HTTPS công khai. Các địa chỉ riêng tư và địa chỉ được dành riêng sẽ bị từ chối.
Giải quyết và ghim IP
Thời gian phân giải DNS được đo, trong khi kết nối dùng địa chỉ IP công khai đã được xác thực để ngăn DNS rebinding.
Mở một kết nối mới
Probe đo TCP, và với HTTPS thì đo cả TLS, mà không tái sử dụng kết nối nào trước đó.
Đọc byte đầu tiên
Sau khi gửi GET, probe dừng đồng hồ TTFB khi những byte phản hồi đầu tiên đến.
Cách diễn giải các băng hướng dẫn TTFB
web.dev đưa ra mức 800 ms trở xuống như một mục tiêu TTFB tốt mang tính ước lệ, và trên 1.800 ms là kém. Các dải này được thiết kế để diễn giải trải nghiệm người dùng; ở đây chúng chỉ mang tính định hướng cho một mẫu đo mô phỏng.
Kiểm tra lại và so sánh từ các khu vực người dùng liên quan trước khi kết luận URL luôn nhanh.
Sử dụng phân tích giai đoạn để xem liệu thiết lập kết nối hay thời gian yêu cầu đến byte đầu tiên chiếm ưu thế.
Lặp lại phép đo, so sánh hành vi khi có và khi không có bộ nhớ đệm, sau đó điều tra giai đoạn chiếm phần lớn thời gian đo được.
Kết quả này bao gồm gì - và những gì nó không có
Được đo trong lần chạy này
- Một tra cứu DNS từ máy chủ Novaverb
- Một kết nối TCP mới đến IP công cộng đã xác thực
- Một bắt tay TLS cho một URL HTTPS
- Thời gian từ khi gửi yêu cầu đến khi nhận byte phản hồi đầu tiên
- Trạng thái HTTP, vị trí chuyển hướng, giao thức và tiêu đề máy chủ hiển thị
Chưa được đo hoặc chứng minh
- Thời gian phản hồi từ người dùng thực hoặc trình duyệt từ vị trí của khách truy cập của bạn
- LCP, CLS, INP, FCP hoặc bất kỳ đánh giá Core Web Vitals nào
- Thực thi JavaScript, kết xuất, hoàn tất hiển thị hình ảnh hoặc mức sẵn sàng tương tác
- Thời gian hoạt động, phân phối phần trăm hoặc hiệu suất dưới tải liên tục
- Thời gian thực thi ứng dụng thuần túy tách biệt với độ trễ trả về mạng
Những gì thường làm cho byte đầu tiên chậm?
DNS có thẩm quyền phản hồi chậm, khoảng cách tới bộ phân giải (resolver) hoặc một truy vấn chưa được lưu trong bộ nhớ đệm đều có thể làm tăng thời gian của giai đoạn đầu tiên.
Khoảng cách mạng xa và mất gói làm tăng số vòng truyền khứ hồi trước khi bất kỳ yêu cầu HTTP nào được gửi đi.
Một kết nối HTTPS mới yêu cầu thương lượng mã hóa; tái sử dụng và TLS hiện đại có thể giảm chi phí lặp lại.
Truy vấn cơ sở dữ liệu, lệnh gọi API, mã ứng dụng và tranh chấp tài nguyên có thể làm chậm quá trình tạo phản hồi.
Một lần trượt bộ nhớ đệm (cache miss) có thể buộc máy chủ biên phải liên hệ với máy chủ gốc, trong khi một lần trúng bộ nhớ đệm (cache hit) có thể trả về nhanh hơn nhiều.
Mỗi redirect thêm một yêu cầu nữa và có thể thêm một lượt thiết lập DNS, TCP và TLS nữa trước khi đến trang cuối cùng.
Hướng dẫn tiêu chuẩn và đo lường
W3C, Navigation Timing Level 2Định nghĩa responseStart là điểm ngay sau khi byte phản hồi đầu tiên được nhận.
web.dev, Optimize TTFBGiải thích các dải tham chiếu gần đúng 800 ms và 1.800 ms, và lý do TTFB không phải là một Core Web Vital.
RFC 9110, HTTP SemanticsTrạng thái HTTP và ngữ nghĩa phản hồi làm nền tảng cho yêu cầu được đo.
Câu hỏi về thời gian phản hồi của máy chủ
Đây có phải là TTFB mà khách truy cập của tôi trải nghiệm không?
Không. Đây là một yêu cầu mô phỏng từ một máy chủ ở Đức. Một khách truy cập có thể ở khu vực khác, đi theo đường mạng khác, dùng giao thức khác, có trạng thái bộ nhớ đệm khác và dùng lại kết nối sẵn có.
TTFB có phải là một Core Web Vital không?
Không. TTFB là một chỉ số chẩn đoán cơ bản, nhưng các Core Web Vitals là LCP, INP và CLS.
Thời gian nhận byte đầu tiên có phải chỉ là thời gian xử lý của máy chủ không?
Không. Nó bao gồm thời gian xử lý của ứng dụng hoặc CDN, cộng với thời gian truyền mạng để những byte đầu tiên quay về probe.
Trình kiểm tra có theo dõi chuyển hướng không?
Không. Nó đo đúng URL mà bạn đã gửi. Nếu phản hồi đó là một redirect, đích đến sẽ được hiển thị để bạn kiểm tra riêng.
Tại sao kết quả lại thay đổi giữa các lần chạy?
Trạng thái bộ nhớ đệm của DNS và CDN, tải của máy chủ gốc, định tuyến mạng, tắc nghẽn và hạ tầng dùng chung đều có thể thay đổi. Hãy so sánh nhiều mẫu đo và dữ liệu người dùng thực tế.
Tôi nên sửa chữa điều gì trước tiên?
Bắt đầu từ giai đoạn lặp lại có thời lượng lớn nhất. Thời gian chờ yêu cầu cao chỉ về phía máy chủ gốc hoặc hành vi của bộ nhớ đệm; các giai đoạn kết nối cao chỉ về phía khoảng cách, DNS hoặc thiết lập tầng vận chuyển.
Đây là một phép đo tổng hợp duy nhất từ một vị trí (EU, Đức), không phải là TTFB của trình duyệt người dùng thực hoặc Core Web Vitals thực địa.
Nguồn
Where does the server response time checker get its data?
The server response time checker gets its data from one live HTTP/1.1 request over a fresh connection, sent from Novaverb's server in Germany when you run it. Every phase shown is timed during that request. If the probe cannot complete a public connection within the timeout, the tool reports that no response time was measured.
Giới hạn
What does the server response time checker not tell you?
The server response time checker does not tell you what visitors experience. One synthetic server-side request from Germany is not a visitor's browser TTFB, field data, Core Web Vitals, uptime monitoring or a global multi-location test. Request wait also includes the network return path, so it is not pure application execution time.
Bằng chứng
What does a server response time result prove?
A server response time result proves how long one server took to send the first byte to one Novaverb server on one run, and which phase consumed that time. It cannot prove the page is fast or slow for real users, because no browser rendering happens and a cached hit and a cold miss can differ widely.
1. Nguồn
Một yêu cầu HTTP/1.1 trực tiếp trên kết nối mới từ máy chủ Novaverb tại Đức. Kết quả xác định nguồn gốc của bằng chứng.
2. Ranh giới
Đây là một yêu cầu tổng hợp phía máy chủ, phát từ Đức. Nó không phải TTFB trên trình duyệt của khách, không phải dữ liệu thực địa, không phải Core Web Vitals, không phải giám sát uptime và không phải phép đo đa vị trí toàn cầu.
3. Hành động tiếp theo
Sử dụng phát hiện để xác minh một vấn đề, sau đó kết nối một không gian làm việc khi bạn cần lịch sử, giám sát hoặc phân tích toàn bộ trang web.
Tiêu chuẩn
Which standards does the server response time checker apply?
The server response time checker applies W3C Resource Timing, RFC 9110 and the web.dev Time to First Byte guidance. Resource Timing defines the DNS, TCP, TLS and wait phases that are timed. RFC 9110 defines the HTTP semantics of the request and response. The guidance supplies the guide bands, which describe a 75th percentile field distribution.
W3CResource Timing
Resource & Navigation Timing
Phân tách yêu cầu thành các giai đoạn DNS, TCP, TLS và chờ (TTFB) của mô hình thời gian W3C.
Đọc thông số kỹ thuậtIETFRFC 9110
HTTP Semantics
Gửi một yêu cầu HTTP tuân thủ tiêu chuẩn và đọc trạng thái phản hồi.
Đọc thông số kỹ thuậtGoogleweb.dev TTFB
Time to First Byte guidance
Đối chiếu TTFB bạn đo được với dải khuyến nghị công khai 800 ms cho dữ liệu thực tế.
Đọc thông số kỹ thuậtChúng tôi chỉ liệt kê một tiêu chuẩn khi công cụ này thực sự đọc hoặc đo lường theo đó. Khi một tín hiệu nằm ngoài kiểm tra trực tiếp, kết quả sẽ nói rõ điều đó thay vì ngụ ý rằng có sự bao phủ.
Xác minh
How can you verify a server response time result yourself?
Verify a server response time result by timing the same URL with a command-line HTTP client that prints DNS, connect, TLS and first byte times, or by reading the document request in the browser network panel. Expect different absolute numbers from another location, and compare which phase dominates instead of the totals.
Ví dụ
What does a typical server response time finding look like?
A typical server response time finding is a page whose request wait dominates the total while DNS, TCP and TLS stay small, with a response header marking a cache miss. That pattern points at origin work or caching, not distance. A second run that returns a cache hit can report a much shorter wait.
Chi phí
Is the server response time checker free?
The server response time checker is free and needs no account to run a live request and see the full phase breakdown. A free Novaverb account is needed only for what one public run cannot do: saving the evidence, monitoring response time over time and turning a finding into a rechecked task.
Trong không gian làm việc
What does a Novaverb workspace add to the server response time checker?
A Novaverb workspace adds saved evidence, monitoring over time and site-wide analysis to the server response time checker, which measures one URL once. Site Health continues the job: it evaluates the URLs captured by a crawl of the whole site against supported technical checks, orders the findings by severity and records fresh rechecks.
Khi nào cần đi xa hơn
When is a free server response time checker not enough?
A free server response time checker is not enough when the question covers more than one URL at one moment. Judging a whole site, proving that a fix held after release, watching for a slowdown under load, or comparing the regions where customers live all need recurring or site-wide measurement, not a single sample.
Bước kế tiếp
What should you do after running the server response time checker?
After running the server response time checker, repeat the test to confirm the pattern, then compare cached and uncached behavior. Investigate the dominant phase next: caching and origin work for a high request wait, DNS or distance for slow setup. If the URL redirected, test the destination separately, then compare with field data.
Công cụ liên quan
Which free tools pair with the server response time checker?
Several free tools pair with the server response time checker. The Website Performance Test adds community probes in other regions and an HTML transfer phase. The HTTP Status & Redirect Checker traces the redirect chain this tool does not follow. The Core Web Vitals Checker shows the real-user field data a server timing cannot.
Công cụ kiểm tra SEO websiteHomepage status, indexability, title, headings and links from one live scan
Công cụ nghiên cứu từ khóaFree keyword research tool: monthly searches, cost per click, ad …
Trình kiểm tra SERPFree SERP checker: the organic results for a keyword in …
Công cụ Kiểm tra Bảo mật Trang webFree website security checker: a limited outside check of a …
Kiểm tra Cấu hình Bảo mật WordPressFree WordPress security checker: eight public configuration areas on a …
Phân tích BacklinksFree backlink checker: see the referring domains, link totals, follow …
Trình kiểm tra robots.txtFree robots.txt tester: fetch a site's live robots.txt and see …
Sitemap CheckerFree sitemap checker: find a site's XML sitemaps from robots.txt …
Trình kiểm tra thẻ metaFree meta tag checker: a page's live title, meta description, …
Trình kiểm tra trạng thái HTTP và chuyển hướngFree redirect checker: trace every hop of a URL's redirect …
Giám sát trang webFree website status checker: one live request to your address …
Kiểm tra HTTP/2Free HTTP/2 test: opens one live TLS connection to a …
Kiểm tra HTTP/3Free HTTP/3 test: attempts a real QUIC connection to a …
Kiểm tra Hiệu suất Trang webFree website performance test: time one request to your URL …
Trình kiểm tra GEOFree GEO checker: retrieve, quote, cite and graph signals from …
Công cụ kiểm tra Core Web VitalsFree Core Web Vitals checker: real-user LCP, INP and CLS …
Trình kiểm tra PageSpeedFree PageSpeed checker: a Lighthouse lab audit of a public …
Kiểm tra an toàn trang webFree website safety checker: see whether a URL is listed …
Kiểm tra Knowledge GraphFree Knowledge Graph checker: look up a brand or name …
Kiểm tra khoảng cách từ khóaFree keyword gap analysis: keywords a competitor ranks for and …
Các trang hàng đầu của đối thủFree competitor top pages tool: a domain's leading pages by …
Câu hỏi
What do people ask about the server response time checker?
People ask the server response time checker FAQ what TTFB is, what a good value looks like, and whether the number matches what visitors experience. Other questions cover why DNS or TLS varies between runs, whether redirects are followed, how first byte differs from page load time, and what to fix first.
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?
Không có một con số duy nhất phù hợp với mọi website. Công cụ này xếp TTFB đo được của bạn vào các dải theo hướng dẫn công khai của Google trên web.dev ở bách phân vị 75 và hiển thị kết luận ngay bên cạnh giá trị, nên dải sẽ thay đổi khi hướng dẫn thay đổi. Hãy coi kết quả đo tổng hợp là mức nền của máy chủ; người dùng thật còn cộng thêm khoảng cách và thời gian thiết bị.
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 behavior. 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.