UXUXCheck
Производительность·8 мин·2026-09-17

Скорость сайта и конверсия: TTFB, отрисовка первого экрана и задержка клика

Что измерять, какие пороги считать проблемой и почему Lighthouse не видит медленный чекаут

А

Алексей Смирнов

Lead Product Architect, UXCheck

Источники: Deloitte Digital × Google, Google web.dev, Akamai
Коротко о главномПользователь не знает слова TTFB, но чувствует три порога: 0,1 с (мгновенно), 1 с (заметная пауза), 10 с (потеря внимания). Метрики загрузки главной только начало. Настоящие потери происходят на клике «Оформить», который думает 4 секунды, и на форме, где каждое поле дёргает сервер.

Исследование Deloitte и Google на 37 брендах показало: ускорение мобильного сайта на 0,1 секунды поднимает конверсию ритейла на 8,4%, а средний чек почти на 10%. Akamai фиксирует зеркальную картину: каждые 100 мс задержки отнимают до 7% конверсии. Эти цифры давно стали общим местом, но большинство команд продолжает мерить скорость одним способом: баллом Lighthouse по главной.

Проблема в том, что Lighthouse измеряет загрузку одной страницы в лабораторных условиях. А деньги теряются на пути: клик по кнопке, переход в корзину, подгрузка шага доставки, ответ сервера после «Отправить». Поэтому в методологии UX-аудита производительность идёт отдельным разделом, который меряется на каждом шаге сценария.

Три порога восприятия по NN/g

Между секундой и десятью лежит зона, где сайт формально «работает», а конверсия тихо утекает. Кнопка «Оформить заказ», отвечающая через 3 секунды без спиннера, генерирует двойные нажатия и дубли заказов: тот самый дефект, который описан в разборе ошибок вайбкодинга.

  • 0,1 секунды.Порог мгновенности. Реакция на клик быстрее 100 мс воспринимается как прямое управление. Если медленнее, человек начинает сомневаться, нажал ли он.
  • 1 секунда.Порог непрерывности мысли. Пауза заметна, но пользователь остаётся в задаче. Всё, что дольше секунды, требует индикатора загрузки.
  • 10 секунд.Порог внимания. Дальше человек переключается на другую вкладку и с большой вероятностью не возвращается.

Метрики, которые связаны с деньгами

Последние две строки не из Core Web Vitals. Их не покажет ни один лабораторный отчёт, потому что для измерения нужно реально кликнуть и реально печатать. Именно они чаще всего объясняют разрыв между «зелёным» Lighthouse и падающей конверсией.

МетрикаЧто измеряетХорошоПроблема
TTFBВремя до первого байта ответа сервера≤ 800 мс> 1,8 с
LCPОтрисовка самого крупного элемента первого экрана≤ 2,5 с> 4 с
INPЗадержка реакции на действие пользователя≤ 200 мс> 500 мс
CLSСдвиг макета при загрузке≤ 0,1> 0,25
Клик к целиМежду нажатием и сменой URL или появлением окна≤ 1 с> 3 с
Заполнение поляРеакция формы на ввод (маска, подсказка, валидация)≤ 100 мс> 500 мс

TTFB: где сервер теряет время

Высокий TTFB почти всегда означает работу на бэкенде до отдачи HTML: тяжёлые запросы к базе, отсутствие кеша, синхронные обращения к CRM или 1С прямо в обработчике страницы. На витринах с Bitrix и WordPress типичная картина: 1,5–3 секунды до первого байта на карточке товара из-за пересчёта остатков при каждом запросе.

Отдельный маркер: повторная загрузка. Если страница открылась не с первой попытки (таймаут, редирект по кругу, 5xx с последующим успехом), это фиксируется отдельно: пользователь такое не прощает, а в средних показателях оно тонет.

LCP и первый экран: не только картинки

Самый крупный элемент первого экрана на коммерческих сайтах обычно баннер или главное изображение. Три типовые причины медленного LCP: изображение в оригинале на 4 МБ без сжатия, ленивое подгружание того, что должно быть видно сразу, и веб-шрифты, блокирующие отрисовку текста оффера. Все три исправляются за день и заметны в конверсии сразу.

На мобильных к этому добавляется сдвиг макета: баннер появляется позже текста, кнопка CTA уезжает вниз, и палец попадает не туда. О том, куда именно, рассказывает статья о тач-таргетах и thumb zone.

Задержка клика: невидимая метрика чекаута

Самая недооценённая метрика: время от нажатия «В корзину» до реакции интерфейса. Её не меряют, потому что она требует прохода по сценарию, а не загрузки страницы. Между тем именно она отделяет «сайт работает» от «сайт продаёт»: три секунды между кликом и появлением корзины — это три секунды сомнений, нажал ли человек вообще.

Кнопка, которая после двух нажатий не открыла ни страницу, ни окно, это уже не медленный, а мёртвый контрол, и её нужно считать отдельно от производительности.

Как это измеряет UXCheck

Время клика считается до смены URL или появления окна, без учёта пауз самого аудита. В отчёте раздел «Производительность» стоит рядом с «Интерфейс» и «Тексты»: время открытия страниц, TTFB и отрисовка, задержки кликов и заполнения; повторная загрузка помечена отдельно. Заметные задержки главной и медленный клик к цели попадают в находки и могут оказаться в «Что исправить в первую очередь».

Почему скорость нужно мерить каждую неделю

Производительность деградирует незаметнее любых других характеристик сайта. Маркетинг добавил третий пиксель аналитики, разработчик подключил чат-виджет, контент загрузил баннер без сжатия. По отдельности всё в пределах нормы, вместе LCP вырос с 2 до 4 секунд за квартал. Никто не заметил, потому что никто не мерил регулярно. Как устроен еженедельный контроль таких регрессий, разобрано в статье о недельной дельте.

Экономика проста и хорошо описана в кейсе о кнопке на 300 миллионов: при трафике в 50 000 визитов и конверсии 2% каждый процент относительного роста конверсии даёт десять заявок в месяц. Секунда на первом экране стоит дороже любого баннера.

Частые вопросы

Какая скорость загрузки сайта считается нормальной?
По Core Web Vitals: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Для TTFB ориентир до 800 мс. Для клика к целевому действию до 1 секунды, иначе нужен индикатор загрузки.
Почему Lighthouse показывает 90+, а сайт кажется медленным?
Lighthouse измеряет загрузку одной страницы в лабораторных условиях. Он не видит задержку клика по кнопке, ответ сервера после отправки формы и подгрузку шагов чекаута. Эти метрики нужно снимать на реальном проходе по сценарию.
Что такое TTFB и почему он высокий?
Time to First Byte: время между запросом и первым байтом ответа сервера. Высокий TTFB означает тяжёлую работу бэкенда до отдачи HTML: запросы к базе без кеша, обращения к CRM или 1С, отсутствие CDN.

Источники, исследования и стандарты

  • [1]
    Deloitte Digital × Google: Milliseconds Make Millions: влияние 0,1 с на конверсию ритейла и туризма
  • [2]
    Google web.dev: Core Web Vitals: пороги LCP, INP, CLS и методика полевых измерений
  • [3]
    Akamai: State of Online Retail Performance: задержка 100 мс и −7% конверсии
  • [4]
    Nielsen Norman Group (NN/g): Response Times: The 3 Important Limits (0,1 с / 1 с / 10 с)
Экспресс-проверка интерфейса

Хотите узнать, есть ли эти ошибки на вашем сайте?

UXCheck проходит сайт в живом браузере глазами вашей аудитории, находит скрытые баги верстки, трение в формах и чекауте и формирует список селекторов для исправления.

Запустить бесплатный аудит

1 бесплатный аудит на аккаунт

Читайте также по теме

Все статьи
Продукт & Мониторинг

Регрессионный UX: почему ваш интерфейс незаметно деградирует от релиза к релизу

Программисты тестируют код unit-тестами, но кто тестирует сценарии пользователя? Разбираем проблему тихих UX-регрессий в продуктовых командах и методику еженедельного контроля.

7 минЧитать статью
Вайбкодинг & AI

Мёртвые кнопки и клики в никуда: как найти контролы, которые ничего не делают

Кнопка выглядит живой, а по клику ничего не происходит: нет обработчика, ссылка на #, модалка не смонтирована. Разбираем таксономию мёртвых контролов, правило двух кликов, фиксацию исхода клика и формат баг-репорта, который можно вставить в Cursor.

7 минЧитать статью
Бизнес & ROI

Кнопка на $300 000 000: легендарный кейс Джареда Спула и реальный ROI юзабилити

История хрестоматийного кейса Джареда Спула. Разбираем экономику юзабилити: почему каждый вложенный в UX рубль приносит в разы больше, чем закупка дополнительного рекламного трафика.

6 минЧитать статью