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

Сначала уточните, что именно происходит на телефоне: долго нет ответа, поздно появляется главное содержимое, прыгают блоки или не реагирует кнопка — это разные задачи для диагностики

Один балл PageSpeed помогает заметить проблему, но не объясняет её целиком — для исправления нужны точный URL, условия и наблюдаемая задержка

Ниже — порядок проверки, с которым можно подготовить задачу разработчику и затем сравнить результат без подмены неудачного замера удачным

Что считать медленной загрузкой

Откройте страницу на телефоне и опишите последовательность — виден ли текст, когда появляется главное изображение, можно ли уже открыть меню и остаются ли блоки на месте

Пустой экран, поздняя картинка и задержка реакции выглядят как «сайт тормозит», но причины и проверка результата будут различаться

Запишите, возникает ли проблема при первом открытии, повторном визите или после перехода из другого приложения — кэш и способ запуска меняют условия

Не сравнивайте разные страницы как один объект — главная с анимацией и текстовая статья могут загружать разные ресурсы и иметь разные узкие места

Как собрать первый замер

Откройте PageSpeed Insights и вставьте полный адрес нужной страницы — проверяйте тот URL, на который приходит посетитель, а не похожую главную или страницу другого раздела

Запустите анализ и дождитесь отчёта — сначала прочитайте, какой адрес и момент проверки указаны в нём — если страница перенаправляет посетителя, сохраните и исходный, и итоговый адрес

Откройте вкладку мобильных устройств — в верхней части отчёта посмотрите наличие реальных пользовательских данных, а ниже найдите лабораторный анализ производительности

Запишите четыре оценки отдельно, но для задачи скорости выпишите именно Performance и его метрики — число SEO не является скоростью загрузки, а оценка доступности не сообщает, когда появилась обложка

Затем переключитесь на компьютер и сохраните его показатели отдельной строкой — это другой профиль измерения, поэтому усреднять два балла как «общую скорость сайта» не нужно

Скопируйте ссылку на отчёт — снимок круга без URL, даты и метрик трудно использовать для повторной проверки

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

По описанию PSI лабораторные данные помогают отладке, а полевые описывают опыт реальных посещений — при недостатке данных полевой блок может отсутствовать

Отсутствие полевых данных не означает, что сайт быстрый или медленный — это ограничение доступной выборки

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

Что делать с ошибкой вместо отчёта

Если сервис пишет, что страницу или ресурс не удалось получить, сохраните сообщение и адрес отчёта — отсутствие числового результата нельзя записывать как ноль или как успешные 100 баллов

Проверьте, открывается ли тот же URL в браузере, и передайте разработчику время сбоя — ему потребуется сравнить ответ сервера и доступность названного ресурса

Одного удачного открытия у вас недостаточно, чтобы объяснить тайм-аут из другой среды — но и один тайм-аут проверяющего сервиса ещё не доказывает постоянную недоступность сайта

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

Какие показатели отвечают на разные вопросы

LCP, CLS и INP входят в Core Web Vitals — web.dev указывает ориентиры: LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1 на 75-м процентиле посещений с раздельной оценкой мобильных и настольных устройств

Эти пороги относятся к соответствующим метрикам — они не означают обещание загрузить любую страницу за одинаковое время на любом телефоне

75-й процентиль можно понимать так: выбранная граница включает не менее 75% учтённых значений — для каждого показателя она оценивается отдельно

Посмотрите и область данных — если сервис показывает значения всего сайта вместо конкретного URL, подпишите это в журнале — такой результат нельзя автоматически приписать одной статье

Основной поток — часть работы браузера, где выполняются многие действия JavaScript, расчёты страницы и обработка взаимодействий — длительная непрерывная задача может отложить реакцию на касание

TBT помогает оценить блокирующую работу в лабораторном интервале — INP относится к отклику на взаимодействия — поэтому одинаковая единица «миллисекунды» не делает показатели взаимозаменяемыми

TBT лабораторного запуска не является измеренным INP реальных посетителей — не подставляйте одно число вместо другого

Как перейти от метрики к конкретной задаче

Начните с симптома и связанной метрики — затем найдите в отчёте элемент или запрос, который объясняет задержку — список общих рекомендаций ещё не определяет приоритет работы

Учебный пример чтения двух блоков отчёта

Представим мобильный лабораторный запуск услуги мастерской: LCP 3,1 секунды, CLS 0,03, TBT 0 миллисекунд — полевых данных для URL нет

Из такого набора видно, что главное содержимое появляется позднее ориентира LCP, а в измеренной первоначальной загрузке нет большой суммы блокировок по TBT

При этом нельзя заключить, что меню всегда быстро отвечает посетителям — INP не получен, и сам лабораторный запуск мог вообще не включать нужное взаимодействие

В рабочем файле эти источники хранятся раздельно — строка лабораторного запуска не должна получать придуманный INP только ради заполнения таблицы

Как прочитать разбивку LCP

Для LCP-изображения полезно разделить четыре части пути: ожидание начала ответа документа, задержку до загрузки нужного ресурса, саму загрузку и ожидание его показа

Рассмотрим учебный расчёт — это условные значения для объяснения, не измерение сайта KEIVO или клиента

Если в этом расчёте уменьшить только загрузку с 500 до 250 миллисекунд, итог станет 2850 миллисекунд — улучшение есть, но ориентир 2,5 секунды ещё не достигнут

Наибольшие части здесь связаны с поздним началом загрузки и ожиданием отрисовки — именно их нужно исследовать, а не обещать решить всё ещё одним сжатием картинки

У текстового LCP структура объяснения отличается — отдельного файла изображения может не быть — поэтому сначала определяется фактический элемент, а уже затем выбирается способ оптимизации

Почему главное изображение появляется поздно

Попросите разработчика определить фактический LCP-элемент в отчёте — им может быть крупный текст, а не обложка, которую решили сжать первой

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

Картинки ниже первого экрана можно загружать позже — но назначать lazy-загрузку главному видимому изображению без анализа рискованно

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

Что делать со сдвигами и зависаниями

Как проверить причину сдвига

Откройте страницу заново и наблюдайте за местом, где читаете текст — если абзац отодвинулся после появления картинки, отметьте этот момент и блок

Попросите разработчика проверить, зарезервировано ли место до получения изображения — для исходника 960×640 соотношение сторон составляет 3:2, поэтому область можно подготовить до загрузки самих пикселей

При этом резерв должен соответствовать реальному способу показа — фиксированная высота, подходящая широкому экрану, может оказаться неверной в узкой колонке

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

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

Как проверить задержку реакции

Запишите одно действие, которое ощущается медленным — например, касание кнопки меню — отдельно укажите, сразу ли появляется обратная связь и когда панель становится пригодной для управления

Если полевой INP недоступен или не объясняет конкретный случай, разработчик может записать это взаимодействие на панели Performance в Chrome DevTools

Последовательность проверки: начать запись, выполнить проблемное действие, остановить запись и сопоставить событие с работой основного потока — в задаче должен появиться конкретный обработчик или другая подтверждённая часть работы

Просто удалить произвольный скрипт из отчёта недостаточно — после изменения необходимо повторить само взаимодействие и проверить, что сохранились нужные функции страницы

Как выбрать порядок оптимизации

Если долго не появляется сам документ

Уточните симптом: после открытия адреса ещё нет основного содержимого, а не только одной фотографии — затем попросите разработчика проверить запрос HTML-документа

Для самостоятельного первичного наблюдения откройте DevTools, перейдите в Network и перезагрузите страницу — панель начнёт показывать запросы, совершённые при загрузке

Найдите документ нужного адреса — в фильтре типов он обычно относится к Doc — сравните адрес, статус, последовательность перенаправлений и время ожидания ответа

В инструкции Chrome по Network показаны список запросов и сведения об отдельном ресурсе — для задачи важно сохранить именно запрос документа, а не время произвольной картинки

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

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

После исправления повторите получение того же адреса и проверьте, что итоговая страница сохранила содержание, правильный адрес и доступ к действию

Как связать наблюдение с ответственным

Для документа передайте запрос и время ожидания тому, кто отвечает за сервер и маршрутизацию — для позднего обнаружения картинки нужны сведения о её включении в страницу и порядке загрузки

Для сдвига приложите момент появления блока и запись страницы — для медленного меню приложите действие и запись взаимодействия — общее «сайт медленный» не заменяет ни один из этих наборов

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

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

Такой порядок помогает не смешивать четыре разные работы в одну строку «ускорить сайт» — у каждой будут своё доказательство и способ проверки

Для первого исправления выберите подтверждённое узкое место с заметным вкладом в нужный сценарий — после изменения повторите измерение, прежде чем переходить к следующему предположению

Изменения сторонней аналитики, согласий и виджетов согласуйте отдельно с владельцем — сначала установите их вклад, затем определите допустимое поведение, сохраняя требования приватности

Как поставить задачу по одному узкому месту

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

В задаче сохраните исходный отчёт, фактический элемент и способ сравнения — не обещайте конкретный прирост до измерения

Если проблема в долгом ответе документа, задача по изображениям не подтверждает устранение причины — разработчику нужны данные сети и сервера, а не только список советов из другого URL

Начните с одного подтверждённого узкого места — после изменения проверьте затронутые соседние страницы общего шаблона

Можно ли требовать 100 в PageSpeed

Можно поставить 100 как целевой лабораторный результат — но принимать работу нужно вместе с условиями, метриками и проверкой сценария

Chrome объясняет изменчивость оценки Lighthouse условиями измерения — удачный повтор не отменяет медленный исходный запуск

Не удаляйте нужное содержание, доступность или согласия ради круга — после оптимизации должны работать текст, меню, документы и предусмотренные действия

Как проверить результат на домене

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

Сравнивайте один и тот же URL и профиль устройства — сохраните исходную и новую версию сайта, даты, показатели и сообщения об ошибках

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

Не смешивайте в одном сравнении первый визит без кэша и повторный визит с уже загруженными ресурсами — если проверяете оба режима, подпишите их отдельно

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

Как закрыть задачу из учебного примера

В журнале исходной версии остаются LCP 3,1 секунды и разбивка на четыре части — рядом записывается выбранная гипотеза и изменение, которое её проверяет

В новой строке указываются версия после изменения, профиль устройства, ссылка на свежий отчёт и фактические метрики — если изменённое место не повлияло на нужный участок цепочки, гипотезу нужно пересмотреть

Отдельно повторяется маршрут посетителя: открыть услугу, прочитать условия и выполнить предусмотренное действие — успешная цифра не закрывает ошибку, появившуюся в этом маршруте

Так у задачи получается проверяемое завершение — не «ускорение сделано», а «изменён такой участок, показатели сравнили в таких условиях, путь посетителя повторён, оставшиеся ограничения перечислены»

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

Для визуальных ошибок используйте план проверки мобильной версии, для объёма работ — матрицу приёмки адаптива и описание услуги вёрстки

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

Достаточно ли данных для задачи

Те же пункты доступны без интерактива: условия, исходные измерения, проверяемая причина и повторный сценарий — список не запускает PageSpeed автоматически

Источники проверены 31 октября 2026 года — журнал и учебная задача подготовлены редакцией KEIVO