Оптимизация производительности веб-сайта — это работа над тем, как быстро страница открывается, как скоро отвечает на нажатия и не прыгает ли при загрузке. Медленный сайт теряет посетителей ещё до того, как они увидели предложение, а поисковые системы учитывают скорость при ранжировании. Google измеряет её набором метрик Core Web Vitals, поэтому ниже методы ускорения разобраны вместе с тем, на какую метрику каждый из них влияет.
Core Web Vitals: три метрики скорости
Core Web Vitals — набор основных метрик, которые Google ввёл для оценки производительности и удобства страниц. Они стали частью алгоритма поиска и влияют на ранжирование сайтов в выдаче.
Largest Contentful Paint (LCP) — время загрузки самого большого элемента контента на первом экране: изображения, видео или блока текста. Метрика фиксируется в момент, когда основное содержимое становится видно пользователю. Чем раньше это происходит, тем раньше человек начинает работать со страницей.
First Input Delay (FID) до 2024 года измерял время отклика сайта на первое действие пользователя — щелчок по ссылке или кнопке.
С марта 2024 года вместо FID Google учитывает метрику INP (Interaction to Next Paint). Она оценивает задержку не только первого, а всех взаимодействий на странице и берёт одно из самых медленных. Хорошим считается значение до 200 мс. Советы ниже по разгрузке основного потока и сокращению лишнего JS полезны для обеих метрик.
Cumulative Layout Shift (CLS) оценивает визуальную стабильность: суммарное смещение элементов во время загрузки. Когда текст уезжает из-под пальца или кнопка сдвигается в момент нажатия — это и есть высокий CLS. Чем он меньше, тем предсказуемее страница.
| Метрика | Что измеряет | Хорошее значение | Что обычно мешает |
|---|---|---|---|
| LCP | загрузку главного элемента первого экрана | до 2,5 с | тяжёлые изображения, медленный сервер, блокирующие CSS и JS |
| INP | отклик на действия пользователя | до 200 мс | длинные задачи JavaScript, лишние скрипты |
| CLS | смещение макета при загрузке | до 0,1 | картинки и баннеры без размеров, вставка контента сверху |
Вспомогательные метрики
Помимо трёх основных, при диагностике смотрят на метрики, которые объясняют, откуда берётся задержка:
- Time to First Byte (TTFB) — время до первого байта ответа сервера. Высокий TTFB тянет за собой все остальные метрики: браузеру просто нечего показывать.
- First Contentful Paint (FCP) — момент, когда на экране появился первый контент: текст, изображение или видео. Короткий FCP создаёт впечатление быстрой загрузки.
- Total Blocking Time (TBT) — суммарное время, когда страница после начала загрузки была занята и не реагировала на действия. TBT замеряется в лабораторных тестах и хорошо предсказывает проблемы с INP.
Оптимизация изображений и элемента LCP
Изображения — один из главных источников медленной загрузки, и чаще всего именно картинка оказывается элементом LCP. Размер файлов уменьшают сжатием и современными форматами: WebP вместо PNG и тяжёлого JPEG. Атрибуты width и height у изображений обязательны — без них браузер не знает, сколько места оставить, и страница прыгает при загрузке.
Ресурс LCP должен находиться в HTML
Чтобы главный элемент загрузился как можно раньше, ссылка на него должна быть прямо в HTML-разметке страницы. Тогда браузер увидит её при первом разборе документа и начнёт загрузку сразу, а не после того, как скачает и выполнит другие файлы.
Если URL изображения недостижим в HTML
Это значит, что браузер не может найти ресурс по адресу из кода или получить к нему доступ. Причины обычно такие:
- неправильный путь к файлу;
- ошибка загрузки;
- недоступный сервер.
Пока картинка не загрузилась, LCP не наступит, поэтому битые и медленные адреса первого экрана исправляют в первую очередь.
Если изображение запрашивается из внешнего CSS или JS
Фоновая картинка из CSS или изображение, которое подставляет скрипт, обнаруживается браузером поздно — только после загрузки этих файлов. Что помогает:
- вывести изображение первого экрана обычным тегом в HTML или подсказать браузеру о нём заранее через предзагрузку;
- встроить критические стили первого экрана прямо в страницу, чтобы не ждать внешний CSS;
- маленькие декоративные изображения встраивать инлайн.
Ленивая загрузка — только ниже первого экрана
Атрибут loading="lazy" откладывает загрузку картинок до момента, когда они появятся на экране, и разгружает старт страницы. Но изображение первого экрана, которое и есть элемент LCP, лениво загружать нельзя: браузер начнёт качать его позже и LCP вырастет. Ленивая загрузка — для всего, что ниже.
Некритические ресурсы и порядок загрузки
На LCP влияют не только сами элементы первого экрана, но и всё, что загружается до них. Шрифты, сторонние виджеты, счётчики и скрипты, не нужные для первого показа, отнимают канал и время у основного контента.
- загружайте в приоритетном порядке то, что нужно для первоначального отображения страницы;
- некритические ресурсы подключайте асинхронно или откладывайте до полной загрузки;
- после каждого изменения порядка загрузки проверяйте результат: отложенный скрипт иногда ломает функциональность, которая на нём держалась.
Отзывчивость: длинные задачи и лишний JavaScript
Пока браузер выполняет долгую задачу, основной поток заблокирован и страница не реагирует на нажатия — это напрямую ухудшает INP (а раньше FID) и TBT.
Лишний JS
Частая проблема — кода подключено больше, чем нужно странице: целые библиотеки ради одной функции, скрипты от удалённых виджетов, дубли. Это замедляет загрузку и создаёт задержки в работе. Что делать:
- периодически анализировать JavaScript и убирать неиспользуемые функции и библиотеки;
- подключать скрипты с атрибутами async или defer, чтобы браузер продолжал разбирать страницу, не дожидаясь их;
- делить код на небольшие независимые модули и загружать только те части, которые нужны на конкретной странице;
- тяжёлые вычисления выносить в веб-воркеры — они работают в фоне и не блокируют основной поток;
- анимации делать на CSS, а не на JavaScript.
Минификация и объединение файлов
Минификация удаляет из HTML, CSS и JavaScript лишние пробелы, комментарии и переносы строк — файлы становятся меньше и быстрее загружаются. Для этого есть готовые инструменты, в том числе встроенные в сборщики. Вместе с удалением ненужного кода и объединением мелких файлов это заметно сокращает объём, который браузер скачивает и разбирает.
Стабильность макета: как снизить CLS
Главное в борьбе со сдвигами — заранее зарезервировать место под всё, что появляется на странице не сразу:
- Фиксированные размеры элементов. Изображениям, видео, баннерам и другим блокам задают размеры, чтобы браузер оставил под них место до загрузки.
- Атрибуты width и height у мультимедиа. Изображения, видео и аудио вставляют с указанными размерами — через атрибуты или CSS.
- Отложенная загрузка. Ресурсы ниже первого экрана загружают позже, сначала показывая видимый контент.
- Динамический контент. Если блок появляется после начала загрузки — баннер, уведомление, рекламное место, — под него заранее резервируют пространство и не вставляют его над уже показанным текстом.
Анимации и переходы без потери скорости
CSS-анимации и переходы делают интерфейс живее: плавное изменение прозрачности, масштаба, поворота, цвета, размеров и положения элементов. Для производительности у них есть преимущества перед JavaScript:
- их просто настроить — достаточно описать ключевые кадры (keyframes), а переходы между ними браузер просчитывает сам;
- браузер может использовать аппаратное ускорение, поэтому анимации остаются плавными даже на мобильных устройствах;
- они поддерживаются всеми современными браузерами.
Анимации стоит использовать умеренно и с понятной целью — привлечь внимание к важному или показать результат действия. Избыточные эффекты отвлекают и нагружают устройство.
Кэширование и BFCache
Кэширование сохраняет ресурсы в браузере посетителя, и при повторных визитах страницы открываются быстрее. Срок хранения задают отдельно для разных типов файлов: HTML, CSS, JavaScript, изображений.
BFCache (Back-Forward Cache) — механизм браузера, который сохраняет страницу целиком при переходе назад и вперёд кнопками браузера или жестами на телефоне. Страница восстанавливается мгновенно, без повторной загрузки, и это улучшает все три метрики:
- LCP — крупный контент уже загружен и не скачивается заново;
- CLS — макет восстанавливается ровно в том виде, в каком был, без скачков;
- INP — страница сразу готова реагировать на действия.
Чтобы страница попадала в BFCache, её код не должен этому мешать, а восстановленное состояние нужно проверять — особенно на страницах с личными данными, корзиной и формами.
CDN и граничные вычисления
CDN (Content Delivery Network) — сеть серверов в разных регионах, которая отдаёт контент с ближайшего к пользователю узла. Это заметно ускоряет загрузку для посетителей из отдалённых регионов. Граничные вычисления позволяют выполнять часть логики прямо на узлах CDN и дают больше возможностей:
- распределение нагрузки на основной сервер;
- кэширование;
- управление контентом, в том числе ограничение доступа к страницам по географии;
- мобильная оптимизация;
- мониторинг производительности — часть провайдеров даёт аналитику по запросам и поведению пользователей.
Оптимизация базы данных и сервера
Если сайт хранит данные в базе, её структура и запросы напрямую влияют на время ответа сервера, то есть на TTFB, а через него — на все остальные метрики. Индексы ускоряют поиск, а лишние и повторяющиеся запросы к базе стоит убирать: часто одна страница делает десятки запросов там, где хватило бы нескольких.
С чего начинать оптимизацию
| Шаг | Что делаем | На что влияет |
|---|---|---|
| 1 | Замер: PageSpeed Insights, отчёт Core Web Vitals в Search Console | показывает, какая метрика проседает |
| 2 | Сервер, база данных, кэширование | TTFB, а через него LCP и FCP |
| 3 | Изображения и элемент LCP первого экрана | LCP |
| 4 | Размеры медиа и места под динамические блоки | CLS |
| 5 | Лишний JavaScript, длинные задачи, async и defer | INP, TBT |
| 6 | CDN и BFCache | все метрики, особенно для удалённых регионов и повторных визитов |
Отдельно разбираем оптимизация Core Web Vitals на мобильных — что входит в работу, как замеряем скорость на телефоне и по каким показателям считаем результат.
Скорость сайта не разовая задача, а режим: держим её в рамках технической поддержки сайта — замеры, оптимизация и контроль после каждого релиза.
Проверка производительности
Производительность проверяют регулярно, а не один раз: после обновлений, новых виджетов и счётчиков скорость обычно снова падает. Для замеров подходят Google PageSpeed Insights и GTmetrix — они показывают проблемные места и дают рекомендации. Лабораторный замер полезен для поиска причин, а окончательный вывод делают по полевым данным реальных посетителей, на которых и строится оценка Core Web Vitals.
Быстрый сайт — это сумма небольших решений: лёгкие изображения, порядок загрузки, отсутствие лишнего кода, зарезервированное место под блоки и быстрый сервер. Исправления в таком порядке улучшают и удобство для посетителей, и позиции в поиске.
