Сайт грузится 6 секунд: с чего начать аудит

Шесть секунд на загрузку — это не «чуть медленно». На мобильном интернете часть покупателей уходит раньше, чем увидит товар. При этом проблема не всегда в железе: часто сайт можно ускорить без переписывания, если найти, где именно теряется время.

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

Что значат 6 секунд

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

Первые 30 минут: собрать факты

Четыре слоя проблемы

TTFB и сервер

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

• Страница собирается заново при каждом обращении.
• Листинг делает десятки запросов и не использует индексы.
• Внешняя интеграция вызывается синхронно.
• PHP-FPM не хватает воркеров.
• Тяжёлые блоки считаются на сервере в момент запроса.

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

Изображения и шрифты

Изображения — самая частая причина медленного LCP. Одна фотография товара в исходном размере может весить больше всей остальной страницы.

• Переведите основные изображения в WebP или AVIF.
• Задайте width и height, чтобы браузер резервировал место.
• Подготовьте srcset для мобильных и десктопа.
• Уберите loading="lazy" с первого экрана.
• Оставьте одно-два начертания шрифта и используйте font-display: swap.

JavaScript и третьи скрипты

Скрипты влияют на LCP и INP. Они занимают сеть и главный поток. Чем больше виджетов подключено «на всякий случай», тем выше шанс, что кнопка будет отвечать с задержкой.

• Отключите неиспользуемые библиотеки и дубли аналитики.
• Разделите бандл и загружайте некритичные модули по требованию.
• Откладывайте чаты и виджеты до взаимодействия.
• Проверяйте сторонние скрипты на медленном мобильном соединении.

База и кэш

База часто становится узким местом каталога и checkout. Смотрите медленные запросы, блокировки и количество соединений. Кэш помогает, но требует инвалидации по событиям.

• Найдите запросы без индексов и N+1.
• Ограничьте выборки и тяжёлые отчёты.
• Кэшируйте каталог и карточки, но не корзину.
• Сбрасывайте кэш при изменении товара и цены.

План на 14 дней

Как измерять

Сравнивайте лабораторные и полевые данные. Lighthouse показывает, что можно улучшить, а Метрика и CrUX — что происходит с реальными покупателями.

• TTFB и время ответа сервера.
• LCP, INP и CLS по шаблонам.
• Конверсия в корзину и заказ.
• JS-ошибки и таймауты.

Что не помогает

• Покупать более мощный сервер без диагностики.
• Сжимать один баннер вместо системных проблем.
• Включать агрессивный кэш без инвалидации.
• Гнаться за 100 баллами Lighthouse вместо конверсии.
• Оптимизировать один раз и не проверять после релизов.

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

Что смотреть в waterfall

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

• Первый HTML и TTFB.
• Блокирующие CSS и шрифты.
• Главное изображение первого экрана.
• Скрипты, которые запускаются до контента.
• Сторонние домены и их время ответа.
• Запросы, которые можно объединить или отложить.

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

Мобильная сеть и устройство

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

• Slow 4G и средний Android.
• Реальная мобильная сеть, а не Wi-Fi.
• Размер изображений для мобильных.
• Количество скриптов и виджетов.
• Поведение при переключении вкладок.

Как приоритизировать

Как не сломать сайт при ускорении

Ускорение — это изменение продакшена, а не только отчёта. Любые правки кэша, скриптов и базы могут повлиять на заказы, поэтому нужен план проверки.

• Тестируйте на копии, а не на живом магазине.
• Меняйте по одному крупному блоку.
• Проверяйте checkout после каждого релиза.
• Держите план отката.
• Сравнивайте метрики до и после.

Что оставить на потом

• Микрооптимизации отдельных баннеров.
• Экзотические форматы изображений без поддержки.
• Переписывание фронтенда без данных.
• Тонкую настройку CDN до исправления сервера.

Сначала уберите крупные потери, затем измерьте результат. После этого можно заниматься деталями, которые дают последние проценты.

Что проверить в кэше

Кэш может ускорить сайт в разы, но ошибка в инвалидации приводит к старым ценам и остаткам. Поэтому проверяйте не только скорость, но и актуальность.

• Кэш HTML и фрагментов.
• Сброс при изменении товара и цены.
• Кэш статики с версионированием.
• Запрет кэшировать корзину и кабинет.
• Прогрев популярных страниц.

Если после изменения цены покупатель видит старую сумму, кэш настроен опаснее, чем его отсутствие. Лучше меньше ускорения, но корректные данные.

И проверяйте результат на реальном телефоне, а не только в браузере на компьютере. Именно там видно, помогли ли изменения покупателю дойти до оплаты.

Если после оптимизации скорость выросла, а заказы нет, ищите проблему дальше: в форме, доверии или условиях доставки.