Главная может открываться быстро, пока поиск по каталогу заставляет посетителя ждать. Поэтому ускорение сайта начинается с выбора важных страниц и действий, а не с универсального набора настроек. Зафиксируем, где проходит ожидание, какие изменения можно проверить и как принять работу в одинаковых условиях.
Сценарии, которые стоит ускорять в первую очередь
Формулировка «медленно грузится сайт» годится для начала разговора, но не для постановки задачи. Посетитель может ждать карточку, применение фильтра или открытие меню. Для каждого случая нужны свое начало отсчета, ожидаемый результат и способ проверки.
Сначала выбирают небольшой набор сценариев, от которых зависит работа сайта. Для магазина это может быть вход в категорию, поиск по артикулу, выбор свойств и добавление товара в корзину. Для сайта услуг — открытие посадочной страницы и отправка формы. Главную включают, если она участвует в таком пути.
Сценарий описывают так, чтобы другой человек мог его повторить: адрес, исходное состояние, действие, признак завершения. Для поиска таким признаком будет появление подходящих товаров, для фильтра — обновленный список с выбранными условиями.
Важность сценария не сводится к посещаемости: редкое сочетание фильтров нельзя подменить пустой категорией ради удобного замера. Различия проверок разобраны в материале про скорость каталога.
Исходные измерения: протокол вместо скриншота с баллом
До изменений нужен протокол проверки, а не один скриншот с баллом. В нем сохраняют адреса, поисковые фразы, выбранные фильтры, дату и версию сайта. Изменение ассортимента отмечают: выдачи на разных данных не всегда сопоставимы.
Для каждого сценария заранее записывают:
- устройство, браузер и его версию, размер окна;
- реальную сеть или параметры ее ограничения в тесте;
- первый это визит или повторный, какое состояние кеша проверяется;
- состояние посетителя: пустая корзина или уже выбранные товары;
- начало и конец измерения, число повторов и способ сведения результатов;
- время проверки и известные фоновые работы, например обновление каталога.
Отключение кеша браузера не описывает состояние кешей на сервере или в CDN. В протоколе их разделяют: что обошли, что очистили на тестовой среде, что оставили прогретым. Возможность отключить именно браузерный кеш и ограничить сеть описана в документации Chrome DevTools.
Лабораторная проверка позволяет повторить заданные условия, пользовательские данные показывают опыт реальных посещений. Core Web Vitals охватывают загрузку, отзывчивость и визуальную стабильность: LCP, INP и CLS. Эти показатели полезны, но не заменяют отдельное измерение выбранного действия, например ожидания результатов поиска. Различия лабораторных и полевых измерений объясняет обзор Web Vitals.
Повторы нужны, чтобы не выдать случайный удачный запуск за улучшение. Число запусков и способ сравнения согласуют до работы; сохраняют сами результаты, их разброс и выбранный сводный показатель, например медиану. Нельзя сравнивать лучший запуск после изменений со средним результатом до них или менять условия, когда цифры не нравятся.
Где проходит ожидание: сервер, база, сеть или браузер
Диагностика должна связать жалобу с конкретным участком ожидания. Проверяют запрос, отправленный при действии посетителя, время ответа и момент появления готового результата. Так отделяют медленную передачу данных от ситуации, в которой данные уже получены, а интерфейс еще занят.
До первого байта ответа. Долгое ожидание не означает автоматически, что пора менять хостинг. TTFB при открытии страницы включает не только подготовку ответа сервером, но и сетевые этапы, в том числе соединение и перенаправления. Состав показателя приведен в описании TTFB. Чтобы назвать причиной код, базу или внешний сервис, нужны дополнительные измерения на стороне приложения.
Внутри приложения. Специалист сопоставляет медленный запрос с журналами и временем его обработки: сколько заняли обращения к базе, вычисления, ожидание интеграции. Долгий запрос к базе — повод исследовать его план и объем обрабатываемых данных, а не обещать эффект от любого нового индекса. Высокую нагрузку рассматривают вместе со временем жалобы: отчет за спокойную ночь не объясняет дневную задержку.
При передаче ответа. В сетевой записи смотрят последовательность запросов и их фазы. В Chrome DevTools раздел Timing позволяет различить ожидание первого байта и получение содержимого; длительное получение может быть связано не только с сетью, но и с занятостью браузера. Эти различия описаны в справочнике Network. Одна длинная полоса не определяет виновника без разбора.
После получения данных. Если ответ уже пришел, а список товаров еще не готов, исследуют работу браузера: обработку данных, выполнение скриптов, построение и отрисовку интерфейса. Здесь нужен профиль самого действия, а не только отчет открытия страницы. Ускорение ответа сервера не закрывает задачу, если посетитель продолжает ждать на следующем этапе.
Каталог примерно на 60 000 товаров, обмены и отдельный JSON-сервис обновления цен — пример проекта, где важно различать эти участки. Масштаб не доказывает причину задержки. Без замеров после внедрения аудит остается диагностикой, а не подтверждением эффекта.
Изменения только под найденную причину
Результат диагностики — ограниченный перечень задач с объяснением каждой. В нем должны быть сценарий, найденная задержка, подтверждающие данные, предлагаемое изменение и способ приемки.
Если основное время уходит на обработку поиска в базе, рассматривают запросы и организацию поиска. Если задержка возникает в браузере после ответа, проверяют объем работы интерфейса. Если критичный ресурс долго передается, изучают его размер и способ доставки. Это направления проверки, а не набор изменений, который следует применять к любому сайту.
Покупку более мощного сервера обосновывают найденным ограничением ресурсов. Сжатие изображений привязывают к ожиданию изображений, настройку кеша — к повторяемой работе и допустимому сроку актуальности данных. Так можно ускорить загрузку сайта там, где она мешает посетителю, и не оплачивать несвязанные с жалобой переделки.
Условный пример задачи: «Сократить ожидание результатов поиска по согласованным артикулам. По записи диагностики основная задержка приходится на обработку запроса к базе. Проверить изменение запроса на тестовой копии; сравнить полное время до появления выдачи по исходному протоколу. Состав результатов, цены и порядок сортировки должны сохраниться». Численный предел приемки добавляют после исходных измерений, а не придумывают для примера.
В состав работ по ускорению сайта включают задачи с подтвержденной причиной и понятной проверкой. Для каждой фиксируют страницы, состояния и границы исследования. Такой объем можно оценить и завершить.
Быстро, но с устаревшей ценой: проверка после кеширования
Быстрый ответ с устаревшей ценой не решает задачу магазина. До настройки кеша определяют, какие данные допустимо использовать повторно, как долго они могут оставаться прежними и какое событие должно их обновить. Для общей страницы категории и персональной корзины это разные требования.
Общий HTTP-кеш и кеш конкретного браузера также различаются. Если персональный ответ попадет в общий кеш, его могут получить другие посетители; наличие cookies само по себе не делает ответ приватным. Правила разделения описаны в руководстве MDN по HTTP-кешированию. Конкретную настройку выбирает специалист с учетом приложения, а при приемке проверяют изоляцию данных.
Проверку строят вокруг изменений, которые пользователь должен увидеть. На тестовой среде обновляют цену или остаток, затем проверяют категорию, карточку, поиск и корзину. Результаты сравнивают с согласованным сроком актуальности. Отдельно проверяют новый визит и повторное открытие: отсутствие ошибки при первом запуске не подтверждает правильность повторного использования ответа.
Для измененного поиска сравнивают выдачу и сортировку. При отложенной загрузке ресурсов проверяют доступность кнопок и форм. После изменения корзины проверяют добавление, удаление и количество товара. Обход страниц должен соответствовать внедренной задаче.
До выпуска сохраняют возможность вернуть прежнюю версию и настройки. Условия возврата согласуют заранее: неверные данные, ошибки сценария или ухудшение выбранной метрики.
Как принять работу и следить за скоростью дальше
Работу принимают по тем же сценариям и условиям, которые зафиксировали до изменений. В итоговом отчете рядом стоят исходные и повторные измерения, число запусков, разброс и описание внедренной задачи. Если устройство, сеть, данные или методика поменялись, сравнение помечают как ограниченное и при необходимости повторяют.
Прикладывают результаты проверки корректности: выдача соответствует условиям, данные обновляются, формы и корзина работают. Для каждой задачи указывают выполнение критерия, побочные эффекты и оставшиеся ограничения. Без связи между изменением и сценарием отдельную работу трудно принять.
Если улучшения нет, фиксируют именно это и возвращаются к гипотезе о причине. Перечень выполненных настроек не заменяет результата, а успешный лабораторный запуск еще не описывает опыт всех посетителей. После выпуска наблюдают за пользовательскими данными, когда они доступны, и отдельно повторяют контрольные сценарии.
Для дальнейшего контроля сохраняют протокол, ответственного и поводы повторить проверку: обновление шаблона, изменение поиска, подключение виджета, рост каталога. Новые жалобы привязывают к действиям и времени возникновения — это исходные данные следующей задачи.