Скорость сайта и Core Web Vitals: как ускорить для SEO

Скорость загрузки давно перестала быть вопросом «про комфорт». С 2021 года Google учитывает Core Web Vitals как сигнал ранжирования, а с переходом на mobile-first индексацию метрики, замеренные на реальных мобильных устройствах, напрямую влияют на позиции. По данным Google, при росте времени загрузки с 1 до 3 секунд вероятность отказа пользователя увеличивается на 32%, а с 1 до 6 секунд — на 106%. В конкурентных нишах разница в полсекунды может стоить сайту первой страницы выдачи.

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

Почему скорость сайта влияет на SEO

Скорость работает на SEO сразу на трёх уровнях. Первый — это сам сигнал ранжирования: Google оценивает Core Web Vitals по реальным данным пользователей (field data) из отчёта Chrome User Experience Report и учитывает их в поиске. Второй — поведенческие факторы: медленный сайт получает больше отказов и меньше времени на странице, а эти сигналы поисковик считывает как признак низкой релевантности. Третий — краулинговый бюджет: чем медленнее отвечает сервер и чем тяжелее страницы, тем меньше страниц робот успевает обойти за отведённое время, особенно на больших каталогах.

Для коммерческих сайтов скорость конвертируется в деньги напрямую. Исследования показывают, что каждая дополнительная секунда загрузки мобильной страницы снижает конверсию на величину до 7–20% в зависимости от ниши. Для интернет-магазина со средним чеком это ощутимые потери выручки ещё до того, как пользователь дойдёт до корзины. Поэтому оптимизация скорости — не «косметика», а часть комплексного продвижения сайта, которая даёт эффект и в выдаче, и в конверсии.

Важно понимать нюанс: Google смотрит не на лабораторный показатель Lighthouse на мощном десктопе, а на 75-й перцентиль реальных сессий с мобильных устройств. Если ваши посетители сидят на бюджетных Android-смартфонах в сетях 3G, именно их опыт определяет, пройдёт ли сайт порог Core Web Vitals. Это меняет приоритеты оптимизации: десктопная скорость почти ничего не решает, если мобильная версия «проседает».

Три метрики Core Web Vitals: LCP, INP, CLS

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

LCP — Largest Contentful Paint

LCP измеряет время, за которое на экране появляется самый крупный элемент основного контента — обычно это заголовок, большое изображение или блок-обложка. Это главная метрика «воспринимаемой скорости»: пользователь видит не белый экран, а уже наполненную страницу. Целевое значение — 2,5 секунды и меньше. В зоне «требует улучшения» — от 2,5 до 4 секунд, выше 4 секунд — плохо.

Чаще всего LCP тормозят четыре вещи: медленный ответ сервера (TTFB), блокирующие рендер CSS и JavaScript, долгая загрузка ключевого изображения и задержки на клиентском рендеринге. Измерив LCP и разложив его на составляющие в PageSpeed Insights, вы почти всегда найдёте главного виновника без гадания.

INP — Interaction to Next Paint

INP заменил устаревший FID в марте 2024 года и стал официальной метрикой отзывчивости. Он измеряет задержку от действия пользователя — клика, тапа, нажатия клавиши — до момента, когда браузер отрисовал следующий кадр. Итоговое значение — это не среднее, а близкий к худшему 75-й перцентиль всех взаимодействий за сессию: Google специально не даёт «хорошим средним» маскировать отдельные зависания.

Хороший INP — 200 миллисекунд и меньше, от 200 до 500 мс — требует улучшения, выше 500 мс — плохо. Заметное отставание почти всегда связано с длинными задачами JavaScript: главный поток занят обработкой тяжёлого скрипта и не может ответить на клик. Именно поэтому борьба за INP — это в первую очередь борьба с раздутым JavaScript, а не с картинками.

CLS — Cumulative Layout Shift

CLS измеряет, насколько сильно «прыгает» макет при загрузке: сдвинулся ли текст, когда подгрузился шрифт, уехала ли кнопка, когда появился баннер или рекламный блок. Высокий CLS раздражает и приводит к случайным кликам не туда. Хорошее значение — 0,1 и меньше, до 0,25 — приемлемо, выше — плохо.

Типичные причины сдвигов — изображения и вставки без заданных размеров, шрифты с обменом после загрузки, динамически вставляемый контент и баннеры. Решается это резервированием места под элементы ещё до их загрузки.

Как и чем измерять скорость

Первое правило диагностики — различать лабораторные и полевые данные. Лабораторные замеры (Lighthouse в Chrome DevTools, PageSpeed Insights в режиме синтетического теста) прогоняют страницу в контролируемой среде с фиксированным «железом» и сетью. Они воспроизводимы и удобны для сравнения «до и после», но не отражают опыт ваших реальных пользователей. Полевые данные (field data) собираются с реальных устройств посетителей через CrUX и показывают, что происходит на самом деле.

Базовый набор инструментов выглядит так:

• PageSpeed Insights — быстрая проверка конкретного URL с разбором LCP, INP, CLS и списком рекомендаций. Показывает и лабораторные, и полевые данные, если по странице их достаточно.
• Google Search Console → «Основные интернет-показатели» — агрегированная картина по всему сайту: какие группы страниц проходят порог, а какие нет. Это отчёт, который видит сам Google, поэтому он приоритетнее любых сторонних тестов.
• Chrome DevTools → Lighthouse и вкладка Performance — глубокая отладка: длинные задачи, цепочки запросов, время ответа сервера.
• Расширение Web Vitals для Chrome — показывает метрики вживую при навигации по сайту.
• Сервисы RUM (мониторинг реальных пользователей) — собственная телеметрия метрик с реальных сессий, если нужен непрерывный контроль.

Ориентируйтесь на полевые данные, а лабораторные используйте как рабочий стенд. Если Search Console показывает «нужно улучшить» по группе страниц, но ваш личный тест на мощном ноутбуке даёт зелёные цифры — проблема реальна, просто ваш девайс и канал её не воспроизводят. Доверяйте агрегату, а не единичному прогону.

Оптимизация изображений

По данным HTTP Archive, изображения в среднем занимают около половины веса веб-страницы — часто больше 1 МБ на одну страницу. Это самый большой и при этом самый благодарный резерв оптимизации: сжатие картинок не требует переписывания кода и почти всегда даёт заметный прирост скорости.

Порядок действий для любого сайта:

1. Перевести изображения в современные форматы. WebP сжимает сильнее JPEG и PNG в среднем на 25–35% при сопоставимом качестве, AVIF — ещё эффективнее. Сегодня оба формата поддерживаются всеми актуальными браузерами.
2. Отдавать картинки в правильном размере. Нельзя грузить фото 2400×1600 для отображения в блоке 600 пикселей шириной. Генерируйте версии под каждую точку вставки и отдавайте их через атрибуты srcset и sizes, чтобы на мобильном устройстве браузер скачивал маленькую версию, а на десктопе — большую.
3. Сжимать без видимой потери качества. Для фотографий обычно достаточно качества 70–80% и умеренного сжатия; визуальную разницу заметит только специалист, а вес файла упадёт в разы.
4. Включить ленивую загрузку. Атрибут loading="lazy" на изображениях ниже первого экрана откладывает их скачивание до момента, когда пользователь до них доскроллит. Это радикально снижает вес начальной загрузки.
5. Выделить LCP-изображение. Картинку, которая попадает в Largest Contentful Paint, наоборот, нельзя лениво грузить: её стоит подсказать браузеру заранее через <link rel="preload"> и отдавать в первую очередь, иначе LCP уедет вверх.
6. Задавать ширину и высоту. Атрибуты width и height резервируют место под изображение до его загрузки и устраняют сдвиги макета, влияющие на CLS.

Отдельный сценарий — каталоги с десятками тысяч товаров. Здесь вручную оптимизировать картинки нереально, поэтому используют автоматический ресайз на лету через CDN или плагины, которые генерируют WebP/AVIF-версии при загрузке. На создании сайта такой конвейер закладывается в архитектуру сразу, а не добавляется потом заплатками.

Шрифты: невидимый тормоз загрузки

Веб-шрифты редко обсуждают, когда говорят о скорости, но именно они часто держат рендеринг текста. Пока браузер не скачал шрифтовые файлы, он может вообще не показывать текст (FOIT — невидимый текст) или показывать его системным шрифтом, а затем заменять (FOUT). Оба варианта бьют по метрикам: FOIT откладывает LCP, а резкая замена шрифта сдвигает макет и увеличивает CLS.

Практические меры:

• font-display: swap — разрешить браузеру сразу показать текст системным шрифтом и подменить его, когда фирменный шрифт догрузится. Это устраняет невидимый текст и делает загрузку воспринимаемой.
• Формат WOFF2 — самый компактный современный контейнер, сжимает шрифты на 30–40% лучше WOFF. Другие форматы сегодня нужны только для устаревших браузеров.
• Сассетинг (поднаборы) — подключать не весь шрифт с тысячами глифов, а только нужные наборы символов. Для русскоязычного сайта кириллический поднабор может весить вдвое меньше полного файла.
• Минимум начертаний — каждое начертание (regular, bold, italic и их комбинации) — это отдельный файл. Ограничьтесь двумя-тремя реально используемыми, а не всей семьёй «на всякий случай».
• preload для критичного шрифта — файл основного начертания, используемого в первом экране, стоит подсказать браузеру через <link rel="preload" as="font">, чтобы он начал качаться параллельно с остальными ресурсами.
• Локальный хостинг — держать шрифты на своём домене вместо внешнего CDN: это убирает лишнее DNS-соединение и делает загрузку предсказуемой.

JavaScript-бандлы и сторонние сценарии

JavaScript — главный враг INP и вторая по значимости причина медленного LCP. Современные сайты собираются из готовых модулей и плагинов, и в продакшен часто уходит бандл, который на 60–70% состоит из кода, реально не используемого на конкретной странице. Каждый лишний килобайт JS нужно не только скачать, но и распарсить и выполнить — а это нагрузка на главный поток, которая задерживает отклик на действия пользователя.

Ключевые техники:

• Разделение кода (code splitting) — грузить только тот JavaScript, который нужен текущей странице, а не весь бандл сайта. Скрипт галереи не должен скачиваться на странице контактов.
• Tree shaking и минификация — на этапе сборки выкидывать неиспользуемый код и ужимать то, что осталось. Современные сборщики делают это автоматически, если конфигурация корректна.
• defer и async — не блокировать парсинг HTML скриптами. defer сохраняет порядок выполнения, async запускает скрипт сразу после загрузки — выбор зависит от зависимостей скрипта.
• Аудит сторонних скриптов — счётчики аналитики, онлайн-чаты, виджеты обратного звонка, пиксели ретаргетинга. Каждый такой скрипт тянет свои зависимости и свои сетевые запросы. Оставьте только то, что реально приносит заявки, остальное — отключайте или грузите отложенно.
• Разбивка длинных задач — тяжёлые вычисления дробить на части или выносить в Web Worker, чтобы главный поток успевал отвечать на клики.

Ориентир бюджета веса для типовой корпоративной страницы:

Если сайт построен на CMS с десятком активных плагинов, каждый из которых подключает свой JS и CSS, — это почти гарантированный «жёлтый» или «красный» INP. Здесь помогает не точечная правка, а регулярный аудит в рамках технической поддержки сайта: удаление неиспользуемых модулей, консолидация скриптов и контроль веса бандла при каждом обновлении.

Кэширование и серверные ответы

Скорость начинается ещё до того, как браузер получил первый байт. Время до первого байта (TTFB) — это ответ сервера на запрос, и если он превышает 0,8–1 секунду, даже идеально оптимизированный фронтенд не спасёт LCP. Поэтому серверная часть — такой же объект оптимизации, как картинки и скрипты.

Что проверять и настраивать:

• Кэш на стороне сервера. Полностраничное кэширование (page cache) и объектный кэш избавляют сервер от повторной сборки страницы и запросов к базе на каждый визит. Для типовой CMS это самое дешёвое ускорение в разы.
• Заголовки кэширования браузера. Cache-Control с разумным сроком жизни и ETag позволяют повторному посетителю загружать неизменяемые ресурсы (картинки, CSS, JS) из локального кэша без единого запроса к серверу.
• Сжатие ответов. Включите Brotli или gzip для текстовых ресурсов — HTML, CSS, JS, JSON. Это сокращает передаваемый объём на 60–80%.
• CDN. Сеть доставки контента отдаёт статику с серверов, ближайших к пользователю, и снимает нагрузку с основного сервера. Для аудитории, распределённой по регионам, это ощутимый выигрыш по TTFB.
• HTTP/2 и HTTP/3. Современные протоколы мультиплексируют запросы и сокращают задержки установления соединения. Проверьте, что сайт отдаётся по HTTP/2 или HTTP/3 с TLS.
• Свежая версия окружения. Устаревшие версии PHP и тяжёлые шаблоны с неоптимальными запросами к базе — частая скрытая причина медленного TTFB. Иногда ускорение сводится к обновлению стека и профилированию запросов.

Типичная картина «медленного» сайта на аудите: TTFB 1,8 секунды из-за отсутствующего page cache, затем 2,4 МБ картинок без сжатия и бандл на 900 КБ. Исправление только серверного кэша уже сокращает LCP на секунду, а остальное добирается оптимизацией фронтенда. Порядок именно такой: сначала сервер и кэш, потом ресурсы страницы.

Чек-лист оптимизации и типичные ошибки

Соберите работы в последовательность — это убережёт от хаотичных правок, которые меняют одну метрику и ломают другую.

1. Замерьте базовые значения LCP, INP, CLS и TTFB в PageSpeed Insights и Search Console.
2. Настройте серверный кэш, сжатие Brotli/gzip и корректные заголовки Cache-Control.
3. Оптимизируйте изображения: форматы WebP/AVIF, размеры, srcset, ленивую загрузку, preload для LCP-картинки.
4. Приведите в порядок шрифты: WOFF2, кириллический поднабор, font-display: swap, preload основного начертания.
5. Проведите аудит JavaScript: code splitting, удаление неиспользуемых модулей, defer/async, контроль сторонних скриптов.
6. Уберите сдвиги макета: задайте размеры изображениям и вставкам, зарезервируйте место под баннеры.
7. Повторите замеры и зафиксируйте результат; при необходимости итерируйте.

Типичные ошибки, которые мы регулярно видим на аудитах: сжатие картинок без изменения их физических размеров (файл стал легче, но по-прежнему 3000 пикселей шириной); ленивая загрузка LCP-изображения, которая сама по себе ухудшает LCP; оптимизация только десктопной версии при том, что Google оценивает мобильную; удаление важного функционала ради «зелёных» цифр без оглядки на конверсию. Скорость — не самоцель, а средство: страница должна грузиться быстро и при этом продавать.

Если после базовых мер метрики не выходят в зелёную зону, стоит привлечь специалистов для глубокой диагностики — профилирования длинных задач, разбора цепочек запросов и настройки серверного окружения. Цены на такие работы зависят от объёма и состояния проекта; уточнить стоимость можно на странице прайса или связавшись с нами для оценки конкретного сайта.

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

Полезно на сайте: дизайн сайтов, ИТ-аутсорсинг, цены, отзывы клиентов.