Ускорение загрузки сайта в 2026 году: пороги LCP 2,5 с и INP 200 мс, инструменты замера и объём работ
Коротко: сайт считается быстрым, если у 75 % визитов LCP укладывается в 2,5 секунды, INP – в 200 мс, CLS – в 0,1, а ответ сервера (TTFB) не превышает 800 мс. Полевые данные снимают отчётом Core Web Vitals в Search Console и PageSpeed Insights, причину ищут в Lighthouse и во вкладках Performance и Network в Chrome DevTools. Порядок работ: сервер и кэш → изображения → шрифты и JavaScript → сторонние скрипты. Данные актуальны на 18 сентября 2026 года.
Содержание
- Какая скорость загрузки считается нормальной в 2026 году?
- Как найти узкие места и чем замерять скорость?
- Из-за чего сайт грузится медленно?
- Что делать в первую очередь: порядок работ и целевые значения
- Сколько времени занимает ускорение сайта?
- Что показал наш опыт
- Частые вопросы
Какая скорость загрузки считается нормальной в 2026 году?
Порог «хорошо» по Core Web Vitals: LCP не больше 2,5 секунды, INP не больше 200 мс, CLS не больше 0,1. Оценка ведётся не по среднему, а по 75-му перцентилю реальных визитов за скользящее окно 28 дней, отдельно для мобильных и десктопа. То есть уложиться должны три визита из четырёх – «в среднем нормально» здесь не работает.
| Метрика | Что измеряет | Порог «хорошо» | Где смотреть |
|---|---|---|---|
| LCP | Отрисовку самого крупного элемента первого экрана | ≤ 2,5 с | Search Console, PageSpeed Insights, Lighthouse |
| INP | Отклик на клик, тап, ввод с клавиатуры | ≤ 200 мс | Только полевые данные и RUM |
| CLS | Смещение вёрстки во время загрузки | ≤ 0,1 | Search Console, Lighthouse |
| TTFB | Время до первого байта ответа сервера | ≤ 800 мс | Вкладка Network, WebPageTest |
| FCP | Первую отрисовку любого содержимого | ≤ 1,8 с | Lighthouse, PageSpeed Insights |
Состав метрик пересматривается: в марте 2024 года INP официально заменил FID в наборе Core Web Vitals, а в сентябре 2024 года FID убрали из отчётов. Инструкции, написанные до этих дат, ссылаются на метрику, которой больше нет. Проверяйте состав набора хотя бы раз в год.
Как найти узкие места и чем замерять скорость?
Сначала снимают полевые данные – они показывают, есть ли проблема у живых посетителей. Затем делают синтетический прогон – он объясняет причину. Порядок нельзя менять: оптимизация по одному лабораторному отчёту часто чинит то, что пользователей не беспокоит.
Полевые данные (реальные визиты)
- Отчёт Core Web Vitals в Google Search Console – группирует URL по шаблонам и сразу показывает, какие разделы красные;
- PageSpeed Insights – верхний блок отчёта берёт данные из публичного набора CrUX по конкретному URL или домену;
- библиотека web-vitals – подключается скриптом и отправляет LCP, INP и CLS в вашу аналитику. Позволяет увидеть метрики страниц с малым трафиком, по которым полевых данных в CrUX нет.
Синтетические прогоны (диагностика)
- Lighthouse – показывает LCP-элемент, объём неиспользуемого JavaScript и CSS в килобайтах;
- вкладка Network в Chrome DevTools – отсортируйте запросы по колонке Size и разбирайте верх списка: именно эти файлы дают основной вес;
- вкладка Performance – трассировка главного потока; ищите длинные задачи дольше 50 мс, они и портят INP;
- WebPageTest – прогон из разных регионов и на медленном канале, когда важна география аудитории.
Отдельно проверьте, не мешает ли скорости техническая часть: обрывы редиректов, отсутствие сжатия и мусорные скрипты обычно всплывают вместе с другими проблемами из списка типовых SEO-ошибок, тормозящих продвижение.
Из-за чего сайт грузится медленно?
В большинстве случаев причина не одна, а четыре-пять сразу, и вес у них разный. Разбирать их нужно по порядку – от сервера к содержимому страницы.
- Сервер. Медленный ответ бэкенда, тяжёлые запросы к базе, отсутствие кэширования готовых страниц. Если TTFB выше 800 мс, эффект остальных работ будет ограничен.
- Изображения. Фотографии, загруженные в исходном размере с камеры или из фотостока, в JPEG или PNG вместо WebP и AVIF.
- JavaScript. Один общий бандл на весь сайт, блокирующие скрипты в <head>, неиспользуемые библиотеки.
- Шрифты. Шесть начертаний вместо двух, полные кириллические наборы, блокировка отрисовки текста.
- Сторонние виджеты. Счётчики, чаты, карты, пиксели рекламных систем. Каждый добавляет свои запросы и работу главного потока.
- Смещения вёрстки. Картинки и рекламные блоки без заданных размеров, баннеры, которые появляются поверх контента.
Что делать в первую очередь: порядок работ и целевые значения
Начинают с того, что влияет на все страницы сразу, – с сервера и передачи данных. Дальше идут изображения первого экрана, затем скрипты и шрифты. Ниже – проверяемые ориентиры, по которым понятно, сделана работа или нет.
- Сервер и передача. Кэш готовых страниц, HTTP/2 или HTTP/3, сжатие Brotli с запасным gzip. Цель – TTFB в пределах 800 мс.
- Главное изображение первого экрана. Конвертация в WebP или AVIF с качеством порядка 75–82 (визуально близко к исходнику, вес заметно снижается), ширина под реальный контейнер, атрибут fetchpriority="high" и никакого lazy-load. Для полноэкранного баннера разумный потолок – сотни, а не тысячи килобайт.
- Остальные изображения. loading="lazy" всему, что ниже первого экрана, плюс обязательные width и height – это напрямую снимает CLS.
- JavaScript. Разделение бандла по шаблонам, defer или async у некритичных скриптов, удаление неиспользуемого кода по отчёту Lighthouse. Задайте проектный бюджет – например, не больше 150–200 КБ критического JS после Brotli на шаблон. Это ваш внутренний норматив, а не требование поисковых систем, но без бюджета бандл обычно разрастается.
- Шрифты. font-display: swap, preload основного начертания, подмножество только нужных символов, два начертания вместо шести.
- Сторонние скрипты. Счётчики и чаты – с defer или подгрузкой по первому взаимодействию. Ревизия: всё, что не используется в отчётах, удаляется.
- Контроль. Повторный замер через месяц, когда обновится окно полевых данных.
Скорость – только один из факторов оценки страницы; какие ещё сигналы реально работают, разбирали в материале о том, что влияет на позиции в 2026 году.
Сколько времени занимает ускорение сайта?
Оценки ниже – условный пример, построенный на допущениях: сайт до 100 страниц или 500 карточек, есть доступ к коду и настройкам сервера, редизайн не делается, работа идёт на существующем шаблоне. Ставка в расчёте – условные 2 500 ₽/ч; реальная зависит от подрядчика и стека. Если хотя бы одно допущение не выполняется (нет доступа к серверу, параллельно меняется дизайн), объём считается заново.
| Пакет работ | Что входит | Часы | Условный расчёт при 2 500 ₽/ч |
|---|---|---|---|
| Аудит и план | Полевые данные, синтетика, список работ с приоритетами | 6–10 ч | 15 000–25 000 ₽ |
| Базовая оптимизация | Сжатие, кэш, изображения, lazy-load, размеры картинок, defer у счётчиков | 12–25 ч | 30 000–62 500 ₽ |
| Глубокая оптимизация | Разделение бандла, шрифты, ревизия виджетов, серверный кэш, работа с INP | 35–95 ч | 87 500–237 500 ₽ |
| Контроль после релиза | Замер раз в месяц, проверка после каждого нового виджета | 2–4 ч/мес | 5 000–10 000 ₽/мес |
Что показал наш опыт
В проекте VINExperts задача звучала как переход с конструктора на собственный сайт: нужны были своя CMS, формы обращений и телефония. Побочный, но важный эффект такого переезда – над скоростью вообще становится возможно работать.
Механика ограничений конструктора простая. Настройки сервера и заголовки кэширования закрыты – TTFB не трогается. Общий JavaScript платформы грузится на всех страницах целиком, вырезать неиспользуемую часть нельзя. Шаблоны подтягивают собственные шрифты и виджеты, состав которых не редактируется. Формат и степень сжатия изображений задаёт платформа, а не вы. В итоге из семи шагов раздела выше доступными остаются один-два: заменить тяжёлые картинки и убрать лишние блоки со страницы.
Поэтому в аудите мы первым делом выясняем, есть ли доступ к серверу и к сборке фронтенда. Если доступа нет, честный ответ – не «ускорим на столько-то», а «список возможных работ сокращается до содержимого страниц». Порядок и состав этапов при переносе на собственный движок разбирали отдельно – в материале об этапах разработки сайта от брифа до запуска.
Частые вопросы
Сколько часов занимает ускорение существующего сайта?
Условный пример. Аудит с планом – 6–10 часов. Базовый пакет (сжатие, кэш, изображения, отложенная загрузка скриптов) – 12–25 часов. Глубокая работа с пересборкой фронтенда, шрифтами и сторонними виджетами – 35–95 часов. Ориентиры действуют при допущениях: сайт до 100 страниц, есть доступ к коду и серверу, параллельный редизайн не идёт.
Что можно сделать бесплатно своими руками за один день?
Четыре действия без разработчика: добавить loading="lazy" изображениям ниже первого экрана; проставить width и height у картинок, чтобы убрать смещения вёрстки; перевести счётчики и виджеты на defer; включить Brotli или gzip в конфигурации nginx. Затем перезамерить страницу в PageSpeed Insights и сравнить отчёты.
Влияет ли скорость загрузки на позиции в поиске?
Core Web Vitals входят в сигналы page experience Google, оценка ведётся по 75-му перцентилю реальных визитов. Это один сигнал из многих: скорость сама по себе не компенсирует слабую релевантность. У Яндекса публично объявленного порога по этим метрикам нет – скорость учитывается в общей оценке качества страницы.
Чем полевые данные отличаются от лабораторных?
Полевые (CrUX, Search Console, собственный RUM на библиотеке web-vitals) собраны с реальных устройств за окно 28 дней и показывают, что происходит у посетителей. Лабораторные (Lighthouse, Performance в DevTools, WebPageTest) – один прогон в заданных условиях: они не подтверждают проблему, а объясняют её причину.
Почему PageSpeed Insights показывает высокий балл, а сайт кажется медленным?
Балл Lighthouse – синтетический прогон на эмулированном устройстве и канале. Реальные посетители заходят с других телефонов, сетей и из других регионов, часто с пустым кэшем. Ориентируйтесь на полевой блок отчёта с данными CrUX и на INP: он измеряется только при живом взаимодействии.
Нужно ли переходить на Next.js ради скорости?
Не обязательно. Если тормозят сервер, изображения и сторонние скрипты, смена фреймворка проблему не решит – те же работы делаются на текущем стеке дешевле. Переход оправдан, когда нужен серверный рендеринг вместо тяжёлой клиентской отрисовки или когда платформа не даёт управлять сборкой и кэшированием.
Как часто перепроверять скорость после оптимизации?
Отчёт Core Web Vitals в Search Console строится на скользящем окне 28 дней, поэтому эффект виден не сразу – смотрите примерно через месяц. Синтетический прогон полезно делать после каждого релиза и после подключения любого нового виджета: сторонние скрипты чаще всего возвращают метрики назад.
Материал подготовил Альберт К.