Скорость сайта в Яндексе: что поручить подрядчику и как принять работу
Кратко. Яндекс называет скорость «одним из важных показателей качества» сайта, но норматива в секундах для вас не публикует и участие скорости в ранжировании не комментирует. Единственный его числовой порог касается робота. При этом сам Яндекс измеряет скорость своих сервисов по метрикам Google и проводил эксперименты, где замедление на две секунды снижало добавления в корзину почти на 2%. Ниже: что мерить, что поручить подрядчику и как принять работу. Чек-лист для исполнителя лежит в конце файлом.
Что об этом говорит Яндекс
Начнём с первоисточника, потому что вокруг темы много пересказов. Справка Вебмастера, раздел «Как сделать сайт быстрее»:
«Скорость загрузки страниц сайта это один из важных показателей его качества. Из-за низкой скорости пользователь может не дождаться открытия страницы и перейти на другой ресурс. Это снижает уровень доверия к сайту, его посещаемость и влияет на другие статистические показатели.»
Обратите внимание, каких слов здесь нет: «позиции», «выдача», «ранжирование». Мы проверили это машинным поиском по полному своду справки объёмом 3,15 мегабайта. Утверждения, что скорость влияет на позиции, там нет нигде. На прямой вопрос в блоге для вебмастеров сотрудник компании ответил: «влияние конкретных факторов на ранжирование мы не комментируем».
Механизм при этом существует, просто он длиннее на один шаг. В документе о качестве поиска описана метрика, которая уменьшается, когда «пользователь быстро вернулся на страницу с результатами поиска». Медленная страница бьёт по позициям через возврат человека в выдачу.
Единственный числовой порог касается робота
«Если некоторые страницы загружаются больше 3 секунд, робот фиксирует это как ошибку. Из-за медленной работы сервера индексирование сайта может задерживаться.»
Цена, которую называют прямо, это задержка индексирования. Про падение позиций речи нет. Разница важна: страница, которую робот не успел обойти, не участвует в выдаче вообще.
Показателя «скорость сайта» в Вебмастере больше нет
Его вводили в апреле 2020 года: считался по обезличенным данным Яндекс Браузера при переходах из мобильного поиска, обновлялся раз в месяц, шкала из пяти делений. Числовых порогов для делений не публиковали и прямо отказались: «мы не готовы раскрыть данные и формулы расчёта».
Мы проверили 24 сентября 2026 года. В справке абзац про этот показатель закомментирован в исходном коде страницы и читателю не виден. В интерфейсе Вебмастера его тоже нет.
Половина советов в интернете до сих пор рекомендует «смотреть индекс скорости в Вебмастере». Смотреть больше нечего.
Эксперимент, где сервис замедляли намеренно
А вот это самое интересное, и в рунете почти не цитируется.
Никита Сидоров, руководитель службы инфраструктуры пользовательской скорости Яндекса, рассказал на YaTalks, как команда Маркета проводила A/B-эксперименты с намеренным замедлением боевого сервиса. Методика строже привычного рассказа про ускорение: там меняли одну переменную и смотрели, что отвалится.
«Мы проводили А/В-эксперименты, чтобы посмотреть, как замедление на разных экранах влияет на метрики.»
Что получилось на карточке товара:
| Что замедляли | На сколько | Результат |
|---|---|---|
| показ контента | на 2 секунды | добавления в корзину −1,8% |
| показ контента | на 1 и 2 секунды | переходы из блока «Ещё может подойти» −2% и −3% |
| показ контента | на 0,5 секунды | у новых пользователей просмотров страниц −1,9% |
| показ контента | на 2 секунды | у новых пользователей просмотров −13,4% |
| оформление заказа | на 1 и 2 секунды | переход к оформлению −1,7% и −2,8% |
Два вывода, которые стоит забрать целиком.
Первый: новые пользователи чувствительнее к скорости, чем постоянные. У лояльной аудитории просадка измеряется единицами процентов, у новичков доходит до тринадцати. Это прямо про рекламный трафик: за него вы платите, и приходит он к вам впервые.
Второй: интерактивность важнее показа. Дословно: «Когда не работают клики и скролл, эффект получается в 1,5 раза больше, чем показ контента». То есть страница, которая нарисовалась быстро, но не отвечает на касания, хуже страницы, которая просто медленно показалась.
И честное предупреждение оттуда же
Отдельно разобран случай, когда замедление улучшает метрику:
«Иногда при замедлении контента можно увидеть рост бизнес-метрик, но таким данным доверять нельзя. Например, при замедлении контента под рекламным блоком «Скоро в продаже» мы задерживаем пользователя на странице и дольше показываем ему рекламу. Рекламная метрика CPM растёт, но это нечестно и плохо для интегральных метрик продукта.»
Если подрядчик приносит отчёт, где после его работ выросло время на сайте, это ещё не победа. Человек мог просто дольше ждать.
Второй эксперимент, на поисковой выдаче
Разработчик интерфейсов Андрей Прокопюк описывал похожий случай на HolyJS: на поисковую выдачу внедрили веб-шрифт, отрисовка ухудшилась на 62 миллисекунды, то есть на 3%.
«Заметная невооруженным глазом задержка начинается только со 100 миллисекунд, и все же время до первого клика сразу увеличилось на полтора процента… Почти на полпроцента уменьшилось число кликнутых страниц.»
Фичу откатили. Комментарий автора: «В реальности полтора процента это сотни тысяч человек».
Важная оговорка, без неё цитировать нельзя. Оба эксперимента это замеры на собственных сервисах компании про поведение внутри продукта. О том, как поисковик учитывает скорость при ранжировании чужих сайтов, они не говорят ничего.
Посмотреть оба доклада целиком
Выступление, из которого взяты числа выше. Никита Сидоров разбирает, как связаны технические показатели и деньги продукта, и почему скорость приходится защищать перед руководством цифрами, а не ощущениями.
Второй доклад того же инженера на профессиональной конференции фронтендеров. Сюжет другой и прикладной: что делать, когда в компании скоростью не занимается никто. Ответ в названии, и он контринтуитивный.
Чем мерить российскую аудиторию
Тут начинается место, где чаще всего теряют деньги: три инструмента дают три разных ответа, и это не сбой.
Метрика: единственный полевой замер по всей вашей аудитории
Путь: Отчёты → Мониторинг → Время загрузки страниц. Работает при трафике от ста просмотров в неделю.
Главная строка отчёта называется «время до отрисовки», и описана она так:
«Именно это значение субъективно воспринимается посетителем как скорость загрузки сайта. Обычно оно занимает не более двух секунд.»
Ловушка, из-за которой отчёт врёт в вашу пользу. Дословно из справки: «По умолчанию выбран квантиль 50%. Это означает, что в 50% случаев время загрузки страниц будет не больше, чем указанное в отчёте». То есть по умолчанию Метрика показывает медиану, и половина ваших посетителей ждёт дольше, чем вы видите. Переключите квантиль на 75% или 90%, и отчёт начнёт описывать тех, у кого сайт грузится хуже всего.
PageSpeed Insights: показывает не всю вашу аудиторию
Полевые данные там собираются только с Chrome на компьютерах и на Android. Не попадают: Chrome на iPhone, встроенные браузеры приложений и браузеры на Chromium не от Google.
Яндекс Браузер это как раз Chromium не от Google. По нашему замеру Радара за август 2026 года, на мобильных его доля 38,75%, у Chrome 26,49%, у Safari 18,77%.
То есть полевая часть PageSpeed описывает примерно половину российской аудитории. Собственного аналога у Яндекса нет: по полным сводам справок Вебмастера и Метрики слова Core Web Vitals, LCP, INP и CLS не встречаются ни разу.
Но себя Яндекс мерит именно по метрикам Google
И это лучший аргумент в пользу того, что методику брать стоит. Из блога компании за март 2026 года:
«Для измерения скорости сервисов в Яндексе используется метрика Velocity Index, это агрегация метрик Web Vitals (FCP, LCP, TBT, INP, CLS). Итоговое значение получается в диапазоне от 0 до 100 баллов. Хорошим результатом считается индекс больше 85.»
Вебмастерам этих показателей не дают. Свои сервисы при этом оценивают именно ими.
Что в Вебмастере действительно помогает
Показателя скорости там больше нет, но три инструмента по теме работают, и ими пользуются редко.
Диагностика сайта. Раздел находит страницы, которые отвечают дольше трёх секунд, и помечает это ошибкой «Долгий ответ сервера». Это единственное место, где поисковик сам показывает вам список проблемных адресов. Список можно отдать подрядчику как есть.
Проверка ответа сервера. Инструмент показывает, что именно получает робот: код ответа, заголовки, содержимое, время. Тайм-аут у него те же три секунды. Полезен, когда человек видит страницу, а робот нет: так вскрываются редиректы, блокировки по user-agent и заглушки хостинга.
Третий инструмент, статистика обхода, показывает, сколько страниц робот обошёл за сутки и на какие ответы наткнулся. Резкое падение числа обойдённых страниц при росте времени ответа это прямой признак, что сервер не справляется.
Рядом лежит путаница, на которой теряют время. В Вебмастере есть раздел «Скорость обхода», и это не про скорость сайта для людей. Это про то, сколько запросов в секунду робот отправляет на ваш сервер. Половина рунет-материалов путает нагрузку от робота со скоростью для посетителя, и подрядчики иногда крутят эту настройку, отчитываясь об ускорении.
Чего в Вебмастере нет: ни Core Web Vitals, ни аналога PageSpeed, ни нормативных порогов скорости для страницы. Полевые данные по вашей аудитории смотрите в Метрике.
Методика Google: три метрики, по которым принимают работу
Подход Google универсален и применим к любому поисковику. Причина простая: меряет он опыт живого человека, а вовсе не ранжирование. Ниже официальные пороги из документации.
| Метрика | Что показывает человеческими словами | Хорошо | Плохо |
|---|---|---|---|
| LCP | когда появился главный элемент экрана: картинка, заголовок, товар | до 2,5 с | больше 4 с |
| INP | через сколько страница откликается на нажатие | до 200 мс | больше 500 мс |
| CLS | насколько прыгает вёрстка, пока грузится | до 0,1 | больше 0,25 |
| TTFB | ответ сервера, в тройку не входит | до 0,8 с | больше 1,8 с |
Деталь, по которой сразу видно устаревший совет. До марта 2024 года вместо INP работала метрика FID. Google объявил замену 12 марта 2024 года, срок на переход закончился 9 сентября того же года.
Мы разобрали 28 статей, которые сейчас ранжируются по этой теме: семь из них описывают FID как действующую метрику и не упоминают INP ни разу. У одной дата обновления стоит сентябрём 2026 года, а внутри по-прежнему FID. Подрядчик приносит отчёт с FID, значит работает по методичке двухлетней давности.
Пороги считаются по 75-му перцентилю. В норматив должны укладываться три четверти реальных загрузок. Средняя тут не считается вовсе: она прячет тех, кому хуже всех, а уходят именно они.
Где у этой методики границы, по словам тех же инженеров
Тот же доклад Сидорова называет и слабые места, а это полезнее любой рекламы метрик.
«Стандартной браузерной метрике FCP доверять нельзя, нужно писать свою.»
Причина: Safari отдаёт её неверно. Ещё один случай: «в поисковом сценарии для пользователя важны товары из органической выдачи, а Google рассчитывает LCP на основе загрузки рекламного баннера». То есть метрика может следить не за тем элементом, который важен вашему клиенту.
И случай, когда метрики слепы: «Мы сэкономили процессорное время клиента, получили рост кликов, продукт очевидно стал лучше. Но если ориентироваться на Web Vitals, никаких изменений не произошло».
При этом рабочая часть названа прямо: «Метрики LCP и TBT хорошо работают из коробки. Они действительно показывают пользовательский опыт».
Что именно поручить подрядчику
Задача, поставленная как «сделай, чтобы сайт летал», закрывается красивым отчётом. Ниже готовый текст, его можно скопировать и отправить исполнителю как есть.
Задача. Довести скорость до зелёной зоны по полевым данным на мобильных: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не больше 0,1, по 75-му перцентилю. Время до отрисовки в Яндекс Метрике на квантиле 75% не больше двух секунд. Страницы. Главная и посадочные, на которые идёт реклама и поиск. Список прилагаю. Что принести в начале. Текущие значения по каждой метрике и каждой странице из двух источников: Яндекс Метрика и PageSpeed Insights. Плюс разложение: сколько секунд забирает сервер, сколько картинки, сколько сторонние скрипты. Что принести в конце. Те же значения после работ, снятые тем же способом, и список сделанного по пунктам. Чего делать нельзя. Отключать счётчики аналитики и пиксели без согласования. Прятать содержимое от проверяющего бота. Ставить отложенную загрузку на главную картинку экрана. Срок замера «после». Не раньше чем через месяц после правок: полевые данные Google обновляются окном в 28 дней.
Три вопроса, которые отличают работу от отчёта
Вопрос первый: полевые данные или лабораторные?
PageSpeed показывает два блока. Верхний это данные реальных посетителей за 28 дней, нижний это симуляция на чужом сервере. Инженер Google формулирует прямо: если у вас есть и те и другие, приоритеты расставляйте по полевым.
Подрядчик, который приносит только лабораторный прогон, показал вам скорость одного запуска. Про скорость сайта это не говорит ничего.
Вопрос второй: какие три числа, а не какой балл?
Общий балл PageSpeed собран из пяти показателей с весами: блокировка потока 30%, LCP 25%, сдвиг вёрстки 25%, первая отрисовка 10%, индекс скорости 10%.
Посчитайте: два показателя из пяти к нормативу Google отношения не имеют. INP при этом не входит в балл ни на один процент. Поэтому бывает девяносто баллов и провал по LCP одновременно.
Вопрос третий: замер снят тем же способом, что и в начале?
Если «до» мерили одним инструментом, а «после» другим, сравнивать нечего. Яндекс предупреждает об этом сам: «Результаты измерений скорости сайтов разными сервисами могут существенно отличаться, это не говорит об ошибках».
Где обычно теряются секунды
Руководителю не нужно чинить это самому. Нужно понимать, о чём говорит подрядчик, и видеть, когда причина названа, а когда нет.
| Симптом | Что обычно за этим стоит | Кому поручить | Как принять |
|---|---|---|---|
| сервер отвечает дольше секунды | хостинг, тяжёлые запросы к базе, синхронизация с учётной системой | хостинг или бэкенд-разработчик | TTFB до 0,8 с на тех же страницах |
| страница показывается долго, сервер быстрый | тяжёлые картинки, блокирующие стили и скрипты | верстальщик, фронтенд | LCP до 2,5 с по полевым данным |
| страница нарисовалась, но не отвечает на касания | тяжёлые скрипты, сторонние виджеты | фронтенд | INP до 200 мс |
| вёрстка прыгает при загрузке | у картинок и блоков не заданы размеры | верстальщик | CLS до 0,1 |
| всё чинили, стало хуже | отложенная загрузка поставлена на главную картинку | тот же исполнитель, с указанием на ошибку | LCP вернулся к норме |
Картинки и скрипты это две главные статьи веса. По замеру HTTP Archive за 2025 год медианная мобильная страница весит 2 559 килобайт, из них картинки 911, JavaScript 632. Остальное вместе меньше.
Сторонние скрипты стоят дороже, чем кажется. Не меньше 90% сайтов подключают хотя бы один внешний сервис, и цепочка обычно трёхуровневая: скрипт тянет скрипт, который тянет третий. Свежий замер двух чат-виджетов показал разницу наглядно: один добавил к времени блокировки 2,5 секунды, второй почти 13 секунд.
Автор того замера честно оговаривает границы: это лабораторная дельта на двух конкретных сайтах в конкретный день, и на исследование она не тянет. Но порядок величины понятен, и вопрос «сколько стоит наш чат» задать стоит.
И самая дорогая ошибка отрасли. В докладе про оптимизацию Авто.ру разработчики рассказали, как нашли отложенную загрузку на первой фотографии карточки объявления. Поставил её кто-то, кто, по словам докладчика, начитался советов по ускорению и решил, что все фотографии надо грузить отложенно. Именно эта фотография была тем самым главным элементом экрана, по которому меряется LCP.
По данным HTTP Archive так делают 16-17% сайтов в мире, при том что у 76% мобильных страниц главный элемент это именно картинка.
Чего делать нельзя, даже если очень хочется
Накручивать балл. Существует схема, где сайт узнаёт проверяющего бота по его подписи и отдаёт ему облегчённую страницу. Баллы становятся стоклеточными, скорость для людей не меняется. Защита простая: попросите показать замер на видео или с временно отключённым счётчиком и сравните скриншот из отчёта с тем, что видите в браузере сами.
Выносить аналитику ради баллов. Счётчики и пиксели действительно весят. Но вместе с ними уходят данные, на которых держится весь маркетинг: источники, отказы, атрибуция. Правильный разговор звучит как «согласуем, сколько внешних сервисов и какого веса мы вешаем».
Третья ошибка это ускорять главную вместо посадочных. Деньги приходят на страницы услуг и товаров, куда ведёт реклама и поиск. Главная тут ни при чём.
Ждать результата на следующий день. Полевые данные Google это скользящее окно в 28 дней плюс пара суток задержки. Через неделю отчёт почти не сдвинется, и это не повод откатывать работу или менять подрядчика.
Частые вопросы
Влияет ли скорость на позиции в Яндексе?
Прямого утверждения об этом у Яндекса нет: мы проверили полный свод справки Вебмастера машинным поиском. Яндекс называет скорость «одним из важных показателей качества» и объясняет механизм через поведение, когда пользователь не дождался загрузки и вернулся в выдачу. Единственный числовой порог, три секунды, относится к роботу и грозит задержкой индексирования. Участие скорости в ранжировании Яндекс комментировать отказывается.
Влияет ли скорость на цену клика в Яндекс Директе?
Нет, и это распространённое заблуждение. В справке Директа нет ни одного упоминания скорости загрузки применительно к сайту. В коэффициент качества входит релевантность страницы запросу. Медленная посадочная удорожает не клик, а заявку: клик стоит столько же, до формы доходит меньше людей.
Что там с Турбо-страницами?
Формат закрыт 7 февраля 2025 года. Официальная причина Яндекса: «Сегодня скорость мобильных сетей значительно выросла», и «отключение Турбо никак не повлияет на распределение трафика на сайты».
Сколько трафика приходит с телефонов?
По данным Яндекс Радара около 70% поисковых визитов Яндекса приходится на мобильные устройства, и доля продолжает расти. Наш замер за август 2026 года дал 69,62%. Значит мерить скорость надо в первую очередь на мобильных.
Правда ли, что 53% пользователей уходят после трёх секунд?
Эта цифра кочует по статьям без источника. В оригинале она из отчёта Google и DoubleClick 2016 года и меряла зарубежную аудиторию. Вторая популярная цифра, «каждая секунда снижает конверсию на 20-30%», источника не имеет вовсе. Мы проверили 28 статей из топа: ссылку на исследование с именем автора даёт ровно одна.
Сколько стоит ускорение?
Зависит от причины, поэтому смету без диагностики брать не стоит. Замена хостинга, сжатие картинок и вынос стороннего скрипта это три разные работы с разной ценой. Ориентир от практиков: ускорение в два-три раза без изменения функциональности это очень хороший результат.
Чек-лист: отправьте это вебмастеру
Тот же список лежит отдельным файлом: чек-лист. Его удобно переслать исполнителю в чат, не пересказывая статью.
Замер до начала работ
| Что снять | Где | Норма |
|---|---|---|
| время до отрисовки | Яндекс Метрика, квантиль 75% | до 2 с |
| LCP, INP, CLS на мобильных | PageSpeed, полевые данные | 2,5 с · 200 мс · 0,1 |
| TTFB главной и трёх посадочных | любой замер времени ответа | до 0,8 с |
| разрез по устройствам и браузерам | Метрика | где именно медленно |
| разложение времени | отчёт подрядчика | сервер, картинки, скрипты |
Во время работ
Причина каждой секунды названа. Формулировка «оптимизируем всё» не принимается.
Счётчики и пиксели не тронуты без отдельного согласования.
На главной картинке экрана нет отложенной загрузки. Это самая частая ошибка ускорения.
Правки идут по одной, с замером после каждой.
Формы проверены живой отправкой после каждой правки.
Приёмка работы
| Проверка | Критерий |
|---|---|
| способ замера | тот же, что в начале |
| срок после последней правки | не меньше 28 дней |
| LCP, INP, CLS | 2,5 с · 200 мс · 0,1 по полевым данным |
| время до отрисовки в Метрике | до 2 с на квантиле 75% |
| содержание отчёта | метрики, а не общий балл |
| внешний вид страниц | не изменился, сверьте скриншоты |
| заявки с сайта | доходят, проверьте отправкой сами |
Проверим ваш сайт и составим смету работ. Аудит скорости Optimism даёт разложение проблемы по вкладу в секундах, отдельно по серверу, странице и сторонним скриптам, и список работ в порядке отношения выигрыша к затратам. Оставить заявку на аудит.
Источники
Яндекс
- Как сделать сайт быстрее, справка Вебмастера
- Отчёт «Время загрузки страниц», справка Метрики
- Коэффициент качества, справка Директа
- Перфоманс в культуре разработки продукта, Никита Сидоров, Яндекс, YaTalks 2023
- Системный подход к скорости во фронтенде, Андрей Прокопюк, Яндекс, HolyJS 2018
- Ускорение Яндекс Трекера: в погоне за Velocity Index, блог Яндекса, 19.03.2026
- Индекс скорости сайта в Вебмастере, 20.04.2020
- Яндекс Радар, доли браузеров и устройств
- Largest Contentful Paint: пороги и методика
- Interaction to Next Paint
- INP заменяет FID, Rick Viscomi, 12.03.2024
- Page experience в справке Google Search
- Лабораторные и полевые данные, Philip Walton
- Как складывается балл Lighthouse
- Методология Chrome UX Report
Замеры и кейсы
- Оптимизация Авто.ру, доклад на HolyJS, 03.02.2023
- Как во ВКонтакте ускоряли мобильную версию, 03.05.2024
- Сколько весят чат-виджеты, 28.07.2026
- Web Almanac 2025, вес страниц
- Web Almanac 2025, сторонние сервисы
- Кейс Vodafone Italy, 17.03.2021
- Кейс Rakuten 24, 24.08.2022
Теги публикации: pagespeed, скорость сайта
Такой подход позволяет увеличить спрос и снизить стоимость каждого клиента
Оптимизация сайта под максимально широкий пул ключевых запросов
Вид поискового продвижения, при котором оплата производится за целевые действия
