Core Web Vitals: Почему кастомный код получает 100 – а WordPress редко превышает 60

Есть структурная причина, по которой написанные вручную сайты проходят Core Web Vitals, тогда как сайты на конструкторах борются за каждый балл: чистый код просто не тащит за собой балласт, ломающий метрики. Core Web Vitals — подтверждённый фактор ранжирования Google, и вот что большинство разработчиков не скажут вслух: выбранная платформа определяет около 80% вашего базового балла ещё до любой оптимизации. Кастомный PHP может достичь 100 при минимуме усилий; WordPress даже с плагинами кэширования часто застревает в диапазоне 40–60. Я создавал и оптимизировал и то и другое, так что это не теория. Позвольте показать вам, почему именно так, на реальных цифрах, реальном коде и реальных результатах клиентов.

Бизнес-обоснование для прохождения Core Web Vitals

Прежде чем погрузиться в код, поймите влияние. Данные Google показывают:

• Сайты, проходящие Core Web Vitals, видят на 24% меньше отказов пользователей.
• Улучшение LCP на 0,5 с может увеличить конверсию на 12–15% (исследование Google).
• Взаимодействие со страницей теперь является фактором разрешения споров, когда две страницы имеют одинаковую релевантность.

Ваш выбор платформы – это не только удобство разработчика, это прямой двигатель дохода и рейтинга.

Реальные цифры: кастомный PHP против WordPress (один сервер)

Я провел контролируемый тест на идентичном хостинге (Hostinger VPS, 2 vCPU, 2 ГБ ОЗУ, хранилище NVMe). Два веб-сайта:

• Сайт А: Кастомный PHP/HTML, без фреймворка, минимальный CSS/JS, ручная оптимизация.
• Сайт Б: Чистый WordPress 6.7 + тема Astra + 5 основных плагинов (Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

847 КБ JavaScript – это убийца. WordPress загружает jQuery, редактор блоков, скрипты плагинов и ресурсы темы – даже если вы их не используете. Google Lighthouse измеряет все это, и каждый килобайт добавляется к LCP и INP.

Объяснение Core Web Vitals (пороги 2026 года)

Google подтвердил, что взаимодействие со страницей является сигналом ранжирования как на мобильных устройствах, так и на настольных компьютерах. В 2026 году пороги следующие:

• LCP (Largest Contentful Paint) – измеряет скорость загрузки. Хорошо: менее 2,5 с.
• INP (Interaction to Next Paint) – измеряет отзывчивость. Хорошо: менее 200 мс (заменил FID в 2024 году).
• CLS (Cumulative Layout Shift) – измеряет визуальную стабильность. Хорошо: менее 0,1.
• TTFB (Time To First Byte) – ответ сервера. Хорошо: менее 600 мс (неофициально, но Google использует).

Сайт, который не соответствует этим метрикам, опускается ниже более быстрых конкурентов – даже если у него больше обратных ссылок.

Как кастомный PHP достигает идеального 100 (реальный код + передовые методы)

Вот именно то, что я делаю при каждой кастомной сборке, чтобы гарантировать оценку Lighthouse 100.

1. Предварительная загрузка критических ресурсов

Сообщите браузеру, что наиболее важно, прежде чем он даже начнет анализировать HTML.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. Встраивание CSS над сгибом (сокращение FCP вдвое)

Извлеките только те стили, которые необходимы для видимой области. Используйте вкладку Coverage в Chrome, чтобы найти неиспользуемый CSS.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. Отдача адаптивных изображений с помощью srcset и WebP

Большинство сайтов отдают изображения размера рабочего стола на мобильные устройства – это огромный штраф для LCP. Используйте `srcset` для отдачи изображений подходящего размера.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. Оптимизация ответа сервера (TTFB)

Я использую PHP‑FPM с включенным OPcache, сжатием GZIP и индексацией базы данных. Отсутствие накладных расходов `wp_query` WordPress означает, что запросы возвращаются за 5–15 мс, а не за 150 мс. Дополнительные настройки:

• Включить Keep‑Alive и HTTP/2.
• Использовать CDN (Cloudflare или Bunny.net) для кеширования статических ресурсов.
• Перенести базу данных на отдельный сервер или использовать Redis для кеширования объектов при необходимости.

5. Устранение сдвигов макета (CLS = 0,01)

Каждое изображение, видео и рекламное место получает явные атрибуты `width` и `height`. Зарезервируйте место для шрифтов с помощью `font-display: swap`.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. Отложить некритический JavaScript

Используйте `defer` или `async` для всех внешних скриптов и переместите аналитику, чтобы она загружалась после взаимодействия с пользователем.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. Используйте `loading="lazy"` для изображений под сгибом

Изначально невидимые изображения должны загружаться лениво. Это экономит пропускную способность и ускоряет LCP.

Почему WordPress не может легко сравниться с этими цифрами

• Каждый плагин добавляет свой собственный CSS/JS, часто без `async` или `defer`. Даже «оптимизированные» плагины добавляют накладные расходы.
• Редактор блоков загружает более 500 КБ JavaScript, даже если вы используете только простую страницу. Это полмегабайта неиспользуемого кода.
• Плагины кеширования помогают, но они не могут устранить основное раздувание – они только кешируют уже раздутый вывод.
• Сторонние темы включают целые фреймворки (Bootstrap, Tailwind) – 90% неиспользуемого CSS, который все еще блокирует рендеринг.

Даже если вы временно получите 90 в Lighthouse, обновление плагина или новая тема могут обрушить его до 45 за одну ночь. С кастомным PHP ваша производительность детерминирована – она не меняется, пока вы ее не измените.

Два реальных преобразования клиентов

Пример 1: Магазин ювелирных изделий WooCommerce → кастомный PHP

Ювелирный магазин имел сайт WooCommerce с оценкой 43 в Lighthouse (мобильный). У них было 12 активных плагинов, раздутая тема и время загрузки 4,2 с. После миграции на кастомный PHP-магазин с Stripe Checkout:

• Оценка Lighthouse: 43 → 98.
• Время загрузки на мобильных: 4,2 с → 0,9 с.
• Коэффициент конверсии: 1,8% → 3,4% (+89%).
• Средняя стоимость заказа увеличилась на 22% (более быстрая оплата стимулировала дополнительные продажи).

Пример 2: Сайт недвижимости с более чем 500 страницами

Агентство недвижимости имело сайт WordPress со временем загрузки страниц 3,5 секунды и CLS 0,28 (плохо). Мы перестроили фронтенд как кастомный PHP-сайт, используя легкий шаблон, встроенный критический CSS и предварительно загруженные изображения героя.

• LCP: 3,1 с → 0,9 с.
• CLS: 0,28 → 0,02.
• Показатель отказов снизился с 58% до 37%.
• Отправки контактных форм увеличились на 41% в течение 60 дней.

Скрытая стоимость конструкторов страниц: Wix, Squarespace, Shopify

Дело не только в WordPress. Все платформы перетаскивания страдают от плохих настроек по умолчанию:

• Wix/Squarespace: Встроенные стили повсюду, огромный размер DOM и отсутствие контроля над критическим CSS. Средняя мобильная оценка Lighthouse: 30–50.
• Shopify: Лучше, чем Wix, но темы загружают тяжелый JavaScript и внешние шрифты. Средняя оценка: 60–75.
• Webflow: Может быть оптимизирован, но требует экспертных знаний и все равно выдает раздутый код по сравнению с рукописным PHP.

Только кастомный PHP дает вам полный контроль над каждым байтом, попадающим в браузер.

Как начать (даже если вы не разработчик)

Вам не нужно писать все с нуля. Я создаю каждый веб-сайт вручную, поэтому вы получаете 100% адаптированную кодовую базу. Результат: оценка Lighthouse, которую вы можете сфотографировать и использовать как сигнал доверия. Вы также можете начать с генератора статических сайтов (Hugo, Eleventy), а затем добавить PHP для динамических функций.

План действий: доведите свой сайт до 100 сегодня

1. Протестируйте свой текущий сайт на PageSpeed Insights (мобильный). Запишите свой LCP, INP, CLS.
2. Исправьте простые проблемы: сожмите изображения, включите кеширование, удалите неиспользуемые плагины.
3. Если вы ниже 70, рассмотрите миграцию платформы. ROI кастомного PHP-сайта часто окупается за 6–12 месяцев за счет более высоких конверсий и снижения затрат на хостинг.
4. Или наймите меня. Я создам для вас кастомный PHP-сайт, который набирает 100 – гарантия.

Заключительное резюме: выбор платформы – это 80% битвы

Вы можете оптимизировать любой сайт, но начало с кастомного PHP дает вам огромное преимущество. WordPress требует постоянной борьбы с собственной архитектурой. Wix и Squarespace запирают вас в медленных шаблонах. Кастомный PHP дает вам полный контроль. Цифры говорят сами за себя.

Если вы хотите веб-сайт, который естественно набирает 96–100 в Lighthouse и превосходит конструкторы страниц, давайте поговорим.

Все тестовые данные были собраны на Hostinger VPS (2 vCPU, 2 ГБ ОЗУ) с использованием Lighthouse 12.0 (мобильная симуляция). Ваши результаты могут отличаться в зависимости от контента и хостинга.