Скорость сайта на 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 пункта, без которых не подписывать
- Baseline-таблица с датой и устройством. Без неё акт — это бумага.
- Названный виновник и подтверждённый вклад. Не «оптимизировали в целом», а «плагин X давал 500 мс, отключён, LCP упал с 4,2 до 2,1».
- Повторные замеры после кэша и Redis. Пока кэш не настроен, результат не закреплён.
Как зафиксировать в договоре
Формулировки, которые можно вставить в акт или ТЗ. Они проверяемые, а не «улучшили производительность».
| Что фиксируем | Формулировка |
|---|---|
| Baseline | «До начала работ зафиксированы LCP, INP, CLS для мобильных и десктопа через PageSpeed Insights, дата и скриншоты приложены». |
| Диагностика | «Составлен ранжированный список плагинов по вкладу во время загрузки на основе Query Monitor и Chrome DevTools Coverage». |
| Результат | «После работ LCP, INP, CLS улучшены относительно baseline, подтверждено 3 замерами подряд в инкогнито». |
| Функционал | «Ключевые сценарии (заказ, заявка, подписка) проверены после замены плагинов, регрессий нет». |
| Закрепление | «Настроены страничный кэш, объектный кэш Redis и CDN, повторные замеры приложены». |
Если подрядчик отказывается фиксировать baseline и повторные замеры — вы покупаете файл, а не решение. Смотрите, что именно вам сдают: каталог услуг по разработке и оптимизации построен вокруг измеримых результатов, а не «работ по улучшению».
Что делать через 10 минут после чтения
- Откройте PageSpeed Insights, введите URL, переключитесь на мобильные. Сохраните скриншот с датой.
- Поставьте Query Monitor, откройте любую тяжёлую страницу. Посмотрите топ-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-аудит сайта
Когда речь про органический трафик, позиции и «почему нет заявок из поиска» — технический и коммерческий разбор с приоритетами.
- Ошибки индексации и скорость
- Структура страниц под интент
- План работ с приоритетами
Скорость
Ускорение сайта
Когда форма «не успевает» или LCP режет конверсию — точечный разбор и правки за дни, не «редизайн всего».
- Замер до/после на ключевых URL
- Картинки, кэш, сервер
- Проверка формы на телефоне
Созвон
Сопоставить статью с вашим процессом
Стек, нагрузка, SLA: переводим текст материала в реальные вводные без общих слов.
- Короткий созвон с теми, кто будет в работе
- Без обязаловки по договору
- Можно сразу с командой имплементации
Сценарий внедрения: дорожная карта на первые недели
Сначала прогоните сайт через PageSpeed Insights и зафиксируйте метрики LCP, INP, CLS для мобильных и десктопа. Затем в Chrome DevTools на вкладке Coverage посмотрите, какие CSS и JS файлы загружаются, но не используются. Отключите по одному подозрительные плагины (слайдеры, конструкторы, мультиязычность, чаты) и после каждого отключения замеряйте LCP через Lighthouse в режиме инкогнито. Для точности используйте Query Monitor: он покажет, сколько запросов к базе и сколько времени выполняет каждый плагин. После выявления виновника замените его на лёгкий аналог или перенесите функционал в тему. Финальный шаг — настроить кэширование страниц и объектный кэш (Redis), затем повторить замеры Core Web Vitals.
- Нулевая неделя: baseline-метрики, карта ролей и ответственности, технические ограничения и SLA.
- Неделя 1-2: запуск узкого пилота, контрольные точки, лог ошибок типовых сценариев.
- Неделя 3-4: первое улучшение по KPI или честное признание, что нужно поменять сценарий/данные.
- Неделя 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-отчёта по экспериментам: там видно, когда пора усиливать сценарий, а когда — остановиться.
- Запросить диагностику процесса: Открыть форму контактов PrimeCoder
- Получить план внедрения на 30 дней: Подключить AI Boost Team как внешний AI-офис с KPI
Практическое действие после чтения
Проверьте скорость, мобильность и базовые 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 секунды, смена хостинга их не уберёт.
Дальше по теме платформы: смежные материалы (Разработка и запуск продукта)
Статью лучше читать в связке — так быстрее собирается картина, как ответ складывается в работающую воронку, а не в изолированный совет.