Kiểm tra thời gian phản hồi máy chủ (TTFB) miễn phí
Đo thời gian máy chủ trả về byte đầu tiên (TTFB), tra cứu DNS, kết nối TCP và độ trễ bắt tay TLS theo thời gian thực. Kiểm tra phản hồi máy chủ tức thì.
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.
Biết điều gì mà kết quả chứng minh
Kiểm tra này chứng minh một máy chủ mất bao lâu để gửi byte đầu tiên của phản hồi tới một máy chủ Novaverb, chia thành tra cứu DNS, kết nối TCP, bắt tay TLS và thời gian chờ phản hồi. Đây là phép đo phía máy chủ, không phải phép đo tốc độ trang: không có bước kết xuất nào trong trình duyệt, nên nó không nói gì về Core Web Vitals hay về trải nghiệm của một khách truy cập trên mạng khác.
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.
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
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.
Điều gì cần gửi - và điều gì cần tránh
Gửi bất kỳ địa chỉ công khai nào. Một miền trống, một URL đầy đủ với một đường dẫn hoặc một chuỗi truy vấn đều được chuẩn hóa trước khi yêu cầu. Một máy chủ riêng tư sẽ bị từ chối. Nhớ rằng một phép đo từ một vị trí là một mẫu, và một lần truy cập được lưu cache và một lần truy cập lạnh trên cùng một URL có thể khác nhau rất nhiều.
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.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.Chính xác cách kết quả này được sản xuất
Địa chỉ được chuẩn hóa và một kết nối HTTP/1.1 mới được mở từ một máy chủ Novaverb, với từng giai đoạn được đo riêng: tra cứu DNS, kết nối TCP, bắt tay TLS, chờ phản hồi và tổng Time To First Byte. TTFB sau đó được xếp 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 chứ không phải kết luận.
- 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.
Các tiêu chuẩn quốc tế mà kiểm tra này áp dụng
Ba tài liệu công khai xác định phép đo và thanh. W3C Resource Timing xác định các giai đoạn được đo thời gian, RFC 9110 xác định ngữ nghĩa HTTP mà yêu cầu tuân theo, và hướng dẫn TTFB của Google web.dev cung cấp ngưỡng. Bởi vì hướng dẫn đó mô tả phân phối trường 75th-percentile, một mẫu đơn lẻ được so sánh với nó chỉ để định hướng.
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ậtGử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ậtĐố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ậtKiểm tra thời gian phản hồi máy chủ Câu hỏi thường gặp
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.