Любой финансовый директор понимает, что такое скидка в 5%. Она видна в счёте, она отражается в валовой марже, её кто-то должен утвердить.
Скидку, которую раздаёт ваш сайт, не утверждает никто. Её нигде не видно. Это разница между выручкой, которая у вас есть, и выручкой, которая была бы, если бы страница откликалась, когда на неё нажимают.
Это не метафора. Это арифметика, и кейсы здесь на редкость чистые, потому что компании ставили настоящие эксперименты.
- Vodafone провёл A/B-тест двух версий лендинга. Версия с LCP лучше на 31% принесла на 8% больше продаж, а заодно на 15% лучше конверсию визитов в заявки и на 11% лучше — визитов в корзину. Vodafone опубликовал это на web.dev.
- redBus переделал то, как поля ввода работают с состоянием, сократил INP на 72% и зафиксировал рост общих продаж на 7% — их собственный разбор, тоже на web.dev.
Теперь приложите эти цифры к своему отчёту о прибылях и убытках. Если бы подрядчик предложил вам +8% к выручке за две недели разработки, вы согласились бы без совещания. Если бы кто-то предложил снизить все цены на 8%, вы потребовали бы экономического обоснования.
Медленный сайт — это второе, замаскированное под первое. Вы уже платите эту скидку. Решить вам осталось только одно: продолжать ли платить.
Посчитайте в деньгах
Консультант для этого не нужен. Нужны четыре цифры, которые у вас уже есть.
- Число сессий в месяц
- Текущая конверсия
- Средний чек или средняя сумма сделки
- Текущие LCP и INP на 75-м перцентиле по данным реальных пользователей
Дальше — оценка:
Годовой налог на задержку ≈ сессии × 12 × текущая конверсия × средний чек × ожидаемый прирост конверсии
Берите прирост с запасом. Опубликованные результаты для заметного улучшения скорости укладываются в 5–15% относительного прироста; берите 6%, если своих данных нет.
Пример. У бизнеса 40 000 сессий в месяц, конверсия 1,8% и средний чек $120 — это $1 036 800 в год. Относительный прирост конверсии на 6% — это $62 208 в год. Если работы на три недели, окупаемость измеряется неделями, а каждый следующий год достаётся бесплатно.
Посчитайте по своим цифрам, прежде чем читать дальше. Смысл статьи в том, что результат обычно меняет ваш следующий шаг.
Метрика, которая сегодня реально стоит вам денег
Большинство разговоров о скорости по-прежнему про время загрузки. Это проблема прошлого десятилетия, и для большинства сайтов её в целом решают нормальный хостинг и CDN.
Дорогая метрика 2026 года — INP, Interaction to Next Paint. Она измеряет задержку между действием пользователя и тем, как экран на него отвечает, — на протяжении всей сессии, а не только в первый момент. Каждое нажатие на фильтр, каждое открытие выбора варианта товара, каждый символ, набранный в форме.
Для бизнеса это важно по конкретной причине: загрузка происходит до того, как посетитель во что-то вложился, а взаимодействие — после. Медленная загрузка теряет зевак. Медленный отклик теряет покупателей — людей, которые уже выбрали, уже ввели данные, уже решили. Их привлечь дороже всего, а потерять легче всего.
И именно эта метрика чаще всего плохая на сайте с хорошими оценками. Страница может загружаться за 1,1 секунды и при этом отвечать на нажатие через 400 миллисекунд, потому что JavaScript, который делает её интерактивной, блокирует основной поток. Обычно виноваты сторонние скрипты: чат-виджеты, записи тепловых карт, менеджеры тегов, которые загружают другие менеджеры тегов, четыре системы аналитики — потому что ни одну никто так и не удалил.
Почему большинство работ по скорости оптимизирует не то
Вот неудобная часть, и она касается многого из того, что продают под видом оптимизации скорости.
Оценка PageSpeed — это косвенный показатель, а косвенные показатели подкручивают. Вполне можно поднять лабораторную оценку так, что ни один реальный пользователь не почувствует разницы: отложить то, что измеряет тест, лениво грузить всё, что ниже первого экрана, перенести тяжёлую работу на момент после замера. Оценка становится зелёной. Нажатие всё так же тормозит.
Честность работы держится на двух правилах:
Измеряйте в поле, а не в лаборатории. Лабораторные инструменты работают на эмулированном устройстве с хорошим соединением. Ваш реальный пользователь на 75-м перцентиле сидит на Android среднего класса в перегруженной сети. Только данные реальных пользователей показывают, что происходит у них, а разница между этими двумя мирами обычно трёхкратная.
Оптимизируйте взаимодействие, которое стоит перед деньгами, а не главную страницу. На главной никто не покупает. Важен путь «поиск → фильтр → карточка → корзина → оформление заказа» или «список → форма → отправка». Исправить INP на шаге прямо перед оплатой ценнее, чем исправить LCP на странице, которую большинство посетителей вообще не видит.
Что действительно двигает цифру
Четыре категории — в порядке убывания отдачи для большинства сайтов.
1. Уберите сторонний JavaScript. Почти всегда это самый большой выигрыш, и это решение бизнеса, а не техническое, потому что у каждого тега есть заинтересованное лицо. Разберитесь, зачем нужен каждый, кто читает его данные и заметит ли этот человек, если тег исчезнет. Обычно несколько человек не заметят.
2. Отдавайте меньше собственного JavaScript. Рендерите на сервере всё, что можно отрендерить на сервере. Страница, которая приходит готовым HTML, бесплатно быстрая даже на плохом телефоне. Поэтому всё, что мы делаем, по умолчанию использует серверный рендеринг — это не отдельный этап оптимизации.
3. Разберитесь с тяжёлыми ресурсами. Современные форматы изображений, правильные размеры и шрифты, которые не блокируют отрисовку. Конкретный пример из нашей работы: в Finkonkurs мы встроили иконки Material Symbols как SVG вместо того, чтобы загружать иконочный веб-шрифт на 3,8 МБ. Одно решение, принятое один раз, ценнее месяца микронастроек.
4. Перестаньте делать работу, о которой пользователь не просил. Тоже из Finkonkurs: мы отключили предзагрузку ссылок. Страница монеты ссылается на десятки бирж, данные каждой страницы расходятся примерно на 13 запросов к бэкенду, и предзагрузки по попаданию в область видимости хватало, чтобы сработал лимит запросов с одного IP в самом API. «Оптимизация» делала сайт медленнее и менее надёжным. Теперь закэшированные данные страниц получают явный срок жизни в браузере, так что повторные переходы перестали скачивать их заново, а серверный рендеринг ходит в API по внутренней сети, а не петлёй наружу через CDN.
Именно этот пример стоит усвоить. Работа над скоростью — это не чек-лист лучших практик. Наполовину она состоит из того, чтобы убрать хитрости, которые кто-то добавил ради скорости и которые под реальным трафиком оказались ошибкой.
Версия на тридцать минут, которую можно сделать самому
Чтобы понять, стоит ли это отдельного проекта, разработчик не нужен.
1. Откройте свой сайт на своём телефоне, через мобильный интернет, там, где две палочки сигнала. Не офисный Wi-Fi. Не тот компьютер, на котором сайт проверяли. Один этот шаг скажет больше любого инструмента, потому что именно в таких условиях на самом деле находится большая часть вашего трафика.
2. Засеките путь к деньгам, а не главную. Включите секундомер, пройдите от страницы категории к товару, добавьте в корзину, дойдите до экрана оплаты. Всё, что заставило вас ждать, — кандидат на исправление, и у вас уже есть рейтинг по тому, где было больнее всего.
3. Быстро понажимайте на элементы и следите за задержкой. Откройте фильтр. Смените вариант товара. Наберите что-нибудь в поле формы. Если экран не отвечает мгновенно — это INP, и так происходит у каждого клиента с телефоном среднего класса.
4. Посчитайте сторонние скрипты. Попросите того, кто ведёт у вас маркетинг, дать список скриптов на сайте: аналитика, менеджер тегов, чат-виджет, тепловые карты, пиксели, виджет отзывов, баннер согласия на cookie. Потом спросите, кто читает данные каждого. Те, у которых нет конкретного читателя, — это бесплатная скорость.
5. Посмотрите на самое большое изображение на самой посещаемой странице. Если оно больше места, в котором показывается, вы платите за доставку пикселей, которых никто не видит. Даже в 2026 году это одна из самых частых находок.
Запишите, что нашли. Если ответ — «почти ничего», вы сэкономили себе проект на основании фактов, а в этом и весь смысл: проверить до того, как что-то покупать.
Куда на самом деле уходит типичный бюджет на скорость
Для обычного маркетингового сайта или магазина работа делится примерно так — и большинство владельцев удивляет, как мала в ней доля кода:
| Работа | Доля усилий | Кто решает |
|---|---|---|
| Удаление или отложенная загрузка сторонних скриптов | ~35% | Бизнес, а не разработка |
| Работа с изображениями и шрифтами | ~25% | Дизайн и разработка |
| Стратегия рендеринга (сервер или клиент) | ~20% | Разработка |
| Исправление двух-трёх медленных взаимодействий | ~15% | Разработка |
| Кэширование и доставка | ~5% | Разработка |
Верхняя строка — это переговоры. У каждого тега есть человек, который его попросил, и удалить тег — значит обсудить, пользуется ли этот человек ещё его данными. Поэтому проекты по скорости внутри компаний буксуют, а внешняя команда часто двигается быстрее — не из-за технического мастерства, а потому что задаст вопрос, который никто внутри задавать не хочет.
Архитектурные решения, которые делают скорость бесплатной
Самый дешёвый быстрый сайт — тот, который никогда не был медленным.
В Bronjoy API работает на Laravel Octane со Swoole, поиск — на Meilisearch, а горячие пути — на Redis. Не потому, что это модно, а потому, что у маркетплейса, построенного вокруг карты и 23 727 заведений, строка поиска обязана отвечать мгновенно, иначе продукт не работает. В Knigopoisk картинки Open Graph для репостов рендерятся на сервере через Satori и resvg, без headless-браузера вообще: целого класса медленной и хрупкой инфраструктуры в этой системе просто нет.
Это архитектурные решения, принятые до того, как нарисовали хоть один интерфейс. Поэтому же мы закладываем скорость в стоимость разработки, а не продаём её потом отдельным проектом: каждый сайт, который мы сдаём, выходит с оценкой PageSpeed 90+ и подключённой аналитикой ещё до запуска — от $99 и за 3–5 дней для лендинга.
Если сайт у вас уже есть и вы хотите знать, во что он вам обходится, для этого есть аудит скорости — от $90, и выводы вы получаете независимо от того, наймёте ли нас что-то исправлять.
Расскажите, что вам нужно. В ответ вы получите фиксированную цену и дату сдачи — бесплатно и без обязательств продолжать.
Частые вопросы
Скорость сайта всё ещё влияет на позиции в Google?
Да, но это наименее интересная причина о ней думать. Core Web Vitals — скромный фактор ранжирования и крупный фактор конверсии. Оптимизируйте ради выручки, и эффект для позиций придёт побочно; сделаете наоборот — будете гоняться за оценкой вместо денег.
Какой INP считать хорошим?
Порог «хорошо» — меньше 200 миллисекунд на 75-м перцентиле. Но важнее разрыв между медианой и 75-м перцентилем: большой разрыв значит, что у части ваших пользователей всё гораздо хуже, чем у вашей команды, — обычно у тех, у кого телефоны подешевле.
Наш сайт сделан на конструкторе. Его можно ускорить?
Отчасти, и у этого есть потолок. Конструкторы отдают универсальную среду выполнения плюс всё, что добавляет каждый установленный плагин, а состав этого набора вы не контролируете. До приемлемого уровня обычно дотянуть можно; до отличного — как правило, только уйдя с конструктора. Более широкий расклад мы разбираем в статье «Против вашего конструктора сайтов».
Сколько времени занимает работа над скоростью?
Для типичного маркетингового сайта от одной до трёх недель покрывают крупные выигрыши: аудит сторонних скриптов, работу с ресурсами, стратегию рендеринга и исправление двух-трёх важных взаимодействий. Более глубокая работа над приложением целиком зависит от архитектуры под ним.
Стоит ли это делать, если у сайта небольшой трафик?
Проведите расчёт, описанный выше. При 2 000 сессиях в месяц годовая сумма может оказаться маленькой — и тогда правильно будет заняться чем-то другим. Расчёт для того и нужен, чтобы отказываться на основании фактов, а не интуиции.



