Скорость сайта и конверсия: TTFB, отрисовка первого экрана и задержка клика
Что измерять, какие пороги считать проблемой и почему Lighthouse не видит медленный чекаут
Алексей Смирнов
Lead Product Architect, UXCheck
Исследование 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.
Задержка клика: невидимая метрика чекаута
Самая недооценённая метрика: время от нажатия «В корзину» до реакции интерфейса. Её не меряют, потому что она требует прохода по сценарию, а не загрузки страницы. Между тем именно она отделяет «сайт работает» от «сайт продаёт»: три секунды между кликом и появлением корзины — это три секунды сомнений, нажал ли человек вообще.
Кнопка, которая после двух нажатий не открыла ни страницу, ни окно, это уже не медленный, а мёртвый контрол, и её нужно считать отдельно от производительности.
Время клика считается до смены 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-регрессий в продуктовых командах и методику еженедельного контроля.
Мёртвые кнопки и клики в никуда: как найти контролы, которые ничего не делают
Кнопка выглядит живой, а по клику ничего не происходит: нет обработчика, ссылка на #, модалка не смонтирована. Разбираем таксономию мёртвых контролов, правило двух кликов, фиксацию исхода клика и формат баг-репорта, который можно вставить в Cursor.
Кнопка на $300 000 000: легендарный кейс Джареда Спула и реальный ROI юзабилити
История хрестоматийного кейса Джареда Спула. Разбираем экономику юзабилити: почему каждый вложенный в UX рубль приносит в разы больше, чем закупка дополнительного рекламного трафика.