Три разные «медленно»

Когда посетитель говорит «сайт тупит», он может иметь в виду разное. Разделите проблему на три этапа, прежде чем искать причину.

  • Ответ сервера (TTFB) — сколько браузер ждёт первый байт ответа, до любой отрисовки.
  • Отрисовка первого экрана (LCP) — когда появляется главный видимый элемент: заголовок, картинка, баннер.
  • Отклик на действия (INP) — задержка между кликом или тапом и видимой реакцией интерфейса.

Быстрый сервер не спасает от тяжёлого JavaScript, и наоборот. Чиниться должно то, что реально медленное, а не то, что проще измерить.

Как проверить самому за пять минут

  • Откройте сайт в приватном окне на обычном интернете, а не на офисном Wi-Fi с кэшем в браузере.
  • Вкладка Network в инструментах разработчика показывает время ответа сервера и что именно грузится дольше всего.
  • PageSpeed Insights и аналогичные сервисы отдельно считают мобильную и десктопную версию — цифры почти всегда разные.
  • Букмарклет «Сводка страницы» на ProWebStatus показывает вес HTML, число и объём скриптов прямо на странице — без установки расширений.

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

Core Web Vitals простыми словами

  • LCP (Largest Contentful Paint) — как быстро появляется главный контент. Хорошо — до 2.5 секунд.
  • INP (Interaction to Next Paint) — как быстро интерфейс реагирует на клики после загрузки. Хорошо — до 200 миллисекунд.
  • CLS (Cumulative Layout Shift) — насколько сильно «прыгает» вёрстка, пока догружаются картинки и шрифты. Хорошо — близко к нулю.

Это не абстрактные баллы для галочки: Google использует эти метрики как один из сигналов ранжирования, а плохой CLS — прямая причина случайных кликов не туда.

Частые причины на стороне сервера

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

Частые причины на стороне фронтенда

  • Изображения весом в мегабайты без сжатия и без указанных width/height.
  • Шрифты, которые блокируют показ текста, пока не догрузятся.
  • Сторонние скрипты — чаты, пиксели аналитики, виджеты — грузятся синхронно и задерживают отрисовку.
  • Много JavaScript выполняется до того, как страница вообще стала видимой, вместо того чтобы подгружаться после.
  • Анимации и тяжёлые эффекты на элементах, которые пользователь видит в первую секунду.

Мобильная скорость — отдельная история

Телефон почти всегда медленнее ноутбука разработчика, а мобильная сеть — домашнего Wi-Fi. Сайт, который на компьютере открывается за секунду, на телефоне в дороге может грузиться пять-семь секунд — и именно с этого устройства приходит основной трафик.

  • Проверяйте скорость отдельно на mobile-профиле, а не только на desktop.
  • Тестируйте с намеренным замедлением сети (throttling) в инструментах разработчика, а не только на своём быстром интернете.
  • Считайте вес страницы целиком, включая шрифты и скрипты, а не только главную картинку.

С чего начать, если чинить всё сразу дорого

  1. Сначала измерьте: зафиксируйте текущие TTFB, LCP и вес страницы — без числа «до» непонятно, помогла ли правка.
  2. Сожмите и переоформите изображения — обычно самый быстрый и дешёвый выигрыш.
  3. Уберите или отложите сторонние скрипты, которые не влияют на первый экран.
  4. Если сервер медленный сам по себе (высокий TTFB даже на пустой странице) — вопрос к хостингу или кэшированию, а не к вёрстке.
  5. Проверьте результат тем же способом, что и в начале, на тех же страницах.

Технический аудит и AI-анализ ProWebStatus фиксируют вес страниц, скрипты и медленные шаблоны по всему сайту — не только на проверенной вручную главной.