Как ускорить сайт: 12 способов улучшить скорость загрузки

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

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

Основные показатели

Core Web Vitals измеряют реальный пользовательский опыт:

• LCP — основной контент должен появиться в пределах 2,5 секунды;

• INP — реакция на действие должна укладываться в 200 мс;

• CLS — неожиданные смещения должны оставаться на уровне 0,1 или ниже.

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

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

12 способов ускорить сайт

1. Изучите водопад загрузки

В PageSpeed, DevTools или WebPageTest найдите время HTML, LCP-элемент, момент начала его загрузки, крупные файлы, блокирующие CSS/JS, длинные задачи и сторонние домены. До изменений сформулируйте конкретный диагноз.

2. Дайте приоритет LCP-элементу

Главное изображение или заголовок должны обнаруживаться рано. Не используйте lazy loading для LCP-картинки. При необходимости применяйте обоснованный preload или приоритет, правильный размер и не прячьте контент внутри тяжелого слайдера.

3. Отдавайте изображения нужного размера

Создавайте адаптивные версии через srcset и sizes, используйте WebP или AVIF там, где это уместно. Не отправляйте 4K-файл небольшому телефону. Задавайте размеры и лениво загружайте только контент ниже первого экрана.

4. Оптимизируйте шрифты

Оставьте необходимые семейства, начертания и языковые наборы. Используйте WOFF2, подходящий font-display и preload только критического шрифта. Fallback должен иметь похожие пропорции, чтобы текст не сдвигал макет.

5. Сократите блокирующий CSS

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

6. Уменьшите и отложите JavaScript

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

7. Проведите аудит сторонних скриптов

Составьте реестр аналитики, рекламы, чата, call tracking, heatmap, A/B-тестов, карт и соцсетей. Для каждого укажите владельца и цель. Загружайте только на нужных страницах и удаляйте дубли и старые теги.

8. Настройте кеш и сжатие

Используйте длительный браузерный кеш для версионированных ресурсов, Brotli или gzip для текста, page cache для подходящих публичных страниц и object cache там, где это полезно. После релиза проверяйте обновление кеша. Не кешируйте вслепую кабинет, корзину и персональные данные.

9. Уменьшите TTFB и серверную работу

Профилируйте базу, API, редиректы, плагины и middleware. Увеличение ресурсов оправдано, когда CPU, память или I/O действительно исчерпаны, но оно не заменяет исправление плохого запроса или блокирующего API.

10. Используйте CDN для подходящей задачи

CDN приближает статику к посетителям и помогает при пиках. Он не уменьшит большой JavaScript и не заставит браузер раньше обнаружить LCP. Проверьте правила кеша, очистку, HTTPS, редиректы и персонализированные ответы.

11. Устраните скачки макета

Резервируйте место для изображений, iframe, cookie-баннеров и динамических блоков. Не вставляйте промополосу над уже видимым контентом. Используйте стабильные placeholders и, где возможно, анимируйте transform и opacity.

12. Введите бюджет производительности

Ограничьте вес первой загрузки, JavaScript, сторонние домены и hero-медиа. Зафиксируйте пороги LCP, INP и CLS. Добавьте лабораторную проверку к приемке релиза и наблюдайте реальные метрики после новых плагинов, рекламных тегов и функций.

Чек-лист WordPress

Проверьте дублирующие плагины, медленные запросы, cron, ресурсы конструктора, адаптивные изображения, page/object cache, устаревшие таблицы, версии PHP и модулей, WooCommerce-скрипты на обычных страницах и конфликты оптимизаторов.

Не устанавливайте несколько speed-плагинов одновременно. Они могут по-разному перестраивать CSS/JS и создавать конкурирующие кеши. После каждого изменения тестируйте навигацию, формы, оплату и админку.

Быстрая диагностика

• Долго пустой экран: TTFB и блокирующие ресурсы.

• Поздно появляется баннер: обнаружение, размер и приоритет LCP.

• Медленная кнопка: длинные JavaScript-задачи и INP.

• Контент скачет: размеры, шрифты и динамические баннеры.

• Медленный checkout: доставка, оплата, сессии и API.

• Проблема только на телефоне: выполнение JS и крупные файлы на реальном устройстве.

Гарантирует ли скорость ТОП Google?

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

Полный процесс описан в пошаговой инструкции BB STUDIO о выводе сайта в ТОП Google.

Вывод

Не начинайте со случайного плагина или дорогого сервера. Определите, что тормозит: backend, основной контент, взаимодействие или стабильность. Затем исправьте самый влиятельный ресурс, скрипт, кеш, запрос или инфраструктурное ограничение.

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

FAQ

Какой PageSpeed считается хорошим?

Лабораторный Performance score от 90 отмечается зеленым, но важнее реальные LCP, INP и CLS. Идеальные 100 нужны не каждому сайту.

Почему мобильный результат ниже?

Мобильный тест моделирует менее мощное устройство и сложную сеть. Большие медиа и JavaScript сильнее влияют на телефон.

Поможет ли плагин кеширования?

Только если кеш — часть проблемы. Плагин не исправит тяжелое hero-изображение, лишний JavaScript, медленный API или плохой CLS.

Нужно ли включать lazy loading для всех картинок?

Нет. LCP-изображение первого экрана должно загружаться сразу. Lazy loading нужен контенту ниже viewport.