Công cụ miễn phí, không cần tài khoản

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ì.

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.

DNSGiải quyết
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
Mô hình bằng chứng

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

1

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.

2

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.

3

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 đó.

4

Đọ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.

≤ 800 msBăng hướng dẫn tốt

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.

801–1.800 msCần xem xét

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ế.

> 1.800 msBăng thông hướng dẫn chậm

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?

Tra cứu DNS

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.

TCP và địa lý

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.

Thương lượng TLS

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.

Xử lý nguồn gốc

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.

CDN hoặc lỗi bộ nhớ cache

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.

Chuyển hướng

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.

Nhận câu trả lời đúng

Đ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.

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.
Phương pháp công khai

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.

  1. 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.
  2. 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).
  3. 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.
  4. 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.
Xây dựng trên các tiêu chuẩn công khai

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.

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ật
Googleweb.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ật
Chú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ủ.
Câu hỏi thường gặp

Kiể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.

Nhiều kiểm tra miễn phí hơn

Khám phá tất cả Công cụ Miễn phí của Novaverb

Công cụ kiểm tra SEO websitePhạm vi thu thập dữ liệu, các trang có thể lập chỉ mục và liên kết nội bộ
Công cụ nghiên cứu từ khóaKiểm tra khối lượng tìm kiếm có sẵn của truy …
Trình kiểm tra SERPKiểm tra các kết quả tự nhiên trả về cho …
Công cụ Kiểm tra Bảo mật Trang webRà soát trạng thái bảo mật của trang web, chứng …
Kiểm tra Cấu hình Bảo mật WordPressKiểm tra tám khu vực cấu hình WordPress có thể …
Phân tích BacklinksKiểm tra dữ liệu backlink và tên miền giới thiệu …
Trình kiểm tra robots.txtKiểm tra và xác thực các quy tắc robots.txt, chỉ …
Sitemap CheckerPhát hiện các khai báo sitemap, kiểm tra tài liệu …
Trình kiểm tra thẻ metaKiểm tra độ dài tiêu đề trang, mô tả meta, …
Trình kiểm tra trạng thái HTTP và chuyển hướngTruy vết mã trạng thái HTTP (200, 301, 302, 404, …
Giám sát trang webChạy một lượt kiểm tra khả dụng trực tiếp và …
Kiểm tra HTTP/2Kiểm tra xem đúng tên máy chủ đã gửi có …
Kiểm tra HTTP/3Dùng một phép thử bắt tay trực tiếp để kiểm …
Kiểm tra Hiệu suất Trang webSo sánh thời gian phản hồi HTTP từ các vị …
Trình kiểm tra GEOKiểm tra các tín hiệu quan sát được trên trang …
Công cụ kiểm tra Core Web VitalsKiểm tra LCP, INP và CLS của người dùng thực …
Trình kiểm tra PageSpeedChạy một lượt kiểm tra Lighthouse trong phòng thí nghiệm …
Kiểm tra an toàn trang webKiểm tra xem một miền hoặc URL có bị gắn …
Kiểm tra Knowledge GraphTra cứu các thực thể trùng khớp với một thương …
Kiểm tra khoảng cách từ khóaTìm các từ khóa xếp hạng được quan sát cho …
Các trang hàng đầu của đối thủTìm các trang có lưu lượng truy cập tự nhiên …
Kiểm tra → hiểu → sửa

Biến kiểm tra này thành một sửa chữa đã được xác minh

Mỗi công cụ miễn phí của Novaverb là một phễu duy nhất: chạy kiểm tra, hiểu bằng chứng, rồi sửa và chứng minh vấn đề đã được xử lý bằng một lần kiểm tra lại mới - không bịa ra trạng thái đạt.