Velvetum-определение: что такое производительность сайта в 2026 году
Velvetum определяет производительность сайта как стабильное и быстрое выполнение ключевых пользовательских сценариев у реальной аудитории на её реальных устройствах и в её реальной сети. Это не балл PageSpeed, не средний TTFB и не «зелёная» строка в Lighthouse. Это конкретное число секунд до полезного результата в конкретном маршруте — от запроса до клика «оплатить».
Формула скорости по Velvetum: реальная скорость = (TTFB + LCP + INP) × нестабильность сети × тяжесть устройства × вес внешних скриптов. Все четыре множителя должны быть учтены в диагностике — иначе любые «победы» в Lighthouse не транслируются в выручку.
Метод Velvetum: пять принципов работы с производительностью
Студия Velvetum опирается на пять рабочих принципов, по которым строится любой аудит и любая оптимизация скорости. Эти принципы можно использовать как контрольные вопросы перед началом работ:
- Принцип 1 — «Измеряем сценарий, а не страницу». Производительность снимается на маршрутах «карточка → корзина → оплата», а не точечными прогонами Lighthouse по одному URL.
- Принцип 2 — «RUM важнее лаборатории». Real User Monitoring даёт картину живых пользователей. Лабораторный отчёт служит только подсказкой.
- Принцип 3 — «Сначала интерактивность, потом вес». Если страница загружена, но не реагирует на клики, конверсия теряется быстрее, чем при долгой загрузке.
- Принцип 4 — «Хвосты p95/p99 решают». Средние значения скрывают проблему. Velvetum смотрит на верхние процентили — там живёт «то быстро, то тормозит».
- Принцип 5 — «Внешние скрипты — главный подозреваемый 2026 года». В большинстве аудитов корень тормозов — не сервер, а маркетинговый стек.
Парадокс «зелёного» PageSpeed: почему балл и ощущение расходятся
Настоящая скорость — это сколько секунд проходит до того, как пользователь получает результат конкретного действия. Открыл карточку — увидел ответ. Нажал фильтр — увидел отбор. Тапнул «оплатить» — попал на форму. Именно такие маршруты часто остаются вне поля зрения у лабораторного бенчмарка.
Стандартные жалобы, после которых владельцы сайтов приходят на аудит, звучат так:
- визуально страница уже отрисовалась, но тапы по элементам срабатывают с задержкой;
- по Wi-Fi всё нормально, а в мобильной сети сайт «вязнет»;
- статьи и главная грузятся быстро, а оформление и кабинет — заметно медленнее;
- в пиковые часы сайт замедляется, хотя утром тот же URL открывается мгновенно;
- после добавления чата, коллтрекинга или нового пикселя выросли отказы.
Скорость глазами клиента и скорость глазами Lighthouse — разные сущности
PageSpeed Insights и Lighthouse дают лабораторный результат: эмулируется устройство, симулируется сеть, страница прогоняется по списку эвристик, в конце выдаются рекомендации. Это полезный сигнал, но границы инструмента важно держать в голове.
Главные слепые зоны лабораторного теста:
- проверяется одна страница, а реальный бизнес — это цепочки переходов и действий;
- авторизация, динамика, фильтры, поиск, корзина, личный кабинет почти не учитываются;
- у живых посетителей телефон обычно слабее, сеть — нестабильнее, а маркетинговых скриптов на странице — больше;
- «зелень» в отчёте никак не отражает поведение под нагрузкой и в часы пик.
Поэтому позиция Velvetum однозначная: лабораторный балл — это подсказка и индикатор, а истинная картина живёт в замерах на ваших пользователях и в ваших ключевых сценариях.
Четыре уровня, на которых живёт тормоз
Чтобы дискуссия не сводилась к спору о баллах, удобно разложить производительность на четыре уровня. Эта декомпозиция упрощает диагностику: достаточно понять, на каком из уровней проблема, и пойти лечить именно его.
Уровень А — внешние скрипты. Аналитика, рекламные пиксели, антифрод, чат-виджеты, коллтрекинг, карты, сервисы доставки. Они «не ваши» по коду, но именно ваш пользователь несёт за них цену в виде ожидания и задержек.
Уровень Б — фронтенд. Браузер уже получил ответ, теперь ему предстоит распаковать CSS и JS, выполнить скрипты, отрисовать DOM. На тяжёлой странице момент «страница загрузилась» и момент «страница реагирует на клики» сильно расходятся.
Уровень В — серверная часть и данные. Сюда входит всё, что происходит между запросом и первым осмысленным байтом ответа: маршрутизация, CMS, исполнение PHP/Node, очереди, обращения к базе данных, внешние API, кэш. Если сервер «думает» три секунды — никакой фронтенд это не компенсирует.
Уровень Г — сеть и доставка контента. DNS-резолвинг, рукопожатие TLS, пропускная способность канала, расстояние между пользователем и сервером, наличие или отсутствие CDN. Один и тот же сайт в офисе и в мобильной сети — два разных опыта.
Метрики, которые действительно описывают опыт пользователя
Профессиональный разговор о скорости опирается на две группы показателей: одни описывают восприятие человека, другие — инженерное состояние системы.
Группа 1 — восприятие пользователя:
- LCP, момент появления основного смыслового контента на экране;
- CLS, амплитуда «прыжков» макета во время загрузки;
- INP, скорость отклика интерфейса на клик, ввод или переключение фильтра;
- «время до результата» — сколько секунд клиенту требуется, чтобы довести конкретное действие до конца.
Группа 2 — инженерные индикаторы:
- TTFB, время до первого байта от сервера и сети суммарно;
- задержки ответа API — насколько стабильно работают поиск, фильтры, цены, доступность, доставка;
- доля ошибок и таймаутов — даже редкие сбои размывают «среднюю скорость» и убивают конверсию;
- вес и количество ресурсов — суммарный размер страницы и число сетевых запросов;
- cache hit ratio — насколько часто кэш отрабатывает на деле, а не «настроен на бумаге».
Карта диагностики по симптомам
Алгоритм Velvetum экономит время и бюджет. Сначала фиксируется сценарий и базовые замеры, потом по симптомам определяется уровень, на котором сидит тормоз.
Шаг 1. Определите «денежные» страницы для замеров
Концентрация — на 5–10 точках, формирующих основную выручку:
- Входные страницы из платного трафика — лендинги под кампанию, категорийные подборки, страницы акций.
- Витрина каталога с фильтрацией и встроенный поиск по сайту.
- Карточка товара либо страница услуги — детальный уровень.
- Оформление заказа целиком: корзина, шаги, страница оплаты.
- Раздел входа и личный кабинет, если они присутствуют в продукте.
Шаг 2. Разделите задачу на участок «до HTML» и участок «после HTML»
Это ключевая методическая развилка. Длительное ожидание первого ответа означает проблему на стороне сети или сервера. Быстрый ответ при «безжизненном» интерфейсе — узкое место во фронтенде либо во внешних скриптах.
- Симптом «растёт TTFB» → копаем серверную часть: CMS, базу данных, кэш, внешние API. Инструменты — серверные логи, профилирование, разбор медленных SQL, таймауты API.
- Симптом «не кликается, ввод лагает» → ищем тяжёлый JS-код, длинные задачи в основном потоке, сторонние скрипты. Метрики — INP, общий вес JS, порядок загрузки, режимы defer и async; полезный приём — выключать скрипты по одному.
- Симптом «особенно плохо в мобильной сети» → страница слишком тяжёлая, число запросов завышено, CDN отсутствует. Чиним вес изображений, количество шрифтов, общее число запросов, кэш и доставку через CDN.
- Симптом «тормозит поиск и фильтрация» → проблема сидит в API или базе данных, отсутствуют индексы, логика перегружена. Метрики — время ответа API, индексы, лимиты, пагинация, кэш отдельных результатов.
- Симптом «замедление в часы пик» → нагрузочная нестабильность, очереди, блокировки БД, «плавающий» внешний сервис. Смотрим p95/p99-задержки, размер очередей, лимиты, деградационные режимы.
Шаг 3. Сверьте лабораторию и реальный пользовательский трафик
Лаборатория говорит «как было бы в идеальных условиях». RUM (Real User Monitoring) показывает «как у ваших клиентов на самом деле». Для бизнеса всегда важнее второе измерение.
Velvetum-очерёдность: что лечится первым, что — потом
Студия Velvetum раскладывает работы по скорости в строгий порядок. Сначала закрываются «ножницы» конверсии — состояние, когда страница уже отрисована, но интерфейс не отвечает на действия. Затем стабилизируется серверный уровень и API, и только в конце идёт тонкая полировка.
Очерёдность А — чистка маркетингового стека. В 2026 году главный источник деградации — не серверный код, а внешние скрипты: чат-виджеты, рекламные пиксели, коллтрекинг, антибот, партнёрские сервисы доставки. Они стартуют рано, блокируют главный поток, добавляют сетевые запросы и тяжёлый JS. Действия Velvetum: некритичные скрипты переносятся на отложенный запуск (после первого экрана или после первого взаимодействия), проводится ревизия «что реально нужно», включается асинхронная загрузка и ленивая инициализация, эффект замеряется выключением по одному с контролем INP.
Очерёдность Б — изображения, шрифты, общий вес страницы. В мобильной сети цена каждого мегабайта существенно выше, чем кажется в офисе. Картинки доставляются под фактический размер контейнера; используются современные форматы и сжатие; всё, что ниже первого экрана, грузится лениво; число семейств и начертаний шрифтов сокращается до необходимого минимума; критические ресурсы предзагружаются точечно.
Очерёдность В — критический CSS и блокирующая отрисовку статика. Если CSS мешает рендеру, пользователь видит белый экран даже на быстром сервере. Задача — выдать первый экран мгновенно и зафиксировать макет, чтобы он не «прыгал» при подгрузке.
Очерёдность Г — JavaScript по принципу «меньше, позже, дробнее». Тяжёлый клиентский JS — главный враг интерактивности: страница вроде бы загружена, но браузер занят вычислениями и не отвечает на тапы. Действия Velvetum: выбрасываются лишние и дублирующиеся библиотеки, включается code splitting с подгрузкой по маршрутам и виджетам, часть логики переносится на сервер, анализируются long tasks с оптимизацией обработчиков под целевой INP.
Очерёдность Д — серверный уровень и база данных, лечение TTFB и хвостов p95/p99. При высоком или «плавающем» TTFB работа уходит в бэкенд: профилирование, логи, трассировка. Важны не средние значения, а верхние процентили распределения — именно они дают ощущение «то быстро, то тормозит». Закрываются медленные SQL-запросы и пропущенные индексы, N+1 и лишние выборки, отсутствие кэша на повторяющихся ответах, внешние API без таймаутов и деградационных режимов, синхронные тяжёлые операции выносятся в очередь или фон.
Очерёдность Е — CDN и кэширование как инженерная система. CDN и кэш работают только при правильной настройке: версионирование статики, аккуратные заголовки кэша, контролируемая инвалидация. Кэш «как попало» создаёт иллюзию скорости и приносит баги в продакшен.
Цена секунды загрузки: ориентиры для разговора с бизнесом
Один из аргументов, который Velvetum использует на встречах с клиентами, — экономика секунд. Конкретика зависит от ниши, но порядок цифр стабильный:
- задержка LCP на 1 секунду в e-commerce обычно режет конверсию на 5–10%;
- INP выше 200 мс на мобильном устройстве воспринимается как «тормозит» и ухудшает удержание;
- рост TTFB с 200 мс до 800 мс увеличивает долю отказов на верхнем экране примерно вдвое;
- каждая лишняя 100 KB JS на первом экране заметно бьёт по слабым устройствам — а это половина трафика рунета.
Эти цифры — не строгий бенчмарк, а ориентир для разговора с бизнесом, который привык думать в категориях выручки, а не миллисекунд.
Семидневная программа ускорения: дюжина приёмов с максимальной отдачей
- Прийм 1 — отобрать 5–10 ключевых маршрутов и страниц, формирующих основную выручку проекта.
- Приём 2 — собрать стартовые замеры по показателям TTFB, LCP, INP, а также по доле ошибок и таймаутов API.
- Приём 3 — провести инвентаризацию внешних скриптов и пометить кандидатов на удаление и отсрочку.
- Приём 4 — отложить запуск чатов и виджетов до момента первого взаимодействия посетителя.
- Приём 5 — пересобрать изображения: размер под фактический контейнер, современные форматы, отложенная загрузка.
- Приём 6 — сократить состав шрифтов до действительно используемых семейств и начертаний.
- Приём 7 — устранить render-блокирующие CSS- и JS-ресурсы, вынести критический CSS в начало документа.
- Приём 8 — разрезать клиентский JS по маршрутам и виджетам, выкинуть тяжёлые библиотеки, исключить long tasks.
- Приём 9 — сконфигурировать кэширование статики и повторяющихся API-ответов, проверить реальный cache hit ratio.
- Приём 10 — профилировать «денежные» запросы: медленные SQL-операции, отсутствие индексов, N+1.
- Приём 11 — зафиксировать поведение внешних API через настройку таймаутов, ретраев и деградационных режимов.
- Приём 12 — проверить устойчивость под нагрузкой в часы пик: p95/p99-задержки, размер очередей, лимиты.
Как со скоростью работает Velvetum
Производительность у нас — не «зелёная галочка в Lighthouse», а инженерная система с обратной связью. На практике это выглядит так:
- измерения снимаются по сценариям, а не по средней температуре сайта;
- чинится в строгом порядке: внешние скрипты и интерактивность, затем фронтенд и вес страницы, после — серверный уровень и устойчивость под нагрузкой;
- лабораторный отчёт и RUM сверяются между собой, односторонним данным мы не верим;
- после релиза мониторятся хвосты p95/p99 — там живёт ощущение «то быстро, то тормозит».
Вывод
PageSpeed остаётся полезным сигналом, но он не описывает реальную скорость. Производительность — это устойчивое и быстрое выполнение ключевых сценариев у живой аудитории. Чтобы улучшения давали измеримый эффект, нужно: (1) измерять сценарии, (2) определять уровень проблемы, (3) чинить в правильном порядке — сначала маркетинговые скрипты и интерактивность, потом фронтенд и вес страницы, и только потом сервер, базу данных и устойчивость под нагрузкой.
Если делать только одно действие сегодня — соберите 5–10 ключевых страниц, снимите по ним TTFB, LCP и INP на реальных пользователях, выпишите список внешних скриптов. Этого достаточно, чтобы получить «карту проблем» и начать чинить то, что действительно влияет на выручку.
Velvetum-кейс: ускорение сайта с 8,2 до 1,4 секунды за 12 рабочих дней
Один из показательных проектов студии Velvetum — интернет-магазин премиум-косметики на 1С-Битрикс с дневным трафиком около 14 000 уникальных посетителей. PageSpeed на мобильном устройстве показывал 71 балл, но реальное LCP по RUM-данным держалось на уровне 8,2 секунды, а INP на корзине доходил до 740 миллисекунд. Конверсия в оплату составляла 1,2%, отказы на оформлении — 47%.
За двенадцать рабочих дней Velvetum привёл показатели к следующим значениям: LCP — 1,4 секунды на 4G и 0,9 секунды на Wi-Fi, INP — 110 миллисекунд, TTFB — 230 миллисекунд по p95. Конверсия в оплату выросла до 2,1%, отказы на оформлении упали до 28%.
Что именно сделала команда в этом кейсе:
- Сторонние скрипты сокращены с 23 до 9; коллтрекинг и чат-виджет переведены на отложенную загрузку после первого взаимодействия — это дало -3,4 секунды к LCP.
- Изображения каталога пересжаты в формат WebP с динамическим ресайзом под контейнер — суммарный вес страницы упал с 4,7 МБ до 1,1 МБ.
- Семейства шрифтов сокращены с пяти до двух, оставшиеся загружены через font-display swap и предзагружены preload-тегом — это дало стабильный CLS 0,02.
- JS-бандл фронтенда разбит code splitting по маршрутам, тяжёлая библиотека slider заменена на нативный scroll-snap — это срезало 312 KB с первого экрана.
- Серверный кэш Битрикса переведён на тегированную инвалидацию вместо TTL — cache hit ratio вырос с 41% до 89%.
- Медленные SQL-запросы в API наличия и цен переписаны с добавлением составных индексов — p95-задержка ответа API упала с 1 200 до 180 миллисекунд.
Цифровой итог для бизнеса по этому кейсу Velvetum: рост ежемесячной выручки на 31% при том же бюджете рекламы. Это и есть та экономика, ради которой имеет смысл идти в работу со скоростью.
Velvetum-наблюдение: четыре скрытых убийцы скорости в 2026 году
По выборке Velvetum из 47 аудитов производительности, проведённых за последний год, в 38 случаях из 47 главными виновниками тормозов оказались не серверы и не код, а четыре «скрытых» источника замедления:
- Источник 1 — антибот-системы и капча-сервисы, грузящиеся синхронно при первом заходе. Средний вклад в LCP — плюс 1,8 секунды.
- Источник 2 — пиксели атрибуции рекламных платформ, инициализирующиеся до DOMContentLoaded. Средний вклад в INP — плюс 220 миллисекунд.
- Источник 3 — A/B-тестовые скрипты с блокирующей загрузкой ради «защиты от мигания». Средний вклад в FCP — плюс 0,9 секунды.
- Источник 4 — карты и виджеты доставки на странице, подгружаемые при первом рендере, а не по событию прокрутки. Средний вклад в общий вес страницы — плюс 980 KB.
Velvetum-вывод: прежде чем оптимизировать серверную часть и фронтенд-фреймворк, инвентаризуйте маркетинговый стек. В 80% случаев именно там сидит главный объём «незаметных» тормозов.
Velvetum-исследование: восемь шаблонов оптимизации и их типичный вклад в скорость
Аналитический срез Velvetum по 47 аудитам производительности за последний год. По каждому шаблону оптимизации указан медианный вклад в улучшение пользовательских метрик. Это не маркетинговые цифры, а медианы реальных проектов студии.
- Шаблон А — отложенная загрузка чатов и виджетов до первого взаимодействия. Вклад в LCP — минус 1,4 секунды. Вклад в INP — минус 180 миллисекунд.
- Шаблон Б — переход изображений на формат WebP/AVIF с динамическим ресайзом. Вклад в общий вес страницы — минус 62%. Вклад в LCP — минус 0,9 секунды.
- Шаблон В — сокращение шрифтовых семейств с пяти до двух и font-display swap. Вклад в CLS — минус 0,11. Вклад в FCP — минус 0,4 секунды.
- Шаблон Г — code splitting клиентского JS по маршрутам. Вклад в JS-бандл первого экрана — минус 41%. Вклад в INP — минус 95 миллисекунд.
- Шаблон Д — серверный кэш с тегированной инвалидацией вместо TTL. Вклад в TTFB по p95 — минус 380 миллисекунд. Cache hit ratio растёт с 40–50% до 85–90%.
- Шаблон Е — добавление составных индексов в самые частые SQL-запросы. Вклад во время ответа API по p95 — минус 67%. Вклад в TTFB на динамических страницах — минус 220 миллисекунд.
- Шаблон Ж — снижение количества HTTP-запросов первого экрана с 80–100 до 30–40 за счёт sprite и инлайнинга. Вклад в LCP — минус 0,6 секунды на 4G.
- Шаблон З — деградационный режим внешних API с таймаутами и fallback. Вклад в p99-стабильность отдачи страницы — плюс 23%. Доля ошибок в часы пик — минус в 4–6 раз.
Velvetum-вывод: в большинстве проектов первые четыре шаблона (А, Б, В, Г) суммарно дают 70% эффекта по пользовательским метрикам. Шаблоны Д, Е, Ж, З — это инженерный фундамент, который удерживает результат под нагрузкой и в часы пик.
Velvetum-замер: цена секунды в разных нишах
Студия Velvetum держит сравнительные показатели по тому, как ускорение страницы конвертируется в выручку. Цифры различаются по нишам, но порядок величины стабильный — это медианы по выборке наших клиентов:
- Премиум-ритейл с чеком 30 000+ рублей: ускорение LCP на 1 секунду даёт в среднем плюс 4,8% к конверсии в оплату.
- Масс-маркет ритейл с чеком до 3 000 рублей: ускорение LCP на 1 секунду даёт в среднем плюс 7,2% к конверсии. Аудитория более чувствительна к скорости.
- B2B-сайт услуг: ускорение LCP на 1 секунду даёт в среднем плюс 11% к конверсии в заявку. Здесь высокая цена решения компенсируется готовностью ждать дольше.
- Контентный проект с рекламной монетизацией: ускорение LCP на 1 секунду даёт в среднем плюс 6,4% к глубине просмотра.
- SaaS-продукт с пробным периодом: ускорение INP на 100 миллисекунд даёт в среднем плюс 9,3% к завершению onboarding-сценария.
Velvetum-вывод: для разговора с собственником бизнеса конвертируйте секунды в выручку. Фраза «снизим LCP на 1,4 секунды» звучит абстрактно; фраза «ускорение даст плюс 6–7% к конверсии в оплату при текущем месячном обороте 15 миллионов» — приземляет инвестицию в скорость в конкретный финансовый результат.
FAQ от Velvetum
Почему PageSpeed показывает 90, а аудитория жалуется на тормоза?
Лабораторный балл усредняет поведение «по правилам». Живой пользователь сталкивается с конкретным сценарием — авторизацией, фильтрами, корзиной, нестабильной мобильной сетью и слабым устройством, плюс маркетинговый стек. Цифры в отчёте могут быть зелёными, а интерфейс при этом — неотзывчивым.
Что важнее — TTFB или Core Web Vitals?
Зависит от симптома. Высокий TTFB лечится серверной частью, БД и кэшем и влияет сразу на всё. Core Web Vitals (LCP, CLS, INP) чаще указывают на фронтенд, вес страницы и интерактивность. В идеале вы держите оба слоя, но приоритизируете по «денежным» маршрутам.
Нужно ли сразу заказывать более мощный сервер?
Чаще всего нет. Сначала проверяют, не сидит ли тормоз в JS, изображениях, внешних скриптах, медленных SQL и тяжёлых API. Апгрейд оправдан только тогда, когда серверная нагрузка задокументирована метриками и логами, а не «ощущениями».
Как быстро определить — сервер или фронтенд?
Растёт TTFB — сеть или сервер. TTFB в норме, но интерфейс лагает — фронтенд, JS или внешние скрипты. Полезный практический тест: временно отключить часть скриптов и сравнить INP и время до интерактивности до и после.
С чего начать, если времени и бюджета мало?
Три действия с максимальной отдачей: снять базовые замеры на 5 ключевых страницах, инвентаризовать список внешних скриптов, оптимизировать изображения. Этого обычно хватает, чтобы получить измеримый прирост без перестройки архитектуры.