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

Скорость сайта проверяется за 5 мин. бесплатными инструментами, и для этого не нужен разработчик. В статье — пошаговая инструкция проверки, нормы Core Web Vitals на 2026 год и разбор причин, из-за которых сайты тормозят чаще всего.

Каждая лишняя секунда загрузки заметно режет конверсию: по данным исследования Google/Deloitte «Milliseconds Make Millions» (2020), ускорение мобильной версии всего на 0,1 сек. увеличивает конверсию ритейл-сайтов в среднем на 8%. Порог терпения пользователя с тех пор только снизился. При этом владельцы сайтов обычно не знают реальную скорость своего проекта: на их компьютере, с кешем и быстрым офисным интернетом, сайт всегда «летает».

Проверка занимает 5 минут и не требует технических навыков. Разберем, чем мерить, какие цифры считать нормой и что делать с результатами.

Шаг 1. Проверка в PageSpeed Insights

Откройте pagespeed.web.dev, вставьте адрес страницы и нажмите «Анализировать». Через полминуты получите 2 блока данных.

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

Второй — лабораторный тест с оценкой от 0 до 100. Он воспроизводим и удобен для сравнения «до и после», но помните: это эмуляция среднего смартфона на среднем 4G, а не приговор. Гнаться за 100 баллами бессмысленно, важно выйти из красной зоны.

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

На какие цифры в отчете PageSpeed смотреть

В первую очередь на верхний блок с данными реальных пользователей и строку с оценкой Core Web Vitals (в русском интерфейсе — «Основные интернет-показатели»). «Пройдена» означает, что страница укладывается в нормы скорости у большинства посетителей. «Не пройдена» — что хотя бы одна из 3 основных метрик вышла из зеленой зоны, и отчет сразу показывает какая.

Общий балл лабораторного теста вторичен. Он пригодится позже, когда начнете править сайт и захотите сравнить результат до и после. Полезнее то, что лежит под оценками: список рекомендаций, у части которых указана примерная экономия времени или веса. Это почти готовый список задач для разработчика.

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

Шаг 2. Метрики Core Web Vitals и нормы скорости

Google оценивает скорость через Core Web Vitals. Их 3, и у каждой есть четкий порог нормы:

• LCP (Largest Contentful Paint) — через сколько секунд появился самый крупный элемент экрана. Норма: до 2,5 секунды;
• INP (Interaction to Next Paint) — как быстро страница реагирует на клики и ввод. Норма: до 200 миллисекунд;
• CLS (Cumulative Layout Shift) — насколько содержимое «прыгает» при загрузке. Норма: до 0,1.

Пороги официальные, из документации web.dev. Если все 3 метрики зеленые по данным реальных пользователей, у сайта нет проблемы со скоростью, что бы ни показывал лабораторный балл.

Чтобы понять, соответствует ли сайт стандартам времени загрузки, сверьте свои цифры с порогами. У каждой метрики 3 зоны.

Метрика считается пройденной, когда в хорошую зону попадают минимум 75% визитов. Среднее значение здесь ничего не решает. Поэтому сайт может «летать» у вас и при этом не проходить оценку: четверть посетителей с медленным телефоном или слабой связью тянет результат вниз. TTFB в тройку основных метрик не входит, но без быстрого ответа сервера уложиться в норму по LCP почти невозможно.

Шаг 3. Дополнительные проверки

PageSpeed меряет из-за рубежа, поэтому стоит перепроверить скорость из России. Вариант без сервисов: откройте сайт в Chrome в режиме инкогнито, нажмите F12, вкладка «Сеть», включите троттлинг «Fast 4G» и обновите страницу. Внизу увидите время полной загрузки и вес страницы. Вес больше 3–4 МБ — почти всегда признак несжатых картинок.

В Яндекс Метрике есть отчет «Стандартные отчеты → Мониторинг → Время загрузки страниц»: он покажет, какие разделы сайта медленнее остальных именно у вашей аудитории.

И проверьте время ответа сервера в том же отчете PageSpeed (пункт «Reduce initial server response time»). Если сервер отвечает дольше 600 миллисекунд, оптимизировать картинки бесполезно, пока не решена проблема хостинга или бэкенда.

Почему сайты тормозят: 5 типовых причин

За годы верстки и аудитов я видел десятки медленных сайтов, и причины повторяются с удручающей стабильностью. Скорость — одна из проверок в полном SEO-аудите сайта, но всплывает она почти всегда первой.

Тяжелые изображения. Лидер списка. Фото 4000 px в блоке 400 px, PNG вместо WebP, отсутствие ленивой загрузки. Лечится конвертацией в WebP/AVIF, генерацией размеров под экраны и атрибутом loading="lazy" для картинок ниже первого экрана. Часто одно это снимает половину веса страницы.

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

Скрипты сторонних сервисов. Чаты, квизы, пиксели, карты, виджеты отзывов. Каждый по отдельности «легкий», вместе они съедают секунды. Ревизия раз в полгода обязательна: половина этих скриптов обычно уже не используется, а грузится.

Неоптимальная загрузка шрифтов и стилей. 5 начертаний шрифта, блокирующие CSS и JS в шапке. Пользователь смотрит на белый экран, пока все это качается.

Прыгающая верстка. Формально не скорость, но портит CLS: баннеры и картинки без заданных размеров сдвигают контент, человек промахивается по кнопкам. Лечится указанием размеров для всех медиа-элементов.

Как ускорить сайт: с чего начать

Ускорение сайта начинают с самого затратного по времени узкого места, и почти всегда оно одно. Порядок работ такой: сервер, затем картинки, затем сторонние скрипты, шрифты со стилями и в конце стабильность верстки. Менять последовательность невыгодно: если страница 2 сек. ждет ответа сервера, сжатые картинки дадут прирост, которого никто не заметит.

Сервер и кеш. Цель: время ответа в пределах 0,8 сек., а для страниц из кеша в разы меньше. Включите кеширование страниц в CMS, проверьте версию PHP и сжатие ответа сервера. Для сайтов на 1С-Битрикс причины и настройки разобраны отдельно: почему тормозит сайт на Битриксе.

Изображения. Отдавайте картинку того размера, в котором она показывается, в современном формате и с заданными шириной и высотой. Для всего, что ниже первого экрана, включайте ленивую загрузку. Главной картинке первого экрана, наоборот, поднимают приоритет: обычно именно по ней и считается LCP.

<!-- главная картинка первого экрана: грузим сразу и с приоритетом -->
<img src="/img/hero-1200.webp"
     srcset="/img/hero-600.webp 600w, /img/hero-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw, 1200px"
     width="1200" height="600" alt="Каталог продукции"
     fetchpriority="high">

<!-- картинки ниже первого экрана: ленивая загрузка -->
<img src="/img/card-400.webp" width="400" height="300"
     alt="Карточка товара" loading="lazy">

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

Шрифты и стили. Оставьте 2–3 начертания, которые реально используются, храните файлы шрифтов у себя и разрешите браузеру показывать текст до их загрузки. Стили для первого экрана должны приходить первыми, остальное можно догрузить позже.

<!-- свой скрипт не блокирует отрисовку -->
<script src="/js/app.js" defer></script>

<!-- шрифт: текст виден сразу, начертание подменится после загрузки -->
<link rel="preload" href="/fonts/manrope.woff2" as="font"
      type="font/woff2" crossorigin>
<style>
  @font-face {
    font-family: "Manrope";
    src: url("/fonts/manrope.woff2") format("woff2");
    font-display: swap;
  }
</style>

Стабильность верстки. Размеры для картинок, видео и баннеров, зарезервированное место под блоки, которые подгружаются позже. Самая дешевая правка из списка, и именно она чинит CLS.

После каждого шага перемеряйте страницу лабораторным тестом: так видно, что дала конкретная правка. Данные реальных пользователей обновляются медленнее, это скользящее окно в 28 дней, поэтому зеленая оценка Core Web Vitals появится в отчете только через несколько недель после работ.

Мы в Design Lab идем в том же порядке и первым делом фиксируем цифры «до»: без них не показать, что оптимизация что-то дала.

Что из этого делать самостоятельно

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

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