Сайт медленно грузится на телефоне: как найти причину в PageSpeed и DevTools

У двух страниц может быть одинаковый балл PageSpeed, а тормозить они будут по-разному. На одной долго висит пустой экран. На другой текст появляется сразу, но обложка догружается последней. На третьей всё видно, однако меню после нажатия не открывается сразу. Если во всех трёх случаях начать со сжатия картинок, только на одной странице это может решить главную проблему.

Быстрый маршрут: возьмите один проблемный URL, откройте мобильный отчёт PageSpeed Insights, затем воспроизведите симптом в Chrome DevTools. Найдите, где потеряно время, исправьте одну причину и повторите замер в тех же условиях.

Начните с симптома, который видит посетитель

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

Прочитайте мобильный отчёт PageSpeed Insights

Вставьте URL проблемной страницы в PageSpeed Insights и выберите «Мобильные». Не подставляйте главную, если медленная именно карточка товара, статья или галерея: у них разные ресурсы и разные причины задержки.

В отчёте два типа данных:

• Опыт реальных пользователей (CrUX) — сводка за последние 28 дней. Смотрите, показаны данные конкретного URL или всего сайта. Для нового адреса или сайта с небольшим трафиком их может не быть.
• Лабораторная диагностика (Lighthouse) — отдельный запуск с заданными условиями. Она помогает воспроизвести проблему и проверить изменение сегодня. Её балл не заменяет полевые данные.

Ориентиры относятся к 75-му процентилю полевых данных: для оценки берут значение, в которое укладываются как минимум 75% наблюдений по метрике. Нельзя заключить, что у реальных посетителей хороший INP, если один запуск Lighthouse показал низкий TBT. TBT полезен для поиска блокирующего JavaScript при загрузке, а задержку меню лучше записать отдельно. Официальное описание PageSpeed · Метрики Web Vitals.

Проверьте загрузку в Network

1. Откройте страницу в Chrome и запустите DevTools. Включите режим устройства, выберите мобильную ширину и зафиксируйте её.
2. В Network включите Disable cache и выберите один профиль ограничения сети. Отключение кэша действует, пока DevTools открыты. Запишите, какой профиль использовали.
3. Перезагрузите страницу. Выберите запрос Document, откройте Timing и посмотрите, где задержка: соединение, ожидание ответа или скачивание.
4. Переключитесь на изображения, затем на скрипты. Для каждого подозрительного ресурса сравните Size, начало и длину полосы Waterfall, а также Initiator — что запустило запрос.

Одна длинная полоса в Waterfall ещё не объясняет проблему. Если обложка начала качаться поздно, проверьте, когда она стала известна браузеру: её мог добавить скрипт или открыть только после загрузки CSS. Если запрос стартовал рано, но долго скачивался, проверьте размер и выбранный вариант картинки. Для изображения первого экрана не ставьте loading="lazy"; для остальных сначала убедитесь, что они действительно находятся ниже видимой области. Разбор причин медленного LCP.

Для быстрой перепроверки документа можно выполнить GET-запрос из терминала. Подставьте конечный URL без редиректа:

curl -sS -o /dev/null \
  -w 'HTTP %{http_code}\nПервый байт: %{time_starttransfer} с\nВесь ответ: %{time_total} с\n' \
  https://example.com/page/

time_starttransfer учитывает путь запроса и ожидание первого байта. Это не чистое время исполнения PHP и не время отрисовки страницы. Если у документа высокий TTFB и в браузере, и в нескольких запросах с разных подключений, дальше смотрите журналы и время обработки на сервере. Если медленно только на одном подключении, проверьте DNS, сеть и перенаправления, прежде чем менять сервер.

Запишите Performance: что именно опоздало

Для медленного первого экрана начните запись с перезагрузкой страницы. В отчёте найдите метку LCP и посмотрите, какой элемент браузер посчитал самым крупным. Сопоставьте её с запросом этого элемента в Network. Если это заголовок, а не картинка, искать причину только в размере фотографий бессмысленно: проверьте шрифты, CSS и занятость основного потока.

Для задержки после нажатия запишите другой сценарий: дождитесь загрузки, начните запись, один раз нажмите проблемную кнопку и остановите запись после реакции интерфейса. Посмотрите дорожку взаимодействий и Main вокруг нажатия. Так можно увидеть, что отнимает время: обработчик события, пересчёт стилей или отрисовка. Для прыгающей кнопки откройте событие Layout shift и посмотрите, какие элементы сдвинулись. Документация Chrome DevTools.

Реальный пример: сколько весят оригиналы и превью в галерее

В локальном пакете подборки обоев для iPad у каждой карточки есть уменьшенные WebP для просмотра и отдельная ссылка на оригинал. Ниже — размеры трёх изображений в разных вариантах из проекта. Сравнение показывает, сколько байтов экономится, если браузеру для карточки подходит превью шириной 360 или 720 px, а не полный JPG.

Для этих трёх карточек вариант 360 px меньше оригиналов примерно на 95%, вариант 720 px — на 83%. Экономия получилась за счёт уменьшения размеров и смены формата вместе. Это измерение файлов на диске, а не тест времени загрузки или результат PageSpeed. В реальном браузере выбранный файл зависит от ширины карточки и плотности экрана; его видно в Network. Оригиналы по кнопке скачивания сохранились в полном качестве.

Для своей галереи подготовьте копии в конвертере WebP, укажите варианты в srcset и фактическую ширину карточки в sizes. Задайте width и height, чтобы браузер мог зарезервировать пропорции до загрузки. Проверьте отдельно обычный телефон и экран с высокой плотностью пикселей: на них браузер может выбрать разные файлы.

Исправьте одну причину и повторите замер

• Поздно появляется HTML. Сначала отделите редиректы и сетевую задержку от обработки на сервере. Смотрите время ответа того же URL, затем журналы приложения. Если нужен кэш, начните с публичной страницы и убедитесь, что не кэшируете личные данные.
• Поздно появляется обложка. Для большой картинки на первом экране проверьте, есть ли она в начальном HTML и не отложена ли её загрузка. Если запрос уже начинается рано, сравните размер вариантов и качество.
• Дёргается вёрстка. Выделите место для изображения, баннера или виджета до его загрузки. После исправления повторите запись и проверьте, не остался ли сдвиг из другого блока.
• Кнопка реагирует с задержкой. Воспроизведите конкретное нажатие. Если время тратится в длинном обработчике, сократите объём работы в нём или перенесите необязательные вычисления. Проверьте, что сам сценарий по-прежнему работает.

Для сравнения запустите по три замера до и после с тем же URL, профилем сети, шириной экрана и режимом кэша. Сравните медиану нужной метрики и разброс. Запишите, что меняли: «обложка 720 px вместо оригинала» даёт больше информации, чем «оптимизировали сайт». Проверьте итог на телефоне. Полевой отчёт обновляется по мере накопления новых визитов, поэтому в день исправления может почти не измениться.

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

🟣Почему PageSpeed даёт разный балл при повторном запуске?

У лабораторного запуска меняются условия: отклик сервера, сеть, работа внешних скриптов. Сравнивайте несколько запусков в одинаковом режиме и смотрите на конкретную метрику или проблемный ресурс. Один высокий балл не подтверждает, что исправление стабильно помогает посетителям.

🟢Что делать, если PageSpeed пишет, что данных о реальных пользователях нет?

Проверьте, есть ли данные для всего сайта. Для диагностики конкретной страницы используйте Lighthouse, запись в DevTools и тест на реальном телефоне. Укажите в отчёте, что вывод основан на лабораторных замерах: они не описывают весь трафик сайта.

🔵Почему сайт быстрый на Wi-Fi, но медленный по мобильной сети?

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