Сторінки повільно надсилають перший байт
У звітіSlow server response (TTFB) for HTML documents
document_ttfb_slow · Потребує перегляду
Це з’являється, коли щонайменше десять унікальних сторінок одного джерела мають вимірювання прямих відповідей HTML 200, що відповідають умовам, їхній 75-й процентиль за методом найближчого рангу перевищує 800 мілісекунд від початку передавання до першого байта відповіді, а пізніша детермінована вибірка тих самих сторінок також перевищує 800 мілісекунд. web.dev описує 0,8 секунди або менше як добрий результат, а понад 1,8 секунди — як поганий. Перегляньте обробку на сервері й кешування за зафіксованими вибірками; це вимірювання аудиту, а не польові дані браузера.
Серйозність: Середня.
Чому це важливо
web.dev описує час до першого байта як показник, що передує всім іншим суттєвим показникам завантаження, і зазначає, що більшість сайтів має прагнути до 0,8 секунди або менше. Там також зазначено, що це не показник Core Web Vitals, тож досягати порогу не обов’язково, коли інші показники добрі.
Що зробити
- Перегляньте знахідку: у ній показано 75-й процентиль обох вимірювань і перелічено виміряні сторінки з їхнім часом.
- Перевірте, що робить сервер, перш ніж відповісти: запити до бази даних, звернення до інших сервісів і рендеринг сторінки. Найбільше зазвичай допомагає кешування цілих сторінок на сервері чи в CDN.
- Порівняйте повільні й швидкі сторінки в списку. Якщо повільний лише один вид сторінок, причина ймовірно в тому, як формується цей вид сторінок.
Коли залишити як є: якщо ваші польові дані, наприклад у Search Console чи інструменті моніторингу реальних користувачів, показують добрий час завантаження для відвідувачів, це можна залишити. Аудит вимірює з одного місця.
Що ми читаємо
Для HTML-сторінки, яку аудит запитує безпосередньо й яка відповідає кодом 200, вимірюється час від зафіксованого початку запиту до першого байта відповіді. Він включає встановлення з’єднання та TLS, коли це потрібно, і не включає пошук DNS, власне очікування аудиту між запитами та попереднє переспрямування. Відсутні вимірювання, відповіді з переспрямуванням та інші непридатні вимірювання не доводять, що перевірку пройдено або проблему виправлено.
Якщо для одного origin (схеми, хоста й порту) є щонайменше десять придатних сторінок, початкова група є вибіркою. Якщо її 75-й процентиль, обчислений методом найближчого рангу, перевищує 800 мілісекунд, визначений за сталим правилом набір щонайменше з трьох тих самих сторінок вимірюється знову пізніше. Щоб повідомити про цю групу, обидва вимірювання мають перевищувати 800 мілісекунд.
Якщо придатних сторінок від однієї до дев’яти, аудит спочатку має встановити, що виявлення адрес і весь обсяг перевірки сторінок завершено без обмежувальної перешкоди. Таку групу оцінюють як повну малу сукупність, і повільний початковий результат потребує подальшого вимірювання кожної її сторінки. Мала вибірка з обмеженим обсягом, перерваною перевіркою чи неповним виявленням адрес так не оцінюється.
Групи, збережені з попередньої знахідки, оцінюються окремо за їхніми власними сторінками та вимогами до повторних вимірювань. Групи, що перетинаються, не об’єднують у більшу й швидшу сукупність. Понад 1800 мілісекунд результат позначається як поганий.
Приклад і докази
Ілюстративний приклад — один аудит, а не реальний результат.
Аудит вимірює дванадцять сторінок bakery.example. Якщо впорядкувати їх за часом, дев’ята сторінка — це 75-й процентиль:
https://bakery.example/ 410 ms
https://bakery.example/recipes/ 980 ms
https://bakery.example/recipes/sourdough/ 1240 ms <- 75th percentile of 12 pages
...
second measurement of 3 pages: 75th percentile 1190 msОбидва вимірювання перевищують 800 мілісекунд, тому про хост повідомляється. Якби перше вимірювання становило 800 мілісекунд або менше, нічого не повідомлялося б і друге вимірювання не виконувалося б.
Підтвердити й перевірити знову
Перевірте самі: відкрийте одну зі сторінок у списку з інструментами розробника браузера на вкладці Network, прочитайте час очікування запиту сторінки й повторіть це кілька разів.
Повторна перевірка: Повний аудит — запустіть новий аудит сайту. Знахідка закривається, коли кожну раніше виміряну сторінку виміряно знову і 75-й процентиль цих самих сторінок становить 800 мілісекунд або менше. Сторінка, яка тепер переспрямовує, відсутня, перевищила час очікування чи не була прочитана, залишає знахідку непідтвердженою, а нові швидкі сторінки її не закривають.
Обмеження та джерела
Це вимірювання з одного місця проведення аудиту, а не від ваших відвідувачів. Вони не включають пошук DNS і попередні переспрямування, тому можуть відрізнятися від вимірювань у браузері чи польових даних.
Група з менш ніж десяти сторінок перевіряється лише тоді, коли аудит встановлює повну малу сукупність у межах виявленого ним обсягу. Це не доводить, що можна було виявити кожну адресу сайту. Ліміти сканування, неповне виявлення адрес, відсутні вимірювання або недостатнє покриття повторними вимірюваннями лишають відповідне порівняння непідтвердженим.
Бюджет подальших запитів спільний для поточних і збережених груп. Група, для якої не завершено потрібне повторне вимірювання, лишається непідтвердженою. Обмеження сховища або розміру об’єкта перевірки також лишає перевірку незавершеною; воно не доводить, що попередню знахідку виправлено.
Перевірка не вимірює Largest Contentful Paint чи інші показники завантаження й нічого не стверджує про позицію в пошуку. Сторінки групуються за origin (схемою, хостом і портом), а не за типом сторінки.
Упевненість: Середня, бо час вимірює аудит на власних запитах і підтверджує другим вимірюванням, але з одного місця й на обмеженій кількості сторінок.
Джерела
- web.dev, Час до першого байта (TTFB) — зазначає, що добрі значення TTFB — 0,8 секунди або менше, а погані — понад 1,8 секунди, що TTFB не є показником Core Web Vitals і що він складається з часу переспрямувань, пошуку DNS, з’єднання й узгодження TLS, а також запиту до першого байта відповіді. Перевірено 14 жовтня 2026.
Редакційна перевірка: 19 жовтня 2026