Чек-лист по ускорению сайта: 8 практических шагов

53% пользователей сразу покидают страницу, если она загружается дольше 3 секунд. Скорость веб-сайта напрямую влияет не только на пользовательский опыт (UX), но и на позиции в поисковых системах (SEO) и показатели конверсии. Алгоритмы Google учитывают метрики Core Web Vitals в качестве официального фактора ранжирования.

В этой статье мы рассмотрим чек-лист из 8 практических шагов, которые помогут ускорить любой веб-проект, снизить нагрузку на сервер и существенно сократить время загрузки страниц.

1. Перевод изображений в формат WebP или AVIF

На большинстве сайтов изображения составляют 60–70% от общего объема страницы. Использование современных форматов WebP или AVIF вместо устаревших PNG и JPEG позволяет уменьшить размер картинок на 30–70% без видимой потери качества.

Пример адаптивной загрузки изображений в HTML для современных браузеров:

<picture>
  <source srcset="rasm.avif" type="image/avif">
  <source srcset="rasm.webp" type="image/webp">
  <img src="rasm.jpg" alt="Mahsulot rasmi" width="800" height="600" loading="lazy">
</picture>

Всегда задавайте явные атрибуты width и height для изображений. Это предотвращает сдвиги макета и решает проблему Cumulative Layout Shift (CLS).

2. Применение Lazy Loading для изображений и iframe

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

<img src="hero-pastidagi-rasm.webp" alt="Tavsif" loading="lazy">
<iframe src="https://youtube.com/embed/video-id" loading="lazy"></iframe>

Важное исключение: никогда не добавляйте loading="lazy" к первому главному изображению в первом экране (Above-the-fold или элемент LCP). Напротив, используйте атрибут fetchpriority="high" для его приоритетной загрузки.

3. Сжатие статических файлов (Gzip или Brotli)

Передача файлов HTML, CSS, JavaScript и JSON в несжатом виде замедляет передачу трафика. Включите сжатие Brotli или Gzip на сервере Nginx или любом другом используемом веб-сервере. Алгоритм Brotli сжимает текстовые файлы на 15–20% эффективнее по сравнению с Gzip.

Пример базовой конфигурации для Nginx:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml+rss text/javascript;
gzip_min_length 1024;
gzip_comp_level 6;

4. Грамотная настройка кеширования браузера (Cache-Control)

Неизменяемые статические файлы (логотипы, шрифты, версионированные JS/CSS файлы) нет необходимости заново запрашивать с сервера при каждом визите. Указание браузеру сохранять эти ресурсы в локальном кеше ускоряет повторные посещения вплоть до 90%.

location ~* \.(jpg|jpeg|png|webp|avif|css|js|woff2|woff)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Чтобы пользователи гарантированно получали свежие версии файлов при их изменении, настройте сборщики (Vite, Webpack) на добавление хеша к именам файлов (например: app.8f3b2a.js).

5. Оптимизация шрифтов (Web Fonts)

Некорректно подключенные внешние шрифты задерживают отображение текста (эффект FOIT — Flash of Invisible Text). При работе со шрифтами придерживайтесь следующих правил:

• Используйте только формат .woff2 — он наиболее компактный и современный.
• Указывайте свойство font-display: swap; в CSS-правилах шрифта. Это отобразит системный шрифт до завершения загрузки кастомного.
• Загружайте шрифты со своего сервера или доверенного CDN вместо сторонних сервисов (например, Google Fonts).
• Используйте предзагрузку для основного шрифта: <link rel="preload" href="shrift.woff2" as="font" type="font/woff2" crossorigin>.

6. Минификация файлов JavaScript и CSS

Во время разработки (development) исходный код содержит пробелы, комментарии и длинные имена переменных. Для продакшена обязательны очистка (минификация) и объединение ресурсов (бандлинг).

Кроме того, удаляйте неиспользуемый CSS- и JS-код с помощью механизма Tree Shaking. Чтобы скрипты не блокировали парсинг и рендеринг страницы, подключайте их с атрибутами defer или async:

<script src="bundle.js" defer></script>

7. Подключение сети доставки контента (CDN)

Если сервер расположен в Ташкенте, а посетитель находится в другой стране (или наоборот, сервер в Европе, а клиент в Узбекистане), физическое расстояние увеличивает сетевую задержку (latency). Использование CDN-сервисов (например, Cloudflare) позволяет раздавать статический контент с ближайшего к пользователю узла сети.

Даже бесплатный тариф Cloudflare включает защиту от DDoS-атак, автоматическое сжатие Brotli и глобальное кеширование.

8. Проверка времени ответа сервера (TTFB) и оптимизация запросов к БД

Каким бы безупречным ни был фронтенд, медленный ответ сервера на первый байт (Time to First Byte — TTFB) затормозит весь сайт. В норме TTFB должен находиться в пределах 200–500 мс.

Способы снижения TTFB:

• Индексы в базе данных: создавайте индексы для колонок, по которым часто выполняется поиск, фильтрация и сортировка.
• Оптимизация ORM: устраняйте проблему N+1 запросов в Django или других фреймворках (используйте select_related и prefetch_related).
• Кеширование через Redis: кешируйте ресурсоемкие или редко изменяемые динамические данные в памяти Redis.
• Настройки серверов приложений (Gunicorn/Uvicorn): подбирайте оптимальное количество воркеров в соответствии с числом процессорных ядер (CPU) сервера.

Чек-лист для быстрой проверки

1. Проверили ли вы показатели в Google PageSpeed Insights и Lighthouse?
2. Сконвертированы ли изображения в WebP и добавлен ли атрибут loading="lazy"?
3. Включены ли Gzip/Brotli и заголовки кеширования для статических файлов?
4. Удалены ли неиспользуемые библиотеки и скрипты JavaScript?
5. Оптимизированы ли тяжелые запросы к базе данных на стороне бэкенда?

Последовательно внедрив эти шаги, вы сможете сократить время загрузки проекта минимум в 2–3 раза и существенно улучшить показатели конверсии.