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

Проверяйте скорость на конкретных страницах и действиях: когда появляется главное содержание, как быстро отвечает кнопка и не смещается ли форма. Сопоставьте данные реальных посетителей с лабораторным тестом, найдите ресурс или скрипт, который создаёт задержку, затем повторите измерение и пройдите путь заявки. Один балл PageSpeed без URL, устройства и условий не показывает, что нужно исправлять.

Какие страницы взять для первой проверки

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

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

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

Что измеряют LCP, INP и CLS

Core Web Vitals, или основные показатели удобства веб-страниц, описывают три разных события. LCP, Largest Contentful Paint, показывает, когда появился крупнейший видимый элемент содержания. INP, Interaction to Next Paint, оценивает задержку отклика после взаимодействий. CLS, Cumulative Layout Shift, измеряет неожиданные смещения макета. Это не синонимы «времени полной загрузки»; страница может быстро появиться, но плохо реагировать на нажатие.

В документации web.dev хорошими порогами названы LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1. Проверку ведут по 75-му перцентилю реальных посещений отдельно для мобильных и настольных устройств. Перцентиль означает, что 75% измерений укладываются в это значение; остальные 25% могут быть хуже. Порог не является обещанием позиции или числа продаж.

Почему PageSpeed и реальные посетители показывают разное

Лабораторный тест запускает страницу в заданных условиях и полезен для поиска причины. Полевые данные собираются при реальных посещениях с разными устройствами, сетями, кешем и действиями. web.dev отдельно объясняет, почему результаты двух методов могут расходиться. Например, у лабораторного пользователя крупнейший элемент один, а у реальных людей на разных экранах или при персонализации другой.

PageSpeed Insights может показывать данные для точного URL либо для всего источника, если отдельной странице данных недостаточно. Перед выводом проверьте подпись блока. Агрегат всего домена не подтверждает качество конкретной формы заказа. Полевой отчёт CrUX использует скользящий период 28 дней, поэтому исправление сегодня не обязано завтра полностью изменить агрегированную цифру. Лабораторный тест может показать эффект сразу; полевые показатели проверяют позже на сопоставимой аудитории.

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

Как найти причину позднего первого экрана

Начните с фактического LCP-элемента в отчёте. Им бывает изображение, крупный текст или другой видимый блок. Затем разберите путь до его появления: когда пришёл первый ответ сервера, когда браузер обнаружил нужный ресурс, сколько заняла передача и что задержало отрисовку. На странице с медленным сервером сжатие маленькой иконки почти не повлияет на первый экран. На странице с обложкой, найденной только после выполнения скрипта, причина может быть в позднем обнаружении изображения.

Для изображения проверьте размеры файла, реальное разрешение на телефоне, формат и порядок загрузки. Важную обложку первого экрана обычно не следует откладывать через loading="lazy": web.dev отмечает, что это может задержать LCP. Изображения ниже первого экрана, наоборот, можно загружать по мере прокрутки. Приоритет загрузки и предзагрузка применяются к действительно важному ресурсу после проверки водопада запросов, иначе они отберут сеть у других нужных файлов.

Если главным элементом стал текст, посмотрите блокирующие стили, шрифты и работу сервера. Проверьте, виден ли текст до загрузки нестандартного шрифта и не меняет ли запасной шрифт макет. Если сторонний скрипт вставляет первый экран, оцените, можно ли отрисовать основное предложение без ожидания этого скрипта. Каждое изменение проверяйте на фактическом URL и на телефоне; оптимизированный файл может потерять читабельность схемы или резкость фотографии.

Что делать, если кнопка открывается с задержкой

INP связан с взаимодействиями за время пребывания на странице. Найдите конкретное действие, которое медленно: открыть меню, выбрать фильтр, добавить товар, отправить форму. В инструментах разработчика посмотрите длительные задачи главного потока и работу после события. Даже когда страница уже видна, большой JavaScript может занимать процессор и мешать браузеру показать ответ на нажатие.

Разделите тяжёлую обработку на части, уберите ненужный код из первого экрана, отложите функции, которые не нужны до действия пользователя, и проверьте сторонние виджеты. Для фильтра каталога важны число элементов и объём пересчёта; для формы важно не блокировать интерфейс ожиданием аналитики или внешнего уведомления. Архитектурное решение зависит от сайта, поэтому рекомендация «удалить все скрипты» опасна: можно сломать заказ, согласие или измерение.

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

Как обнаружить смещение макета, которого нет на скриншоте

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

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

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

Когда причина в сервере, кеше или третьей стороне

Медленный первый ответ может задержать все ресурсы. Посмотрите время ответа на нескольких страницах и при повторном запросе, различайте генерацию страницы и передачу статических файлов. Если проблема появляется только на страницах каталога, проверьте запросы к базе, фильтры и сторонние программные интерфейсы (API). Если медленно всё, смотрите инфраструктуру и блокирующие операции. Один TTFB, то есть время до первого байта ответа, не объясняет всю загрузку, но помогает выбрать место расследования.

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

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

Как выбрать первую правку по результатам измерения

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

Не считайте предполагаемую экономию секунд суммой из всех подсказок Lighthouse: они могут пересекаться и измерены в одной лабораторной среде. Сделайте одну ограниченную правку, повторите тест, затем переходите к следующей. Для сложной страницы возможен пакет связанных работ, но сохраняйте запись о том, что изменено. Без неё невозможно объяснить результат после выпуска.

Как читать отчёт PageSpeed по шагам

Откройте точный URL и выберите мобильный режим. Проверки одного домена недостаточно. Сначала посмотрите, есть ли блок реальных данных и к чему он относится: к этой странице или ко всему источнику. Запишите период и три показателя Core Web Vitals. Затем перейдите к лабораторному результату. Найдите фактический LCP-элемент, список длинных задач и смещений. Подсказки ниже отчёта используйте как гипотезы для проверки на выбранной странице. Они не гарантируют экономию.

Если полевая оценка плохая, а лаборатория хорошая, проверьте регион, сеть, устройства и действия посетителей. Возможно, тестовый прогон не открывал меню или корзину, где возникает медленный INP. Если лаборатория плохая, а полевые данные пока хорошие, посмотрите, не изменился ли недавно сайт и достаточно ли свежие полевые измерения. Скользящий период сохраняет старые посещения. В обоих случаях фиксируйте различие, без усреднения двух разных цифр.

Число «производительность» в Lighthouse удобно для навигации по проблемам, но оно составлено из нескольких лабораторных метрик. Приёмку лучше привязать к конкретному действию и показателю. Например: «на мобильной карточке основное изображение появляется поздно из-за загрузки после скрипта; после правки оно обнаруживается раньше при том же качестве». Такой протокол позволяет проверить работу даже при небольшом колебании общего балла.

Как оценить вес изображений без магического лимита

Посмотрите реальные размеры файла и область показа. Если мобильному первому экрану нужна ширина около 400 пикселей макета (CSS-пикселей), один исходник шириной в несколько тысяч пикселей может передавать лишние данные. Для плотных экранов нужно больше физических пикселей, поэтому нельзя просто обрезать всё до 400. Подготовьте подходящие варианты и дайте браузеру выбрать через адаптивные источники. Сравните визуальное качество текста, людей и предметных деталей после сжатия.

Сохраните список крупных ресурсов первого экрана: изображение, шрифт, стиль, скрипт. Различайте размер передачи и момент обнаружения. Маленький файл, который браузер начинает загружать очень поздно, может задерживать LCP сильнее более крупного, обнаруженного сразу. Порядок запросов в водопаде показывает причину лучше, чем правило «каждая картинка меньше одной цифры». Для иллюстраций ниже первого экрана используйте отложенную загрузку и заданные размеры, чтобы не создавать смещение.

Если изображение содержит таблицу или схему, проверьте читаемость на узком телефоне. Экономия байтов не должна стирать цифры и подписи. Важные данные продублируйте обычным текстом. Так оптимизация улучшает передачу изображения, не превращая его в единственный и нечитаемый источник ответа.

Как наблюдать скорость после выпуска

Полевые данные полезны, когда ясно, какие страницы, устройства и взаимодействия они описывают. Отдельно смотрите ключевые шаблоны: услуга, категория, карточка, оформление. Если посещений мало, агрегат по источнику может помочь заметить общую проблему, но он не доказывает состояние конкретного URL. Запишите эту границу в отчёте. При наличии собственного измерения реальных посетителей проверьте, не собирает ли оно чувствительные данные формы; для технической диагностики достаточно времени, вида страницы и показателя.

После выпуска сравнивайте одинаковые группы устройств и похожие периоды. Появление новой рекламной кампании может привести на страницу людей с другими телефонами и сетями; изменение распределения объясняет часть сдвига метрики. Сравните также версии страниц и список сторонних скриптов. Если полевой показатель ухудшился после добавления чата, воспроизведите задержку с чатом и без него на тестовой версии, а потом принимайте решение о способе подключения.

Для наблюдения заведите запись: дата, URL или шаблон, устройство, источник измерения, показатель, изменение сайта и повторная проверка. Это не требует обещать фиксированный процент роста. Цель наблюдения: находить регрессии и подтверждать, что важные страницы остаются удобными после новых функций и материалов.

Какие ускорения способны сломать результат

Удаление формы, аналитики, защиты от спама или оплаты уменьшит объём скриптов, но лишит сайт нужного действия. Агрессивный кеш может показывать старую цену. Скрытие изображения первого экрана до прокрутки меняет метрику и вид страницы. Перевод всех картинок в маленькие файлы может уничтожить читабельность инфографики. Каждую оптимизацию проверяйте вместе с её функцией и содержимым.

Отложенная загрузка всего подряд также мешает. Для первого экрана критические ресурсы должны быть обнаружены вовремя; для нижних блоков отсрочка часто разумна. Приоритет нельзя назначить всем ресурсам сразу. Если серверный ответ медленный из-за тяжёлого запроса к базе, замена формата картинок не устранит причину. Отчёт должен объяснять связь «наблюдение, причина, правка, повторный тест».

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

Как принять ускорение и не потерять заявки

Представим учебный случай: мобильная страница услуги показывает LCP 4 секунды в лабораторном тесте, а главным элементом распознана обложка. Эти 4 секунды относятся только к выбранному прогону, не к каждому посетителю. В учебной записи 4 секунды складываются из 0,8 секунды до первого байта HTML-разметки страницы, 1,4 секунды ожидания обнаружения обложки, 0,7 секунды её загрузки и 1,1 секунды до отрисовки: 0,8 + 1,4 + 0,7 + 1,1 = 4,0 секунды. Это четыре неперекрывающихся части LCP для одного условного прогона. Числа учебные; измерение реальной страницы нужно выполнить отдельно. Дольше всего ресурс ждёт обнаружения; сначала проверяют ссылку на него в HTML и скрипт, который вставляет изображение. Гипотеза: более раннее обнаружение изображения уменьшит задержку загрузки ресурса. Сокращение на 1,4 секунды заранее не обещают: ожидание может перейти в задержку отрисовки. Исправьте путь обнаружения на тестовой версии, повторите несколько прогонов с тем же URL и сравните момент появления обложки. Если он почти не изменился, ищите другую причину, например задержку ответа сервера или блокировку отрисовки.

Теперь представим, что после этого выросла задержка открытия меню. Это отдельная проблема INP, которую нельзя объявить решённой улучшением LCP. Запишите действие, при котором возникает задержка, и сравните его до и после правки. Если картинка стала быстрее, а меню осталось медленным, результат частичный. Если на странице есть форма, отправьте контрольную заявку и найдите её запись: техническая оптимизация не должна оборвать путь обращения.

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

Если после оптимизации лабораторный показатель улучшился только на главной, проверьте, изменялся ли общий шаблон услуги и каталога. Для одной страницы можно сделать отдельное исправление, но тогда протокол должен называть именно её URL. Задача «ускорить сайт» без списка затронутых шаблонов создаёт ложное ожидание, что каждая страница стала быстрее.

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

До правки сохраните исходный URL, версию, скриншоты или запись проблемного поведения и показатели с условиями измерения. После правки повторите тест в тех же условиях. Сравните LCP-элемент, медленное взаимодействие и смещения, которые исправляли. Лабораторный результат может колебаться; для полевого вывода потребуется период и достаточное число реальных посещений. Если URL-отчёта ещё нет, прямо укажите это ограничение.

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

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

Документация и источники

• web.dev: Core Web Vitals
• web.dev: различия лабораторных и полевых данных
• web.dev: оптимизация LCP

Редакция Webclub. Опубликовано 2026-10-03, обновлено 20.10.2026.

Обсудим задачу вашего сайта?

Пришлите адрес и опишите, что хотите исправить. Согласуем состав работ и порядок проверки.

ПОСМОТРЕТЬ СОСТАВ РАБОТ