Скорость сайта — это не одна цифра, а цепочка: браузер находит сервер через DNS, устанавливает защищённое соединение, получает HTML, затем загружает стили, скрипты, шрифты и картинки, и только после этого пользователь видит готовую страницу. Тормозить может любое звено. Хорошая новость: в большинстве случаев виноваты две-три типичные проблемы, и их можно исправить без переписывания сайта.
Шаг 1. Измерьте, прежде чем что-то менять
Без замера невозможно понять, что именно замедляет страницу и помогли ли изменения. Начните с проверки скорости сайта: инструмент покажет время загрузки, вес страницы, количество запросов и метрики Core Web Vitals.
Различайте два вида данных:
- Лабораторные — один синтетический замер в контролируемых условиях. Удобны для отладки: видно, какой файл грузится дольше всего.
- Полевые — статистика реальных пользователей Chrome (отчёт CrUX), её показывают PageSpeed Insights и Google Search Console. Именно они учитываются в поиске.
Проверяйте не только главную, но и типовые страницы: карточку товара, категорию, статью блога. И обязательно мобильную версию — в России и СНГ большая часть трафика приходит со смартфонов, часто по мобильной сети.
Подробно про пороги метрик читайте в гайде Core Web Vitals: LCP, INP и CLS.
Шаг 2. Изображения — главный резерв
На типичном сайте картинки составляют больше половины веса страницы. Частая ситуация: фотограф прислал снимок 6000×4000 пикселей весом 8 МБ, и его поставили в слайдер на главной.
Что делать:
- Уменьшите размеры до реально отображаемых. Если блок на экране шириной 800 px, файл шириной 4000 px — лишние мегабайты.
- Сожмите. Сжатие изображений с качеством 75–85 % обычно уменьшает JPEG в 2–5 раз без видимой разницы.
- Перейдите на современные форматы. WebP в среднем легче JPEG на 25–35 %, AVIF — ещё легче. Конвертировать можно в конвертере WebP.
- Включите ленивую загрузку для картинок ниже первого экрана:
loading="lazy". Но не для главного баннера — его, наоборот, нужно грузить как можно раньше. - Указывайте width и height, чтобы браузер заранее резервировал место и макет не «прыгал».
<img src="/img/sofa-800.webp" width="800" height="533"
alt="Угловой диван серого цвета" loading="lazy">Больше деталей — в гайде Оптимизация изображений для сайта.
Шаг 3. Кэширование
Кэширование позволяет не загружать одно и то же повторно.
- Кэш браузера. Для статики (CSS, JS, шрифты, картинки) задайте долгий срок хранения через заголовок
Cache-Control. Если в имени файла есть хеш версии, можно ставить год:
Cache-Control: public, max-age=31536000, immutable- Серверный кэш страниц. Для WordPress, Bitrix и других CMS используйте плагины или модули кэширования: страница собирается один раз, а затем отдаётся готовой.
- Кэш объектов (Redis, Memcached) ускоряет тяжёлые запросы к базе данных в интернет-магазинах.
Шаг 4. JavaScript и CSS
Скрипты — главный враг отзывчивости. Пока браузер выполняет тяжёлый JavaScript, он не реагирует на нажатия, и страдает метрика INP.
- Удалите неиспользуемое: старые слайдеры, виджеты, которые давно не работают, дублирующиеся библиотеки.
- Подключайте скрипты с атрибутом
defer, чтобы они не блокировали отрисовку. - Сторонние сервисы (онлайн-чаты, виджеты обратного звонка, пиксели) загружайте отложенно — после взаимодействия или через несколько секунд.
- Минифицируйте CSS и JS и включите сжатие Brotli или gzip на сервере.
- Критичные стили для первого экрана можно встроить прямо в HTML.
Каждый счётчик аналитики и рекламный пиксель добавляет запросы. Проверьте, все ли из них действительно нужны.
Шаг 5. Шрифты
Веб-шрифты часто задерживают показ текста. Правила простые: используйте формат WOFF2, подключайте только нужные начертания и наборы символов (для русскоязычного сайта — кириллицу и латиницу, без лишних алфавитов), добавьте font-display: swap и предзагрузку основного шрифта.
Шаг 6. Хостинг, сервер и CDN
Если время ответа сервера (TTFB) стабильно больше 0,8 секунды, никакая оптимизация фронтенда не спасёт.
| Признак | Вероятная причина | Что делать |
|---|---|---|
| TTFB > 0,8 с на всех страницах | Слабый тариф, перегруженный сервер | Сменить тариф или хостинг, включить кэш страниц |
| Медленно только в корзине и поиске | Тяжёлые запросы к БД | Индексы в базе, кэш объектов |
| Быстро в Москве, медленно в регионах | Далёкий сервер | CDN или сервер ближе к аудитории |
| Старая версия PHP | Медленное выполнение кода | Обновить PHP до поддерживаемой версии |
Для аудитории в России и СНГ важно, где физически стоит сервер: дата-центр в Москве или Санкт-Петербурге даст меньшую задержку, чем сервер в Америке. При выборе зарубежного CDN учитывайте, что с середины 2025 года часть российских провайдеров ограничивает трафик к некоторым иностранным сетям доставки контента (например, Cloudflare публично сообщала о таких замедлениях). Если ваша аудитория в России, проверяйте скорость именно из российских сетей.
Пример: главная страница интернет-магазина
Допустим, замер показал: вес главной страницы 6,2 МБ, из них 4,8 МБ — восемь баннеров и фото в формате JPEG, ещё 900 КБ — JavaScript, остальное — HTML, CSS и шрифты. LCP на мобильном — 5,1 секунды.
Что сделали по шагам:
- Баннеры уменьшили до ширины 1200 px и перевели в WebP — картинки стали весить 1,1 МБ вместо 4,8 МБ (экономия 3,7 МБ).
- Включили ленивую загрузку для всех баннеров, кроме первого.
- Убрали неиспользуемый слайдер и старый виджет чата — минус 350 КБ скриптов.
- Включили кэш страниц и Brotli.
Итог: вес страницы снизился с 6,2 до 2,15 МБ (6,2 − 3,7 − 0,35 = 2,15), то есть примерно в 2,9 раза, а LCP на мобильном опустился ниже 2,5 секунды. Цифры условные, но пропорции типичны: на большинстве сайтов именно картинки дают основной эффект.
Типичные ошибки
- Оптимизировать только по баллу PageSpeed, а не по реальным метрикам пользователей.
- Ставить «плагин ускорения» поверх 40 других плагинов вместо того, чтобы убрать лишние.
- Включать ленивую загрузку для главного изображения первого экрана — это ухудшает LCP.
- Забывать про мобильную версию и медленную сеть.
- Не проверять результат после изменений.
Чек-лист
- Замерили скорость главной и ключевых страниц (мобильная и десктопная версии).
- Изображения сжаты, переведены в WebP/AVIF и имеют правильные размеры.
- Ленивая загрузка включена для картинок ниже первого экрана.
- У статики долгий
Cache-Control, на сервере работает кэш страниц. - Включено сжатие Brotli или gzip.
- Убраны лишние скрипты, остальные подключены с
defer. - Шрифты в WOFF2, с
font-display: swap. - TTFB меньше 0,8 секунды.
- Повторный замер после изменений подтверждает улучшение.
Начните с самого простого — изображений и кэша, затем повторите проверку скорости. Обычно уже после этих двух шагов страница становится заметно быстрее.