Скорость загрузки сайта — одна из тех вещей, которые владелец бизнеса не замечает: у него быстрый интернет, мощный ноутбук и сайт давно в кэше браузера. Клиент открывает ту же страницу с телефона в метро и видит белый экран, прыгающие кнопки и меню, которое не реагирует на нажатие. Он не ждёт — он возвращается в поиск и открывает конкурента.
Ниже разбираем, как скорость связана с заявками, рекламой и позициями, что означают метрики Core Web Vitals, чем проверить скорость сайта и что обычно его тормозит. В конце — порядок работ и чек-лист, по которому можно пройтись вместе с разработчиком.
Почему скорость загрузки сайта влияет на заявки
Заявку оставляет человек, который дождался страницы, разобрался в предложении и дошёл до формы. Медленный сайт мешает на каждом шаге: часть посетителей уходит, не дождавшись первого экрана, часть — когда кнопка не реагирует или форма съезжает под пальцем.
- Посетители уходят. Чем дольше пустой экран, тем больше людей закрывают вкладку. Особенно на мобильном интернете, где задержки заметнее.
- Реклама дорожает. За клик в Директе или Google Ads вы платите, даже если страница не успела открыться. Медленная посадочная страница превращает часть бюджета в отказы. В Google Ads, кроме того, удобство целевой страницы входит в оценку качества объявления.
- Страдает доверие. Сайт, который дёргается и подвисает, воспринимается как неаккуратный, и это переносится на компанию.
Поэтому скорость — это часть конверсии, а не техническая мелочь. Ускорять сайт имеет смысл в первую очередь на страницах, куда ведёт реклама и откуда приходят заявки.
Как скорость связана с позициями в Google и Яндексе
Google прямо называет Core Web Vitals частью сигналов удобства страницы, которые учитывают его системы ранжирования. При этом Google сам подчёркивает: хорошие показатели не гарантируют высоких позиций, а главным остаётся соответствие страницы запросу. Скорость скорее помогает при прочих равных, чем вытаскивает слабую страницу в топ.
Яндекс не публикует, как именно учитывает скорость. Но он учитывает поведение пользователей и удобство сайта, а медленная загрузка ухудшает и то, и другое: больше возвратов в выдачу, меньше просмотренных страниц. Так что ускорение полезно и для Яндекса, хотя честнее говорить о косвенном влиянии.
Быстрый сайт не обгонит конкурента сам по себе, но медленный легко теряет то, что заработали контент и реклама.
Core Web Vitals: LCP, INP и CLS
Core Web Vitals — три метрики, которыми Google описывает, как человек ощущает загрузку страницы. В 2024 году метрика INP заменила прежнюю FID, поэтому в старых материалах можно встретить другой набор.
- LCP (Largest Contentful Paint) — когда на экране появился самый крупный элемент первого экрана: обычно главная картинка, баннер или заголовок. Это ответ на вопрос «когда страница загрузилась».
- INP (Interaction to Next Paint) — как быстро страница реагирует на нажатия, клики и ввод с клавиатуры. Медленный INP — это меню, которое открывается с задержкой, и кнопка, после нажатия на которую ничего не происходит.
- CLS (Cumulative Layout Shift) — насколько элементы прыгают во время загрузки. Типичный пример: человек целится в кнопку, сверху подгружается баннер, и он нажимает не туда.
| Метрика | Хорошо | Нужно улучшить | Плохо |
|---|---|---|---|
| LCP — загрузка главного элемента | до 2,5 с | 2,5–4 с | больше 4 с |
| INP — отклик на действие | до 200 мс | 200–500 мс | больше 500 мс |
| CLS — сдвиг макета | до 0,1 | 0,1–0,25 | больше 0,25 |
Google оценивает метрики по 75-му процентилю: страница считается хорошей, если пороговое значение выдерживают как минимум три посещения из четырёх. Мобильные и десктопные данные оцениваются отдельно, и мобильные почти всегда хуже.
Лабораторные данные и данные реальных пользователей
Скорость измеряют двумя способами, и путать их — частая причина неверных выводов.
Лабораторные данные — это тест одной загрузки в заданных условиях: определённое устройство, скорость сети, без кэша. Их показывают Lighthouse и нижняя часть отчёта PageSpeed Insights. Такой тест воспроизводим и подробно объясняет причины, но описывает одну искусственную ситуацию.
Данные реальных пользователей собираются с настоящих посещений. Главный источник для Google — CrUX (Chrome User Experience Report): статистика из браузера Chrome за последние 28 дней. Она видна в верхней части PageSpeed Insights и в отчёте «Основные интернет-показатели» в Search Console, который группирует похожие страницы. В Яндекс Метрике есть технический отчёт о времени загрузки страниц по вашим посетителям.
Как проверить скорость сайта
Для большинства задач хватает бесплатных инструментов. Каждый отвечает на свой вопрос.
- PageSpeed Insights. Первое, с чего стоит начать: показывает данные CrUX по странице и сайту, лабораторный замер и список рекомендаций. Проверяйте не только главную, но и страницы услуг, каталог и карточки товаров.
- Lighthouse. Тот же движок, встроенный в Chrome (вкладка Lighthouse в инструментах разработчика). Удобен, чтобы проверить страницу до публикации или на тестовом сервере.
- WebPageTest. Подробная проверка из разных городов, браузеров и типов сети. Показывает диаграмму загрузки — какой файл и когда тормозит отрисовку — и видео заполнения экрана.
- Вкладка Network в браузере. Список всех запросов страницы с размером и временем. Здесь быстро видно картинку на несколько мегабайт, десяток шрифтов или скрипт чата, который грузится раньше контента.
Что тормозит сайт и как это лечить
Картинки
Самая частая причина медленного LCP — тяжёлые изображения. Фото из фотобанка весом в несколько мегабайт, баннер шириной 4000 пикселей на телефоне, PNG там, где хватило бы сжатого формата.
- Отдавайте картинки в современных форматах WebP или AVIF: при том же качестве они обычно заметно легче JPEG и PNG.
- Готовьте несколько размеров и указывайте их в srcset, чтобы телефон не скачивал версию для большого монитора.
- Ставьте loading="lazy" для картинок ниже первого экрана, а главное изображение первого экрана, наоборот, загружайте сразу.
- Указывайте ширину и высоту изображений, чтобы браузер заранее зарезервировал место и макет не прыгал.
Так устроены обложки в нашем блоге: если браузер поддерживает WebP, сервер отдаёт их в этом формате, а в карточках через srcset подключены два размера, и телефон берёт лёгкую версию.
Шрифты
Пока шрифт не загрузился, браузер может вообще не показывать текст. Помогает font-display: swap — текст сразу появляется системным шрифтом и подменяется, когда фирменный готов. Основное начертание стоит предзагрузить через preload, лишние начертания убрать, а из шрифта оставить только нужные символы: кириллицу, латиницу, цифры. Такое подмножество весит в разы меньше полного файла.
Сторонние скрипты
Онлайн-чат, виджет обратного звонка, квиз, несколько счётчиков, пиксели рекламных систем, карта — каждый из них по отдельности кажется лёгким, а вместе они занимают процессор телефона и портят INP. Проведите ревизию: что из этого реально используется и приносит заявки. Оставшееся подключайте отложенно — после загрузки основного контента или по первому действию пользователя.
Тяжёлые библиотеки и анимации
Большие JavaScript-библиотеки ради одного слайдера, анимации на каждом блоке, видео на фоне первого экрана. Всё это нужно скачать и выполнить, прежде чем страница станет отзывчивой. Анимации стоит строить на свойствах transform и opacity, которые браузер обрабатывает дёшево, а код разбивать на части и загружать только там, где он нужен.
Хостинг и TTFB
TTFB — время до первого байта ответа сервера. Пока сервер думает, браузеру нечего показывать, и никакая оптимизация картинок это не компенсирует. Ориентир Google — до 0,8 секунды. Причины медленного TTFB: перегруженный дешёвый хостинг, тяжёлые запросы к базе данных, отсутствие кэша страниц, сервер далеко от посетителей.
Кэширование, CDN и сжатие
Статические файлы — картинки, стили, скрипты, шрифты — должны кэшироваться в браузере надолго, чтобы при повторном визите не скачиваться заново. CDN раздаёт их с серверов ближе к пользователю. Текстовые файлы сервер должен сжимать через gzip или Brotli: это включается в настройках и почти бесплатно уменьшает объём передаваемых данных. Для сайтов, где страницы меняются редко, хорошо работает статическая генерация: готовый HTML отдаётся сразу, без расчётов на сервере.
Оптимизация скорости сайта: порядок работ
Ускорение даёт результат, когда идёт от измерения к причине, а не от списка советов из интернета.
- Выбрать ключевые страницы. Главная, посадочные страницы рекламы, услуги, каталог, карточка товара — те, откуда приходят заявки и деньги.
- Снять исходные данные. Данные реальных пользователей из PageSpeed Insights и Search Console плюс лабораторный замер. Записать значения, чтобы потом было с чем сравнить.
- Найти причины. Для каждой плохой метрики определить, что её портит: какой элемент отвечает за LCP, какой скрипт блокирует отклик, что сдвигает макет.
- Исправить самое дешёвое и заметное. Обычно это картинки, лишние сторонние скрипты, шрифты, сжатие и кэширование.
- Взяться за сервер и код. Хостинг, кэш страниц, тяжёлые библиотеки, рендер. Это дороже, поэтому сначала стоит убедиться, что быстрые меры исчерпаны.
- Проверить результат и закрепить. Данные CrUX обновляются за 28 дней, поэтому эффект в отчётах виден не сразу. Дальше — проверка скорости после каждого обновления.
Главное правило — сначала измерить, потом исправлять, потом снова измерить. Иначе легко потратить неделю на то, что не влияло на скорость.
Когда мы делаем сайты, скорость закладываем в проект с начала: формат и размеры изображений, шрифты, отложенную загрузку виджетов, серверный рендер. Примеры наших сайтов — в разделе проектов.
Чек-лист: как ускорить сайт
- Core Web Vitals проверены на ключевых страницах по данным реальных пользователей, отдельно для мобильных.
- Картинки отдаются в WebP или AVIF, в нескольких размерах через srcset.
- Изображения ниже первого экрана загружаются лениво, главное изображение — сразу.
- У картинок, баннеров и встроенных блоков заданы размеры, макет не прыгает.
- Для шрифтов указан font-display, основное начертание предзагружается, лишние символы и начертания убраны.
- Проведена ревизия чатов, виджетов, счётчиков и пикселей, оставшиеся подключаются отложенно.
- Нет тяжёлых библиотек ради одной функции, анимации не нагружают процессор.
- Время ответа сервера (TTFB) в пределах нормы, включён кэш страниц.
- Статические файлы кэшируются в браузере, при необходимости подключён CDN.
- Включено сжатие gzip или Brotli.
- Скорость проверяется после каждого обновления сайта и нового виджета.
Частые вопросы
Какая скорость загрузки сайта считается нормальной?
Ориентир — пороги Core Web Vitals от Google: главный элемент страницы появляется не позже чем за 2,5 секунды, отклик на действие занимает не больше 200 миллисекунд, а сдвиг макета не превышает 0,1. Оценивать нужно по данным реальных пользователей, причём хорошими должны быть не только средние значения, но и показатели у 75% посещений, включая мобильные.
Почему PageSpeed Insights показывает разные оценки при каждой проверке?
Лабораторный тест каждый раз загружает страницу заново, а скорость сети, нагрузка на сервер и сторонние скрипты меняются от запуска к запуску. Поэтому оценка плавает на несколько пунктов. Сравнивайте медиану нескольких запусков и смотрите на блок с данными реальных пользователей, он стабильнее.
Влияет ли скорость сайта на позиции в Яндексе?
Яндекс не публикует подробности о том, как учитывает скорость. Зато медленный сайт ухудшает поведение посетителей: люди чаще уходят, смотрят меньше страниц и реже оставляют заявки, а поведенческие сигналы и удобство для пользователя Яндекс учитывает. Поэтому ускорение полезно и для этого поисковика, но чудес в позициях от него одного ждать не стоит.
Можно ли ускорить сайт на конструкторе или готовой CMS?
Частично. Почти везде можно сжать картинки, убрать лишние виджеты и счётчики, включить кэширование и подключить CDN. Но если тормозит сам шаблон или платформа, возможности ограничены: тяжёлый код темы и общий хостинг не всегда удаётся заменить. Тогда стоит оценить, что выгоднее — продолжать оптимизацию или перенести сайт.
Как часто нужно проверять скорость сайта?
После каждого заметного обновления: нового блока на главной, виджета, счётчика, рекламного пикселя. В остальное время достаточно раз в месяц смотреть отчёт по Core Web Vitals в Search Console и данные в PageSpeed Insights для ключевых страниц. Новые проблемы чаще всего появляются вместе с новыми сторонними скриптами.
