Меня зовут Максим, я веб-разработчик. В 2025 году я делал сайт для сети аптек с 40 точками — 12 из них в малых городах Сибири и Дальнего Востока. Когда мы запустили первую версию сайта, из Москвы он грузился за 1,8 секунды. Идеально. А потом я попросил фармацевта из Тынды (Амурская область) открыть сайт на своём телефоне — Samsung Galaxy A13, мобильный интернет 3G. Результат: 14 секунд загрузки, половина изображений не загрузилась, интерактивные элементы подвисали. Сайт для 12 из 40 точек был фактически неработоспособен. Мы переделали техническую часть — и добились 3,2 секунды на том же устройстве в тех же условиях. Расскажу, как.

Масштаб проблемы

Мы привыкли разрабатывать сайты на MacBook Pro с оптоволокном в 500 Мбит/с. А потом удивляемся, почему конверсия в регионах в 3 раза ниже, чем в Москве.

Реальность российских регионов:

Интернет. В малых городах и посёлках — 3G или нестабильный 4G. Скорость: 2–5 Мбит/с, пинг: 100–300 мс. В сельской местности — бывает и хуже. По данным Минцифры, около 30% населённых пунктов России не имеют стабильного 4G-покрытия.

Устройства. Бюджетные Android-смартфоны: Samsung Galaxy A-серии, Xiaomi Redmi, Realme, Tecno. Процессор — начальный уровень, оперативная память — 3–4 ГБ. На таких устройствах тяжёлые JavaScript-фреймворки работают со скрипом.

Браузер. Chrome на Android — основной. Но версии могут быть не самыми свежими (пользователи не обновляют). Встроенные WebView-браузеры в Telegram и ВК — ещё менее производительные.

Если ваш сайт рассчитан на аудиторию за пределами Москвы и Петербурга — оптимизация под слабый интернет и бюджетные устройства — необходимость, а не «бонус».

Принципы разработки для плохого интернета

Принцип 1: Каждый килобайт на счету

Средняя веб-страница в 2026 году весит 2,5–3 МБ. На 3G со скоростью 3 Мбит/с это ~8 секунд только на загрузку данных (без учёта рендеринга). Цель: уложить первую загрузку в 500–800 КБ.

Что я делаю:

Изображения — главный враг. Один некомпрессированный PNG-баннер может весить 2 МБ. Решение:

  • Формат WebP (на 30–50% легче JPEG при том же качестве), с fallback на JPEG для старых браузеров
  • AVIF — ещё легче, но поддержка пока не универсальна
  • Адаптивные размеры: `<img srcset="...">` — разные размеры для разных экранов. Телефону не нужна картинка 1920px — достаточно 480px
  • Lazy loading: `loading="lazy"` — изображения ниже экрана загружаются только при прокрутке
  • Компрессия: squoosh.app, sharp (Node.js) — агрессивное сжатие с контролем качества

JavaScript — второй враг. Среднестатистический React-сайт отправляет 300–500 КБ JavaScript. На бюджетном процессоре парсинг и выполнение этого кода занимает 3–5 секунд. Решение:

  • SSR (Server-Side Rendering) — HTML генерируется на сервере, пользователь видит контент до загрузки JS
  • Code splitting — разбиение JS на чанки, загрузка только нужного кода для текущей страницы
  • Tree shaking — удаление неиспользуемого кода из бандла
  • Минимизация сторонних библиотек — каждый `npm install` увеличивает бандл

CSS. Удаление неиспользуемых стилей (PurgeCSS). Критический CSS инлайнится в HTML, остальное загружается асинхронно.

Шрифты. Один шрифт, одно начертание, формат WOFF2 (самый компактный). Использование `font-display: swap` — текст виден сразу системным шрифтом, кастомный подгружается потом.

Принцип 2: Серверный рендеринг — обязательно

На бюджетном устройстве клиентский рендеринг (SPA/CSR) — катастрофа. Браузер скачивает 300 КБ JS, парсит его 3 секунды, выполняет 2 секунды, делает API-запрос, ждёт ответ 1 секунду, рендерит контент 1 секунду. Итого: 7+ секунд до первого контента.

SSR (Server-Side Rendering): сервер генерирует готовый HTML, отправляет его браузеру. Браузер показывает контент сразу — ещё до загрузки JS. Пользователь видит страницу через 1–2 секунды. JS догружается в фоне для интерактивности.

В Next.js это встроенная возможность — я использую SSR для всех страниц, которые должны быть доступны моментально.

Ещё лучше — SSG (Static Site Generation) для страниц, которые не меняются часто (каталог, описание услуг, контакты). Статический HTML отдаётся CDN мгновенно.

Принцип 3: CDN с точками в России

CDN (Content Delivery Network) — сеть серверов, которая отдаёт контент с ближайшей к пользователю точки. Если ваш сервер в Москве, а пользователь во Владивостоке — добавляется 100–200 мс задержки на каждый запрос.

CDN с российскими точками присутствия: Яндекс Cloud CDN, Selectel CDN, CDNvideo. Они имеют серверы в Новосибирске, Владивостоке, Екатеринбурге — что критически важно для регионального бизнеса.

Что отдаю через CDN: изображения, CSS, JS, шрифты — всю статику. HTML — тоже, если страницы статические (SSG).

Принцип 4: Работа оффлайн (Service Worker)

PWA с Service Worker может кэшировать ключевые страницы и ресурсы. При повторном визите — страница загружается из кэша мгновенно, даже если интернет пропал.

Для аптечной сети это означает: фармацевт открыл каталог лекарств утром (когда интернет был) — и может пользоваться им весь день, даже если связь пропала.

Стратегии кэширования:

  • Cache First — сначала ищем в кэше, если нет — идём в сеть. Для статики (изображения, CSS, JS)
  • Network First — сначала пробуем сеть, если недоступна — берём из кэша. Для данных (каталог, цены)
  • Stale While Revalidate — показываем из кэша, параллельно обновляем. Лучший баланс скорости и актуальности

Принцип 5: Скелетон-загрузка вместо белого экрана

Пока контент загружается — показываем «скелетон»: серые прямоугольники на месте будущего контента. Это создаёт ощущение, что сайт «уже работает», и пользователь ждёт терпеливее. На бюджетных устройствах разница в восприятии — огромная.

Принцип 6: Минимум сторонних скриптов

Каждый внешний скрипт — отдельное DNS-разрешение, отдельное TCP-соединение, отдельная загрузка. На медленном интернете это секунды.

Аудит: проверяю все скрипты через Chrome DevTools (вкладка Network). Типичные «преступники»: виджеты чатов (JivoSite, Carrot Quest), аналитика (если несколько счётчиков), соцсети (виджеты ВК, Telegram), шрифты (Google Fonts).

Решение: оставляю минимум (Яндекс Метрика + один виджет), остальное — загружаю отложенно (после основного контента) или заменяю лёгкими аналогами.

Как тестировать производительность на слабых устройствах

Chrome DevTools — эмуляция

В Chrome DevTools → Performance → настройки: CPU throttling (4x slowdown), Network throttling (Slow 3G — 780 Кбит/с, 2 000 мс латентность). Это грубая, но полезная эмуляция.

Lighthouse

Встроенный инструмент Chrome. Выбираю профиль «Mobile» с throttling. Целевые показатели:

  • Performance score: > 70
  • LCP (Largest Contentful Paint): < 2,5 сек
  • TBT (Total Blocking Time): < 300 мс
  • CLS (Cumulative Layout Shift): < 0,1

Реальные устройства

Покупаю (или арендую) бюджетный Android-смартфон для тестирования. Samsung Galaxy A14 или Xiaomi Redmi 12 — типичные устройства моей аудитории. Тестирую через мобильный интернет, а не через Wi-Fi.

WebPageTest

Онлайн-сервис, который тестирует скорость загрузки с реальных серверов в разных регионах. Можно выбрать тип устройства и скорость соединения.

Результат: аптечная сеть

До оптимизации: размер страницы каталога — 3,2 МБ. Загрузка на 3G — 14 секунд. LCP — 8,7 секунды. Половина изображений не загружалась.

После оптимизации:

  • Размер страницы: 680 КБ (–79%)
  • Загрузка на 3G: 3,2 секунды (–77%)
  • LCP: 2,1 секунды
  • Все изображения загружаются (WebP + адаптивные размеры + lazy loading)
  • Service Worker кэширует каталог — повторные визиты мгновенны

Бизнес-эффект:

  • Конверсия с мобильных в регионах: +62%
  • Отказы (bounce rate) на мобильных: с 58% до 31%
  • Количество онлайн-заказов из малых городов: +45%

Стоимость оптимизации

Аудит производительности + оптимизация существующего сайта: 50–200 тысяч рублей. Срок: 1–4 недели.

Разработка нового сайта с учётом performance-first подхода: надбавка 10–15% к базовой стоимости. Значительно дешевле, чем оптимизировать потом.

Если ваша аудитория — не только Москва и Петербург — обращайтесь. Сделаем сайт, который работает везде.