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

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.

Còn được gọi là: TTFB test · Time to First Byte · server response time
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 được đo

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 công cộng · 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

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. Nguồn

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. Ranh giới

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. 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ỉ các mục tiêu HTTP hoặc HTTPS công cộng được chấp nhận. Các địa chỉ riêng và dự trữ bị từ chối.

2

Giải quyết và ghim IP

DNS được tính thời gian, trong khi kết nối sử dụng IP công khai đã được xác thực để ngăn chặn tái liên kết DNS.

3

Mở một kết nối mới

Probe đo TCP và, đối với HTTPS, TLS mà không tái sử dụng một kết nối trước đó.

4

Đọc byte đầu tiên

Sau khi gửi GET, đầu dò dừng đồng hồ TTFB khi các 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 trình bày 800 ms hoặc ít hơn như một mục tiêu TTFB tốt thô và trên 1,800 ms là kém. Những băng này được thiết kế để diễn giải trải nghiệm người dùng; ở đây chúng chỉ là định hướng cho một mẫu tổng hợp.

≤ 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 bài kiểm tra, so sánh hành vi đã lưu và chưa lưu, sau đó điều tra giai đoạn đo lường chiếm ưu thế.

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 thành trực quan hoặ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 ủy quyền chậm, khoảng cách bộ giải hoặc tìm kiếm chưa lưu có thể làm tăng giai đoạn đầu tiên.

TCP và địa lý

Khoảng cách mạng dài và mất gói thêm các vòng đi trước khi bất kỳ yêu cầu HTTP nào được gử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

Các truy vấn cơ sở dữ liệu, cuộc gọi API, mã ứng dụng và sự cạnh tranh 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ỗi bộ nhớ cache có thể buộc biên giới liên hệ với nguồn gốc, trong khi một lần truy cập có thể trả về nhanh hơn nhiều.

Chuyển hướng

Mỗi chuyển hướng thêm một yêu cầu khác và có thể thêm một DNS, TCP và thiết lập TLS khác trước 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 tổng hợp từ một máy chủ ở Đức. Một khách truy cập có thể sử dụng một khu vực, đường mạng, giao thức, trạng thái bộ nhớ đệm và kết nối đã sử dụng khá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.

Yêu cầu đến byte đầu tiên có bằng thời gian xử lý backend không?

Không. Nó bao gồm xử lý ứng dụng hoặc CDN cộng với thời gian mạng cho các byte đầu tiên trở lại vị trí kiểm tra.

Trình kiểm tra có theo dõi chuyển hướng không?

Không. Nó đo thời gian chính xác của URL đã gửi. Nếu phản hồi đó chuyển hướng, đích sẽ được hiển thị để bạn có thể 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 DNS và CDN, tải gốc, định tuyến mạng, tắc nghẽn và hạ tầng chia sẻ có thể thay đổi. So sánh nhiều mẫu và dữ liệu thực địa.

Tôi nên sửa chữa điều gì trước tiên?

Bắt đầu với giai đoạn lặp lại lớn nhất. Thời gian chờ yêu cầu cao chỉ ra hành vi nguồn hoặc bộ nhớ đệm; các giai đoạn kết nối cao chỉ ra khoảng cách, DNS hoặc thiết lập 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

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.

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, một miền trống hoặc một đường dẫn đầy đủ - chúng tôi chuẩn hóa cho bạn.
Run it a few timesĐọc xu hướng, không phải một con số - một yêu cầu đơn lẻ thay đổi với bộ nhớ cache lạnh.
Tránh điều này
Reading it as 'my users' real speed'Đây là một yêu cầu tổng hợp từ Đức, không phải trải nghiệm của khách truy cập của bạn - coi nó như một cơ sở backend.
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

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.

  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 so sánh TTFB với hướng dẫn thực địa web.dev công khai (≈800 ms tại phần trăm thứ 75) - định hướng, không phải phán quyết đỗ/không đỗ.
  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

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

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
IETFRFC 9110
HTTP Semantics

Phát hành 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
Googleweb.dev TTFB
Time to First Byte guidance

Định hướng TTFB đã đo lường của bạn theo băng hướng dẫn trường công khai 800 ms.

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

Server Response Time Checker 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?

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.

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

Trình kiểm tra SEO trang webPhạm vi thu thập thông tin, các trang có thể lập chỉ mục và liên kết nội bộ
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 …
Duyệt trung tâm công cụ miễn phí đầy đủ
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 kênh: thực hiện kiểm tra, hiểu bằng chứng, sau đó sửa chữa và chứng minh rằng nó đã được giải quyết với một lần kiểm tra lại mới - không có trạng thái vượt qua nào được tạo ra.