Скорость загрузки сайта

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

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

Вторая скорость адресована роботам. Им безразлично, дождался ли человек кнопки: значение имеет время ответа сервера и число страниц, которые робот успевает забрать за визит. Две скорости расходятся чаще, чем совпадают: сервер отвечает мгновенно, а страница собирается три секунды, потому что вся сборка вынесена в скрипты.

Этапы загрузки страницы и что тормозит на каждом из них

Скорость для человека и скорость для робота

Человек оценивает страницу по тому, что видит и трогает: появился ли заголовок с картинкой, откликнулась ли кнопка на нажатие, не уехал ли текст из-под пальца, когда догрузился баннер. Это восприятие и разложено на три метрики Core Web Vitals, которые снимают прямо в браузере посетителя.

Робот поисковой системы смотрит на другое. Google описывает предел обхода как величину, зависящую от состояния сайта: когда время ответа растёт или сервер отдаёт ошибки 5xx и код 429, предел снижается и Google обходит меньше страниц; при стабильно быстрых ответах предел поднимается сам. Яндекс задаёт скорость обхода числом запросов в секунду и по умолчанию подбирает её алгоритмом, отдельно предупреждая, что избыточные запросы робота сами увеличивают время ответа сервера. Отсюда прямая связь медленного хостинга с индексацией: на сайте в сотню страниц она не заметна, на каталоге в сотню тысяч часть адресов до индекса не доходит.

Разница сказывается на выборе работ. Сжатие картинок и шрифтов меняет то, что видит человек, и почти не двигает обход. Ускорение ответа сервера двигает обе стороны сразу, поэтому в техническом аудите с него и начинают.

Откуда взялось

Скорость учитывалась в ранжировании Google задолго до появления нынешних метрик, но тот сигнал касался десктопной выдачи. 17 января 2018 года Google объявил Speed Update: с июля 2018 года скорость стала фактором и в мобильном поиске. В том же объявлении названы границы: обновление затрагивает страницы с самым медленным откликом и небольшую долю запросов, а медленная страница с релевантным содержимым может ранжироваться высоко.

В мае 2020 года появилась связка «страничный опыт», куда вошли Core Web Vitals. Набор менялся один раз: 12 марта 2024 года метрику отзывчивости FID сменила INP, а поддержку FID в инструментах Chrome прекратили 9 сентября 2024 года. Google обещает менять состав предсказуемо, раз в год, и публиковать правки в открытом журнале изменений. По состоянию на сентябрь 2026 года метрик по-прежнему три, новых в набор не добавляли, пороги не сдвигали.

Core Web Vitals

Три метрики описывают три разных ощущения от страницы. Оценку по каждой берут по 75-му перцентилю визитов с разделением на мобильные и десктопные, то есть требование звучит так: три четверти посещений уложились в порог. Цифры ниже сняты с документации web.dev 6 сентября 2026 года.

LCP, отрисовка крупнейшего элемента

Largest Contentful Paint фиксирует момент, когда в видимой области отрисовался самый большой блок содержимого: картинка, кадр видео, крупный текстовый блок. Хорошо это 2,5 секунды и меньше, от 2,5 до 4 секунд требует работы, больше 4 секунд считается плохим результатом. LCP отвечает на вопрос «когда стало похоже на страницу, за которой человек пришёл».

INP, отклик на действие

Interaction to Next Paint измеряет задержку между действием человека (клик, тап, нажатие клавиши) и ближайшей отрисовкой, где видно результат. Метрика собирает такие задержки за весь визит, а не только первую. Хорошо это 200 миллисекунд и меньше, от 200 до 500 миллисекунд требует работы, больше 500 миллисекунд плохо. Именно INP ловит ситуацию, когда страница нарисовалась, а на нажатия не отвечает: браузер занят выполнением скриптов.

CLS, смещения вёрстки

Cumulative Layout Shift считает неожиданные сдвиги содержимого. Порог хорошего значения 0,1, коридор до 0,25 считается требующим улучшения, всё выше 0,25 плохим. Значение собирают по окнам: подряд идущие сдвиги с паузами меньше секунды объединяются в серию длиной до пяти секунд, и в зачёт идёт самая тяжёлая серия за жизнь страницы. Это та самая ситуация, когда человек целится в ссылку, а над ней догружается баннер и уводит вёрстку вниз.

Чем измеряют

Лабораторные и полевые данные

Лабораторный замер это прогон страницы в контролируемых условиях: заданное устройство, заданный канал, чистый профиль. Он повторяем, показывает причину и годится для поиска проблемы, но условия стенда не равны условиям посетителей.

Полевые данные собираются у настоящих людей. Источник для инструментов Google это Chrome User Experience Report (CrUX): анонимные замеры браузеров тех пользователей, кто согласился на передачу статистики, за скользящие 28 дней. Полевые данные показывают, как обстоят дела в жизни, но не объясняют причину и появляются только у страниц с достаточной посещаемостью. Отсюда типичное расхождение: в лаборатории зелёные цифры, в поле красные, потому что стенд не знает про старые телефоны и слабую сеть.

Инструменты

• PageSpeed Insights. Показывает оба слоя сразу: сверху полевые данные CrUX по трём метрикам, ниже лабораторный прогон и список рекомендаций. Работает по адресу без установки.
• Lighthouse. Лабораторный движок, встроенный в браузер Chrome и доступный из командной строки. Отдаёт оценку от 0 до 100, где 90 и выше считается хорошим результатом, 50-89 требующим улучшения, ниже 50 плохим. Оценка складывается из пяти лабораторных метрик с разными весами, тяжелее прочих весит Total Blocking Time.
• Отчёт CrUX. Полевые данные в чистом виде, доступны через API и публичный набор данных. Нужны, когда надо сравнить свои цифры с чужими или посмотреть динамику по месяцам.
• Яндекс Вебмастер. В разделе «Качество сайта» показывалось достижение «скорость сайта»: индекс считается по переходам пользователей Яндекс Браузера из мобильной выдачи и обновляется не реже раза в месяц. Числовых порогов Яндекс не публикует.
• Яндекс Метрика. Отчёты по времени загрузки страниц на собственной аудитории сайта, справка Яндекса отсылает именно к ним.

Инструменты не заменяют друг друга. Полевые данные говорят, что происходит, лабораторные почему, и разбор инструментов юзабилити строится на том же разделении.

Что тормозит сайт

• Картинки. Самая частая причина плохого LCP. Фотография на 4 мегабайта в блоке шириной 600 пикселей грузится целиком, а потом уменьшается браузером. Лечится сжатием, современными форматами и отдачей размера под экран.
• Скрипты. Каждый счётчик, чат, виджет отзывов и пиксель рекламной системы это лишний файл и лишняя работа процессора. Пока браузер выполняет скрипт, он не отвечает на нажатия, и портится INP.
• Ответ сервера. Время до первого байта (TTFB) метрикой Core Web Vitals не является, но входит в LCP целиком. Ориентир web.dev: хорошо 0,8 секунды и меньше, плохо больше 1,8 секунды. Тяжёлые запросы к базе, отсутствие кэша и слабый хостинг видны именно здесь, и на популярных CMS проблема чаще в наборе плагинов, чем в самом движке.
• Редиректы. Каждый редирект это дополнительный запрос до начала загрузки. Цепочка из трёх звеньев съедает время до того, как браузер увидит первый байт содержимого.
• Шрифты. Пока файл шрифта не приехал, текст либо невидим, либо показан запасным начертанием и потом перерисовывается. Первое портит LCP, второе даёт смещение и портит CLS.
• Блоки без заданных размеров. Баннер, картинка или блок рекламы без указанной высоты раздвигает страницу в момент появления. Это основной поставщик плохого CLS.

Что делать на практике

1. Снять исходные цифры по трём метрикам в PageSpeed Insights для мобильной и десктопной версии, отдельно для главной, страницы каталога и карточки. Сохранить дату замера.
2. Проверить время ответа сервера. Пока TTFB высокий, работа с картинками и скриптами даёт мало.
3. Разобраться с LCP-элементом: найти, что именно является крупнейшим блоком, сжать его, отдать в нужном размере и не откладывать его загрузку.
4. Проставить ширину и высоту всем изображениям и зарезервировать место под баннеры и виджеты. Это самый дешёвый способ убрать CLS.
5. Пересмотреть список сторонних скриптов. Отключить то, чем никто не пользуется, остальное грузить после отрисовки.
6. Убрать цепочки перенаправлений: внутренние ссылки, карта сайта и меню должны вести на конечные адреса.
7. Включить кэширование и сжатие на сервере, проверить, что статика отдаётся с длинным сроком хранения.
8. Повторить замер через две-четыре недели: полевые данные CrUX обновляются медленно, скользящее окно в 28 дней растворяет вчерашние правки.

Влияет ли скорость на позиции

Тема обросла мифами, и разбор мифов в отдельной статье начинается ровно с таких сюжетов. Проверяемая картина по состоянию на сентябрь 2026 года выглядит скромнее обещаний.

Google

Скорость подтверждена как сигнал, слабый по сравнению с содержанием. В документации о страничном опыте сказано прямо: единого сигнала «page experience» нет, системы ранжирования смотрят на набор признаков; поиск показывает наиболее релевантное содержимое, даже если опыт страницы посредственный. Идеальные Core Web Vitals не гарантируют верхних позиций. При этом когда по запросу есть много одинаково подходящих ответов, страничный опыт помогает выбрать. Из объявления Speed Update видно ту же логику: наказывают заметно медленные страницы, а не всех подряд.

Яндекс

Яндекс называет скорость загрузки одним из показателей качества сайта и объясняет её влияние через поведение: с медленной страницы уходят, и это сказывается на статистике сайта. Формулировки «скорость это фактор ранжирования» в справке нет, а на прямой вопрос в блоге для вебмастеров представитель Яндекса ответил, что влияние конкретных факторов на ранжирование не комментируется. При этом поведение посетителей само входит в факторы ранжирования, поэтому скорость действует на позиции косвенно.

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

Ограничения и спорные места

Порог не равен ранжированию. Зелёные Core Web Vitals это выполнение требования Google к качеству страницы, а не место в выдаче. Google прямо пишет, что идеальные значения ничего не гарантируют, и не раскрывает, какой вес получает страничный опыт среди прочих признаков.

Публичных замеров влияния на позиции в Рунете нет. Корреляционные исследования агентств встречаются, но методики у них разные, выборки закрытые, а разделить эффект скорости и эффект остальных отличий быстрых сайтов от медленных они не могут. Ссылаться на такие цифры как на доказательство нельзя.

Полевые данные есть не у всех. CrUX собирает статистику только с браузеров Chrome и только при достаточном числе визитов. Сайту с малой посещаемостью и аудитории, сидящей в других браузерах, полевого слоя не достанется, и остаётся лабораторный прогон со всеми его условностями.

Лабораторная оценка нестабильна. Повторные прогоны Lighthouse на одной и той же странице дают разброс из-за сети, загрузки машины и работы сторонних сервисов. Одиночный замер годится для поиска проблем, для отчётности берут серию.

Что показывает Яндекс, известно частично. Индекс скорости считается по переходам из мобильной выдачи в Яндекс Браузере, но формула, пороги и вес неизвестны. Отдельной страницы справки с описанием этого показателя найти не удалось (проверено 6 сентября 2026 года), действующее описание есть только в блоге для вебмастеров.

Что устареет первым. Состав Core Web Vitals и пороги: Google меняет их по годовому циклу и предупреждает об этом в журнале изменений. Следом идут интерфейсы инструментов и набор отчётов в панелях Яндекса. Формулировки Google о слабости сигнала держатся с 2018 года и меняются медленнее прочего.

См. также

• Аудит сайта: необходимые инструменты
• Анализ юзабилити сайта: что это такое и зачем его проводить
• Robots.txt

Источники

1. Google. web.dev, «Web Vitals», сверено 06.09.2026. https://web.dev/articles/vitals
2. Google. web.dev, «Largest Contentful Paint (LCP)», обновлено 04.09.2025. https://web.dev/articles/lcp
3. Google. web.dev, «Interaction to Next Paint (INP)», обновлено 02.09.2025. https://web.dev/articles/inp
4. Google. web.dev, «Cumulative Layout Shift (CLS)», обновлено 12.04.2023. https://web.dev/articles/cls
5. Google. web.dev, «Time to First Byte (TTFB)», обновлено 18.11.2025. https://web.dev/articles/ttfb
6. Google. web.dev, «Interaction to Next Paint is officially a Core Web Vital», 12.03.2024. https://web.dev/blog/inp-cwv-launch
7. GoogleChrome. Библиотека web-vitals, CHANGELOG, последний релиз 6.2.1 от 26.08.2026. https://github.com/GoogleChrome/web-vitals/blob/main/CHANGELOG.md
8. Google Search Central. «Using page speed in mobile search ranking», 17.01.2018. https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search
9. Google Search Central. «Evaluating page experience for a better web», май 2020. https://developers.google.com/search/blog/2020/05/evaluating-page-experience
10. Google Search Central. «Understanding page experience in Google Search results», обновлено 10.12.2025. https://developers.google.com/search/docs/appearance/page-experience
11. Google Search Central. «Crawl budget management for large sites», обновлено 22.07.2026. https://developers.google.com/crawling/docs/crawl-budget
12. Google. «About PageSpeed Insights», обновлено 21.10.2024. https://developers.google.com/speed/docs/insights/v5/about
13. Google. Chrome for Developers, «Lighthouse performance scoring», сверено 06.09.2026. https://developer.chrome.com/docs/lighthouse/performance/performance-scoring
14. Яндекс. Справка для вебмастеров, «Как сделать сайт быстрее», сверено 06.09.2026. https://yandex.ru/support/webmaster/ru/yandex-indexing/page-speed.html
15. Яндекс. Справка для вебмастеров, «Скорость обхода сайта», сверено 06.09.2026. https://yandex.ru/support/webmaster/ru/service/crawl-rate
16. Яндекс. Блог для вебмастеров, «Новое достижение: „скорость сайта“», сверено 06.09.2026. https://webmaster.yandex.ru/blog/novoe-dostizhenie-skorost-sayta