Скорость сайта в Яндексе: что поручить подрядчику и как принять работу

Яндекс называет скорость «одним из важных показателей качества» сайта, но норматива в секундах для вас не публикует и участие скорости в ранжировании не комментирует. Единственный его числовой порог касается робота. При этом сам Яндекс измеряет скорость своих сервисов по метрикам 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.

К последним относится Яндекс Браузер. По нашему замеру Радара за август 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 с

Устаревший совет можно узнать по метрике FID. Она работала вместо INP до марта 2024 года. Google объявил замену 12 марта 2024 года, срок на переход закончился 9 сентября того же года.

Мы разобрали 28 статей, которые сейчас ранжируются по этой теме: семь из них описывают FID как действующую метрику и не упоминают INP ни разу. У одной дата обновления стоит сентябрём 2026 года, а внутри по-прежнему 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», март 2026
• Блог Яндекс Вебмастера, запись об индексе скорости сайта, апрель 2020
• Яндекс Радар, доли браузеров и устройств

Google

• web.dev, «Largest Contentful Paint»: пороги и методика
• web.dev, «Interaction to Next Paint»
• Philip Walton, web.dev, «Лабораторные и полевые данные»
• Chrome for Developers, «Как складывается балл Lighthouse»
• Chrome for Developers, «Методология Chrome UX Report»

Замеры и кейсы

• Доклад об оптимизации Авто.ру на HolyJS, Хабр, 2023
• Хабр, «Сколько весят чат-виджеты», июль 2026
• HTTP Archive, Web Almanac 2025, глава о весе страниц

Теги публикации: pagespeed, скорость сайта