Как ускорить загрузку сайта: что тормозит и что чинить первым

Человек нашёл вас в выдаче, нажал на ссылку и три секунды смотрит на белый экран. На четвёртой он возвращается назад и открывает соседний сайт. Вы об этом не узнаете: в отчётах останется сухая строчка про отказ.

Владельцу при этом непонятно, критично всё или терпимо. PageSpeed показывает три десятка баллов из ста и красный список замечаний, подрядчик отвечает «для WordPress нормально», заявки идут, просто мало. По одному числу тут ничего не поймёшь.

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

Скорость ради поисковика и скорость ради заявок

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

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

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

Теперь вторая половина, про которую забывают. Медленный сайт съедает трафик, за который вы уже заплатили. Клик в Директе списывается в момент перехода, дождался человек загрузки или нет. Пять секунд ожидания на мобильном интернете превращают часть оплаченных кликов в убыток.

Получается два разных заказчика у одной работы. Поисковику нужны метрики в нормативе. Бизнесу нужно, чтобы посетитель дожил до кнопки «Оставить заявку». Второе считается по отказам и конверсии — эту связку мы разбирали в материалах про поведенческие факторы и повышение конверсии сайта.

Как измерить: три метрики и понятные пороги

Коротко. Откройте PageSpeed Insights, введите адрес и смотрите на три показателя: LCP, INP, CLS. Пороги Google опубликовал, гадать не нужно.

Набор этих метрик называется Core Web Vitals. Их три, и каждая отвечает за свой тип раздражения посетителя.

LCP (Largest Contentful Paint) — момент, когда на экране отрисовался самый крупный элемент: баннер, фотография товара, заголовок. Проще говоря, когда страница перестала быть белым пятном. Норматив Google — уложиться в 2,5 секунды.

INP (Interaction to Next Paint) — задержка между действием человека и реакцией страницы. Нажали на кнопку меню, а оно раскрылось через полсекунды. Норма — до 200 миллисекунд. Метрика стала обязательной в марте 2024 года и сменила прежнюю FID: та мерила только первое взаимодействие, эта учитывает все.

CLS (Cumulative Layout Shift) — сдвиги вёрстки во время загрузки. Вы целитесь в ссылку, сверху дорисовывается баннер, палец попадает в рекламу. Норма — не выше 0,1.

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

Метрика	Что меряет	Хорошо	Требует улучшения	Плохо
LCP	Отрисовка главного элемента экрана	до 2,5 с	2,5-4,0 с	больше 4,0 с
INP	Отклик на действия посетителя	до 200 мс	200-500 мс	больше 500 мс
CLS	Сдвиги вёрстки при загрузке	до 0,1	0,1-0,25	больше 0,25
TTFB	Время ответа сервера	до 0,8 с	0,8-1,8 с	больше 1,8 с

TTFB в тройку не входит, но на нём стоит весь LCP. Google рекомендует держать ответ сервера в пределах 0,8 секунды и отводить ему примерно 40 процентов бюджета LCP.

Российские инструменты дополняют картину. В Яндекс Вебмастере есть проверка ответа сервера, в Метрике — отчёт «Время загрузки страниц» в группе «Мониторинг». Он разбирает загрузку по этапам: DNS, редиректы, установка соединения, ответ сервера, обработка HTML, время до отрисовки. Узкое место там видно нагляднее, чем в общем балле. Аббревиатуры разложены в глоссарии интернет-маркетинга.

Почему лабораторный балл и реальные данные не сходятся

Коротко. PageSpeed выдаёт два набора цифр: статистику живых пользователей за 28 дней и симуляцию на условном телефоне. Расхождение между ними нормально.

Верхний блок отчёта — полевые данные из Chrome User Experience Report. Анонимная статистика реальных заходов, скользящее окно в 28 дней, обновление ежедневно. Страница должна быть публичной и набрать достаточно посещений, иначе блока просто не будет. У небольшого регионального сайта их часто нет вообще.

Нижний блок — лабораторный прогон Lighthouse: одна загрузка на смоделированном устройстве при фиксированной скорости канала. Отсюда берётся балл от 0 до 100, вокруг которого ломают копья.

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

Шкала оценок тоже опубликована: от 0 до 49 красная зона, от 50 до 89 оранжевая, от 90 до 100 зелёная. Google прямо предупреждает: круглая сотня достигается крайне тяжело.

Отсюда практический вывод. Гонка за идеальным числом в лаборатории обходится дорого: последние десять баллов стоят больше всех предыдущих вместе. Ориентир для бизнеса — зелёная зона у живых пользователей.

С Яндексом сравнение не работает в принципе. Он считает по своим данным и методику не публикует. Зелёный PageSpeed и средняя шкала в Вебмастере спокойно уживаются на одном сайте.

Что реально тормозит сайт малого бизнеса

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

Начнём с картинок: самая частая и самая дешёвая в устранении проблема. Фотограф отдал снимки по 4000 пикселей и три мегабайта, их залили на сайт как есть, в вёрстке они выводятся в блоке шириной 600 пикселей. Браузер послушно скачивает оригинал и уменьшает его уже на телефоне посетителя.

Современные форматы снимают половину вопроса без потери качества. По данным Google, WebP без потерь весит на 26 процентов меньше PNG, с потерями — на 25-34 процента меньше сопоставимого JPEG, а изображения с прозрачностью уменьшаются примерно втрое. WordPress понимает WebP с версии 5.8, AVIF — с версии 6.5, если хостинг поддерживает нужную версию PHP.

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

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

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

Что тормозит	Как понять, что это ваш случай	Что делать
Тяжёлые картинки	Страница весит мегабайты, в отчёте замечание про размер изображений	Обрезать под реальный размер, сжать, перевести в WebP
Сторонние скрипты	Долгий отклик на клики, много запросов к посторонним доменам	Убрать неиспользуемое, остальное грузить с задержкой
Тема и плагины	Десятки CSS и JS файлов на простой странице	Отключить лишнее, объединить, убрать со страниц без нужды
Нет кеша	Одинаково медленно при любом трафике	Страничный кеш, OPcache, объектный кеш
Слабый хостинг	Ответ сервера дольше 0,8 секунды	Сменить тариф или хостинг, подключить CDN
Шрифты	Текст появляется с задержкой или подпрыгивает	Оставить два начертания, положить файлы на свой сервер

Схема объясняет, почему одной работы с картинками часто мало. Если сервер отвечает полторы секунды, остальным этапам остаётся меньше секунды. Первый шаг здесь — замер. Плагин ускорения без замера добавляет сайту ещё один слой кода.

Разница между движками тут меньше, чем принято думать. Тяжёлым бывает и WordPress, и Битрикс: вопрос в том, что на них навешано. Платформы мы сравнивали в разборе WordPress или Битрикс.

Что владелец может проверить сам за полчаса

Коротко. Полчаса и браузер закрывают три вопроса: сколько весят картинки, сколько на странице чужих скриптов и как быстро отвечает сервер.

Разработчик для этого не нужен. Хватит Chrome, доступа в Вебмастер и Метрику плюс готовности посмотреть на неприятные цифры.

• Прогоните главную и две ключевые страницы через PageSpeed Insights в мобильном режиме, выпишите LCP, INP и CLS
• Нажмите F12, откройте вкладку Network, обновите страницу и отсортируйте по колонке Size: сверху окажутся главные виновники
• Там же внизу видно общий вес страницы и число запросов. Больше сотни запросов на простой странице — повод разбираться
• Выпишите все виджеты: чат, карта, коллтрекинг, попапы, счётчики. Напротив каждого отметьте, кто им пользуется
• Проверьте ответ сервера инструментом Яндекс Вебмастера и сравните с порогом 0,8 секунды
• В Метрике зайдите в «Мониторинг» и откройте «Время загрузки страниц»: там видно, на каком этапе теряются секунды
• Откройте сайт с телефона на мобильном интернете. Офисный Wi-Fi врёт

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

Порядок работ: что чинить первым

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

1. Разобраться с картинкамиОбрезать под реальные размеры вёрстки, сжать, перевести в WebP или AVIF. Картинку первого экрана из отложенной загрузки исключить: Google прямо просит не вешать lazy-load на элемент LCP.
2. Провести ревизию виджетовВсё, чем никто не пользуется, снести. Оставшееся подключать после основного содержимого или только там, где оно работает.
3. Включить кешированиеСтраничный кеш отдаёт готовый HTML вместо повторной сборки. OPcache хранит скомпилированный PHP. Объектный кеш экономит обращения к базе. Все три уровня описаны в документации WordPress.
4. Проверить серверЕсли TTFB держится выше 0,8 секунды при небольшом трафике, дело в тарифе или настройках хостинга. CDN снимает часть нагрузки, раздавая статику со своих серверов.
5. Убрать блокирующий кодCSS и JS, которые тормозят первую отрисовку, выносят вниз или подгружают отложенно. Стили первого экрана иногда вставляют прямо в HTML.
6. Привести в порядок шрифтыОставить два начертания, положить файлы на свой сервер, включить показ текста запасным шрифтом на время загрузки.
7. Перемерить через месяцЛабораторный балл меняется сразу, полевые данные подтягиваются в течение 28 дней. Раньше этого срока выводы делать рано.

• Поставить три плагина ускорения сразу и получить конфликт кешей
• Гнаться за сотней баллов в лаборатории, ни разу не заглянув в полевые данные
• Сжать фотографии товаров до каши и потерять доверие покупателя
• Включить отложенную загрузку на картинке первого экрана и ухудшить LCP
• Снести аналитику вместе с виджетами и остаться без данных по заявкам
• Замерить один раз до и один раз после, поверив разнице в пару баллов

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

Наш пример: с 8,4 до 3,0 секунды

Коротко. На собственном сайте мы срезали полное время загрузки главной с 8,4 до 3,0 секунды, а вес страницы с 487 до 148 килобайт. Ниже — за счёт чего.

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

Теперь честная оговорка. Цифры наши, переносить их на чужой сайт нельзя. На тяжёлом визуальном конструкторе потолок будет ниже: часть кода там убрать невозможно без разбора всей вёрстки. Простой сайт, которым никогда не занимались, ускоряется примерно так же.

Из примера стоит взять последовательность действий. Мы не покупали новый хостинг и не переписывали сайт заново. Сначала выкинули лишнее, потом ускорили то, что осталось. Хотите понять, где теряются ваши секунды — оставьте заявку на бесплатный экспресс-аудит.

Когда дешевле собрать сайт заново

Коротко. Если сайт стоит на тяжёлом конструкторе, оброс двумя десятками плагинов и его всё равно пора обновлять, ускорение превращается в бесконечную борьбу с чужим кодом.

У оптимизации чужой сборки есть потолок. Разработчик отключит лишние стили, сожмёт картинки, поставит кеш. Ядро темы, за которое отвечает сторонний автор, он переписывать не станет. Каждый следующий выигрыш в полсекунды стоит дороже предыдущего.

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

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

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