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

Происхождение и история термина

Веб-перформанс как инженерная дисциплина вырос из простого вопроса: за какое время страница загрузится. Долгое время ответом считали момент срабатывания события load. В спецификации W3C Navigation Timing такой интервал формально задан: для записи о навигации startTime всегда равен 0, а длительность считается как loadEventEnd минус startTime ^[9]. Однако авторы web.dev отмечают, что традиционные метрики вроде времени загрузки или DOMContentLoaded ненадёжны: их значения могут не совпадать с моментами, когда пользователь получает полезный отклик ^[5]. Эта критика сместила акцент с «времени полной загрузки» на пользовательские метрики, о которых речь пойдёт ниже.

Ключевые вехи, связанные с поисковыми системами:

Данные 2010, 2018 и 2020 годов старше трёх лет и приведены как историческая справка: они описывают состояние на момент публикации. Подробная история Core Web Vitals (включая замену FID на INP) разобрана в статье Core Web Vitals.

Суть и механизм

Загрузка страницы — цепочка этапов. Каждый следующий начинается, когда предыдущий дал браузеру нужное: адрес сервера, соединение, первые байты ответа, разметку и ресурсы.

Яндекс Метрика в отчёте «Время загрузки страниц» выделяет семь этапов: DNS, редиректы, установка соединения, ответ сервера, загрузка и парсинг HTML, время до загрузки DOM и время до отрисовки; последнее, по описанию справки, посетитель субъективно воспринимает как скорость загрузки сайта ^[7]. Для первых четырёх этапов (DNS, редиректы, установка соединения, ответ сервера) учитываются только значения с ненулевым временем ^[7].

Браузер фиксирует соответствующие отметки времени по стандартам W3C. Запись о навигации (PerformanceNavigationTiming) расширяет интерфейс Resource Timing и наследует его атрибуты ^[9]. В Resource Timing отметки domainLookupStart и connectStart соответствуют началу поиска домена и началу соединения, а responseStart — началу первого промежуточного ответа сервера или, если его не было, началу получения заголовков окончательного ответа ^[18].

Время до первого байта (TTFB) по документации web.dev складывается из пяти фаз: время редиректов, время запуска service worker (если он есть), DNS-запрос, соединение и согласование TLS, запрос вплоть до прихода первого байта ответа ^[6]. TTFB не входит в Core Web Vitals, поэтому достигать его «хорошего» значения не обязательно; сайт с серверным рендерингом может иметь больший TTFB, но лучшие FCP и LCP, чем полностью клиентский ^[6].

Воспринимаемая скорость

Пользователь оценивает не секундомер, а моменты. По формулировке web.dev, загрузка — «не один момент во времени», а опыт, который ни одна метрика не может описать полностью; если сосредоточиться на одной метрике, можно пропустить плохой опыт в остальное время ^[5]. Поэтому современные подходы измеряют несколько моментов: когда появилось что-то, когда появилось главное, когда страница отзывается на ввод и не «прыгает» ли вёрстка.

Восприятие ожидания изучают и в науке о взаимодействии человека и компьютера. В лабораторном эксперименте Ф. Нах (2004) приемлемое время ожидания при поиске информации составило примерно 2 с, а наличие обратной связи о ходе загрузки увеличивало готовность ждать ^[19]. Это данные 2004 года, полученные в иных условиях доступа в интернет, поэтому они приведены как историческая справка, а не как норма.

Виды и классификации

По способу получения данных

Классификация, которую использует Google PageSpeed Insights (PSI) ^[3]:

Справка Search Console прямо предупреждает: результаты ручной проверки в PageSpeed Insights или Lighthouse могут отличаться от данных отчёта ^[12]. Расхождение объясняется разными источниками и периодами данных ^[3].

По этапу и типу метрики

Классификация, принятая в этой статье (редакционная, на основе метрик web.dev ^[4], PSI ^[3] и Lighthouse ^[13]):

Две лабораторные метрики Lighthouse, которые не входят в Core Web Vitals, но дают 40 % итоговой оценки Lighthouse 10 ^[13]:

• Total Blocking Time (TBT) — суммарное время, в течение которого страница не может отвечать на ввод: складываются «блокирующие» части всех длинных задач (дольше 50 мс) между First Contentful Paint и Time to Interactive ^[16].
• Speed Index — показатель того, насколько быстро содержимое визуально появляется при загрузке; Lighthouse записывает видео загрузки и вычисляет визуальный прогресс между кадрами ^[17].

По устройству

Google рекомендует оценивать мобильные и десктопные показатели раздельно ^[4]; в Search Console данные для мобильных и компьютеров выводятся в разных отчётах, и статусы могут различаться ^[12]. Почему мобильные результаты обычно хуже, отчасти объясняет методика: для мобильного прогона Lighthouse в PSI симулирует устройство среднего уровня (Moto G4) в мобильной сети, а для десктопа — эмулированный компьютер с проводным подключением ^[3]. Полевые данные отражают реальные устройства и сети посетителей ^[3], поэтому разница зависит и от аудитории сайта (вывод).

Метрики и пороги

Пороги PSI на дату проверки (документация обновлена 21.10.2024) ^[3]. Обе границы диапазонов включаются в нижнюю категорию: например, для LCP «хорошо» — интервал [0; 2500 мс], «требует улучшения» — (2500; 4000 мс], «плохо» — более 4000 мс ^[3].

Core Web Vitals — подмножество Web Vitals, применимое ко всем страницам ^[4]. Методика оценки (в том числе 75-й перцентиль посещений) разобрана в статье Core Web Vitals, отдельные метрики — в статьях LCP, INP и CLS.

Как применяется на практике

В России

Позиция Яндекса в действующей справке. Справка Яндекс Вебмастера «Как сделать сайт быстрее» называет скорость загрузки страниц одним из важных показателей качества сайта. Среди мер ускорения она перечисляет сокращение числа HTTP-запросов и редиректов, отложенную или асинхронную загрузку скриптов и CSS, не нужных для отрисовки, минификацию кода, CDN, кеширование и сжатие Gzip, сжатие изображений и отложенную загрузку изображений вне видимой области. Для анализа рекомендованы отчёты Яндекс Метрики ^[15]. О ранжировании в справке ничего не сказано ^[15].

Яндекс Метрика. Отчёт «Время загрузки страниц» показывает этапы загрузки (см. таблицу выше). По умолчанию используется квантиль 50 %: в половине случаев время загрузки не превышает значения из отчёта; квантиль можно изменить ^[7]. Справка рекомендует сегментировать данные по браузеру, для отдельной страницы создать сегмент с условием «Просмотр URL», а региональные различия смотреть в группировке по географии ^[7].

Достижение «скорость сайта» в Вебмастере (2020). 20 апреля 2020 года Яндекс запустил в Вебмастере бета-версию достижения «скорость сайта» — скорости загрузки страниц в Яндекс Браузере при переходе из мобильного поиска Яндекса. По описанию 2020 года, индекс рассчитывался по обезличенным данным браузера, обновлялся не реже раза в месяц и показывался только сайтам с достаточным трафиком; в посте также отмечено, что разные инструменты измерения скорости могут давать разные результаты ^[8]. Действующая справка Вебмастера о скорости этот показатель не упоминает ^[15], поэтому его нынешний статус в статье не утверждается.

Что известно о ранжировании в Яндексе. В тексте анонса 2020 года о влиянии скорости на ранжирование не говорится ^[8]. В комментариях к посту сотрудник Яндекса ответил на разные вопросы по-разному:

• 20.04.2020, на просьбу раскрыть расчёт индекса: «мы не готовы раскрыть данные и формулы расчёта» ^[8];
• 21.04.2020, на вопрос, входит ли индекс в ранжирование: «повторюсь: влияние конкретных факторов на ранжирование мы не комментируем» ^[8];
• 18.05.2020, на вопрос, влияют ли на ранжирование Турбо-страницы: Турбо-страницы оптимизированы для быстрой доставки и загрузки, что улучшает пользовательский опыт, а «Все, что улучшает пользовательский опыт, способствует продвижению в поиске»; при этом сами Турбо-страницы, по словам сотрудника, не индексируются и не ранжируются отдельно от оригинальных ^[8].

Это ответы в комментариях, а не документация. Первый и второй прямо отказываются называть фактор и его вес, третий даёт общий тезис о пользовательском опыте без указания на скорость как фактор. Корректная формулировка (вывод): Яндекс публично связывает пользовательский опыт с продвижением, но не раскрывает, учитывается ли скорость загрузки при ранжировании и с каким весом.

В мире

Google предлагает связку инструментов: отчёт Core Web Vitals в Search Console, PageSpeed Insights и данные CrUX ^{[1, 3, 12]}. Документация Search Central прямо рекомендует: «We highly recommend site owners achieve good Core Web Vitals for success with Search» («мы настоятельно рекомендуем владельцам сайтов добиваться хороших Core Web Vitals для успеха в поиске») ^[1].

Связь скорости с бизнес-результатами

Самый известный публичный пример в документации Google — кейс Vodafone (опубликован 17.03.2021, данные исторические). Это A/B-тест на одной посадочной странице: версия A оптимизирована по Web Vitals, версия B — исходная. Трафик из платных каналов (дисплейная реклама, iOS/Android, поиск, соцсети) делился 50/50 ^[14]. Полевой LCP версии A оказался на 31 % лучше (5,7 с против 8,3 с); продажи выросли на 8 %, отношение лидов к визитам — на 15 %, отношение добавлений в корзину к визитам — на 11 % ^[14].

Оговорки обязательны:

• это один кейс одной компании на одной странице, опубликованный площадкой Google; анализа статистической значимости на странице нет, абсолютные бизнес-значения скрыты ^[14];
• вместе с LCP менялось многое: рендеринг виджета перенесли с клиента на сервер, что сократило блокирующий отрисовку JavaScript; критический HTML рендерили на сервере; изображения оптимизировали (уменьшили главное изображение, оптимизировали SVG и PNG, с помощью медиазапросов не загружали изображения, ещё не видимые в области просмотра) ^[14]. Поэтому прирост продаж нельзя приписать только LCP (вывод);
• время DOMContentLoaded в версии A выросло (4,05 с против 3,52 с) — ещё одно подтверждение того, что одна метрика не описывает скорость ^[14].

Обобщённых цифр вида «секунда задержки снижает конверсию на N %» редакция не приводит: первоисточник для них не найден.

Рычаги по этапам загрузки

Приёмы ускорения подробно описаны в отдельных статьях; здесь только карта соответствия (группировка условная, перечень мер — по справке Яндекса ^[15]):

• ответ сервера и соединение: кеширование, сжатие, CDN — Хостинг, CDN;
• загрузка ресурсов: меньше HTTP-запросов и редиректов, минификация, сжатие изображений, отложенная загрузка изображений вне видимой области — Ленивая загрузка;
• отрисовка: отложенная или асинхронная загрузка скриптов и стилей, не нужных для первой отрисовки ^[15]; серверный рендеринг, который может повысить TTFB, но улучшить FCP и LCP ^[6].

Гарантий ускорения «на N %» дать нельзя: эффект зависит от конкретного сайта.

Как измерить или проверить

Порядок диагностики, который соответствует логике инструментов Google ^{[3, 12]} (структура редакции):

1. Полевые данные. Отчёт Core Web Vitals в Search Console строится на данных CrUX ^[12]. Статус группы URL определяется по худшему из трёх показателей (LCP, INP, CLS), значения берутся для 75 % посещений, страницы объединяются в группы со схожим опытом ^[12]. Если ресурс добавлен недавно или данных CrUX недостаточно, отчёт показывает «Нет данных» ^[12]. Параллельно смотрят блок полевых данных в PSI ^[3] и отчёт Яндекс Метрики ^[7].
2. Лабораторный прогон. Lighthouse или PSI помогают искать причины ^[3]. Статус отдельного URL отчёт Search Console не показывает; его проверяют вручную через PageSpeed Insights или Lighthouse ^[12].
3. Разбор по этапам. Если проблема на стороне сервера, смотрят TTFB и его фазы ^[6]; в Метрике — этапы отчёта «Время загрузки страниц» ^[7].

Оценка Lighthouse

Итоговый балл производительности — средневзвешенное оценок отдельных метрик ^[13]. Веса для Lighthouse 10 по документации Chrome:

Та же страница приводит веса Lighthouse 8 (CLS — 15 %, учитывался Time to Interactive с весом 10 %) и отмечает, что веса менялись со временем ^[13]. Поэтому цифры привязаны к Lighthouse 10. Диапазоны оценки: 90–100 — хорошо, 50–89 — требует улучшения, 0–49 — плохо ^{[3, 13]}. Значение метрики переводится в оценку по логнормальной кривой на данных HTTP Archive; у высоких оценок отдача от улучшений убывает ^[13]. Значительная часть колебаний балла вызвана не самим Lighthouse, а внешними причинами: рекламой и A/B-тестами на странице, маршрутизацией сети, различиями устройств, расширениями браузера, антивирусом ^[13].

Мини-инструмент: калькулятор оценки метрик загрузки

Назначение: по значениям, которые пользователь взял из PSI или другого отчёта, определить категорию каждой метрики и понять, к какой части загрузки она относится.

Вход: LCP (с), INP (мс), CLS, FCP (с), TTFB (с). Выход: для каждой метрики категория «хорошо», «требует улучшения» или «плохо» по порогам PSI ^[3], группа метрики (по таблицам выше) и ссылка на статью.

Правило границ (по интервалам PSI ^[3]): значение ≤ good_max — «хорошо»; больше good_max и ≤ ni_max — «требует улучшения»; больше ni_max — «плохо». Пример: LCP ровно 4,0 с — «требует улучшения», 4,01 с — «плохо».

Ограничения, которые инструмент обязан показывать на экране: инструмент ничего не измеряет на сайте и не заменяет PageSpeed Insights; пороги взяты из документации Google на дату проверки (14.10.2026); один хороший показатель не означает хорошей скорости в целом.

Машиночитаемая таблица порогов (источник: ^[3]):

{
  "source": "https://developers.google.com/speed/docs/insights/v5/about",
  "docs_updated": "2024-10-21",
  "checked": "2026-10-14",
  "rule": "value <= good_max -> good; good_max < value <= ni_max -> needs_improvement; value > ni_max -> poor",
  "metrics": {
    "LCP":  {"unit": "s",  "good_max": 2.5,  "ni_max": 4.0},
    "INP":  {"unit": "ms", "good_max": 200,  "ni_max": 500},
    "CLS":  {"unit": "",   "good_max": 0.1,  "ni_max": 0.25},
    "FCP":  {"unit": "s",  "good_max": 1.8,  "ni_max": 3.0},
    "TTFB": {"unit": "s",  "good_max": 0.8,  "ni_max": 1.8, "experimental": true}
  }
}

Ошибки, ограничения и спорные вопросы

Погоня за 100 баллами. Google указывает, что попытка получить идеальный балл только ради SEO может быть не лучшим использованием времени ^[2]. Балл Lighthouse — лабораторная оценка, привязанная к версии и весам ^[13].

Путаница лаборатории и поля. Отчёт Search Console опирается на CrUX и 75 % посещений ^[12], а лабораторный прогон — на одну симулированную загрузку ^[3]; справка Search Console предупреждает, что результаты могут отличаться ^[12].

Одна метрика вместо набора. Фокус на одной метрике может скрыть проблемы в остальные моменты загрузки ^[5]. В кейсе Vodafone LCP улучшился при ухудшении DOMContentLoaded ^[14].

Медиана вместо перцентиля. Google оценивает Core Web Vitals по 75-му перцентилю ^[4], а квантиль по умолчанию в Метрике — 50 % ^[7]; сравнивать значение Метрики по умолчанию с порогами Google напрямую некорректно (вывод).

Данные зависят от аудитории. Полевые данные отражают реальные устройства и сети ^[3]; в Метрике различия видны при группировке по региону и браузеру ^[7].

Нет данных у малотрафиковых сайтов. Отчёт Search Console может не показывать данные, если в CrUX их недостаточно ^[12]; индекс Яндекса в 2020 году тоже показывался только сайтам с достаточным трафиком ^[8].

Спор о влиянии на ранжирование. Позиция Google: Core Web Vitals используются системами ранжирования; «единого сигнала нет»; Google стремится показать наиболее релевантный контент, даже если опыт на странице неудовлетворительный ^[2]. Исторически (2010, 2018) Google заявлял, что скорость слабее релевантности и затрагивает малую долю запросов ^{[10, 11]}. Яндекс вес скорости не раскрывает, хотя его сотрудник связывал улучшение пользовательского опыта с продвижением ^{[8, 15]}. Утверждения агентств и SEO-сервисов вида «ускорение даёт рост позиций» доказательством не являются и в статье не используются.

Частые вопросы

Связанные термины

• Core Web Vitals — подробный разбор набора из трёх метрик и методики оценки
• LCP
• INP
• CLS
• Ленивая загрузка
• CDN
• Хостинг
• Мобильная адаптация
• Яндекс Вебмастер
• Яндекс Метрика