Как ускорить загрузку сайта: полное руководство по оптимизации скорости

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

Как скорость влияет на сайт

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

Какие показатели измерять

Пороговые значения Core Web Vitals оценивают на 75-м процентиле посещёний, отдельно для мобильных и настольных устройств. INP не измеряет прокрутку и не является средним временем всех действий пользователя.

Дополнительные ориентиры: TTFB — время до первого байта ответа, FCP — первое отображение контента, Speed Index — темп визуального заполнения экрана. Лабораторный TBT показывает блокировки основного потока, но не заменяет полевой INP.

Как проверить скорость

1. Выберите типичные страницы: главную, статью, категорию, карточку товара и важную форму.
2. Откройте PageSpeed Insights: отдельно посмотрите полевые данные реальных пользователей и лабораторный тест Lighthouse. Если трафика мало, полевых данных для URL может не быть; агрегированные данные всего домена не следует выдавать за данные отдельной страницы.
3. Повторите несколько лабораторных запусков с одинаковыми настройками устройства и сети. Сохраните отчёт, дату и условия проверки.
4. В Chrome DevTools изучите Network и Performance: тяжёлые запросы, длинные задачи, задержки ответа сервера и загрузку LCP-элемента.
5. После исправления повторите тот же сценарий. Полевые данные отражают период наблюдения и не обновятся мгновенно.

Для первичной диагностики также подойдут проверка скорости PR-CY и массовая проверка Core Web Vitals. Оценка инструмента нужна для поиска проблемы, а итог проверяют по времени загрузки и реальным пользовательским действиям.

1. Оптимизируйте изображения

Сравните JPEG, WebP и AVIF на своих изображениях и выберите вариант с подходящим качеством, размером и совместимостью. PNG полезен для отдельных изображений с прозрачностью, SVG — для логотипов и схем. Один формат не выигрывает на всех картинках.

• Отдавайте размер под экран через srcset и sizes, а не уменьшайте многомегабайтный оригинал только стилями.
• Задавайте width и height или соотношение сторон, чтобы изображение не сдвигало соседний контент.
• Для изображений ниже первого экрана применяйте loading="lazy". Не откладывайте загрузку LCP-изображения.
• Удаляйте ненужные метаданные, проверяя результат после оптимизации. Подписи и важный текст размещайте текстом, а не внутри картинки.

<img src="photo-800.webp"
     srcset="photo-400.webp 400w, photo-800.webp 800w"
     sizes="(max-width: 600px) 100vw, 800px"
     width="800" height="500" alt="Описание изображения">

2. Уменьшите объём CSS и JavaScript

Удалите неиспользуемые зависимости, подключайте код только на нужных страницах и минифицируйте файлы при сборке. Минификация и сжатие — разные операции, они дополняют друг друга. Не объединяйте все стили и скрипты в один файл автоматически: при HTTP/2 и HTTP/3 это может ухудшить кэширование и заставить загружать ненужный код.

Проверьте блокирующие стили и скрипты. Для независимых скриптов подходят async или defer, но выбор зависит от порядка исполнения и зависимостей. Для INP сокращайте длинные задачи, делите тяжёлую работу на части, избегайте лишних изменений DOM и выносите подходящие вычисления в Web Workers.

3. Включите сжатие

GZIP и Brotli уменьшают объём текстовых ресурсов при передаче. Уже сжатые JPEG, видео и архивы обычно не стоит повторно сжимать тем же способом. Выбор алгоритма и уровня зависит от возможностей сервера и нагрузки; заранее гарантировать процент экономии нельзя.

Пример GZIP для Nginx

Директивы размещают в подходящем контексте http или server. HTML сжимается при включённом GZIP автоматически, остальные MIME-типы перечисляют отдельно.

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json text/xml application/xml image/svg+xml;

Пример GZIP для Apache

Нужен модуль mod_deflate. Размещайте настройку в конфигурации сервера или в .htaccess, если хостинг разрешает эти директивы.

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json text/xml application/xml image/svg+xml
</IfModule>

Перед применением проверьте синтаксис конфигурации командой nginx -t или apachectl configtest. В Network проверьте заголовок Content-Encoding фактического ответа: gzip или br. Проверяйте GET, потому что ответ HEAD может отличаться.

4. Настройте кэширование

Разделяйте статические файлы и динамические страницы. Для файла с версией в имени, например app.a1b2c3.css, допустим долгий срок хранения. При изменении файла должна меняться версия URL. Персональные страницы и ответы с данными пользователя нельзя делать общедоступным кэшем.

Пример Cache-Control для Nginx

location /assets/versioned/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Этот пример подходит только для каталога, где имена файлов меняются при каждом изменении содержимого.

Пример Expires для Apache

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 day"
    ExpiresByType application/javascript "access plus 1 day"
</IfModule>

Срок в примере — стартовая настройка, а не универсальная норма. mod_expires формирует Expires и Cache-Control; не добавляйте противоречащие директивы на прокси или CDN. Для часто меняющегося HTML можно использовать Cache-Control: no-cache: ответ разрешено хранить, но перед повторным использованием нужно подтвердить актуальность. Это не то же самое, что no-store.

5. Проверьте сторонние сервисы

Google Analytics, Google Ads, рекламные сети, чаты и другие виджеты не получают исключений из измерений производительности. Их запросы и выполнение JavaScript могут влиять на загрузку и отзывчивость сайта.

1. Найдите сторонние домены в Network и стоимость выполнения скриптов в Performance.
2. На тестовой странице отключайте интеграции по одной и повторяйте измерения.
3. Удалите неиспользуемые счётчики и дубли тегов. Загружайте виджеты только на нужных страницах или после действия пользователя, когда это подходит сценарию.
4. Проверьте, что после изменения продолжают работать аналитика, согласия и важные бизнес-функции.

6. Разберитесь с сервером, хостингом и CDN

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

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

7. Проверьте шрифты, SSR и протокол

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

SSR может раньше показать содержимое, но повышает нагрузку на сервер, а гидратация способна ухудшить INP. HTTP/3 может помочь на отдельных сетях, однако не заменяет оптимизацию контента и JavaScript. AMP не обязателен для быстрой мобильной страницы или показа в поиске.

Чек-лист после изменений

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