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

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

Автор: Редакция KEIVO
Дата публикации: 2026-10-31
Канонический URL: https://keivo.ru/blog/sayt-medlenno-zagruzhaetsya-na-telefone/

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



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

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

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

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

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

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

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


![Генеративная иллюстрация: страница с загружающимся изображением на телефоне в кафе](/blog/_media/m7-20261031/m25-cover-2666ebf23f95.webp)

Генеративная иллюстрация KEIVO — вымышленный интерфейс, не снимок клиентского сайта и не результат измерения



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

Откройте [PageSpeed Insights](https://pagespeed.web.dev/) и вставьте полный адрес нужной страницы — проверяйте тот URL, на который приходит посетитель, а не похожую главную или страницу другого раздела

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

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

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

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

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

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

По [описанию PSI](https://developers.google.com/speed/docs/insights/v5/about) лабораторные данные помогают отладке, а полевые описывают опыт реальных посещений — при недостатке данных полевой блок может отсутствовать

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

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

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

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

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

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

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

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




| Вопрос | На что смотреть | Что проверить дополнительно |
|---|---|---|
| Когда появилось главное содержимое | LCP | Какой элемент оказался крупнейшим и что задержало его показ |
| Почему страница прыгает | CLS | Какие блоки смещаются при загрузке и после действий |
| Почему касание получает поздний ответ | INP в полевых данных | Какое взаимодействие тормозит и что выполняется в этот момент |
| Почему загрузка заняла время | Сеть и ответ документа | Сервер, перенаправления, размеры и цепочки ресурсов |
| Почему лабораторный запуск занят скриптами | TBT и диагностика задач | Какие скрипты блокируют основной поток |




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

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

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

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

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

[TBT](https://web.dev/articles/tbt) помогает оценить блокирующую работу в лабораторном интервале — INP относится к отклику на взаимодействия — поэтому одинаковая единица «миллисекунды» не делает показатели взаимозаменяемыми

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

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

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

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

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

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

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




| Источник в примере | Известно | Чего вывод не подтверждает | Следующее действие |
|---|---|---|---|
| Лабораторный запуск | LCP 3,1 с | Что задержка вызвана только весом изображения | Определить LCP-элемент и прочитать разбивку времени |
| Лабораторный запуск | CLS 0,03 | Отсутствие сдвигов после всех действий посетителя | Проверить состояния меню, сообщений и встраиваемых блоков |
| Лабораторный запуск | TBT 0 мс | Хороший INP реальных посещений | Отдельно проверить проблемное взаимодействие |
| Полевой блок | Данных нет | Хорошую или плохую скорость аудитории | Зафиксировать отсутствие выборки, продолжить лабораторную диагностику и проверку сценария |




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

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

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

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




| Часть пути | Время в примере | Что выяснить |
|---|---|---|
| Начало ответа документа | 600 мс | Сколько времени заняли сервер и путь получения документа |
| Ожидание начала загрузки картинки | 1100 мс | Почему браузер поздно обнаружил или начал получать изображение |
| Загрузка картинки | 500 мс | Подходит ли размер и формат для области показа |
| Ожидание отрисовки | 900 мс | Что мешало показать уже полученное содержимое |
| Всего | 3100 мс | Нужен разбор всей цепочки, а не одного размера файла |




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

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

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

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

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

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

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

Если ресурс уже получен, а показ задерживается, дальнейшее сжатие может не закрыть основную причину — [разбор оптимизации LCP](https://web.dev/articles/optimize-lcp) отдельно рассматривает загрузку ресурса и задержку отрисовки

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

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

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

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

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

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

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

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

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

Если полевой INP недоступен или не объясняет конкретный случай, разработчик может записать это взаимодействие на панели [Performance в Chrome DevTools](https://developer.chrome.com/docs/devtools/performance/overview)

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

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

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

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

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

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

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

В [инструкции Chrome по Network](https://developer.chrome.com/docs/devtools/network/) показаны список запросов и сведения об отдельном ресурсе — для задачи важно сохранить именно запрос документа, а не время произвольной картинки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Chrome объясняет изменчивость оценки Lighthouse](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) условиями измерения — удачный повтор не отменяет медленный исходный запуск

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

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

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

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

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

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

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

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

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

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

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

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

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

Для визуальных ошибок используйте [план проверки мобильной версии](/blog/proverit-mobilnuyu-versiyu-sayta/), для объёма работ — [матрицу приёмки адаптива](/blog/adaptivnaya-verstka-sayta/) и [описание услуги вёрстки](/services/verstka/)

[Скачать журнал измерений скорости](/materials/m7-zhurnal-skorosti.md) — с полями для неудачных запусков, выбранного узкого места и повторной проверки

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




- [ ] Записаны условия и проблема


- [ ] Есть исходные измерения


- [ ] Выбрана причина для проверки


- [ ] Подготовлена проверка результата






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

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