Что именно медленно работает

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

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

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

Выберите страницы и зафиксируйте условия измерения

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

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

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

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

Первый визит и повторное открытие измеряйте отдельно. В Chrome DevTools на вкладке Network можно отключить браузерный кеш, чтобы проверить загрузку без ранее сохранённых ресурсов; этот режим описан в справке по сетевой панели. Не сравнивайте холодную загрузку «до» с повторным визитом «после»: часть выигрыша даст сам кеш.

Разделите ожидание ответа, передачу данных и работу браузера

Откройте Network, перезагрузите страницу и найдите основной HTML-документ. На временной диаграмме запросов видно, когда он начался и какие ресурсы загрузились следом. Длинная полоса сама по себе ещё не объясняет причину: у запроса нужно посмотреть составляющие времени.

Если долго не приходит ответ

Показатель TTFB — время до первого байта ответа. В деталях запроса Chrome этап Waiting (TTFB) включает ожидание сети и подготовку ответа сервером. Поэтому большое значение нельзя автоматически объявлять медленной базой данных. Сначала сопоставьте его с серверными журналами, обращениями к внешним сервисам и результатами из другой сети.

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

Если ответ получен, но экран собирается медленно

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

Если файлы уже переданы, а интерфейс зависает, запишите действия на вкладке Performance. Там можно проследить работу основного потока браузера: выполнение кода, расчёт расположения элементов и отрисовку. Документация Chrome объясняет чтение такой записи. Передайте специалисту саму запись и шаги воспроизведения: скриншот красного индикатора не заменяет диагностику.

Схема и пример

Где может задерживаться страница

  1. Ответ сервера

    Проверьте, сколько приходится ждать начальный HTML, и сопоставьте это с серверными журналами.

  2. Ресурсы страницы

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

  3. Работа браузера

    Проверьте выполнение JavaScript, построение интерфейса и реакцию на действия посетителя.

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

Читайте показатели, а не только итоговый балл

Lighthouse запускает контролируемую проверку и собирает несколько показателей в общую оценку. Её колебания возможны даже без изменения сайта: влияют условия запуска и вариативность загрузки. Это прямо рассматривается в описании расчёта оценки Lighthouse. Поэтому требование «сделать 100 баллов» без списка страниц и условий мало помогает приёмке.

Лабораторный тест удобно использовать для проверки гипотез. Данные реальных посещений показывают, как сайт работает у аудитории с разными устройствами и действиями. В системе Core Web Vitals отдельно оцениваются появление основного содержимого, отзывчивость и стабильность расположения элементов. Небольшой размер страницы сам по себе не означает, что она быстро реагирует на нажатия и не сдвигает текст при загрузке.

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

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

Проверьте изображения, стили и сторонние скрипты

Изображения: размер файла и момент загрузки

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

Изображения далеко ниже первого экрана можно загружать отложенно. Для главной иллюстрации, которую посетитель видит сразу, такое правило способно добавить задержку. Рекомендации web.dev по lazy loading отдельно предупреждают об этом и советуют задавать размеры изображений, чтобы браузер мог заранее выделить место. После изменения проверьте и скорость, и отсутствие скачков текста.

Код: что требуется именно этой странице

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

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

Для CSS, то есть файлов оформления, проверьте объём и порядок подключения. Перенос стилей «на потом» может ускорить одну метрику, но вызвать появление неоформленного содержимого. Для JavaScript не стоит массово менять способ выполнения без проверки зависимостей: поломка формы дороже небольшого сокращения загрузки.

Настройте кеширование и сжатие с учётом содержимого

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

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

Директива private исключает хранение ответа в общих кешах, no-store запрещает его сохранение, а no-cache требует проверки перед повторным использованием. Это разные правила, что поясняет руководство MDN по HTTP-кешированию. Выбор зависит от данных и архитектуры. Проверка двумя тестовыми аккаунтами должна подтвердить, что один пользователь не получает сведения другого.

Сжатие уменьшает объём передаваемых данных. Для HTML, CSS и JavaScript администратор проверяет согласование алгоритма с браузером и фактический ответ сервера, а не только переключатель в панели хостинга. В документации MDN описаны заголовки Accept-Encoding и Content-Encoding, которые участвуют в этом обмене. Изменения сначала проверяют на копии сайта, сохранив прежнюю конфигурацию.

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

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

Условная находкаСледующее действиеКак принять результат
Большая иллюстрация на всех страницах услугПодготовить подходящие размеры и сравнить вариантыОсновной блок появляется раньше; качество изображения сохранено
Долго формируется ответ каталогаРазобрать серверное время и дорогие операцииСократилось ожидание ответа на том же наборе данных
Виджет мешает работе менюПроверить зависимость на копии и изменить подключениеМеню отвечает без зависания; нужная функция виджета работает
После обновления остаётся старое оформлениеПроверить версии ресурсов и правила кешаПервый и повторный визит показывают актуальную страницу

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

Сравнение подходов

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

  1. Расплывчатая цель

    «Поднять оценку теста»

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

  2. Проверяемая гипотеза

    Ускорить появление первого экрана

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

Условный пример: приоритет подтверждается измерениями на выбранной странице.

Повторите измерения и закрепите проверку перед выпуском

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

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

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

Скорость и удобство мобильной версии проверяйте раздельно. Быстрая страница может сохранять обрезанные таблицы и неудобные формы; для них пригодится чек-лист проверки адаптивности. Если нужна помощь с ускорением, передайте ШТАБ ИТ адреса и отчёты: они помогут определить, что нужно проверить на сервере и в браузере.

Источники и полезные ссылки

  1. Chrome DevTools: Network, кеш и этапы сетевого запроса ↗
  2. Chrome DevTools: анализ работы основного потока ↗
  3. Lighthouse: расчёт и изменчивость оценки производительности ↗
  4. web.dev: пользовательские показатели Web Vitals ↗
  5. web.dev: этапы появления крупнейшего элемента ↗
  6. web.dev: отложенная загрузка изображений ↗
  7. MDN: правила HTTP-кеширования ↗
  8. MDN: сжатие при передаче HTTP-ответов ↗

Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.

Игорь Крещенко

Руководитель ШТАБ ИТ. Занимается управлением проектами, веб-разработкой, рекламой и PR. Подробнее об авторе →