PageSpeed с 52 до 69 без CDN и нового хостинга. 8 шагов за один день.
kitetech.ru, сайт кайт-школы на WordPress. Страница /kitecamp/ работает на React SPA внутри WP. PageSpeed Mobile показывал 52 балла, LCP 9.3 секунды. За один день без замены хостинга и без CDN мы довели его до 69 баллов, TBT с 800ms до 70ms, Render Blocking с 12 830ms до 150ms. Помогло одно: удаление лишнего.
До и после: что изменилось
Самая тяжёлая страница сайта. React SPA на WordPress грузил всё подряд: и свои компоненты, и 18 лишних плагинов WP. Вот что в итоге изменилось.
| Метрика | До | После |
|---|---|---|
| Performance Mobile | 52 | 69 |
| Render Blocking | 12 830 ms | 150 ms |
| Total Blocking Time | 800+ ms | 70 ms |
| LCP | 9.3 s | 5.6 s |
| Hero Image | 117 KB (JPG) | 37 KB (WebP) |
| SEO-оценка | 92 | 100 |
В чём была настоящая проблема
WordPress тащит все плагины на каждую страницу: WooCommerce, Smush, CF7, YouTube-фасад, Quiz. На /kitecamp/ они не нужны, там React сам управляет отображением. Но WP об этом не знает и грузит 18 лишних JS/CSS файлов, блокируя рендер на 12+ секунд.
React SPA внутри WordPress: двойная нагрузка
18 лишних файлов плагинов на странице, которой они не нужны. Браузер загружает jQuery и WooCommerce прежде, чем показать первый пиксель React-приложения. Render Blocking 12 830ms складывается ровно из этих файлов.
Hero-изображение 117 KB JPG
Фоновое фото первого экрана работает как LCP-элемент. От его загрузки зависит оценка Largest Contentful Paint. 117 KB в JPG на медленном 4G дают 1-2 лишних секунды до первого контента.
Параллакс и анимации Framer Motion
useScroll и useTransform вешали rAF-цикл 60fps при каждом скролле. На слабых Android-телефонах это главная причина подвисающего интерфейса. Убрать параллакс быстрее, чем его оптимизировать.
8 шагов, которые дали результат
Подключить файл оптимизаций в functions.php
Файл kitecamp-perf.php с хуками уже существовал, но висел неподключённым. Добавили один require в functions.php, и это открыло дорогу всем остальным шагам.
require get_template_directory() . '/inc/kitecamp-perf.php';
Снять 18 лишних JS-файлов плагинов
Сняли через wp_dequeue_script с приоритетом 9999 и двойным хуком. Приоритет тут решает: плагины регистрируются на разных приоритетах, и при 100 они успевают перезаписать. Сработало именно 9999 плюс оба хука (wp_enqueue_scripts и wp_print_scripts).
Render Blocking: 12 830ms → 150ms
defer для плагина кнопки мессенджеров
Плагин нужен визуально, но его JS не нужен до интерактивности. Через фильтр script_loader_tag добавили defer. CSS плагина сделали асинхронным через media="print" onload="this.media='all'".
TBT: 460ms → 70ms
Конвертировать изображения JPG → WebP
5 фото слайдера и hero-фото мы конвертировали через Python Pillow с quality=82. Суммарная экономия около 260 KB. На кайт-фото quality=82 держит баланс между весом и качеством: глазом разницу с оригиналом не поймать.
Hero: 117 KB → 37 KB (-68%)
img = Image.open("hero.jpg")
img.save("hero.webp", "webp", quality=82, method=6)
Preload для LCP-изображения
Добавили <link rel="preload" as="image" fetchpriority="high"> в <head>. Браузер начинает грузить картинку сразу при парсинге HTML, не дожидаясь CSS и JS.
LCP улучшился на ~0.5s
Google Fonts: асинхронная загрузка
Заменили синхронный <link rel="stylesheet"> на паттерн media="print" onload. Шрифты больше не блокируют первый рендер. Добавили <noscript>-фолбэк для браузеров без JS.
Убрали 750ms блокировки
Убрать параллакс и молочный градиент hero
Удалили useScroll и useTransform из Framer Motion, убрали нижний gradient overlay. Фото стало статичным, rAF-цикл на скролле исчез. Прокрутка стала плавнее, анимация при этом никуда не делась, просто перестала грузить процессор.
Preload для шрифтов темы WordPress
Добавили <link rel="preload" as="font"> для Gilroy-Semibold.woff2 и Gilroy-Extrabold.woff2 в header.php. Шрифты hero-блока начинают загружаться немедленно.
FCP главной страницы улучшился
Сначала убери лишнее — потом оптимизируй
18 лишних JS-файлов давали 12 секунд блокировки. Никакой кеш и CDN не спасут, если браузер всё равно вынужден загрузить jQuery и WooCommerce на React-страницу. Диагностика через curl плюс grep по id="*-js" вытаскивает точные handle-имена за 5 минут.
Для React SPA на WordPress 69 баллов это уже рабочий потолок без переделок. Дальше рост упирается в code splitting бандла (сейчас 423 KB одним куском), critical CSS inline и, скорее всего, смену хостинга на LiteSpeed: текущий Hostia не даёт кешировать на уровне сервера.
Промт для аудита PageSpeed вашего сайта
Скопируйте этот промт, вставьте в Claude или ChatGPT, укажите свои данные. На выходе получите пошаговый план оптимизации с конкретным PHP/JS/HTML кодом.
Ты эксперт по Core Web Vitals и PageSpeed. Мне нужно улучшить производительность WordPress-сайта. Контекст сайта: - CMS: WordPress [версия] - Хостинг: [провайдер и тариф] - Тема: [название, кастомная или готовая] - Активные плагины: [перечисли WooCommerce, Yoast, CF7 и т.д.] - Есть ли React/Vue SPA на отдельных страницах: [да/нет] - Текущий PageSpeed Mobile: [число] Вот мои проблемы из PageSpeed Insights: [вставь список: Render blocking requests, Unused JavaScript, LCP и т.д.] Нужно: 1. Найти точные WP handle-имена блокирующих скриптов (id="handle-name-js") и снять их через wp_dequeue_script с приоритетом 9999. 2. Для плагинов, которые нужны визуально, сделать JS defer, CSS асинхронным через media="print" onload. 3. Проверить изображения: какие конвертировать в WebP, какой quality оптимален. 4. Добавить preload для LCP-элемента. 5. Если есть Google Fonts, сделать загрузку асинхронной. 6. Если есть React/Vue SPA, убедиться что WP-плагины не грузятся на этих страницах. Формат: пронумерованный список от важного к менее важному, для каждого шага конкретный код и ожидаемый выигрыш в ms.
Куда расти от 69 баллов
Code splitting React бандла
Сейчас весь React грузится одним файлом 423 KB. Калькулятор, слайдер, FAQ можно разнести на lazy chunks через React.lazy() и Suspense. Это снимет с первого экрана примерно 50-80 KB.
Critical CSS inline
Вынести стили первого экрана в <style> прямо в HTML, остальной CSS грузить асинхронно. Убирает блокировку index-*.css (1 500ms).
Смена хостинга на LiteSpeed
Текущий Hostia не поддерживает LiteSpeed, поэтому серверный кеш не работает. Переход снизит TTFB с ~300ms до ~30ms. Это даст больше, чем все шаги оптимизации вместе взятые.
Провести аудит PageSpeed вашего сайта
Аудит покажет точные handle-имена блокирующих скриптов, список изображений под конвертацию и пошаговый план. Обычно первые изменения дают +10-15 баллов за один рабочий день.
Обсудить аудитИли посмотрите кейс по защите заявок от утечки к конкурентам.