Скорость сайта на WordPress: какие плагины незаметно съедают 2 секунды и как проверить Core Web Vitals

· ·

PrimeCoder · 2026 · формат: checklist

Готовый чек-лист: пункты, которые можно сразу перенести в ТЗ или акт.

Сайт на WordPress обрастает плагинами: кэширование, слайдеры, формы, чаты, аналитика, SEO-панели. Каждый добавляет запросы к базе, внешние скрипты и CSS. В итоге LCP уходит за 4 секунды, INP растёт до 300+ мс, а владелец видит только «сайт тормозит» без понимания, какой именно плагин съел 2 секунды. Проблема не в хостинге, а в невидимой цепочке зависимостей между плагинами и теме.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Зачем этот чеклист и как им пользоваться

Два плагина на WordPress добавляют 2 секунды к загрузке. Вы узнаёте об этом по упавшей конверсии, а не по отчёту. Дальше знакомое: меняете хостинг, ставите кэш, покупаете «оптимизацию» у фрилансера. Через месяц LCP снова 4,2 с, INP 320 мс, отказы растут.

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

Порядок такой: прогоняете сайт по группам проверок, честно отмечаете «готово / не готово». Потом сравниваете с тем, что сдаёт подрядчик или что вы делаете сами. Красные флаги — стоп-сигнал, не подписывайте. Формулировки в конце вставляются в акт дословно.

Ориентир по деньгам и времени: аудит на сайте с 1 000–100 000 сессий в месяц укладывается в 2 нед календарных, если работать по шагам, а не перебирать плагины наугад. Интернет-магазин с жёсткими зависимостями — сначала staging, иначе рискуете остановить продажи.

Группа 1. Замеры до любых правок

Без baseline вы не докажете ни себе, ни подрядчику, что что-то изменилось. «Стало быстрее» — не аргумент. Нужны цифры до и после.

  • ☐ PageSpeed Insights прогнан для мобильных и десктопа отдельно. Мобильные — приоритет, там метрики хуже и там сидит основная аудитория SMB-сайтов.
  • ☐ Зафиксированы LCP, INP, CLS. Не «зелёная зона», а конкретные значения с разбивкой по элементам. Скриншот отчёта сохранён с датой.
  • ☐ Замеры сделаны в режиме инкогнито, без расширений. Ваш браузер с 20 плагинами врёт. Lighthouse в инкогнито — минимум.
  • ☐ Проверено, какой именно элемент даёт LCP. Часто это не картинка героя, а шрифт или баннер слайдера. Пока не знаете элемент — не знаете, что чинить.
  • ☐ Есть baseline по числу SQL-запросов на страницу. Через Query Monitor: сколько запросов и сколько времени. Это ваш эталон.

Готово, если у вас на руках таблица «метрика → значение → дата → устройство». Не готово, если вы помните «примерно 4 секунды».

Группа 2. Диагностика: кто именно съел время

Тут начинается работа, которую обычно пропускают. Отключение плагинов наугад — лотерея. Сначала находим подозреваемых, потом проверяем.

  • ☐ Query Monitor установлен и показывает время выполнения каждого плагина. Смотрите не общий список, а топ по времени и по числу запросов. Плагин, который делает 140 запросов на страницу, — первый кандидат.
  • ☐ Chrome DevTools → Coverage открыт. Видно, какой CSS и JS загружается, но не используется. Если 70% подключённого CSS не задействовано — это балласт.
  • ☐ Проверены внешние скрипты. Чаты, аналитика, виджеты поддержки грузятся с чужих доменов. Они блокируют основной поток и бьют по INP.
  • ☐ Составлен список подозреваемых по убыванию вклада. Конструкторы страниц, слайдеры, мультиязычность, чаты, SEO-комбайны. Не «все плагины», а конкретный порядок.
  • ☐ Проверено, что тянет за собой тема. Тема может грузить свои скрипты поверх плагинных. Двойная загрузка jQuery — классика.

Готово, если у вас есть ранжированный список «плагин → вклад в секундах или мс». Не готово, если список звучит как «ну, наверное, Elementor».

Группа 3. Проверка гипотез без риска для продаж

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

  • ☐ Есть staging-копия сайта. Нет — сначала поднимите. Тесты на проде допустимы только для плагинов, которые точно не влияют на продажи.
  • ☐ Отключение идёт по одному плагину, с замером после каждого. Не «выключил пять, стало лучше». Так вы не узнаете, кто виноват.
  • ☐ После каждого отключения — замер LCP через Lighthouse в инкогнито. Один замер ничего не значит, сделайте 3 и возьмите медиану.
  • ☐ Проверены остатки после удаления. Плагин мог оставить таблицы в базе, скрипты в теме, правила в .htaccess. Удалили плагин — время не вернулось, потому что мусор остался.
  • ☐ Кэш очищен перед каждым замером. Плагин кэша хранит старые версии страниц. Замер по кэшу — это замер вчерашнего сайта.

Ориентир: каждый тяжёлый плагин добавляет 200–500 мс к загрузке. Отключение неиспользуемых модулей внутри плагина экономит до 30% его вклада. То есть иногда плагин не надо убивать — достаточно выключить половину его функций.

Готово, если вы можете назвать виновника и подтвердить его вклад повторным замером. Не готово, если «вроде стало побыстрее».

Группа 4. Замена и перенос функционала

Найти виновника — половина дела. Вторая половина — не потерять функционал, за который вы платили.

  • ☐ Для каждого тяжёлого плагина есть решение: замена, отложенная загрузка или перенос в тему. «Оставим как есть» — не решение, это откат к исходной проблеме.
  • ☐ Конструкторы страниц проверены на возможность работы через Gutenberg. Часто 80% страниц можно пересобрать на блоках без потери вида.
  • ☐ Скрипты чатов и виджетов переведены на отложенную загрузку. Они не нужны в первую секунду. Пусть грузятся после взаимодействия.
  • ☐ Проверено, что замена не сломала формы, оплату, выгрузку товаров. Прогон ключевых сценариев: заказ, заявка, подписка.
  • ☐ Функционал, который реально нужен, перенесён в тему или в лёгкий плагин. Мультиязычность, если языков два, не всегда требует тяжёлого комбайна.

Готово, если после замены все ключевые сценарии работают и метрики не ухудшились. Не готово, если «вроде всё на месте, но надо проверить».

Группа 5. Кэш, объектный кэш и закрепление

Оптимизация без кэша — ремонт с открытым окном. Убрали плагин, но каждый хит всё равно долбит базу.

  • ☐ Страничный кэш настроен и проверен. WP Super Cache или LiteSpeed Cache — не важно что, важно что работает и не конфликтует с остальным.
  • ☐ Объектный кэш (Redis) подключён. Ориентир: переход с shared-хостинга на VPS с SSD и Redis сокращает время ответа сервера на 300–500 мс.
  • ☐ CDN отдаёт статику. Картинки, CSS, JS — с ближайшего к пользователю узла.
  • ☐ Сжатие Brotli включено. Проверьте, что оно реально отдаётся, а не просто «включено в панели».
  • ☐ Повторные замеры Core Web Vitals сделаны после всех правок. Сравнение с baseline, а не с ощущениями.

Готово, если LCP, INP и CLS улучшились относительно baseline и держатся стабильно 3 замера подряд. Не готово, если улучшилось «на одном замере утром в субботу».

Красные флаги: когда не платить и не подписывать

  • Подрядчик не показал baseline до работ. Значит, нечего сравнивать. Это мусор, а не отчёт.
  • Вам говорят «мы всё оптимизировали», но не называют конкретный плагин-виновник и его вклад.
  • Замеры сделаны только на десктопе. Мобильные — там, где больно.
  • Отключили плагины, но не проверили остатки в базе и теме. Через месяц всё вернётся.
  • Нет staging, а работы шли на живом магазине. Даже если «повезло» — это не процесс, это лотерея.
  • Обещают «LCP меньше 2,1 с гарантированно» без доступа к вашим данным и без замеров. Так не обещают.

3 пункта, без которых не подписывать

  1. Baseline-таблица с датой и устройством. Без неё акт — это бумага.
  2. Названный виновник и подтверждённый вклад. Не «оптимизировали в целом», а «плагин X давал 500 мс, отключён, LCP упал с 4,2 до 2,1».
  3. Повторные замеры после кэша и Redis. Пока кэш не настроен, результат не закреплён.

Как зафиксировать в договоре

Формулировки, которые можно вставить в акт или ТЗ. Они проверяемые, а не «улучшили производительность».

Что фиксируемФормулировка
Baseline«До начала работ зафиксированы LCP, INP, CLS для мобильных и десктопа через PageSpeed Insights, дата и скриншоты приложены».
Диагностика«Составлен ранжированный список плагинов по вкладу во время загрузки на основе Query Monitor и Chrome DevTools Coverage».
Результат«После работ LCP, INP, CLS улучшены относительно baseline, подтверждено 3 замерами подряд в инкогнито».
Функционал«Ключевые сценарии (заказ, заявка, подписка) проверены после замены плагинов, регрессий нет».
Закрепление«Настроены страничный кэш, объектный кэш Redis и CDN, повторные замеры приложены».

Если подрядчик отказывается фиксировать baseline и повторные замеры — вы покупаете файл, а не решение. Смотрите, что именно вам сдают: каталог услуг по разработке и оптимизации построен вокруг измеримых результатов, а не «работ по улучшению».

Что делать через 10 минут после чтения

  1. Откройте PageSpeed Insights, введите URL, переключитесь на мобильные. Сохраните скриншот с датой.
  2. Поставьте Query Monitor, откройте любую тяжёлую страницу. Посмотрите топ-3 плагина по времени и по числу запросов.
  3. Запишите эти три плагина в столбик. Это ваш список подозреваемых, с которым уже можно идти к подрядчику или к своему разработчику.

Если сайт на жёстких зависимостях (магазин, оплата, интеграции) — не трогайте прод. Сначала staging. Если staging нет — это первая задача, а не оптимизация. Детали по инфраструктуре и переносу смотрите в разделе про хостинг и инфраструктуру.

FAQ

Какие плагины чаще всего незаметно съедают 2 секунды?

Тяжёлые конструкторы страниц (Elementor, WPBakery) с активными виджетами, слайдеры (Slider Revolution), плагины мультиязычности (WPML), чаты поддержки (Tawk.to, Jivo), SEO-комбайны (Yoast, Rank Math) с лишними модулями. Но порядок зависит от вашей сборки. Без Query Monitor вы угадаете неправильно.

Как проверить Core Web Vitals без программиста?

PageSpeed Insights: вводите URL, смотрите мобильный отчёт, там LCP, INP, CLS с разбивкой по элементам. Для деталей — Chrome DevTools, вкладка Coverage: видно неиспользуемый CSS и JS. Этого достаточно, чтобы составить список подозреваемых и не платить за «диагностику» вслепую.

Почему после отключения плагина скорость не всегда возвращается?

Плагин мог оставить таблицы в базе, скрипты в теме или правила в .htaccess. Плюс кэш страниц хранит старые версии. Очистите кэш плагина, кэш CDN и кэш браузера, потом замеряйте. Если не помогло — ищите остатки в базе.

Можно ли оставить тяжёлый плагин, но ускорить сайт?

Да, если отключить неиспользуемые модули внутри плагина, отложить загрузку скриптов (defer/async), вынести критический CSS и подключить CDN. Но это даёт прирост меньше, чем замена. Ориентир: отключение лишних модулей экономит до 30% вклада плагина. Остальные 70% остаются с вами.

Сколько ждать эффекта после настройки Redis и CDN?

Технически — сразу. Но Google Search Console обновляет отчёт «Основные интернет-показатели» с задержкой, данные приходят из реальных визитов. Не ждите, что позиции вырастут за 1 нед. Сначала смотрите на лабораторные замеры, потом на полевые.

Нужен ли performance-инженер в штате?

Для сайта до 100 000 сессий в месяц — не обязательно. Нужен человек, который умеет читать Query Monitor и DevTools, и процесс: baseline, гипотеза, замер, закрепление. Это можно закрыть подрядчиком, если он работает по измеримым критериям. Если подрядчик не показывает цифры — меняйте подрядчика.

Дальше

Оптимизация — не разовая акция. После обновления плагинов, темы или добавления нового виджета метрики поедут снова. Настройте алерт в Search Console на падение Core Web Vitals и проверяйте сайт после каждого крупного обновления. Если хотите, чтобы аудит и последующую оптимизацию сделали по этому чеклисту — оставьте заявку, и мы начнём с baseline, а не с обещаний.

Что подключить по этому материалу

Для тем про органический трафик связка простая: аудит и структура страниц, сопутствующие SEO-работы и разбор под вашу воронку.

SEO

SEO-аудит сайта

Когда речь про органический трафик, позиции и «почему нет заявок из поиска» — технический и коммерческий разбор с приоритетами.

  • Ошибки индексации и скорость
  • Структура страниц под интент
  • План работ с приоритетами
SEO-аудит

Скорость

Ускорение сайта

Когда форма «не успевает» или LCP режет конверсию — точечный разбор и правки за дни, не «редизайн всего».

  • Замер до/после на ключевых URL
  • Картинки, кэш, сервер
  • Проверка формы на телефоне
Ускорить сайт

Созвон

Сопоставить статью с вашим процессом

Стек, нагрузка, SLA: переводим текст материала в реальные вводные без общих слов.

  • Короткий созвон с теми, кто будет в работе
  • Без обязаловки по договору
  • Можно сразу с командой имплементации
Оставить заявку

Сценарий внедрения: дорожная карта на первые недели

Сначала прогоните сайт через PageSpeed Insights и зафиксируйте метрики LCP, INP, CLS для мобильных и десктопа. Затем в Chrome DevTools на вкладке Coverage посмотрите, какие CSS и JS файлы загружаются, но не используются. Отключите по одному подозрительные плагины (слайдеры, конструкторы, мультиязычность, чаты) и после каждого отключения замеряйте LCP через Lighthouse в режиме инкогнито. Для точности используйте Query Monitor: он покажет, сколько запросов к базе и сколько времени выполняет каждый плагин. После выявления виновника замените его на лёгкий аналог или перенесите функционал в тему. Финальный шаг — настроить кэширование страниц и объектный кэш (Redis), затем повторить замеры Core Web Vitals.

  1. Нулевая неделя: baseline-метрики, карта ролей и ответственности, технические ограничения и SLA.
  2. Неделя 1-2: запуск узкого пилота, контрольные точки, лог ошибок типовых сценариев.
  3. Неделя 3-4: первое улучшение по KPI или честное признание, что нужно поменять сценарий/данные.
  4. Неделя 5+: масштабирование на смежные процессы и фиксация регламентов, чтобы качество держалось без геройства команды.

Формат “один главный результат на одну неделю” сохраняет темп и экономит управленческое внимание.

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

Короткий каркас, который можно перенести в ваш Notion/ТЗ без переписывания с нуля.

# Чеклист приемки перед запуском (фрагмент)
acceptance = {
  "analytics_baseline_fixed": True,
  "perf_budget_ms": {"lcp": 2500, "tti": 3500},
  "seo": {"canonical": True, "indexability": True, "structured_data_ok": True},
  "crm_events": {"lead_created": True, "stage_change": True}
}

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

Риски и как их снять заранее

  • Запуск без baseline и недельной аналитики — самый дорогой вариант, потому что непонятно, что лечить.
  • Смешивание многих задач одновременно — обычно увеличивает календарные сроки и бюджет сверх суммы задач по отдельности.
  • Слабая интеграция с точками истины данных (CRM, биллинг, тикет-системы) даёт красивый интерфейс и плохой бизнес-эффект.

Отдельно для разработки: фиксируйте производительность, безопасность и индексируемость страниц как часть DoD деплоя, а не постфактум.

Что сделать дальше

Короткая диагностика под ваш процесс: обычно 3 дня для малого бизнеса и до 5 дней для проектов со сложной воронкой и несколькими стейджами.

Быстрый расчет эффекта: (количество заявок × текущая стоимость обработки заявки) − (то же после внедрения целевой модели) + (дополнительные продажи × средняя маржа). Число получится грубым и полезным: оно задаёт экономику решения даже без идеальных данных.

По запросу высылаем чеклист диагностики и шаблон weekly-отчёта по экспериментам: там видно, когда пора усиливать сценарий, а когда — остановиться.

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

Проверьте скорость, мобильность и базовые SEO-ошибки до разговора с подрядчиком.

Запустить технический аудит сайта

FAQ по теме статьи

Какие плагины чаще всего незаметно съедают 2 секунды?

Тяжёлые конструкторы страниц (Elementor, WPBakery) с включёнными виджетами, слайдеры (Slider Revolution), плагины мультиязычности (WPML), чаты поддержки (Tawk.to, Jivo), плагины аналитики и пикселей, а также SEO-комбайны (Yoast, Rank Math) с активными модулями. Каждый по отдельности может добавлять 200–500 мс, а вместе — те самые 2 секунды.

Как проверить Core Web Vitals без программиста?

Откройте PageSpeed Insights, введите URL и посмотрите отчёт по мобильным. Там будут LCP, INP, CLS с разбивкой по элементам. Для деталей используйте Chrome DevTools → Lighthouse → Performance. В WordPress установите Query Monitor — он покажет время выполнения каждого плагина и количество SQL-запросов. Этого достаточно, чтобы найти виновника.

Почему после отключения плагина скорость не всегда возвращается?

Плагин мог оставить после себя таблицы в базе, скрипты в теме или настройки в .htaccess. Также кэш страниц мог сохранить старые версии. Очистите кэш (плагина, CDN, браузера), проверьте базу на «осиротевшие» таблицы и удалите остатки кода из functions.php.

Можно ли оставить тяжёлый плагин, но ускорить сайт?

Да, если отключить неиспользуемые модули внутри плагина, отложить загрузку его скриптов (defer/async), вынести критический CSS и подключить CDN. Но это даёт прирост 20–40%, тогда как замена на лёгкий аналог — до 70% экономии времени загрузки.

Как часто нужно перепроверять Core Web Vitals?

После каждого обновления WordPress, темы или плагинов, а также при добавлении новых скриптов (чат, аналитика). Минимум — раз в месяц для активных сайтов. Используйте автоматический мониторинг через Google Search Console (отчёт «Основные интернет-показатели») или сторонние сервисы вроде DebugBear.

Влияет ли хостинг на скорость WordPress?

Да, но не так сильно, как плагины. Дешёвый shared-хостинг с медленным диском и без OPcache даёт задержку 300–500 мс на запрос. VPS с SSD и настроенным кэшем (Redis, Memcached) ускоряет отдачу, но если плагины добавляют 2 секунды, смена хостинга их не уберёт.

Дальше по теме платформы: смежные материалы (Разработка и запуск продукта)

Статью лучше читать в связке — так быстрее собирается картина, как ответ складывается в работающую воронку, а не в изолированный совет.

Нужен рабочий контур, а не разовые эксперименты? Подключайте AI Boost Team и начинайте с процесса, где эффект измерим в неделях, а не в презентациях.

Читайте также