Как ускорить загрузку сайта в 2026 году: 4 метрики, 6 блоков работ и 5 вещей, которые скорость не чинят
Коротко: быстрым считается сайт, у которого на 75-м процентиле реальных визитов LCP не превышает 2,5 с, INP – 200 мс, CLS – 0,1, а ответ сервера (TTFB) укладывается в 0,8 с. Порядок работ почти всегда один: картинки и медиа → кеш и сжатие на сервере → серверная отрисовка и запросы к БД → шрифты → сторонние скрипты → JS и CSS фронтенда. Начинают с замера, а не с покупки нового хостинга.
Содержание
- Какие показатели считаются «быстрым сайтом» в 2026 году?
- Чем измерять скорость: лаборатория или реальные пользователи?
- Почему 75-й процентиль, а не среднее?
- Почему сайт грузится медленно?
- Какие работы ускоряют загрузку и что влияет на их объём?
- Как выстроить цикл «замер → работа → повторный замер»?
- Что НЕ ускоряет сайт?
- Что говорит практика
- Частые вопросы
Какие показатели считаются «быстрым сайтом» в 2026 году?
Ориентир – три метрики Core Web Vitals плюс диагностический TTFB. Целевые значения: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS не выше 0,1, ответ сервера до 0,8 секунды. Оценка берётся по 75-му процентилю реальных визитов и отдельно для мобильных и десктопных устройств.
| Метрика | Что измеряет | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|---|
| LCP | Отрисовка самого крупного элемента экрана | до 2,5 с | 2,5–4,0 с | свыше 4,0 с |
| INP | Отклик страницы на действия пользователя | до 200 мс | 200–500 мс | свыше 500 мс |
| CLS | Смещения вёрстки во время загрузки | до 0,1 | 0,1–0,25 | свыше 0,25 |
| TTFB | Время до первого байта ответа сервера | до 0,8 с | 0,8–1,8 с | свыше 1,8 с |
Главное изменение, из-за которого старые инструкции не работают: в марте 2024 года метрику FID заменили на INP. FID учитывал задержку только первого взаимодействия, INP смотрит на отклик в течение всей сессии и берёт практически худший случай. Поэтому гайд, где написано «держите FID ниже 100 мс», сегодня не просто устарел – он измеряет не то. Сайты, годами проходившие по FID, на INP часто проваливаются: тяжёлые обработчики и сторонние скрипты мешают не на первом клике, а на пятом.
Чем измерять скорость: лаборатория или реальные пользователи?
Данные бывают двух типов. Лабораторные – это синтетический прогон страницы в контролируемых условиях (Lighthouse, вкладка диагностики в браузере, большинство онлайн-чекеров). Полевые – агрегированные показатели настоящих посетителей: для Core Web Vitals это набор CrUX, который собирается из браузера Chrome по согласившимся пользователям, а также собственная RUM-телеметрия сайта. PageSpeed Insights показывает оба блока сразу: сверху полевые, если по домену накоплено достаточно визитов, ниже – лабораторный прогон.
Решения принимают по полевым данным, а причины ищут по лабораторным. Лаборатория даёт воспроизводимость и список конкретных проблем с привязкой к файлам, но моделирует один фиксированный сценарий: один регион, одна скорость канала, одно устройство. Полевые данные учитывают весь разброс аудитории – старые смартфоны, мобильный интернет за городом, кеш у повторных посетителей. Из российских источников похожую роль выполняет отчёт о времени загрузки страниц в системе веб-аналитики, установленной на сайте: это тоже данные реальных визитов. Подробный перечень того, что ещё попадает в проверку, разобран в материале про технический аудит сайта и чтение отчёта.
Почему 75-й процентиль, а не среднее?
75-й процентиль означает: три четверти визитов уложились в это значение, четверть была хуже. Среднее арифметическое прячет проблему – десяток быстрых загрузок с кешем на мощном ноутбуке компенсирует в среднем одну катастрофически медленную на бюджетном смартфоне. Медиана (50-й процентиль) честнее, но объявляет сайт здоровым, когда половина аудитории страдает.
Практический вывод: оптимизировать нужно худшие сценарии, а не улучшать и без того хорошие. Если 75-й процентиль по мобильным – 4,3 секунды, а по десктопу – 1,9, работать надо с мобильной вёрсткой, мобильными картинками и объёмом JavaScript, который прилетает на телефон. Именно поэтому замеры всегда разделяют по типу устройства, а не смотрят одно усреднённое число по сайту.
Почему сайт грузится медленно?
Причины почти всегда лежат в одном из четырёх слоёв: сервер отвечает долго, страница тянет лишние мегабайты, браузер не может начать отрисовку из-за блокирующих ресурсов, либо после отрисовки макет продолжает прыгать и подвисать. Чаще всего задержка складывается из нескольких слоёв сразу, поэтому точечная правка даёт разочаровывающий результат.
- Сервер. Каждый запрос страницы собирается заново: нет кеширования на стороне приложения, тяжёлые выборки к базе на главной и в каталоге, отсутствует кеш фрагментов. Это видно по TTFB.
- Медиа. Фотографии загружены редакторами в исходном размере и отдаются в сжатом до миниатюры блоке; одно изображение в карточке может весить больше, чем вся остальная страница. Это прямой удар по LCP.
- Блокирующие ресурсы. Стили и скрипты в head без атрибутов отложенной загрузки, шрифты без font-display, из-за чего текст либо не виден, либо перерисовывается.
- Сторонние виджеты. Счётчики, пиксели рекламных кабинетов, чат, карта, виджет обратного звонка. Каждый тянет свой скрипт со стороннего домена и занимает основной поток – это частый источник плохого INP.
- Отсутствие резервирования места. Баннеры, баннерные слоты и изображения без указанных размеров: контент уезжает вниз в момент подгрузки, растёт CLS.
Какие работы ускоряют загрузку и что влияет на их объём?
Работы делятся на шесть блоков. Трудоёмкость каждого считается не «по прайсу», а от трёх вещей: сколько уникальных шаблонов на сайте, есть ли доступ к серверу и репозиторию, есть ли тестовый контур, где можно проверить правку до выката. Таблица ниже показывает, что именно раздувает оценку в каждом блоке.
| Блок работ | На какие метрики влияет | Нужен доступ к коду | Что раздувает оценку |
|---|---|---|---|
| Картинки и медиа: сжатие, современные форматы, корректные размеры, приоритет главного изображения, отложенная загрузка нижних блоков | LCP, вес страницы | Частично: шаблоны вывода | Число шаблонов; изображения, вставленные редакторами прямо в тело статей; отсутствие исходников |
| Кеш и сжатие на сервере: заголовки Cache-Control, Brotli/gzip, HTTP/2, отдача статики | TTFB, повторные визиты | Нет, но нужен доступ к конфигурации | Хостинг без доступа к настройкам сервера; несогласованные правила кеша между CMS и прокси |
| Серверная отрисовка: кеширование страниц и фрагментов, оптимизация запросов к базе | TTFB | Да | Самописная CMS без документации; отсутствие тестового контура; тяжёлые фильтры каталога |
| Шрифты: сокращение числа начертаний, подмножества символов, предзагрузка, отказ от иконочных наборов в пользу встроенных SVG | LCP, CLS | Да | Несколько семейств в макете; шрифты, подключённые со стороннего домена; иконки, разбросанные по шаблонам |
| Сторонние скрипты: инвентаризация, удаление дублей, перенос в отложенную загрузку, подключение по событию | INP, LCP | Частично: часть правится в менеджере тегов | Дубли систем аналитики; виджеты, добавленные разными подрядчиками без учёта |
| Фронтенд: разделение бандла, удаление неиспользуемого CSS и JS, отложенная загрузка компонентов | INP, LCP | Да | Отсутствие сборки и репозитория; правки, внесённые напрямую на боевом сервере |
Про форматы изображений в 2026 году отдельно. WebP заметно легче JPEG при сопоставимом визуальном качестве и поддерживается в актуальных версиях основных браузеров. AVIF жмёт ещё сильнее и сегодня поддерживается в актуальных версиях основных браузеров – запасной вариант в JPEG нужен уже не всем проектам, а только тем, у кого в аналитике заметна доля устройств со старыми версиями Safari. Проверяйте долю по своей статистике, а не по общим рекомендациям трёхлетней давности.
Как выстроить цикл «замер → работа → повторный замер»?
После каждого блока делается контрольный замер, и только затем берётся следующий блок. Критерий перехода простой: если метрика, на которую блок был нацелен, не сдвинулась в лабораторном прогоне – причина диагностирована неверно, и браться за следующий блок бессмысленно, иначе через месяц будет непонятно, что именно сработало.
Важно развести горизонты. Лабораторный прогон отражает правку сразу после выката. Полевые данные обновляются с задержкой: CrUX работает на скользящем 28-дневном окне, то есть полная картина по новым показателям сложится примерно через месяц после релиза, а первые сдвиги будут видны раньше и постепенно. Это корректный ответ на вопрос «почему мы всё сделали, а в отчёте по-прежнему красное». Фиксируйте дату выката каждого блока – иначе сопоставить изменения с графиком будет нечем.
Что НЕ ускоряет сайт?
Пять действий, которые регулярно делают вместо диагностики и которые сами по себе метрики не улучшают:
- Смена хостинга без замера TTFB. Если сервер отвечает за 0,3 с, а LCP равен 4 секундам, проблема не в хостинге – переезд её переносит, а не решает.
- Минификация HTML, CSS и JS при мегабайтных картинках. Экономия в килобайтах на фоне изображения, которое занимает основной вес страницы, в метриках не видна.
- Установка «плагина ускорения» поверх неработающего кеша. Два слоя кеширования с противоречащими правилами дают не ускорение, а трудноуловимые баги: пользователи могут видеть чужие корзины и устаревшие цены.
- Погоня за «100 из 100» в синтетическом тесте. Балл агрегирует лабораторные метрики, его можно поднять приёмами, которые реальному посетителю ничего не дают.
- Подключение CDN при медленной серверной отрисовке. CDN ускоряет отдачу статики. Если страница собирается две секунды на стороне приложения, эти две секунды останутся.
Скорость при этом не изолированная задача: правки в вёрстке и шаблонах задевают и выдачу, и аналитику, поэтому их обычно планируют вместе с остальными техническими работами – см. разбор того, что входит в техническую поддержку сайта.
Что говорит практика
Частая причина внезапного замедления – не рост трафика и не «износ» сайта, а регресс после обновления. Обновили CMS или тему, вернули из бэкапа старый шаблон, добавили рекламный пиксель перед запуском кампании – и метрики уезжают, хотя визуально ничего не изменилось. Сайт при этом продолжает работать, поэтому проблему замечают не сразу, а по падению заявок. Как действовать в такой ситуации, подробно разобрано в материале про проблемы сайта после обновления.
Отсюда практическое правило: фиксировать состояние до работ и после них по одному и тому же списку, иначе спорить о результате будет не с чем. Минимальный набор, который имеет смысл сохранять скриншотом или выгрузкой перед каждым выкатом:
- LCP, INP, CLS по 75-му процентилю – отдельно мобильные и десктоп;
- TTFB по главной, типовой странице каталога и карточке товара или услуги;
- суммарный вес страницы и вес самого тяжёлого ресурса;
- число запросов к сторонним доменам и список подключённых скриптов;
- дата и состав выката – какой именно блок работ закрыт.
Частые вопросы
Какая скорость загрузки считается нормальной в 2026 году?
Целевые значения на 75-м процентиле реальных визитов: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1. Диагностический TTFB – до 0,8 секунды. Диапазоны «требует улучшения»: LCP 2,5–4,0 с, INP 200–500 мс, CLS 0,1–0,25, TTFB 0,8–1,8 с. Мобильные и десктопные показатели оцениваются раздельно.
Какие работы дают эффект без доступа к коду за один день?
Три вещи: пересжать и уменьшить самые тяжёлые изображения через админку, отключить дубли счётчиков и неиспользуемые виджеты в менеджере тегов, включить сжатие и заголовки кеширования в панели хостинга. Это обычно позволяет сдвинуть вес страницы и TTFB. Правки в шаблонах, шрифтах и бандле требуют доступа к репозиторию.
Влияет ли скорость на позиции в поиске?
Скорость – сигнал качества страницы в составе page experience, а не отдельный фактор ранжирования: отдельного «буста за скорость» поисковики не обещают, и одной скорости для роста позиций недостаточно. Эффект проявляется косвенно – через отказы и глубину просмотра. Измеряется по полевым данным CrUX и собственной веб-аналитике.
Почему PageSpeed показывает 95 баллов, а сайт кажется медленным?
Балл – это лабораторный прогон в фиксированных условиях: одно устройство, один канал, один регион, пустой кеш. Реальная аудитория шире: старые смартфоны, нестабильный мобильный интернет, тяжёлые страницы каталога вместо главной. Смотрите полевой блок того же отчёта и проверяйте не только главную, но и типовые внутренние страницы.
Нужно ли менять хостинг, если сайт тормозит?
Только если замер TTFB показывает выше 0,8 секунды и при этом серверное кеширование уже настроено, а запросы к базе оптимизированы. В остальных случаях переезд сам по себе обычно не меняет LCP и INP: эти метрики определяются весом медиа, блокирующими ресурсами и сторонними скриптами, а не площадкой размещения.
Через сколько после правок обновятся метрики?
Лабораторный прогон отражает изменения сразу после выката. Полевые данные Core Web Vitals считаются на скользящем 28-дневном окне, поэтому полная картина складывается примерно через месяц, а промежуточные сдвиги видны раньше. Фиксируйте дату каждого релиза, чтобы потом сопоставить изменения на графике с конкретным блоком работ.
Нужен ли AVIF или достаточно WebP?
WebP закрывает задачу для большинства проектов и поддерживается в актуальных версиях основных браузеров. AVIF сжимает сильнее и поддерживается актуальными версиями основных браузеров, поэтому запасной JPEG нужен не всегда. Решайте по своей статистике: если доля устройств со старыми версиями браузеров заметна, оставляйте запасной формат.
Материал подготовил Альберт К.
Выстроить аналитику проекта поможет настройка аналитики от DS495.