Безкоштовний інструмент · обліковий запис не потрібен

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.

Також відомий як: TTFB test · Time to First Byte · server response time

Докази, показані з джереломОбліковий запис не потрібенНемає вигаданих метрик

Одна URL-адреса · чотири виміряні фази

Подивіться, що відбувається перед першим байтом

Введіть публічну HTTP або HTTPS URL вище. Результат розділяє налаштування з'єднання від очікування запиту, щоб ви знали, яка частина потребує розслідування.

DNSВирішити

TCPПідключити

TLSПереговори

Перший байтВідповісти

Тільки публічні цілі · IP закріплено після валідації · без оцінки часу

Модель доказів

Знайте, що доводить результат

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. Джерело

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. Межа

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. Наступна дія

Використовуйте знахідку для перевірки проблеми, а потім підключіть робочий простір, коли вам потрібна історія, моніторинг або аналіз всього сайту.

Що вимірює перевірник часу відповіді сервера?

Він відкриває одне нове HTTP-з'єднання з сервера Novaverb у Німеччині та вимірює чотири фази до прибуття першого байта відповіді: DNS-запит, TCP-з'єднання, TLS-рукопожаття та запит до першого байта. Їхня сума є синтетичним часом з'єднання до першого байта, показаним у результаті.

Як працює тест часу відповіді

Перевірте URL-адресу

Приймаються лише публічні HTTP або HTTPS цілі. Приватні та зарезервовані адреси відхиляються.

Вирішити та закріпити IP

DNS має таймер, тоді як з'єднання використовує вже перевірену публічну IP-адресу, щоб запобігти повторному зв'язуванню DNS.

Відкрити нове з'єднання

Проба вимірює TCP і, для HTTPS, TLS без повторного використання попереднього з'єднання.

Прочитати перший байт

Після відправлення GET, зонд зупиняє годинник TTFB, коли приходять перші байти відповіді.

Як інтерпретувати орієнтовні межі TTFB

web.dev вказує 800 мс або менше як приблизну хорошу ціль TTFB, а понад 1,800 мс як погану. Ці діапазони призначені для інтерпретації користувацького досвіду; тут вони лише орієнтир для одного синтетичного зразка.

≤ 800 msДобра орієнтовна межа

Повторне тестування та порівняння з відповідних регіонів користувачів перед тим, як зробити висновок, що URL постійно швидкий.

801–1,800 msПотрібен перегляд

Використовуйте розподіл фаз, щоб побачити, чи домінує налаштування з'єднання або запит до першого байта.

> 1,800 msПовільна направляюча смуга

Повторіть тест, порівняйте кешовану та некешовану поведінку, а потім досліджуйте домінуючу вимірювану фазу.

Що включає цей результат - і що не включає

Виміряно в цьому запуску

Один DNS-запит з сервера Novaverb
Одне нове TCP-з'єднання до перевіреного публічного IP
Одне TLS-рукопожаття для HTTPS-URL
Час від відправлення запиту до першого байта відповіді
HTTP статус, місце перенаправлення, протокол та видимий заголовок сервера

Не виміряно або не доведено

Час до першого байта (TTFB) від реальних користувачів або браузера з місць ваших відвідувачів
LCP, CLS, INP, FCP або будь-яка оцінка основних веб-показників
Виконання JavaScript, рендеринг, візуальне завершення або готовність до взаємодії
Час безвідмовної роботи, процентний розподіл або продуктивність під тривалим навантаженням
Чистий час виконання програми, відокремлений від затримки повернення мережі

Що зазвичай робить перший байт повільним?

DNS запит

Повільний авторитетний DNS, відстань резолвера або некешований запит можуть збільшити першу фазу.

TCP та географія

Довга мережна відстань і втрата пакетів додають раунди перед відправленням будь-якого HTTP-запиту.

TLS переговори

Свіже HTTPS-з'єднання вимагає криптографічних переговорів; повторне використання та сучасний TLS можуть зменшити повторні витрати.

Обробка походження

Запити до бази даних, виклики API, код програми та конкуренція за ресурси можуть затримувати генерацію відповіді.

CDN або пропуски кешу

Пропуск кешу може змусити край зв'язатися з оригіналом, тоді як влучення може повернутися набагато швидше.

Редиректи

Кожне перенаправлення додає ще один запит і, можливо, ще одне налаштування DNS, TCP та TLS перед фінальною сторінкою.

Стандарти та рекомендації з вимірювання

W3C · Navigation Timing Level 2Визначає responseStart як момент відразу після отримання першого байта відповіді. web.dev · Optimize TTFBПояснює приблизні 800 мс та 1,800 мс орієнтовні межі та чому TTFB не є основним веб-метриком. RFC 9110 · HTTP SemanticsHTTP статус та семантика відповіді, що лежать в основі вимірюваного запиту.

Питання про час відповіді сервера

Чи є це тим самим TTFB, який відчувають мої відвідувачі?

Ні. Це синтетичний запит з одного сервера в Німеччині. Відвідувач може використовувати інший регіон, мережевий шлях, протокол, стан кешу та повторно використане з'єднання.

Чи є TTFB основним веб-показником?

Ні. TTFB є основним діагностичним показником, але основні веб-показники - це LCP, INP та CLS.

Чи дорівнює запит до першого байта часу обробки на сервері?

Ні. Це включає обробку додатків або CDN, а також мережевий час для повернення перших байтів до проби.

Чи слідкує перевіряльник за перенаправленнями?

Ні. Він вимірює точно подану URL-адресу. Якщо ця відповідь перенаправляє, показується призначення, щоб ви могли протестувати його окремо.

Чому результат змінюється між запусками?

Стан кешу DNS та CDN, навантаження на сервер, маршрутизація мережі, затори та спільна інфраструктура можуть варіюватися. Порівняйте кілька зразків та польових даних.

Що мені слід виправити спочатку?

Почніть з найбільшої повторюваної фази. Високий час очікування запиту вказує на поведінку походження або кешу; високі фази з'єднання вказують на відстань, DNS або налаштування транспорту.

Це одне синтетичне вимірювання з боку сервера з одного місця (ЄС · Німеччина), а не реального браузера користувача TTFB або польових Core Web Vitals.

Отримайте правильну відповідь

Що подати - і чого уникати

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.

Використовуйте це так

yourdomain.comБудь-яка форма адреси підходить. http або https, з www або без, простий домен або повний шлях - ми нормалізуємо це для вас.

Run it a few timesЧитайте тренд, а не одне число - один запит варіюється з холодними кешами.

Уникати це

Reading it as 'my users' real speed'Це один синтетичний запит з Німеччини, а не досвід ваших відвідувачів - сприймайте це як базовий показник з боку сервера.

Expecting Core Web Vitals hereЦе вимірює час сервера (TTFB), а не рендеринг браузера - використовуйте інструмент Core Web Vitals для польових показників.

Публічна методологія

Саме так цей результат виробляється

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.

Ми нормалізуємо адресу, відкриваємо нове з'єднання HTTP/1.1 з одного сервера Novaverb та вимірюємо кожну фазу окремо.
Ми фіксуємо DNS запит, TCP з'єднання, TLS рукостискання, очікування запиту та загальний час до першого байта (TTFB).
Ми порівнюємо TTFB з публічними рекомендаціями web.dev (≈800 мс на 75-му процентилі) - орієнтація, а не вердикт про проходження/не проходження.
Ми повністю виключаємо рендеринг браузера; це вимірює сервер, а не Core Web Vitals.

Побудовано на публічних стандартах

Міжнародні стандарти, до яких застосовується ця перевірка

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

Розбиває запит на фази DNS, TCP, TLS та очікування (TTFB) моделі часу W3C.

Читати специфікацію

IETFRFC 9110

HTTP Semantics

Видає стандартний HTTP запит і читає статус відповіді.

Читати специфікацію

Googleweb.dev TTFB

Time to First Byte guidance

Орієнтує ваш виміряний TTFB відповідно до публічної смуги рекомендацій 800 мс.

Читати специфікацію

Ми перераховуємо стандарт лише там, де цей інструмент дійсно читає або вимірює його. Якщо сигнал знаходиться поза межами живої перевірки, результат говорить про це, а не натякає на охоплення.

Загальні запитання

Server Response Time Checker Часті запитання

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.

Більше безкоштовних перевірок