Сайт медленно открывается на мобильном: чек-лист из 12 пунктов

На мобильном сайт тормозит по трём причинам чаще прочего: медленный ответ сервера, тяжёлая картинка первого экрана и блокирующие скрипты со шрифтами. Ориентиры простые: LCP до 2,5 секунды, INP до 200 мс. Когда LCP уходит за 4 секунды, посетители начинают уходить.

Сайт на десктопе летает, а на телефоне грузится 6-8 секунд, и каждый второй посетитель уходит, не дождавшись. Знакомая ситуация, и в 80% случаев виноваты не злые силы, а конкретные технические недоработки. Я собрал чек-лист из 12 пунктов, которые чаще всего тормозят мобильную версию. С каждым пунктом будет разбор: как проверить, как починить, какой эффект ждать.

Сначала замерьте честно

Распространённая ошибка владельцев: открыли сайт со своего iPhone в офисе по Wi-Fi и решили, что всё нормально. Замер не считается. Условия пользователя совершенно другие.

Нормальный замер мобильной скорости делается из трёх источников:

1. PageSpeed Insights. На главной странице pagespeed.web.dev. Дёргает ваш сайт через эмуляцию Moto G4 на медленном 4G. Цифры строгие, ближе к реальным условиям пользователя в провинции.
2. WebPageTest с пресетом Moto G4 - Slow 3G или Slow 4G. Дополнительно показывает waterfall — что именно грузится, в каком порядке, что блокирует.
3. Реальное устройство по 4G. Берём не флагман, а среднестатистический Xiaomi Redmi 8 или iPhone SE 2020, отключаем Wi-Fi, открываем сайт. Это reality check.

Цели на 2026 год: LCP меньше 2.5 секунд, INP меньше 200 мс, CLS меньше 0.1. Если вы попадаете в эти пороги, поисковики не штрафуют. Если LCP уползает за 4 секунды, пользователи начинают уходить уже до взаимодействия.

Откройте PageSpeed Insights для своего сайта прямо сейчас и держите вкладку открытой. Дальше пройдёмся по 12 пунктам, многие из них вы увидите в его рекомендациях.

Пункт 1: TTFB больше 600 мс

Time to First Byte — это сколько ваш сервер думает над первым байтом ответа. Если TTFB 1.5 секунды, никакая фронтенд-оптимизация уже не спасёт.

Проверка через curl:

curl -w "@-" -o /dev/null -s https://yoursite.ru/ <<'EOF'
namelookup:  %{time_namelookup}n
connect:     %{time_connect}n
appconnect:  %{time_appconnect}n
starttransfer: %{time_starttransfer}n
total:       %{time_total}n
EOF

Если starttransfer больше 0.6 секунды, у вас проблема на сервере. Возможные причины:

• Тяжёлая CMS без серверного кэша (WordPress без object cache, Битрикс с пустым менеджером кэша).
• Соседи по shared-хостингу едят процессор.
• База данных раздулась до сотен мегабайт без оптимизации.
• PHP старой версии (7.4 в 2026 — стыдно).

Что делать: включить серверный кэш страниц (для WordPress — LiteSpeed Cache, WP Super Cache, для Битрикс — встроенный менеджер кэша на максимум). Перейти на PHP 8.2 или новее. Если хостинг бутылочное горлышко, рассмотреть переезд.

Пункт 2: Тяжёлая hero-картинка

LCP-элемент в 70% случаев — это первая большая картинка на странице. И она же чаще всего весит 800 КБ в JPG, хотя могла весить 80 КБ в WebP.

Проверка: PageSpeed Insights в разделе «Properly size images» и «Serve images in next-gen formats». Скажет конкретно, какой файл оптимизировать и сколько вы сэкономите.

Что делать:

• Конвертировать в WebP (поддерживается всеми браузерами с 2020 года).
• Подавать через <picture> с fallback на JPG.
• Размер картинки делать ровно под максимальный экран. Не нужно 2400×1600, если она показывается в блоке 1200×800.
• Для разных экранов отдавать разные размеры через srcset.

<picture>
  <source type="image/avif" srcset="/img/hero.avif">
  <source type="image/webp" srcset="/img/hero.webp">
  <img src="/img/hero.jpg" alt="..." width="1200" height="800" loading="eager" fetchpriority="high">
</picture>

fetchpriority="high" для LCP-картинки — просьба к браузеру тащить её первой. Это даёт минус 200-400 мс к LCP в реальных замерах.

Пункт 3: Lazy loading на hero

Парадоксальная ошибка, которую делают все, кто слышал «ставь loading=’lazy’ на все картинки». На LCP-картинку lazy ставить НЕЛЬЗЯ. Браузер начнёт загружать её только когда увидит, что она в viewport, и LCP уползёт на лишнюю секунду.

Что делать: на первом экране у всех картинок loading="eager" (или просто без атрибута, по умолчанию eager). На всех остальных — loading="lazy". Это минута работы, эффект мгновенный.

Пункт 4: Блокирующий рендер JavaScript

Если в <head> стоит <script src="..."> без async или defer, браузер останавливается, скачивает и выполняет скрипт, и только потом рисует страницу. Каждый такой скрипт — это +100-500 мс к LCP на медленном устройстве.

Проверка: PageSpeed Insights, раздел «Eliminate render-blocking resources». Покажет конкретные файлы.

Что делать:

• Все аналитические счётчики (Метрика, Top.Mail.Ru) — в <head> с атрибутом async.
• Все виджеты (онлайн-чаты, обратный звонок, попапы) — в <body> с defer или вообще загружать после события load.
• Слайдеры, лайтбоксы, прочий UI-JS — грузить только на тех страницах, где он реально нужен (а не одним бандлом на весь сайт).

Пункт 5: Шрифты, которые блокируют отрисовку текста

Кастомные шрифты (Google Fonts, Yandex Fonts, self-hosted) — это вторая по частоте причина медленного LCP после картинок. Если шрифт не подгрузился, браузер либо ждёт его (FOIT — flash of invisible text), либо показывает текст системным и потом перерисовывает (FOUT).

Что делать:

• Self-host шрифтов вместо Google Fonts CDN. Особенно в России в 2026 — Google Fonts иногда отдаёт с задержкой 2-3 секунды.
• В @font-face обязательно font-display: swap; — текст показывается системным шрифтом сразу, без ожидания.
• Preload критических шрифтов: <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>.
• Variable fonts вместо четырёх отдельных файлов на каждое начертание — один файл на 200 КБ вместо 800.
• Только те начертания, которые реально используете. Часто на сайте подключены 400, 500, 600, 700, а в дизайне используется только 400 и 700.

Пункт 6: Виджеты, которые тащат полмегабайта JS на дашборд

Онлайн-чаты, формы обратного звонка, конструкторы попапов — это самые жирные клиентские скрипты на типовом сайте. JivoSite, Verbox, Carrot quest — каждый легко тащит 300-700 КБ JS, плюс несколько HTTP-запросов на инициализацию.

Что делать:

• Загружать виджет не сразу, а после прокрутки или через 3 секунды:

window.addEventListener('load', function() {
  setTimeout(function() {
    var s = document.createElement('script');
    s.src = 'https://code.jivo.ru/widget/XXXXXXX';
    s.async = true;
    document.head.appendChild(s);
  }, 3000);
});

• Подумать, нужен ли он на самом деле. По данным Метрики посмотреть, сколько чатов в месяц приходит. Если 5-10 в месяц, а виджет добавляет +1 секунду к LCP у всех 10000 посетителей — может, заменить на простую кнопку Telegram, которая ничего не весит.
• Виджеты обратного звонка типа CallbackHunter с агрессивными попапами часто можно заменить на простой <a href="tel:..."> в шапке, и это даже эффективнее по конверсии.

Пункт 7: Метрика и счётчики

Я.Метрика сама по себе не злодей, но если у вас стоит несколько счётчиков (Метрика + Top.Mail.Ru + Хотджар + Roistat-парсер), это +500 КБ JS и пара десятков сетевых запросов. На медленном 4G это секунда минимум.

Что делать:

• Оставить только то, что реально смотрите. Если в Top.Mail.Ru за полгода никто не заходил, удалить.
• Метрику грузить с атрибутом defer (с 2024 года Яндекс это поддерживает корректно).
• Heatmap’ы (тепловые карты) включать не на всех страницах, а только на ключевых для исследования — и выключать, когда исследование закончено.

Пункт 8: Кэш не настроен или настроен криво

Заголовки Cache-Control и Expires определяют, будет ли браузер скачивать статику повторно или возьмёт из кэша. Если заголовки кривые, на каждый визит пользователь снова тащит все CSS, JS, картинки.

Проверка:

curl -I https://yoursite.ru/wp-content/themes/mytheme/style.css

Смотрим заголовок Cache-Control. Должно быть max-age=31536000 для статики с версионированием (?ver=1.2.3) или max-age=2592000 для картинок без версии.

Что делать в .htaccess:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json
</IfModule>

Эффект на повторных визитах огромный: с 4 секунд до 0.8 секунды на втором заходе. На первом визите кэш не помогает, но это половина задачи.

Пункт 9: HTTP/2 не включён

Если хостинг отдаёт по HTTP/1.1, каждый ресурс — отдельное соединение. На сайте с 60 ресурсами (картинки, скрипты, стили, шрифты) это серьёзная задержка из-за лимита параллельных соединений в браузере (6 на домен).

Проверка:

curl -I --http2 https://yoursite.ru/ 2>&1 | grep -i "HTTP/"

Должно быть HTTP/2 200. Если HTTP/1.1, попросите хостера включить HTTP/2 (на нормальном хостинге это галочка в панели, на старом может потребовать миграцию на современный веб-сервер).

HTTP/3 (QUIC) на 2026 год имеют не все хостинги, но если есть — тоже включить. На мобильных с нестабильным соединением QUIC даёт ощутимый плюс к скорости.

Пункт 10: CSS-бандл на 400 КБ

Если в <head> грузится один большой style.css на 400 КБ, в котором стили на все случаи жизни (включая страницы, которых нет на текущей странице), браузер обязан скачать и распарсить всё это до начала рендера. На бюджетном Android-устройстве парсинг 400 КБ CSS — это +500-800 мс.

Что делать:

• Inline критического CSS в <head> (стили, нужные для первого экрана), остальное грузить асинхронно через <link rel="stylesheet" media="print" onload="this.media='all'">.
• Удалить неиспользуемые стили (PurgeCSS, UnCSS). На WordPress-теме Avada/Divi/Salient это часто +50% размера CSS, который никогда не используется.
• Если сайт многостраничный с разной версткой — не делать общий бандл, а грузить специфический CSS на специфические страницы.

Пункт 11: База данных раздулась

К WordPress пункту, но и к Битриксу относится. Через 3-4 года работы база данных WordPress спокойно может весить 800 МБ — 2 ГБ за счёт ревизий постов, transient-кэша, логов плагинов, осиротевших meta-полей. Каждый запрос к раздутой базе медленнее.

Проверка размера таблиц:

SELECT table_name AS "Table",
       ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "MB"
FROM information_schema.TABLES
WHERE table_schema = "your_db"
ORDER BY (data_length + index_length) DESC
LIMIT 20;

Если wp_posts весит больше 200 МБ при 500 опубликованных постах — это ревизии. Если wp_options больше 50 МБ — transient или раздутый autoload. Если wp_postmeta больше 500 МБ — осиротевшие meta после удаления плагинов.

Что делать:

• WP-CLI: wp post delete $(wp post list --post_type=revision --format=ids) --force.
• Плагин WP-Optimize или Advanced Database Cleaner для разовой чистки и регулярного maintenance.
• Для Битрикс — встроенный модуль «Производительность» с очисткой логов и кэша.
• После чистки — оптимизировать таблицы: OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options;.

Пункт 12: CDN не используется

Если сайт лежит на одном сервере в Москве, а пользователь сидит во Владивостоке, картинки летят через всю страну. Это не блокер, но 100-200 мс потерять можно.

Что делать: подключить CDN для статики. В 2026 рабочие варианты для русского трафика:

• Cloudflare с российскими PoP’ами (работает, хоть и с оговорками).
• Selectel CDN, VK Cloud CDN, Я.Облако CDN — российские провайдеры, без рисков по блокировкам.
• BunnyCDN — дёшево, но иногда отдаёт из европейских PoP’ов.

Подключение CDN на статичные ресурсы (картинки, шрифты, JS-библиотеки) дают +5-10 баллов в PageSpeed на мобильном. Динамику через CDN пускать имеет смысл только если у вас настроены правильные правила кэша.

Сводная таблица: что делать в первую очередь

Пункт	Сложность	Эффект на LCP	Время работы
1. TTFB / серверный кэш	средне	-800 мс	1-2 часа
2. WebP вместо JPG	низко	-500 мс	1-3 часа
3. Убрать lazy с hero	низко	-300 мс	10 минут
4. Async/defer на скрипты	низко	-400 мс	30 минут
5. font-display: swap	низко	-200 мс	15 минут
6. Виджеты с задержкой	средне	-600 мс	1 час
7. Чистка счётчиков	низко	-200 мс	30 минут
8. Cache headers	низко	-1500 мс на повтор	30 минут
9. HTTP/2	зависит от хостинга	-300 мс	5 минут
10. Critical CSS	сложно	-500 мс	4-8 часов
11. Чистка БД	средне	-400 мс TTFB	1-2 часа
12. CDN	средне	-100 мс по регионам	2-3 часа

Если выбирать топ-5 для быстрого эффекта: пункты 2, 3, 4, 5, 8. Это 3-5 часов работы и 25-35 баллов в PageSpeed Insights с гарантией.

Что НЕ ускорит сайт, хотя обещают

Есть несколько вещей, которые часто рекомендуют, но эффект от них или нулевой, или маркетинговый.

Минификация одного CSS на 5%. Сэкономит 5-10 КБ на бандле в 200 КБ. На LCP не повлияет, потому что узкое место не в размере CSS, а в его блокирующем рендере.

Переход с PHP 7.4 на 8.2 без других правок. Сам по себе PHP 8.2 быстрее на 15-20%, но если у вас узкое место в плагинах или базе, +20% скорости PHP-обработчика дадут +5% к итоговому TTFB. Эффект есть, но небольшой.

«Профессиональная оптимизация скорости» за 50 тысяч, которая сводится к установке плагина WP Rocket. Плагин нормальный, но он стоит 50 баксов в год, а не 50 тысяч за установку. Если вам предлагают пакет «оптимизации скорости» без конкретного аудита и без объяснения, что именно тормозит, это просто продажа плагина.

Compression Brotli вместо Gzip. Brotli лучше Gzip на 15%, но это копейки. Внедрять полезно, но как 13-й пункт после первых 12.

Когда зелёные баллы PageSpeed уже не помогают

Бывает: всё сделали, PageSpeed показывает 95 на десктопе и 85 на мобильном, а пользователи всё равно жалуются на медленный сайт. Возможные причины:

1. PageSpeed мерит лабораторные условия. Реальные пользователи могут быть в худших сетях.
2. Сайт быстро рендерится, но медленно реагирует на клик (плохой INP). Лечится оптимизацией JS-обработчиков.
3. Сайт быстро открывается, но потом медленно работает форма / корзина / другая интерактивная часть. Это уже не про скорость загрузки, а про скорость работы.

В таких случаях надо смотреть Real User Monitoring (RUM) — данные с реальных пользователей. Я.Метрика в разделе «Скорость загрузки» показывает реальные данные по визитам, разбитые по устройствам и регионам. Это надёжнее лабораторных замеров.

Если сами не хочется

Аудит мобильной скорости сайта с конкретным списком правок и приоритетами стоит обычно 8-15 тысяч рублей. Полная реализация всех 12 пунктов — от 25 до 60 тысяч в зависимости от CMS и сложности темы. Дальше регулярная поддержка скорости (потому что сайт периодически снова замусоривается) — часть стандартной абонентки.

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

В рубрике Скорость есть подробные разборы по Core Web Vitals, отдельно про LCP больше 2.5 секунд и про сжатие изображений в WebP/AVIF.

Частые вопросы

Почему сайт медленно открывается на телефоне

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

С чего начинать ускорение

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

Какие цифры считать нормой

LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1. Смотреть надо данные реальных посетителей, а не разовый лабораторный замер с офисной оптики.

Что делать со сторонними виджетами

Грузить по клику или по прокрутке. Чат, карта и видео тянут сотни килобайт своих скриптов, а нужны единицам посетителей.