Что делать, если старая страница тормозит

Не всегда нужен новый сайт

Старая страница тормозит - инстинкт говорит «переделать всё». Иногда достаточно убрать тяжёлый чат, пересжать hero и отложить карту ниже fold.

Проверено на живых проектах.

Сначала цифры, потом решения.

Порядок, который я использую

  1. Lighthouse и вкладка Network.
  2. Общий вес страницы и TTFB.
  3. Топ файлов по размеру.
  4. Что блокирует первый экран.
  5. Повтор на мобильном 4G.

Типовые виновники

  • Чат-виджеты и карты на каждой странице.
  • Пиксели рекламы без отложенной загрузки.
  • Старые jQuery-плагины «для одной галереи».
  • Видео без постера и lazy.
  • PNG и оригиналы фото в hero.
<script src="/widget.js" defer></script>
<img src="/hero.webp" fetchpriority="high" width="1200" height="630">

Про картинки подробнее - lazy loading без библиотек. Про хостинг - hosting и SSL: иногда тормозит сервер, не фронт.

СимптомПервый шаг
LCP красныйHero и шрифты
Много JSОтключить виджеты по одному
TTFB высокийКэш, CDN, хостинг
Скорость чинится серией скучных точных действий, не одной галочкой в плагине.

Если после оптимизации страница всё ещё не конвертит - смотрите оффер и форму. Но пока грузится восемь секунд, половина аудитории не дождётся текста. Оценка работ - на ценах.

Кэш и CDN без фанатизма

Для статики - long cache с версией в имени файла, hTML кэшировать осторожно, если контент меняется часто.

Не теория.

CDN имеет смысл при трафике из разных регионов или тяжёлых asset, на малом лендинге иногда достаточно нормального VPS и сжатия gzip/brotli.

Проверяю заголовки ответа в Network: cache-control, etag.

Вот где ломают.

Неправильный кэш = пользователи видят старые картинки после оптимизации.

Шрифты и render-blocking

Два начертания вместо семи семейств. font-display: swap. Подключение Google Fonts - async или self-host, каждый лишний вес шрифта - задержка текста.

Критический CSS для above-the-fold - по желанию на тяжёлых проектах; на лендинге часто хватит одного сжатого CSS файла без @import цепочек.

Legacy CMS и плагины

WordPress с десятью плагинами «для скорости», которые конфликтуют - классика, отключайте по одному на staging, меряйте, при этом иногда быстрее новый лендинг на статике, чем лечить зоопарк.

Third-party: карты, Jivo, Facebook pixel, Hotjar - каждый добавляет сотни килобайт, оставьте только то, чем пользуетесь еженедельно.

Server-side и DB

Медленные SQL на каждый view - профилируйте, кэш страницы на nginx для анонимов, а pHP без opcache на shared hosting - частая причина TTFB.

HTTP/2, brotli, keep-alive - проверьте конфиг nginx, иногда один блок в конфиге минус секунда.

Если страница генерируется 2 сек на сервере - фронт не виноват, смотрите backend.

Бюджет правок: что делать первым

Я обычно делю работу на три очереди, первая - hero, шрифты, top-3 файла в Network: это видно пользователю сразу, при этом вторая - виджеты и скрипты, которые можно отложить или убрать. Третья - архитектурные изменения, если TTFB упирается в CMS или базу.

Заказчик часто просит «ускорить сайт» и ждёт новый дизайн, на созвоне показываю скрин Network: файл на 4 МБ в hero, и после сжатия до 200 КБ Lighthouse зеленеет без единой правки CSS. Это экономит недели и бюджет.

Дальше по теме: картинки и WebP, точечное обновление, чеклист перед запуском рекламы.

Медленная страница. Сначала замерить, потом резать - часто хватает картинок, виджетов и скриптов, без полного редизайна.

Практический порядок

  1. Запустите Lighthouse для mobile и desktop.
  2. Отсортируйте Network по размеру - исправьте топ-3.
  3. Отключите по одному сторонний виджет и замерьте снова.
  4. Пересожмите изображения и включите WebP.
  5. Проверьте TTFB - возможно, дело в хостинге.
  6. Повторите замер через неделю после правок.

Что не стоит повторять

  • Заказывать редизайн, не сделав профиль Network.
  • Ставить ещё один плагин «для ускорения».
  • Оптимизировать CSS, игнорируя шестимегабайтный hero.
  • Мерить только на офисном Wi‑Fi.
  • Подключать пять аналитик и чатов одновременно.

Когда пора к подрядчику. Разработчик нужен, чтобы безопасно вырезать legacy-скрипты, настроить defer/preload и не сломать формы - на старых CMS это быстро ломается «руками маркетолога». Ориентиры по срокам и бюджету - на странице цен, услуги - в разделе услуг.

Быстрый выигрыш без разработчика

Отключите чат на день. Замерьте. Карту из hero - уберите. Пересожмите три тяжёлых JPG. Lighthouse часто зеленеет без кода.

Сначала контент и форма. Потом аналитика и виджеты. Иначе ускоряете страницу, которая не продаёт.

Когда звать разработчика

LCP выше 4 секунд после трёх шагов - нужен скрин Network, не абстрактное «сделайте быстрее». TTFB высокий - смотрим хостинг и кэш.

Редизайн - последний вариант. Не первый.

Миф про «плагин ускорения»

Ставят второй плагин на первый. Конфликт. Сайт ещё медленнее. Я снимаю все «ускорители», оставляю сжатие картинок и нормальный хостинг. Часто этого достаточно.

WordPress с десятью оптимизаторами - отдельный жанр. Лечится отключением, не добавлением.

Цифры, которые стоит записать

LCP, FCP, общий вес, TTFB - до и после, без цифр спор «стало ли быстрее» бессмысленен, и скрин Lighthouse в переписку - и обе стороны в одной реальности.

Один скрин до, один после. Спор закончен.

CDN без сжатия на origin даёт иллюзию скорости, проверьте размер файлов на сервере, не только время ответа edge.

Отложите аналитику ниже fold - скрипты Метрики и чата не должны блокировать первый экран.

Критический CSS для hero - редко нужен на лендинге, но на WordPress с тяжёлой темой иногда даёт минус секунду LCP.

Один такой промах - неделя в минус.

Хотите обсудить похожую задачу? Скиньте URL - посмотрю, что тормозит сильнее всего и с чего начать.

Обсудить проект →