Как увеличить скорость загрузки сайта. Практический чек‑лист.
Сайт может «не падать», но всё равно терять людей из‑за скорости: страница открывается медленно, элементы появляются рывками, а кнопки реагируют с задержкой. В большинстве случаев виноваты не какие‑то загадочные причины, а вполне конкретные вещи: слишком тяжёлые изображения, отсутствие нормального кеширования и лишние скрипты.
Ниже — короткий и прикладной план, который можно пройти за 1–2 вечера без полной переделки сайта.
1) Начните с измерения: что именно тормозит
Для Google и реального пользовательского опыта сейчас важны показатели качества страниц (Core Web Vitals): LCP (скорость появления основного контента), INP (отзывчивость интерфейса) и CLS (стабильность верстки).
INP стал ключевым показателем отзывчивости и официально заменил FID (замена произошла в марте 2024).
Минимальный порядок действий:
- Прогоните страницу через PageSpeed Insights и посмотрите «полевые данные» (если они есть) + лабораторный тест.
- В Chrome DevTools откройте вкладку Network и посмотрите, какие ресурсы самые тяжёлые и что грузится дольше всего.
- Если у вас есть Google Search Console — загляните в отчёт Core Web Vitals: он группирует проблемы по типам и страницам.
Если нужен простой ориентир, какие задачи обычно входят в регулярный «технический контроль» сайта (скорость, ошибки, обновления, резервные копии) — можно посмотреть примерный подход на https://profitkit.ru/
2) Изображения: самый быстрый выигрыш
2.1 Не отдавайте мобильным «десктопные» картинки
Очень частая ошибка — грузить на телефон то же изображение, что и на большой монитор. В результате пользователю уходит лишний трафик, а страница грузится дольше. У Google прямо отмечается, что отправка «десктопных» изображений на мобильные устройства может расходовать в 2–4 раза больше данных, чем нужно.
Решение: несколько размеров одного файла + srcset/sizes (браузер сам выберет подходящий).
<img
src="/img/portfolio-640.jpg"
srcset="/img/portfolio-320.jpg 320w, /img/portfolio-640.jpg 640w, /img/portfolio-960.jpg 960w, /img/portfolio-1280.jpg 1280w"
sizes="(max-width: 480px) 92vw, (max-width: 1024px) 70vw, 640px"
width="640"
height="360"
alt="Пример работы в портфолио">
srcset/sizes — стандартный способ отдавать разные размеры под разные экраны.
2.2 Современные форматы (WebP/AVIF) — часто дают заметную экономию веса
Lighthouse прямо рекомендует «современные форматы», отмечая, что AVIF и WebP обычно дают лучшую компрессию и качество по сравнению с JPEG/PNG, что помогает быстрее загружать страницу и экономить мобильные данные.
Правильный подход — через <picture> с запасным JPEG/PNG:
<picture>
<source type="image/avif" srcset="/img/hero-1280.avif 1280w, /img/hero-960.avif 960w, /img/hero-640.avif 640w">
<source type="image/webp" srcset="/img/hero-1280.webp 1280w, /img/hero-960.webp 960w, /img/hero-640.webp 640w">
<img
src="/img/hero-1280.jpg"
srcset="/img/hero-640.jpg 640w, /img/hero-960.jpg 960w, /img/hero-1280.jpg 1280w"
sizes="100vw"
width="1280"
height="720"
alt="Главный баннер сайта">
</picture>
2.3 Ленивая загрузка для изображений ниже первого экрана
Если на странице много картинок, не обязательно грузить их все сразу. Стратегия «ленивой загрузки» уменьшает нагрузку на критический путь отрисовки и помогает ускорить старт страницы.
Для изображений ниже первого экрана обычно достаточно loading="lazy":
<img
src="/img/gallery-01-800.webp"
width="800"
height="600"
loading="lazy"
alt="Превью галереи">
2.4 Не давайте верстке «прыгать»: указывайте width и height
Чтобы уменьшить CLS (скачки макета), для изображений важно задавать размеры. Google отдельно указывает, что указание width/height помогает предотвратить сдвиги, потому что браузер заранее резервирует место под картинку.
3) Кеширование и сжатие: чтобы браузер не качал одно и то же
3.1 Дайте статике долгий срок жизни и версионируйте файлы
Для файлов, которые редко меняются (картинки, шрифты, CSS/JS), базовая логика такая:
- ставим большой max-age,
- при изменениях меняем URL (версия/хеш в имени файла).
MDN прямо рекомендует подход «cache busting» (версия/хеш в URL), чтобы можно было выставлять долгий max-age.
А web.dev приводит практические примеры значений Cache-Control (например, public, max-age=31536000 — 1 год) и объясняет, как это работает.
3.2 Пример кеширования для Apache (.htaccess)
MDN также описывает директиву immutable — она подсказывает браузеру, что ресурс не меняется и не требует лишней перепроверки.
<IfModule mod_headers.c>
<FilesMatch "\.(css|js|png|jpg|jpeg|gif|webp|avif|svg|ico|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 30 days"
ExpiresByType application/javascript "access plus 30 days"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
3.3 Включите сжатие текста (Brotli/Gzip)
Lighthouse подчёркивает, что текстовые ресурсы стоит отдавать с компрессией; при этом Brotli обычно эффективнее, а Gzip — хорошая совместимая «подстраховка».
web.dev дополнительно объясняет, что и gzip, и Brotli можно настраивать по уровням компрессии и выбирать разумный баланс.
Пример для Apache:
<IfModule mod_brotli.c>
AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json image/svg+xml
BrotliCompressionQuality 5
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json image/svg+xml
</IfModule>
4) Скрипты: уберите блокировку и лишнюю нагрузку
4.1 Добавьте defer для своих скриптов
MDN объясняет, что defer помогает убрать блокировку парсинга HTML: скрипт загружается в фоне и выполняется после разбора документа (до события DOMContentLoaded).
<script defer src="/js/app.js"></script>
<script defer src="/js/forms.js"></script>
4.2 Проверьте сторонние виджеты (чаты, карты, аналитика)
Сторонние скрипты — частая причина замедлений, потому что это ресурсы «вне вашего контроля», которые добавляют запросы и нагрузку на страницу.
Практичный подход:
- удалить всё, что не даёт понятной ценности;
- остальное грузить позже (после первого экрана или по действию пользователя);
- сокращать число сторонних сервисов и их дублей (несколько виджетов «на всякий случай» обычно убивают скорость).
4.3 Если сайт «тяжёлый», режьте код на части
Если у вас большой интерфейс, помогает разделение кода (code splitting): это уменьшает объём JavaScript, который нужно загрузить в самом начале, и ускоряет момент, когда страница становится интерактивной.
5) После правок проверьте не только баллы, но и «бизнес‑сценарии»
Скорость нужна не ради красивых цифр, а чтобы сайт быстрее показывал основной контент и нормально реагировал на действия. Например, LCP измеряет время до появления самого крупного элемента (картинки или блока текста) в видимой области.
После каждой серии оптимизаций проверьте руками:
- отправку формы заявки;
- регистрацию/вход (если есть);
- оплату/корзину (если есть);
- ключевые страницы услуг.
И только потом снова прогоняйте PageSpeed Insights: цель — чтобы сайт стал быстрее и не ломал заявки.