Как проверить скорость сайта и мобильную версию перед сдачей

Короткий ответ: перед сдачей сайта нужно проверить не абстрактную «скорость», а ключевые страницы и действия на реальных сценариях: открыть категорию на смартфоне, найти товар, выбрать вариант, отправить форму или пройти оформление заказа. Одного зелёного балла в Lighthouse недостаточно: лабораторный тест помогает искать узкое место, а данные Метрики и полевые Core Web Vitals показывают, что происходит у посетителей.

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

Что считать «быстро работает»

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

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

Как устроить проверку, чтобы сравнение было честным

1. Выберите типовые страницы. Не тестируйте только главную. Для корпоративного сайта возьмите главную, страницу услуги, статью и форму. Для магазина — категорию, карточку товара, результаты фильтра, корзину и оформление заказа.
2. Зафиксируйте окружение. Запишите устройство или профиль эмуляции, ширину экрана, браузер, скорость сети, регион теста, состояние кеша и адрес страницы. Повторите тест несколько раз: единичный результат может отличаться из-за сети и фоновой нагрузки.
3. Разделите лабораторию и реальные визиты. Lighthouse и PageSpeed Insights полезны для диагностики синтетического прогона. Полевые отчёты собираются с устройств посетителей и меняются не мгновенно. Данные разных источников отвечают на разные вопросы — не сравнивайте их как одно и то же измерение.
4. Пройдите сценарий руками. На телефоне откройте навигацию, нажмите фильтр, выберите значение, вернитесь назад, отправьте тестовую заявку. Зафиксируйте задержки, ошибки, неудобные зоны нажатия и смещение экрана.
5. Проверьте после исправлений. Сравните те же URL и сценарии при сопоставимых условиях. Рядом с каждым замечанием должны быть исходное значение, гипотеза, сделанное изменение и результат повторной проверки.

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

Условный учебный пример, не кейс REDBE. Интернет-магазин напольных покрытий жалуется, что каталог долго открывается на телефоне. В синтетическом тесте главная страница выглядит приемлемо, но посетитель с каталога часто уходит до выбора товара. Команда измеряет не только главную, но три конкретных сценария: загрузить категорию, раскрыть фильтр «цвет», открыть карточку из списка.

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

После изменений нужно убедиться, что визуальное качество фотографий сохранилось, фильтр остаётся доступным поисковым роботам в согласованном виде, а скрипт чата не перестал передавать обращения. «Ускорить» удалением нужной функции — не исправление. В отчёте фиксируют компромисс и проверяют бизнес-функцию повторно.

Какие узкие места обычно ищут в первую очередь

• Большие изображения. Проверяют реальное разрешение, формат, компрессию, размеры в разметке и приоритет загрузки первого экрана. Ленивая загрузка нужна ниже первого экрана, а не для главного изображения, которое формирует LCP.
• CSS и JavaScript, блокирующие показ. Смотрят, какие ресурсы нужны до первого отображения, какие библиотеки загружаются на всех страницах и можно ли отложить некритичный код.
• Шрифты и сдвиги. Проверяют количество начертаний, стратегию загрузки и заданные размеры блоков. Для изображений, баннеров и встраиваемого видео указывают соотношение сторон или резервируют место заранее.
• Тяжёлые интеграции. Чаты, карты, аналитические и рекламные теги измеряют по отдельности. Важно знать не только сколько они весят, но и блокируют ли основной поток и мешают ли отправке формы.
• Серверные ответы и запросы. Если HTML формируется долго, проверяют TTFB, SQL-запросы, кеширование, внешние API, размер каталога и число вычисляемых фильтров. Улучшение фронтенда не решит ожидание медленного источника данных.

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

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

Полезный протокол замечаний короткий и воспроизводимый: «iPhone/390 px → открыть каталог → выбрать фильтр → нажать применить → после загрузки прокрутка возвращается вверх; ожидалось — остаться у списка». Такой дефект можно повторить и принять после исправления. Формулировка «на мобильном неудобно» не говорит, что именно нужно поменять.

Для Яндекс Метрики проверьте сегмент мобильных устройств и поведение на важных страницах; для диагностики скорости используйте профильные отчёты. Официальная рекомендация Яндекса — сокращать блокирующие ресурсы и оптимизировать изображения и скрипты. Для Core Web Vitals сверяйте текущие рекомендации в документации Google Search Central и руководстве web.dev.

Что включить в протокол приёмки

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

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

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

Удобно идти от симптома к слою, который его вызывает. В Chrome DevTools откройте вкладку Network, включите ограничение скорости, отключите кеш для первого прогона и посмотрите, что приходит до отрисовки главного блока. Затем повторите прогон с кешем: это помогает отделить первую загрузку от повторного посещения. В Performance запишите сценарий и посмотрите длинные задачи главного потока. Если проблема воспроизводится только при длинном каталоге, сравните короткую и тяжёлую категорию, число карточек, размер ответа API и объём DOM.

Показатель TTFB — время до первого байта ответа — помогает заметить задержку сервера, но не говорит сам по себе, почему она возникла. Сравните несколько однотипных страниц, посмотрите серверные логи и время запросов к базе; затем проверьте кеш на публичных страницах и его корректное обновление после изменения товара. Если HTML приходит быстро, а LCP поздний, вероятнее искать тяжёлый главный ресурс, блокирующий CSS или приоритет загрузки. Если страница уже видна, но нажатия зависают, смотрите длинные JavaScript-задачи и обработчики события.

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

Матрица приёмки: что нажать и что должно произойти

Устанавливайте бюджет производительности под проект: например, ограничение на вес изображения первого экрана и число синхронных сторонних тегов. Но не подменяйте пользовательскую проверку искусственным нормативом «весь сайт должен весить меньше X КБ»: интернет-магазин с фотогалереей и одностраничная услуга различаются по содержанию. Важнее понять, что загружается до первого полезного действия, а что может подождать.

«Наша задача — сайт продвинуть, а не просто работу свою выполнить».

Вывод

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