Скорость сайта: что проверить владельцу бизнеса

Уточните, что именно кажется медленным

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

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

Разделяйте лабораторную проверку и реальное использование

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

В наборе Core Web Vitals Google выделяет LCP для отображения основного содержимого, INP для отзывчивости и CLS для стабильности макета. Рекомендованные границы хорошего опыта — соответственно до 2,5 секунды, до 200 миллисекунд и до 0,1 на 75-м процентиле. Эти показатели не заменяют проверку заявки и не обещают определённую позицию в поиске. Важно понимать, какой этап пользовательского опыта измеряется каждым числом.

Посмотрите на изображения и первый экран

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

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

Проверьте скрипты и сторонние сервисы

Чаты, карты, аналитика, виджеты отзывов и рекламные инструменты могут добавлять работу браузеру. Составьте список: зачем нужен каждый сервис, кто им пользуется и можно ли загружать его позже. Удаление ненужного виджета иногда полезнее сложной оптимизации собственного кода. Но отключать всё подряд нельзя: вместе со скриптом может исчезнуть нужная форма, измерение или важный клиентский сценарий. Изменение должно иметь владельца и проверку.

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

Не забывайте сервер и содержимое ответа

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

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

Как принять работу по ускорению

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

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

Что проверить в своей задаче

1. Опишите адрес, устройство и момент задержки.
2. Проверьте основные коммерческие сценарии.
3. Разделите лабораторные и пользовательские данные.
4. Оптимизируйте причину, сохраняя функции и качество.
5. Сравните одинаковые условия до и после.