Скорость загрузки сайта: как 3 секунды убивают конверсию и позиции

Core Web Vitals: три метрики, на которые смотреть в первую очередь

Core Web Vitals — набор показателей, которые измеряют скорость и удобство страницы с точки зрения реального пользователя. Их придумала Google, но PageSpeed Insights, которым пользуются для диагностики, опирается именно на них. Яндекс при ранжировании смотрит на свои поведенческие сигналы, но плохие Core Web Vitals почти всегда означают плохое поведение пользователей и там, и там.

LCP — когда загружается главный контент

LCP (Largest Contentful Paint) — время, за которое на экране появляется самый крупный видимый элемент: как правило, это заголовок, обложка или главный блок с оффером. По шкале PageSpeed Insights хорошим считается LCP до 2,5 секунды; от 2,5 до 4 секунд — нужно улучшить; выше 4 секунд — плохо.

Именно этот показатель больше всего ощущает пользователь как «страница тормозит». Если LCP высокий, человек видит пустой или частично загруженный экран и ждёт. Многие не ждут.

CLS — прыгает ли контент при загрузке

CLS (Cumulative Layout Shift) — суммарный сдвиг контента во время загрузки. Когда картинка без указанного размера вдруг появляется и «толкает» текст вниз, или баннер загружается и смещает кнопку в момент нажатия — это CLS. Хорошим считается значение до 0,1; от 0,1 до 0,25 — нужно улучшить; выше 0,25 — плохо.

Высокий CLS раздражает: человек тянется к кнопке, а она уезжает. Это прямо влияет на конверсию форм и кнопок в верхней части страницы.

INP — как быстро страница реагирует на действия

INP (Interaction to Next Paint) — время от клика или нажатия до видимой реакции страницы. Хорошим считается значение до 200 миллисекунд; от 200 до 500 — нужно улучшить; выше 500 — плохо.

Высокий INP означает «подвисший» интерфейс: меню раскрывается с задержкой, фильтры в каталоге не реагируют сразу, форма «думает» после нажатия кнопки «Отправить». Обычно виноват тяжёлый JavaScript, загруженный на странице.

Как измерить скорость своего сайта

Google PageSpeed Insights

Бесплатный инструмент на pagespeed.web.dev. Введите адрес любой страницы, и получите оценку по мобильной и десктопной версии, значения Core Web Vitals и конкретный список проблем с объяснениями. Начните с мобильной оценки: она обычно ниже и важнее, потому что большинство поисковых запросов в России приходит с телефона.

Важная деталь: PageSpeed показывает два типа данных. «Полевые данные» — реальные измерения с устройств настоящих пользователей за последние 28 дней (если их достаточно). «Лабораторные данные» — симулированный тест прямо сейчас. Если на сайте мало трафика, полевых данных может не быть. Ориентируйтесь тогда на лабораторные, но учитывайте, что они не всегда совпадают с реальным пользовательским опытом.

Яндекс.Метрика

В разделе «Мониторинг» есть отчёт «Скорость загрузки сайта»: он показывает среднее время загрузки страниц в разбивке по типу устройства, браузеру и географии. Это реальные данные ваших посетителей, а не симуляция. Если мобильный показатель сильно хуже десктопного — проблема именно там и туда нужно смотреть в первую очередь.

Метрика также показывает показатель отказов в разрезе времени загрузки: можно увидеть, растёт ли доля уходящих пользователей по мере роста времени загрузки. Это помогает оценить, насколько скорость конкретно мешает вашему сайту.

WebPageTest

Инструмент webpagetest.org даёт более детальный разрез: «водопад» загрузки с разбивкой на каждый файл, время ответа сервера, блокирующие ресурсы. Полезен, когда PageSpeed указал на проблему, но непонятно, из-за какого именно файла. Можно проверить загрузку с разных регионов и на разных скоростях соединения.

Как читать отчёт PageSpeed Insights: на что смотреть кроме балла

PageSpeed даёт оценку от 0 до 100, и большинство владельцев сайтов смотрят именно на неё. Но сам балл — наименее полезная часть отчёта. Это агрегированная цифра, которая может скрывать совершенно разные ситуации: 75 баллов с LCP в 3,8 секунды и 75 баллов с быстрым LCP, но высоким CLS — это принципиально разные проблемы с разными решениями.

Отчёт PageSpeed устроен так. Верхняя часть — метрики Core Web Vitals и TTFB, рядом с каждой цветовой индикатор: зелёный, жёлтый или красный. Если есть полевые данные (реальный трафик за 28 дней), они стоят первыми. Если данных мало — показываются только лабораторные: симуляция нагрузки прямо сейчас.

Ниже — раздел «Возможности»: конкретные изменения, которые PageSpeed считает наиболее эффективными. Каждая возможность показывает потенциальную экономию времени. Это не гарантия, а оценка — но она помогает расставить приоритеты. Начинайте с пункта с наибольшей потенциальной экономией.

Ещё ниже — «Диагностика»: менее критичные проблемы. И наконец «Пройденные проверки» — список того, что на сайте уже сделано правильно. Этот раздел полезен, чтобы понять, о чём можно не беспокоиться.

Отдельный важный элемент отчёта: PageSpeed явно указывает, какой элемент страницы является LCP. Это может быть главная фотография, заголовок или баннер с оффером. Знать, что именно тормозит первую отрисовку, — значит понимать, с чего начинать разработчику. Вместо расплывчатого «сайт медленный» получается конкретная задача: «LCP-элемент — изображение весом 2,4 МБ в шапке, нужно сжать до 150 КБ и указать атрибуты размера».

И последнее: запускайте тест несколько раз, особенно для лабораторных данных. Результаты могут колебаться из-за временной нагрузки на сервер или сеть. Три-четыре прогона подряд дадут более точную картину, чем один.

Мобильная версия: почему балл там ниже и что с этим делать

Мобильная оценка в PageSpeed почти всегда ниже десктопной — иногда на двадцать-тридцать баллов. Это нормально: симуляция мобильного устройства использует более медленный виртуальный процессор и соединение с ограниченной пропускной способностью, чтобы воспроизвести условия среднего смартфона. Но проблема не только в симуляции.

Реальные мобильные пользователи часто находятся в зонах с нестабильным сигналом, используют смартфоны двух-трёхлетней давности и держат в фоне много приложений. Тот же JavaScript, который на десктопе отрабатывает за треть секунды, на телефоне занимает полторы. То же изображение скачивается по мобильному интернету заметно дольше, чем по домашнему Wi-Fi.

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

Что делать специально для мобильных

• Используйте разные размеры изображений для разных экранов. Атрибуты srcset и sizes позволяют браузеру загрузить версию, подходящую для ширины экрана, а не полноразмерный файл на весь десктоп. Смартфон с шириной 390 пикселей не должен скачивать изображение, оптимизированное под экран 1920 пикселей.
• Проверьте метатег viewport. Без строки <meta name="viewport" content="width=device-width, initial-scale=1"> мобильный браузер рендерит страницу как десктопную и масштабирует её, что ломает и отображение, и скорость.
• Избегайте тяжёлых визуальных эффектов на первом экране мобильной версии. Параллакс, анимированные фоны, видео-заставки — всё это создаёт нагрузку там, где нужна максимальная скорость.
• Проверьте, не грузятся ли мобильным пользователям десктопные скрипты. Некоторые интерфейсные библиотеки подгружаются целиком, хотя на мобильных нужна лишь малая их часть.

Самый простой практический тест: откройте сайт на реальном смартфоне с выключённым Wi-Fi (только мобильный интернет) и засеките, за сколько секунд вы сможете нажать кнопку заказа или заполнить форму. Этот эксперимент без инструментов часто открывает глаза лучше любого отчёта.

Что тормозит сайт: шесть главных причин

1. Тяжёлые изображения

Самая частая причина медленного LCP. Типичная ситуация: фотограф прислал снимок весом 4 МБ, его загрузили прямо на сайт и вставили в баннер. Браузер вынужден скачать весь файл перед тем, как показать страницу.

Вторая проблема — формат. JPEG и PNG уступают современным форматам: WebP при сопоставимом качестве весит заметно меньше, AVIF ещё легче, хотя поддерживается не всеми браузерами. Большинство современных движков сайтов умеют конвертировать и отдавать изображения в WebP автоматически.

2. Избыточный JavaScript

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

Особенно заметно на мобильных: процессор телефона слабее компьютерного, и то, что на десктопе занимает полсекунды, на телефоне растягивается в два-три раза. Отсюда разрыв между мобильной и десктопной оценкой в PageSpeed.

3. Медленный хостинг и высокий TTFB

TTFB (Time to First Byte) — время от запроса до первого байта ответа сервера. Это база: если сервер думает секунду, прежде чем начать отвечать, всё остальное сдвигается на секунду. PageSpeed отдельно показывает этот показатель и считает хорошим значение до 800 миллисекунд.

Медленный TTFB почти всегда означает либо перегруженный хостинг, либо плохо настроенную CMS с тяжёлыми запросами к базе данных, либо физически далёкий от пользователей сервер. Дешёвый хостинг на одном сервере с сотнями других сайтов — частый виновник.

4. Отсутствие кэширования

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

То же касается серверного кэша: CMS генерирует HTML страниц на лету, делая запросы к базе данных. Кэш на сервере сохраняет готовый HTML и отдаёт его без повторной генерации. Для сайтов на WordPress, «Битриксе» и других CMS это один из самых быстрых способов снизить нагрузку на сервер и ускорить ответ.

5. Блокирующие ресурсы: CSS и скрипты в неправильном месте

Браузер строит страницу последовательно. Если он встречает скрипт в начале документа, то останавливается, загружает и исполняет его, а только потом продолжает рисовать страницу. Скрипты, которые не нужны при первой отрисовке, должны грузиться отложено.

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

6. Внешние шрифты и сторонние ресурсы

Подключение шрифтов через внешний сервис добавляет дополнительный DNS-запрос и сетевой round-trip к чужому серверу. Если сервис медленно отвечает или временно недоступен, загрузка вашего сайта подвисает вместе с ним.

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

Как исправить: практические шаги

Изображения: сжать, конвертировать, отложить

• Сжимайте изображения до загрузки на сайт. Бесплатные инструменты: Squoosh (squoosh.app), TinyPNG. Правило: фотография на странице редко должна весить больше 150–200 КБ.
• Укажите атрибуты width и height для каждого изображения. Без них браузер не знает, сколько места зарезервировать, и страница «прыгает» при загрузке: это поднимает CLS.
• Используйте атрибут loading=«lazy» для изображений, которых нет в первом экране. Браузер загрузит их только тогда, когда пользователь долистает до них.
• Главное изображение на первом экране (то, что определяет LCP) отмечайте атрибутом loading=«eager» или fetchpriority=«high»: оно должно загружаться в первую очередь, без откладывания.

JavaScript: убрать лишнее и отложить остальное

• Проведите аудит скриптов: откройте DevTools в браузере, вкладку Network, отфильтруйте JS. Найдите скрипты, которые вы не узнаёте или которые больше не нужны (старые виджеты, отключённые сервисы).
• Добавьте атрибуты defer или async к скриптам, которые не влияют на первую отрисовку. Defer гарантирует порядок выполнения, async загружает скрипты параллельно без порядка.
• Если вы используете Google Tag Manager или другой менеджер тегов, проверьте, какие теги в нём активны: они часто накапливают мусор из старых кампаний.

Хостинг: выбрать подходящий и настроить

• Если TTFB постоянно выше 1–1,5 секунды, проблема в хостинге. Сравните предложения: виртуальный хостинг с SSD-дисками быстрее обычного, VPS даёт больше контроля над настройками.
• Выбирайте серверы в России или хотя бы в Европе: физическое расстояние влияет на задержку. Сервер в США добавит 100–150 мс к каждому запросу для российских пользователей.
• Для сайтов с большой аудиторией в разных регионах рассмотрите CDN (сеть доставки контента). CDN хранит копии статических файлов (картинки, стили, скрипты) на серверах рядом с пользователями и отдаёт их без обращения к основному серверу.

Кэширование: включить и настроить

• Для сайтов на WordPress самый простой шаг — установить плагин кэширования. WP Super Cache, W3 Total Cache и LiteSpeed Cache работают без ручной конфигурации по умолчанию.
• Убедитесь, что в ответах сервера стоят правильные заголовки Cache-Control для статических файлов: изображения, CSS и JS редко меняются и могут кэшироваться на месяц и дольше.
• Включите сжатие GZIP или Brotli на сервере: текстовые файлы (HTML, CSS, JS) при сжатии уменьшаются в несколько раз. Эта настройка делается в панели хостинга или файле конфигурации.

Шрифты: перевезти к себе

• Скачайте шрифты и разместите их на своём сервере вместо подключения через Google Fonts или другой внешний сервис. Это убирает лишний DNS-запрос и зависимость от стороннего сервера.
• Добавьте preconnect к доменам шрифтов, если по-прежнему используете внешний источник: браузер заранее установит соединение и сократит задержку.
• Используйте font-display: swap в CSS: пока шрифт грузится, браузер покажет системный шрифт, а не пустой текст. Это улучшает и LCP, и пользовательский опыт.

Оптимизация на распространённых платформах

Рычаги ускорения зависят от того, на чём сделан сайт. Подходы отличаются значительно.

WordPress

WordPress управляет большинством малых бизнес-сайтов в России, и «из коробки» он медленный: каждая страница генерируется динамически, с запросами к базе данных. Именно поэтому WordPress-сайты чаще других получают низкие оценки в PageSpeed.

Хорошая новость: экосистема плагинов закрывает большинство проблем без знания кода. Плохая: те же плагины при неосторожном использовании сами становятся источником торможения.

• Плагин кэширования — первый шаг. WP Super Cache, W3 Total Cache или LiteSpeed Cache генерируют статические HTML-файлы вместо динамических запросов к базе данных. TTFB падает заметно: там, где было 1,5–2 секунды, становится 200–400 мс.
• Плагин оптимизации изображений (Imagify, ShortPixel, Smush) автоматически сжимает и конвертирует в WebP при загрузке. Подключить один раз — и новые изображения будут оптимизированными без ручной работы.
• Ограничьте количество плагинов. Сорок плагинов — не редкость для запущенного сайта. Каждый добавляет скрипты, запросы к базе данных и точки отказа. Деактивируйте и удалите то, чем не пользуетесь.
• Выбор темы имеет значение. Некоторые популярные темы несут несколько фреймворков и библиотек, которые вам не нужны. Тема с обилием «опций» почти всегда медленнее минималистичной.

Тильда

Тильда — конструктор с ограниченным контролем над техникой. Здесь меньше рычагов, и большинство из них связаны с контентом, а не с кодом.

• Сжимайте изображения перед загрузкой. Тильда принимает то, что вы загружаете, без автоматической оптимизации. Squoosh или TinyPNG до загрузки — обязательный шаг.
• Убирайте тяжёлые блоки, которые не работают на конверсию. Видеофон, параллакс, анимированные счётчики — это нагрузка. Если блок красивый, но не приносит заявок, подумайте: а нужен ли он.
• Проверяйте HTML-вставки. Виджеты онлайн-консультантов, формы из сторонних сервисов, коды отслеживания — всё, что добавлено через HTML-вставку, загружается дополнительно к основному коду страницы.
• Используйте настройки изображений в блоках. Тильда позволяет задать параметры отображения прямо в редакторе блока. Это не заменяет предварительного сжатия, но помогает при небольших правках.

Кастомный сайт или корпоративная CMS

Здесь максимум возможностей, но без разработчика почти ничего не сделать. Зато и результаты оптимизации обычно значительнее.

• CDN для статики — Cloudflare в бесплатном тарифе покрывает базовые задачи: кэш статических файлов на серверах рядом с пользователями, защита от перегрузок, HTTPS. Подключается за час.
• Минификация CSS и JS — удаление пробелов, переносов и комментариев из кода без изменения функционала. Файлы уменьшаются в размере и скачиваются быстрее.
• HTTP/2 или HTTP/3 — современные протоколы загружают несколько файлов одновременно, а не последовательно. Большинство хостингов поддерживают HTTP/2, нужно только включить.
• Lazy loading на уровне кода — браузер загружает изображения ниже первого экрана только когда пользователь прокручивает к ним. На страницах с длинным контентом или большим каталогом это значительно снижает объём данных при первой загрузке.

Как отслеживать динамику и не потерять прогресс

Ускорение сайта — не разовая задача. Новый плагин, обновление темы, добавление видео на главную или подключение нового виджета аналитики могут откатить результат за несколько минут. Без периодического контроля улучшения постепенно сходят на нет.

• Сохраняйте скриншот отчёта PageSpeed до и после каждого изменения. Это история, по которой потом можно понять, что именно помогло и когда показатели начали падать. Текстовый файл с датой и баллами тоже подойдёт.
• Настройте уведомление в Яндекс.Метрике о росте показателя отказов. Резкое увеличение отказов на конкретной странице часто означает проблему со скоростью после изменений. Метрика позволяет настроить оповещение по email при превышении порогового значения.
• Проверяйте PageSpeed после каждого крупного обновления. Смена дизайна, запуск нового раздела, подключение чата или системы бронирования — каждое из этих событий может изменить картину. Проверка занимает пять минут.
• Раз в квартал делайте плановый аудит. Просматривайте ключевые страницы: главную, страницу услуг, посадочные под рекламу. Сравнивайте с предыдущими результатами. Даже если ничего не меняли — хостинг мог деградировать, а ожидания пользователей выросли.

Дополнительный ресурс: в Яндекс.Вебмастере в разделе «Качество сайта» есть информация об ошибках и проблемах на страницах. Это не замена PageSpeed, но дополнительная точка зрения от самого Яндекса на техническое состояние вашего сайта. Имеет смысл заглядывать туда раз в месяц.

Что исправить без разработчика

Часть задач по ускорению решается силами самого владельца бизнеса или контент-менеджера, без кода и специальных знаний.

• Сжать изображения перед загрузкой. Откройте Squoosh или TinyPNG, загрузите картинку, сохраните сжатую версию и замените на сайте. Это не требует доступа к коду.
• Убрать ненужные виджеты и плагины. Если на сайте висит виджет онлайн-чата, которым никто не пользуется, или счётчик статистики от сервиса, с которым вы расстались два года назад, удалите их через административную панель.
• Проверить активные теги в менеджере тегов. Войдите в Google Tag Manager или аналогичный сервис и пройдитесь по списку. Теги старых рекламных кампаний, A/B-тестов и аналитики, которые уже не нужны, стоит отключить.
• Установить плагин кэширования. Для WordPress это делается в разделе «Плагины» без знания кода. Базовые настройки работают сразу после установки.

Остальное — оптимизация кода, настройка сервера, перевод шрифтов — требует участия разработчика или системного администратора. Но сформулировать задачу теперь можно конкретно: не «сайт тормозит», а «LCP на мобильных 5,2 секунды из-за главного изображения весом 3 МБ, нужно сжать и указать размеры».

Чеклист: быстрая проверка скорости

Пройдитесь по списку и отметьте, что уже сделано, а что нет. Каждый невыполненный пункт — потенциальный источник торможения.

Измерение

• Открывал PageSpeed Insights для главной страницы и ключевых посадочных
• Смотрел мобильную оценку отдельно (она часто хуже десктопной)
• Проверил LCP, CLS и INP в отчёте PageSpeed
• Заглянул в «Скорость загрузки» в Яндекс.Метрике

Изображения

• Изображения сжаты перед загрузкой на сайт
• Формат WebP используется вместо JPEG/PNG там, где это возможно
• Атрибуты width и height указаны у всех изображений
• Изображения ниже первого экрана имеют loading=«lazy»

Скрипты и ресурсы

• Ненужные плагины и виджеты удалены
• Активные теги в менеджере тегов проверены и актуальны
• Шрифты либо размещены на своём сервере, либо подключены с preconnect

Сервер и кэш

• TTFB меньше 800 мс (проверяется в PageSpeed или WebPageTest)
• Кэширование включено (плагин или настройки сервера)
• Сжатие GZIP или Brotli включено на сервере
• Сервер физически находится в России или Европе