Зачем проверять скорость загрузки на мобильных
Скорость загрузки на мобильных устройствах — один из факторов ранжирования и в Яндексе, и в Google. Но важнее другое: медленный сайт теряет пользователей. По данным исследований, 53% мобильных пользователей покидают страницу, если она загружается дольше 3 секунд. Для коммерческого сайта каждая потерянная секунда — это потерянные заявки.
Мобильный трафик составляет 60–70% для большинства сайтов в рунете. При этом мобильные устройства работают в условиях, которые отличаются от десктопа: менее мощный процессор, нестабильное соединение (3G, перегруженный Wi-Fi), ограниченная оперативная память. Страница, которая загружается за 1.5 секунды на компьютере с оптоволокном, на смартфоне в метро может грузиться 8–10 секунд.
Google использует метрики Core Web Vitals как сигнал ранжирования, и все три ключевые метрики (LCP, INP, CLS) измеряются именно на мобильных устройствах. Яндекс в своих рекомендациях также указывает на скорость загрузки как фактор качества сайта и учитывает его при ранжировании. По моему опыту, улучшение мобильного балла PageSpeed с 30 до 75 даёт заметный рост поведенческих факторов: снижается показатель отказов, растёт глубина просмотра.
Пошаговая инструкция
Шаг 1. Измерьте текущую скорость
Начните с объективной оценки. Откройте PageSpeed Insights (pagespeed.web.dev) и проверьте мобильную версию главной страницы и 3–5 ключевых страниц (основная услуга, каталог, статья блога, контакты). Зафиксируйте:
- Performance Score — общая оценка от 0 до 100. Целевое значение — 70 и выше. Ниже 50 — критическая проблема.
- Largest Contentful Paint (LCP) — время загрузки основного контента. Хорошо: до 2.5 сек. Плохо: больше 4 сек.
- Interaction to Next Paint (INP) — отзывчивость при взаимодействии. Хорошо: до 200 мс. Плохо: больше 500 мс.
- Cumulative Layout Shift (CLS) — визуальная стабильность, сдвиги элементов при загрузке. Хорошо: до 0.1. Плохо: больше 0.25.
PageSpeed Insights показывает два типа данных: лабораторные (синтетический тест) и полевые (реальные данные пользователей из Chrome UX Report). Полевые данные приоритетнее — именно их использует Google для ранжирования. Если полевых данных нет (мало трафика), ориентируйтесь на лабораторные.
Шаг 2. Определите главные проблемы
PageSpeed Insights выдаёт список рекомендаций с указанием потенциальной экономии времени. Не бросайтесь исправлять всё подряд — начните с пунктов, дающих максимальный эффект. Вот основные проблемы, которые я встречаю на большинстве сайтов:
Тяжёлые изображения. Самая частая причина медленной загрузки. Фотографии по 2–5 МБ в формате JPEG или PNG, загруженные без сжатия. Решается конвертацией в WebP/AVIF, сжатием и правильными размерами — об этом есть отдельная инструкция по оптимизации изображений.
Блокирующий JavaScript. Скрипты, которые загружаются в <head> без атрибутов defer или async, блокируют рендеринг страницы. Браузер не покажет контент, пока не загрузит и не выполнит все блокирующие скрипты. Особенно критично для мобильных, где скорость выполнения JS в 3–5 раз ниже, чем на десктопе.
Сторонние скрипты. Яндекс Метрика, виджеты чатов, callback-сервисы, рекламные пиксели — каждый добавляет 100–500 мс к загрузке. Три-четыре таких сервиса — и секунда потеряна. При этом отказаться от Метрики нельзя, но загружать её нужно правильно.
Неоптимизированные шрифты. Кастомные веб-шрифты загружаются как отдельные файлы. Если шрифтов несколько начертаний (Regular, Bold, Italic, Light) — это 200–800 КБ дополнительной нагрузки. Пока шрифты не загружены, текст может быть невидим (FOIT) или отображаться системным шрифтом, а затем перерисовываться (FOUT), что вызывает Layout Shift.
Неоптимизированный CSS. Большой файл стилей, из которого на конкретной странице используется 10–20%. Браузер загружает весь файл и парсит его целиком, прежде чем начать отрисовку.
Шаг 3. Оптимизируйте загрузку JavaScript
Добавьте атрибут defer ко всем скриптам, которые не нужны для первого отображения страницы. Атрибут defer говорит браузеру: «Загрузи скрипт параллельно, но выполни только после парсинга HTML».
<!-- Было: блокирующий скрипт -->
<script src="main.js"></script>
<!-- Стало: не блокирует рендеринг -->
<script src="main.js" defer></script>Для сторонних скриптов, которые не критичны для первого отображения (аналитика, виджеты чатов, callback), используйте отложенную загрузку. Загружайте их после события DOMContentLoaded или после первого взаимодействия пользователя со страницей:
<script>
document.addEventListener('DOMContentLoaded', function() {
// Загрузка Яндекс Метрики через 2 секунды после DOM ready
setTimeout(function() {
var s = document.createElement('script');
s.src = 'https://mc.yandex.ru/metrika/tag.js';
s.async = true;
document.head.appendChild(s);
}, 2000);
});
</script>Для WordPress удобнее управлять загрузкой скриптов через плагины (Perfmatters, Asset CleanUp) или напрямую через functions.php с помощью wp_script_add_data($handle, 'strategy', 'defer') в WordPress 6.3+.
Шаг 4. Оптимизируйте шрифты
Загружайте только те начертания, которые реально используются. Если на сайте используются Regular и Bold — не подключайте Light, Medium, Italic. Каждое лишнее начертание — это 50–150 КБ.
- Используйте формат WOFF2 — он сжат лучше всего и поддерживается всеми современными браузерами.
- Добавьте
font-display: swapв директиву@font-face— текст будет виден сразу системным шрифтом, а после загрузки кастомного шрифта перерисуется. Это устраняет проблему невидимого текста (FOIT). - Используйте
<link rel="preload">для основного шрифта — браузер начнёт его загружать раньше:
<link rel="preload" href="/fonts/main-font.woff2" as="font" type="font/woff2" crossorigin>Ещё один вариант — системные шрифты. Стек font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif даёт приемлемый результат без загрузки дополнительных файлов и экономит 200–500 мс на мобильных.
Шаг 5. Сократите сторонние скрипты
Проведите аудит всех сторонних скриптов на сайте. Откройте DevTools (F12), вкладка Network, обновите страницу и отфильтруйте по типу JS. Посмотрите, какие скрипты загружаются с внешних доменов, и оцените их размер и время загрузки.
Типичные «пожиратели скорости»:
- Виджеты онлайн-чатов (JivoSite, Carrot Quest, Talk-Me) — 200–500 КБ JavaScript. Если чат не даёт значимого количества обращений, уберите его и замените ссылкой на мессенджер.
- Callback-виджеты (CallbackHunter, Envybox) — ещё 100–300 КБ. Оцените, сколько обратных звонков он генерирует. Если менее 5 в месяц — виджет замедляет сайт больше, чем приносит пользы.
- Множество счётчиков аналитики. Яндекс Метрика + пиксель VK + пиксель MyTarget + другие. Оставьте только те, которые реально используете для аналитики и рекламы.
- Встроенные видео с YouTube. Каждый iframe YouTube загружает 500–700 КБ скриптов. Используйте фасады: вместо iframe покажите превью-картинку, а iframe загружайте только по клику. Для WordPress есть плагин Lite YouTube Embed или аналоги.
Шаг 6. Настройте кэширование
Браузерное кэширование не ускоряет первую загрузку, но радикально ускоряет повторные визиты. Настройте HTTP-заголовки для статических ресурсов:
# .htaccess (Apache) или аналогичные директивы для Nginx
# Кэширование изображений, шрифтов, CSS и JS
# Изображения — 1 год
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
# Шрифты — 1 год
ExpiresByType font/woff2 "access plus 1 year"
# CSS и JS — 1 месяц (могут обновляться чаще)
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"Для WordPress рассмотрите плагины кэширования серверного рендеринга: WP Super Cache, W3 Total Cache или LiteSpeed Cache (если сервер на LiteSpeed). Серверный кэш отдаёт готовый HTML вместо генерации страницы через PHP при каждом запросе — разница может составлять 500–1500 мс.
Шаг 7. Включите сжатие
Убедитесь, что на сервере включено сжатие Gzip или Brotli. Brotli даёт сжатие на 15–20% лучше, чем Gzip, и поддерживается всеми современными браузерами. Проверьте наличие сжатия:
- Откройте DevTools → Network → выберите HTML-документ → Headers → ищите
content-encoding: br(Brotli) илиcontent-encoding: gzip. - Если заголовка нет — сжатие не настроено, и браузер получает несжатые файлы.
На Nginx сжатие включается в конфигурации сервера. На Apache — через mod_deflate. Для WordPress-хостингов сжатие обычно включено по умолчанию, но лучше проверить.
Шаг 8. Проверьте результат
После оптимизации повторно проверьте PageSpeed Insights. Сравните мобильный балл до и после. Если балл вырос, но остаётся ниже 70, обратите внимание на оставшиеся рекомендации — обычно на этом этапе самые тяжёлые проблемы решены, и дальнейшая оптимизация требует более точечных действий.
Также проверьте реальную скорость в Яндекс Метрике: отчёт «Мониторинг» → «Время загрузки страниц». Здесь вы увидите медианное время загрузки по реальным пользователям — это самый честный показатель, без лабораторных условий.
Типичные ошибки
- Оптимизация только главной страницы. Главная получает 70 баллов, а страница каталога с 50 карточками товаров — 25. Каждый тип страницы нужно проверять отдельно. Особенно часто проседают страницы с галереями, таблицами и встроенными видео.
- Установка «плагина скорости» без настройки. Плагин кэширования без правильной конфигурации может ухудшить ситуацию: ломать динамические элементы, кэшировать авторизованных пользователей, конфликтовать с другими плагинами. Каждый плагин требует тестирования после установки.
- Удаление Яндекс Метрики ради скорости. Метрика нужна для аналитики — без неё вы слепы. Вместо удаления загружайте её отложенно: через
setTimeoutили после первого взаимодействия пользователя. Балл PageSpeed вырастет, аналитика продолжит работать. - Игнорирование Layout Shift (CLS). Баннеры без заданных размеров, шрифты, которые подгружаются и меняют высоту строк, вставки рекламы, которые сдвигают контент — всё это ухудшает CLS. Пользователь начинает читать, и текст прыгает вниз. Раздражает и наказывается поисковыми системами.
- Зацикленность на баллах вместо реальной скорости. Балл 95 в PageSpeed при реальном времени загрузки 5 секунд — бессмысленно. И наоборот: балл 65 при быстрой реальной загрузке — нормальная ситуация. Ориентируйтесь на полевые данные Core Web Vitals и на ощущения при тестировании на реальном устройстве.
- Одна большая связка CSS для всего сайта. Файл стилей на 300 КБ, из которых на конкретной странице используется 30 КБ. Браузер вынужден скачать и распарсить весь файл перед первой отрисовкой. Разбейте CSS: критические стили — инлайном в
<head>, остальное — через<link rel="preload">или в отдельных файлах по страницам. - Отсутствие lazy loading для изображений ниже первого экрана. Все изображения загружаются сразу при открытии страницы, хотя пользователь видит только первые 1–2 картинки. Остальные нужно загружать по мере прокрутки — атрибут
loading="lazy"решает это без единой строки JavaScript.
Что проверить в итоге
- PageSpeed Insights мобильный балл — 70 или выше для всех основных типов страниц
- LCP — не более 2.5 секунд по полевым данным
- INP — не более 200 мс
- CLS — не более 0.1
- Все скрипты в <head> имеют атрибут defer или async (кроме критичных)
- Сторонние скрипты загружаются отложенно — после DOMContentLoaded или по взаимодействию
- Шрифты в формате WOFF2 с font-display: swap, подключены только используемые начертания
- Настроено браузерное кэширование для статических ресурсов (изображения, шрифты, CSS, JS)
- Включено серверное сжатие Gzip или Brotli
- Для WordPress настроен плагин серверного кэширования и проверена корректность его работы
- Изображения ниже первого экрана загружаются с атрибутом loading=»lazy»
- У изображений и iframe заданы атрибуты width и height для предотвращения Layout Shift
- Проверена реальная скорость в Яндекс Метрике — отчёт «Время загрузки страниц»
