Медленный сайт стоит денег: как мы ускоряем сайты

Однажды я открыл в браузере вкладку Network на сайте, который клиент принёс на доработку, и увидел, что главная страница весит 14 мегабайт. Из них 11 — фотографии в слайдере. Пять фото, каждое в оригинальном разрешении с камеры, по 2–3 МБ.

На офисном оптоволокне это незаметно. На 4G в Ташкенте — пара секунд. А на мобильном интернете где-нибудь в районе Хорезма или Сурхандарьи человек смотрит на белый экран, пока не закроет вкладку.

Скорость сайта — не техническая красота. Это деньги, которые вы платите за рекламу и теряете на первом экране.

Почему секунды превращаются в деньги

Представьте, что вы запускаете рекламу. Платите за клик. Человек нажал, а сайт грузится. Каждая лишняя секунда отсекает часть людей, которые уже стоили вам денег. Google по своим исследованиям давно говорит, что при росте времени загрузки с одной до трёх секунд вероятность ухода заметно растёт, а дальше ещё сильнее.

Есть и второй эффект. Google учитывает Core Web Vitals при ранжировании. Это три метрики:

• LCP — когда показался самый крупный элемент первого экрана (цель: до 2,5 с);
• INP — как быстро страница реагирует на нажатия (цель: до 200 мс);
• CLS — насколько «прыгает» вёрстка при загрузке (цель: до 0,1).

Медленный сайт хуже ранжируется и хуже конвертирует. Двойной удар.

Картинки: почти всегда главная проблема

По нашим аудитам, на большинстве медленных сайтов основной вес — изображения. Не JavaScript, не шрифты, а фото, загруженные «как есть».

Что мы делаем с картинками на каждом проекте:

1. Формат WebP. При том же качестве он легче JPEG примерно на 25–35%, а PNG-скриншоты сжимает в разы.
2. Правильный размер. Если фото на сайте показывается шириной 800 пикселей, не нужно грузить 4000. Для телефонов отдаём ещё меньше.
3. Lazy loading. Картинки ниже первого экрана грузятся, только когда человек до них доскроллит.
4. Размеры в вёрстке. У каждого изображения указаны ширина и высота, чтобы страница не прыгала, когда оно подгрузится. Это прямо влияет на CLS.

На Nuxt большую часть этого делает модуль @nuxt/image. Так он настроен, например, на сайте Japanese Garden:

// nuxt.config.ts
image: {
  format: ["webp"],
  screens: { sm: 640, md: 768, lg: 1080, xl: 1280 },
},

Дальше в шаблоне вместо <img> пишем <NuxtImg> с loading="lazy" и sizes, и сервер сам нарезает нужные варианты.

Наш собственный сайт

Сапожник без сапог — это про нас тоже. На сайте idrok.group картинки, загруженные через админку, долго хранились в том виде, в каком их загрузили. В какой-то момент мы сделали то, что советуем клиентам: при загрузке изображения автоматически уменьшаются до реального размера показа и перекодируются в WebP, а для старых файлов написали команду, которая прогнала их через тот же конвейер.

Никакого редизайна, никакого нового кода на фронтенде. Только картинки.

Шрифты и сторонние скрипты

Второй частый виновник — шрифты. Красивый шрифт из Google Fonts, подключённый через @import внутри CSS, означает цепочку: загрузить CSS, разобрать его, найти @import, загрузить ещё один CSS, и только потом сам шрифт. На медленном соединении это лишние сотни миллисекунд белого текста.

Что помогает:

• preconnect к серверам шрифтов в <head>;
• прямой <link> вместо @import;
• font-display: swap, чтобы текст сразу показывался системным шрифтом;
• не больше двух семейств и только нужные начертания. Четыре веса Poppins по 40 КБ — это уже 160 КБ.

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

Отдельная история — сторонние скрипты. Виджет чата, три счётчика аналитики, пиксель соцсети, карта. Каждый тянет свой JavaScript, и каждый «весит всего немного». Вместе они могут добавить секунду. Мы спрашиваем у клиента про каждый: кто им пользуется и что будет, если его убрать. Ответ «не знаю, его поставил прошлый маркетолог» встречается чаще, чем хотелось бы.

SSR, SPA и то, что видит телефон в регионах

Сайт на React или Vue можно собрать двумя способами. Как SPA: браузер получает почти пустую страницу и строит её сам, выполняя JavaScript. Или с серверным рендерингом (SSR): сервер сразу отдаёт готовый HTML, а JavaScript потом «оживляет» его.

Для сайтов, которые должны находиться в поиске и открываться у людей с недорогими Android-телефонами, мы почти всегда берём SSR. MY5 и Japanese Garden, например, сделаны на Nuxt 3 с серверным рендерингом.

9:41garden.redmedia.uz

У Japanese Garden мы пошли дальше: сайт сделан как PWA. После первого посещения сервис-воркер кеширует страницы, и следующий визит открывается почти мгновенно, даже если в саду плохая связь.

CDN и сервер

Если аудитория в Узбекистане, а сервер в Германии, каждый запрос проходит тысячи километров. CDN раздаёт статические файлы (картинки, скрипты, стили) с ближайшего к пользователю узла. Для сайтов с аудиторией в нескольких странах это заметно. Для чисто ташкентского бизнеса иногда разумнее арендовать сервер в Узбекистане и обойтись без CDN.

На стороне бэкенда тоже бывают тормоза, которые не видно в браузере: медленные запросы к базе, API, который отдаёт в десять раз больше данных, чем нужно странице, отсутствие кеша. Это уже работа бэкендеров, и Миродил у нас первым делом смотрит, сколько запросов к базе делает одна страница.

С чего начать, если сайт уже тормозит

Не нужно сразу переписывать сайт. В девяти случаях из десяти большая часть эффекта даёт простое:

1. Откройте PageSpeed Insights и проверьте мобильную версию главной.
2. Посмотрите на самые тяжёлые картинки и переведите их в WebP нужного размера.
3. Уберите сторонние скрипты, которыми никто не пользуется.
4. Проверьте, как подключены шрифты.

Если после этого всё ещё медленно, проблема, скорее всего, в архитектуре: SPA без серверного рендеринга, тяжёлая тема WordPress с десятками плагинов, перегруженный сервер. Тут уже нужен разговор с разработчиками, и мы готовы его провести. О том, как скорость связана с поиском, я бы ещё почитал нашу статью про SEO для новостных сайтов: у медиа эти проблемы проявляются острее всего.

Моё личное правило: перед сдачей любого проекта я открываю его на самом дешёвом Android, который есть в офисе, с выключенным Wi-Fi. Если мне самому неприятно ждать, клиенту я его не показываю.