Цена одной секунды загрузки сайта в конверсии

MAATRIX

Кто-то в очередной раз прислал вам скриншот с надписью «каждая секунда загрузки стоит 7% конверсии» — и попросил объяснить, почему сайт «до сих пор не такой быстрый». Проблема в том, что этой цифры для вашего сайта, скорее всего, не существует: она взята из чужого кейса, в чужой нише, с чужой аудиторией. Ниже — честная методика, как измерить реальную зависимость конверсии от скорости именно у себя, и куда смотреть в первую очередь, если нужно ускориться.

Почему универсального процента не существует

Цифры вида «секунда задержки = минус X% конверсии» кочуют по презентациям с середины 2010-х, и почти всегда это выдержка из одного конкретного исследования одной конкретной компании — крупного e-commerce, чаще всего розницы с высокой долей мобильного трафика. Дальше цифру отрывают от контекста и начинают применять к любому сайту: блогу, SaaS, лендингу B2B, форуму.

Это не работает по нескольким причинам:

• Ниша задаёт чувствительность. У интернет-магазина с горячим спросом («хочу купить прямо сейчас») задержка в секунду реально может стоить части покупок — у пользователя открыто ещё пять вкладок с конкурентами. У контентного сайта или блога читатель, который уже начал читать статью, потерпит лишнюю секунду загрузки заметно охотнее. У B2B SaaS с длинным циклом принятия решения скорость лендинга вообще может быть не в топ-3 факторов конверсии.
• Устройство и канал трафика меняют картину. Мобильный трафик на нестабильной сети объективно чувствительнее к задержкам, чем десктоп в офисе на проводном интернете — но это тоже не значит, что мобильная конверсия просядет ровно на какой-то процент, просто порог терпения обычно ниже.
• Разные сайты меряют «загрузку» по-разному. Time to First Byte, First Contentful Paint, Largest Contentful Paint, полная загрузка всех ресурсов — это разные метрики, и исследование, откуда взят «универсальный процент», могло мерить не то, что меряете вы.
• Эффект не линейный. Разница между 1 и 2 секундами обычно ощутимее, чем между 4 и 5 — где-то после определённого порога терпения у аудитории падение конверсии выходит на плато, и дальнейшее ускорение перестаёт что-то менять.

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

Что вообще стоит измерять

Прежде чем ставить эксперимент, определитесь, какую метрику скорости вы связываете с конверсией. Разумный минимальный набор:

Для связи со скоростью и конверсией обычно достаточно TTFB (он честно отражает вклад инфраструктуры и сервера — то, на что вы напрямую влияете арендой и настройкой) и LCP (он ближе к субъективному ощущению пользователя «сайт загрузился»). Не пытайтесь сразу тащить в анализ все метрики — начните с одной-двух, иначе утонете в данных, не дойдя до вывода.

Методика 1: A/B-тест с искусственной задержкой

Самый чистый способ измерить причинно-следственную связь, а не просто корреляцию — специально замедлить часть трафика и сравнить конверсию.

Логика: вы делите пользователей на группы (например, через cookie или заголовок, который расставляет ваш балансировщик/CDN), одной группе отдаёте страницу как есть, второй — с искусственной задержкой перед отдачей ответа. Дальше сравниваете конверсию между группами за одинаковый период.

Практическая реализация задержки на уровне Nginx (для тестового окружения, не продакшена — на боевом трафике аккуратнее):

# в location добавляем задержку через ngx_http_delay_module
# или проще — через lua, если установлен openresty
location / {
    if ($cookie_ab_group = "slow") {
        # искусственная задержка ответа
        access_by_lua_block {
            ngx.sleep(1.0) -- 1 секунда искусственной задержки
        }
    }
    proxy_pass http://backend;
}

Если OpenResty разворачивать не хочется, задержку проще вносить на уровне приложения (например, sleep(1) в middleware, которое включается по флагу для части пользователей) или через искусственное ограничение полосы на отдельном тестовом сервере — например, через tc (traffic control) в Linux:

# ограничиваем исходящую полосу на интерфейсе для эмуляции медленного канала
tc qdisc add dev eth0 root tokenbucket rate 512kbit burst 32kbit latency 400ms

Важные условия, чтобы тест был честным:

• Группы должны быть сопоставимы по источнику трафика, устройству, географии — иначе вы измеряете разницу в аудитории, а не в скорости.
• Тест должен идти достаточно долго, чтобы набрать статистически значимое число конверсий в каждой группе (не судите по паре сотен визитов).
• Задержку стоит тестировать в нескольких значениях (например, +0.5с, +1с, +2с), чтобы увидеть не просто факт влияния, а форму зависимости — линейная она или выходит на плато.

Методика 2: естественные колебания скорости от нагрузки

Если ставить полноценный A/B-тест с искусственной задержкой не хочется (или страшно портить конверсию сознательно), можно использовать то, что уже происходит на сервере само — колебания времени ответа под нагрузкой.

У любого сервера TTFB не постоянен: он растёт в моменты пиковой нагрузки, при холодном кеше, при фоновых задачах (бэкапы, индексация, деплой). Если вы уже логируете время ответа сервера и конверсии по визитам, можно ретроспективно сопоставить эти два ряда данных.

Практический план:

1. Убедитесь, что access-логи веб-сервера пишут время ответа. В Nginx это делается через кастомный формат лога:

log_format timing '$remote_addr - $time_local "$request" '
                   '$status $body_bytes_sent $request_time '
                   '$upstream_response_time';

access_log /var/log/nginx/access_timing.log timing;

1. Выгрузите из аналитики (Яндекс.Метрика, Google Analytics или собственная система) конверсии по визитам с привязкой ко времени.
2. Сопоставьте визиты по времени и IP/сессии с записями в access-логе, чтобы у каждого визита появилась метка «медленный/быстрый» (например, по квартилям $request_time).
3. Сравните конверсию в квартиле самых медленных ответов и квартиле самых быстрых.

Минус этого метода — он не полностью изолирует причину и следствие: возможно, медленные ответы совпадают с часами пиковой нагрузки, когда меняется и состав аудитории (другой часовой пояс, другой канал трафика). Поэтому естественные колебания — это способ получить первую гипотезу и разведочные данные, а не финальное доказательство. Если корреляция найдена — имеет смысл подтвердить её управляемым A/B-тестом из первой методики.

Какие факторы инфраструктуры реально влияют на скорость

Когда зависимость измерена и решено, что скорость стоит улучшать, разумно проверять факторы в порядке убывания типичного эффекта:

Расстояние сервера от аудитории. Это фундаментальный физический фактор — задержка растёт с расстоянием почти линейно из-за скорости распространения сигнала и числа промежуточных узлов. Если основная аудитория в России, а сервер в США, добавочная задержка на каждый round-trip будет заметна ещё до того, как сервер начнёт формировать ответ — это ложится в TTFB независимо от мощности железа. Прежде чем оптимизировать код, стоит проверить: где физически сидит основная аудитория и где стоит сервер. Если требуется сравнить конкретные значения задержки между регионами — есть отдельный разбор с ориентировочными цифрами в таблице задержек между локациями, а если аудитория делится между несколькими близкими локациями и неочевидно, какую выбрать — см. как выбрать между несколькими близкими локациями.

Мощность и конфигурация сервера. Нехватка CPU или диска на пиковой нагрузке — частая причина роста TTFB именно в момент, когда трафика больше всего (то есть именно тогда, когда конверсия наиболее ценна). Стоит проверить не только «в среднем», а именно на пиках: если у вас VPS с shared CPU и в моменты всплеска трафика он упирается в лимит, время ответа будет расти нелинейно.

Диск и I/O. Если приложение активно обращается к базе данных или файловой системе на каждый запрос, тип диска и его загрузка напрямую влияют на TTFB. NVMe вместо сетевого или медленного SSD-хранилища — одна из самых заметных по эффекту, но недорогих правок.

Оптимизация самого приложения. Тяжёлые SQL-запросы без индексов, N+1 запросы к базе, отсутствие кеширования на уровне приложения — это часто даёт больший вклад в задержку, чем всё перечисленное выше вместе взятое. Если сервер быстрый, а сайт всё равно медленный — проблема почти всегда здесь, а не в инфраструктуре. Разбор именно такой ситуации, когда сеть в порядке, а сайт тормозит — в статье хороший пинг, а сайт медленный: задержка и полоса.

Кеширование на уровне веб-сервера и CDN. Если контент можно кешировать (статика, редко меняющиеся страницы), кеш на Nginx или отдельный кеширующий слой снимает большую часть нагрузки с приложения и базы. Практическая настройка разобрана в статье про ускорение сайта через Varnish Cache, а если аудитория географически распределена — стоит посмотреть настройку CDN для сайта, чтобы статика отдавалась ближе к пользователю независимо от того, где стоит основной сервер.

Порядок проверки на практике обычно такой: сначала локация (это решается один раз выбором сервера и почти бесплатно), потом ресурсы сервера под пиковой нагрузкой, потом диск, и только затем — глубокая оптимизация кода и запросов, которая требует больше времени разработчика.

Как выделить вклад именно сервера, а не кода

Частая ошибка — списывать всю задержку на «медленный хостинг», хотя сервер здесь ни при чём. Чтобы разделить вклад инфраструктуры и вклад приложения, полезно смотреть на разбивку TTFB отдельно от полного времени рендеринга.

Быстрая проверка через curl с замером фаз запроса:

curl -o /dev/null -s -w "\
DNS: %{time_namelookup}s\n\
Connect: %{time_connect}s\n\
TLS: %{time_appconnect}s\n\
TTFB: %{time_starttransfer}s\n\
Total: %{time_total}s\n" https://ваш-сайт.ru/

Если time_connect и time_appconnect большие — проблема в сети и физическом расстоянии до сервера (либо в TLS-настройках). Если разница между TTFB и time_appconnect большая — сервер долго формирует ответ, и это уже вопрос к мощности сервера, базе данных или коду приложения, а не к сети.

Полезно гонять этот замер из разных точек — с сервера, физически близкого к вашей аудитории, а не только с рабочего ноутбука разработчика, который может сидеть в соседнем дата-центре с сервером и не видеть реальной задержки конечного пользователя. Методика замеров реального пинга до сервера из разных точек подробно разобрана в статье как измерить реальный пинг до сервера — методика.

Мониторинг скорости на постоянной основе

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

Простейший вариант — синтетический мониторинг, который дергает ваш сайт снаружи с заданным интервалом и хранит историю ответов, чтобы видеть тренд, а не только текущее значение. Подробная настройка такого мониторинга (включая какие пороги ставить для алертов) есть в статье мониторинг доступности сайта: инструменты.

Если мониторинг уже показал рост TTFB со временем — прежде чем сразу апгрейдить сервер, стоит проверить, не в базе ли данных дело (разрослась ли она, появились ли медленные запросы) и не единичный ли это скачок (например, от бэкапа, который запускается по расписанию и на несколько минут нагружает диск).

Практический вывод: где ваша точка «достаточно быстро»

Главная ошибка в погоне за скоростью — воспринимать её как самоцель, а не как инструмент, который влияет на деньги через конверсию. У ускорения сайта, как у большинства технических улучшений, есть убывающая отдача: разница между «страница грузится за 3 секунды» и «за 1.5 секунды» для реальных пользователей обычно куда заметнее, чем разница между «за 1.5 секунды» и «за 0.8 секунды» — хотя вторая экономия технически может стоить дороже первой.

Практический план:

1. Измерьте свою реальную зависимость одним из двух способов выше — искусственной задержкой или сопоставлением с естественными колебаниями TTFB.
2. Найдите диапазон скорости, за пределами которого конверсия перестаёт заметно меняться — это и есть ваша реальная цель, а не абстрактный рекорд из чужого бенчмарка.
3. Оцените, сколько стоит текущий разрыв между реальной скоростью и этой целью — и сколько будет стоить его закрыть (более мощный тариф, ближе локация, кеш, оптимизация запросов). Сравните с ожидаемым эффектом на конверсию, а не тратьте бюджет на ускорение сверх точки, где эффект уже не измерим.
4. Перепроверяйте раз в квартал или после заметного роста трафика — точка «достаточно быстро» смещается вместе с ростом базы данных и сложности приложения.

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