Что такое Core Web Vitals?
Core Web Vitals -- это три определённые Google метрики, которые делают пользовательский опыт на сайте количественно измеримым. С 2021 года они официально влияют на ранжирование в Google, а значит перестали быть просто приятным дополнением и стали критически важным бизнес-фактором.
Обзор трёх метрик:
| Метрика | Измеряет | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Скорость загрузки | <= 2,5 с | 2,5–4,0 с | > 4,0 с |
| CLS (Cumulative Layout Shift) | Визуальная стабильность | <= 0,1 | 0,1–0,25 | > 0,25 |
| INP (Interaction to Next Paint) | Интерактивность | <= 200 мс | 200–500 мс | > 500 мс |
Важно: все три метрики должны достигать порога «хорошо», чтобы Google считал вашу страницу производительной. Недостаточно, чтобы только одна или две были в зелёной зоне. Проверьте свой сайт прямо сейчас с помощью нашего Performance-Checker и узнайте, где вы находитесь.
Как измеряются CWV?
Google различает полевые данные (реальные пользователи) и лабораторные данные (симуляция):
- Полевые данные поступают из Chrome UX Report (CrUX) и основаны на анонимизированных данных реальных пользователей Chrome. Именно эти данные Google использует для ранжирования.
- Лабораторные данные измеряются инструментами вроде Lighthouse, PageSpeed Insights или WebPageTest в контролируемых условиях. Они идеально подходят для диагностики и оптимизации.
Главное отличие: полевые данные показывают, как ваш сайт работает на самом деле; лабораторные -- как он работает в идеальных условиях. Оптимизируйте по лабораторным данным, но измеряйте успех по полевым.
Как Google использует CWV для ранжирования
В мае 2021 года Google представил Page Experience как сигнал ранжирования, центральной частью которого являются Core Web Vitals. Вот что это значит на практике:
Что мы знаем:
- CWV -- это фактор ранжирования, но не самый важный. Релевантный контент, обратные ссылки и авторитетность домена весят больше.
- При прочих равных условиях CWV могут сыграть решающую роль -- особенно на первой странице результатов поиска.
- Google использует 75-й перцентиль полевых данных: если 75% ваших пользователей получают хорошие значения, страница считается прошедшей проверку.
- CWV оцениваются по каждому URL, а не по домену. Отдельные медленные страницы не влияют на весь сайт.
Влияние на бизнес:
- По данным исследований Google, сайты с хорошими CWV имеют на 24% ниже показатель отказов
- E-commerce-сайты сообщают о повышении конверсии до 15% после оптимизации CWV
- Новостные сайты фиксируют до 22% больше просмотров страниц за сессию
В нашей работе как агентства веб-дизайна мы наблюдаем у клиентов после оптимизации CWV улучшение позиций в среднем на 3–8 мест по конкурентным ключевым словам -- не только благодаря самим CWV, но и за счёт улучшения пользовательского опыта и снижения показателя отказов.
Оптимизация LCP: повышение скорости загрузки
Largest Contentful Paint измеряет, когда самый большой видимый элемент во вьюпорте полностью загрузился -- обычно это hero-изображение, видео или крупный текстовый блок. Цель: менее 2,5 секунд.
Самые частые проблемы с LCP и их решения
1. Неоптимизированные изображения (самая частая проблема)
Hero-изображение является LCP-элементом в 70% случаев. Если оно весит 2 МБ и загружается только после обработки CSS и JavaScript, хороший LCP невозможен.
Решение:
<!-- До: несжатый JPEG, без приоритизации -->
<img src="hero.jpg" alt="Hero изображение">
<!-- После: WebP с фолбэком, Preload, фиксированные размеры -->
<link rel="preload" as="image" href="hero.webp" type="image/webp">
<picture>
<source srcset="hero.webp" type="image/webp">
<source srcset="hero.jpg" type="image/jpeg">
<img src="hero.jpg" alt="Hero изображение"
width="1200" height="600"
fetchpriority="high"
decoding="async">
</picture>
2. Медленное время ответа сервера (TTFB)
Если серверу требуется более 800 мс для выдачи HTML-файла, все последующие ресурсы начинают загружаться с задержкой.
Решение:
- Переход на более качественный хостинг (Managed VPS вместо Shared Hosting)
- Настройка CDN (Cloudflare, Fastly, AWS CloudFront)
- Активация серверного кэширования (Varnish, Redis, Nginx Microcaching)
- Оптимизация запросов к базе данных (индексы, кэширование запросов)
3. Блокирующие рендеринг CSS и JavaScript
CSS и синхронный JavaScript в `<head>` блокируют рендеринг страницы.
Решение:
<!-- Критический CSS инлайн в <head> -->
<style>
/* Только CSS для видимой области (Above the Fold) */
.hero { background: #1a1a1a; min-height: 60vh; }
.hero h1 { font-size: clamp(2rem, 5vw, 4rem); }
</style>
<!-- Некритический CSS загружается асинхронно -->
<link rel="preload" href="styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>
<!-- JavaScript defer вместо синхронного -->
<script src="app.js" defer></script>
4. Отложенная загрузка сторонних скриптов
Analytics, чат-виджеты, встраивания соцсетей и реклама могут значительно ухудшить LCP.
Решение: загружайте сторонние скрипты только после события LCP:
// Загрузка сторонних скриптов после LCP
if ('PerformanceObserver' in window) {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.entryType === 'largest-contentful-paint') {
loadThirdPartyScripts();
observer.disconnect();
}
}
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });
}
Оптимизация CLS: предотвращение сдвигов макета
Cumulative Layout Shift измеряет, насколько сильно элементы неожиданно смещаются во время загрузки. Каждый сталкивался с этим: вы хотите нажать на кнопку, и в последний момент она уезжает, потому что появился рекламный баннер. Цель: менее 0,1.
Самые частые причины CLS
1. Изображения и видео без указанных размеров
Когда браузер не знает размер изображения, он не резервирует для него место. Как только изображение загружается, весь контент под ним смещается.
Решение:
<!-- ВСЕГДА указывайте width и height -->
<img src="foto.webp" alt="Описание" width="800" height="600">
<!-- Или используйте CSS aspect-ratio -->
<style>
.image-container { aspect-ratio: 16/9; overflow: hidden; }
.image-container img { width: 100%; height: 100%; object-fit: cover; }
</style>
2. Веб-шрифты вызывают FOUT/FOIT
При загрузке веб-шрифта текст может внезапно изменить размер (Flash of Unstyled Text) или на мгновение исчезнуть (Flash of Invisible Text).
Решение:
/* font-display: swap — показывает фолбэк-шрифт сразу, заменяет при загрузке */
@font-face {
font-family: 'Inter';
src: url('/fonts/inter.woff2') format('woff2');
font-display: swap;
/* Size-Adjust предотвращает сдвиг макета при замене шрифта */
size-adjust: 100%;
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
}
Дополнительно: предзагрузка файлов шрифтов:
<link rel="preload" href="/fonts/inter.woff2" as="font"
type="font/woff2" crossorigin>
3. Динамически вставляемый контент
Cookie-баннеры, всплывающие окна подписки и лениво загружаемые элементы могут вызывать сдвиги макета, если для них не зарезервировано место.
Решение:
/* Резервирование места для cookie-баннера */
.cookie-banner-placeholder {
min-height: 80px; /* Высота баннера */
}
/* Или: баннер как оверлей, а не сдвигающий элемент */
.cookie-banner {
position: fixed;
bottom: 0;
left: 0;
right: 0;
z-index: 9999;
}
4. Динамическая реклама без фиксированного размера контейнера
Решение: используйте фиксированные размеры контейнеров для рекламных блоков:
.ad-slot {
min-height: 250px; /* Стандартный размер Medium Rectangle */
width: 300px;
background: #f5f5f5; /* Цвет заполнителя */
}
Оптимизация INP: ускорение интерактивности
Interaction to Next Paint (INP) в марте 2024 года официально заменил FID (First Input Delay) в качестве Core Web Vital. INP измеряет время отклика на все взаимодействия пользователя (клики, тапы, нажатия клавиш) за весь сеанс, а не только первое. Цель: менее 200 мс.
Почему INP требовательнее FID
FID измерял задержку только при первом взаимодействии. INP учитывает каждое взаимодействие и берёт худшее значение (точнее: 98-й перцентиль). Это означает: даже если ваша страница быстро реагирует на первый клик, но на десятый тратит 500 мс, INP будет оценён плохо.
Стратегии оптимизации INP
1. Выявление и разбиение длинных задач
JavaScript-задачи длительностью более 50 мс блокируют основной поток и задерживают взаимодействия.
Решение с `requestIdleCallback` и разбиением задач:
// До: блокирующий цикл
function processLargeArray(items) {
items.forEach(item => heavyComputation(item));
}
// После: разбиение на части
function processInChunks(items, chunkSize = 50) {
let index = 0;
function processChunk() {
const chunk = items.slice(index, index + chunkSize);
chunk.forEach(item => heavyComputation(item));
index += chunkSize;
if (index < items.length) {
// Даёт браузеру время для обработки взаимодействий
setTimeout(processChunk, 0);
}
}
processChunk();
}
2. Оптимизация обработчиков событий
Тяжёлые вычисления в обработчиках событий (Scroll, Input, Resize) следует дебаунсить или тротлить.
// Debounce для поля поиска
function debounce(fn, delay = 300) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
const searchInput = document.getElementById('search');
searchInput.addEventListener('input', debounce((e) => {
performSearch(e.target.value);
}, 300));
3. Code-Splitting и Dynamic Imports
Загружайте только тот код, который действительно нужен:
// До: всё загружается сразу
import { heavyChart } from './charting-library';
// После: загружается только по необходимости
const chartButton = document.getElementById('show-chart');
chartButton.addEventListener('click', async () => {
const { heavyChart } = await import('./charting-library');
heavyChart.render('#chart-container', data);
});
4. Web Workers для ресурсоёмких вычислений
// Основной поток — остаётся свободным для взаимодействий
const worker = new Worker('/workers/data-processor.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (e) => {
renderResults(e.data);
};
// data-processor.js (Web Worker)
self.onmessage = (e) => {
const processed = heavyProcessing(e.data.data);
self.postMessage(processed);
};
Инструменты для измерения Core Web Vitals
Правильные инструменты критически важны для успешной оптимизации. Вот наши рекомендации:
| Инструмент | Тип | Бесплатный | Лучше всего для |
|---|---|---|---|
| PageSpeed Insights | Лаб + Полевой | Да | Анализ отдельных страниц |
| Google Search Console | Полевой | Да | Обзор по всему сайту |
| Chrome DevTools | Лаб | Да | Отладка и анализ |
| Web Vitals Extension | Лаб | Да | Мониторинг в реальном времени |
| WebPageTest | Лаб | Да (базовый) | Детальный анализ водопада |
| Lighthouse CI | Лаб | Да | Автоматические CI/CD-проверки |
| SpeedCurve | Лаб + Полевой | Нет (от 12$/мес) | Долгосрочный мониторинг |
| Calibre | Лаб + Полевой | Нет (от 45$/мес) | Командный трекинг |
| GoldenWing Performance-Checker | Лаб | Да | Быстрый анализ |
Рекомендуемый рабочий процесс:
- Обзор: Google Search Console -- проверить отчёт CWV
- Анализ: PageSpeed Insights для самых важных страниц
- Отладка: Chrome DevTools -- вкладка Performance -- выявление узких мест
- Мониторинг: Web Vitals Extension для ежедневной работы
- Автоматизация: Lighthouse CI в пайплайн сборки
Чек-лист Core Web Vitals
Ваш полный чек-лист, упорядоченный по приоритету:
Чек-лист LCP
- [ ] Hero-изображение сжато в WebP/AVIF (менее 200 КБ)
- [ ] Hero-изображение с `fetchpriority="high"` и Preload-подсказкой
- [ ] TTFB менее 800 мс (качественный хостинг + CDN)
- [ ] Критический CSS инлайн в `<head>`
- [ ] Блокирующий рендеринг JavaScript устранён (`defer`/`async`)
- [ ] Сторонние скрипты загружаются после LCP
- [ ] Предзагрузка шрифтов для заголовков
- [ ] Нет Lazy Loading для изображений выше линии сгиба
Чек-лист CLS
- [ ] Все изображения имеют атрибуты `width` и `height`
- [ ] `font-display: swap` для всех веб-шрифтов
- [ ] Переопределение метрик шрифта (`size-adjust`, `ascent-override`)
- [ ] Фиксированные размеры контейнеров для рекламы и встраиваний
- [ ] Cookie-баннер как оверлей (не сдвигающий элемент)
- [ ] Нет динамически вставляемого контента без заполнителей
- [ ] CSS `aspect-ratio` для адаптивных контейнеров
- [ ] Нет поздних DOM-манипуляций в видимой области
Чек-лист INP
- [ ] Нет Long Tasks длиннее 50 мс в основном потоке
- [ ] Обработчики событий с debounce (Search, Scroll, Resize)
- [ ] Code-Splitting для некритических модулей
- [ ] `requestAnimationFrame` для визуальных обновлений
- [ ] Web Workers для ресурсоёмких вычислений
- [ ] Минимальный размер бандла (Tree-Shaking, Dead Code Elimination)
- [ ] Сторонние скрипты асинхронные или отложенные
- [ ] Нет синхронных XHR-запросов
Оптимизации для WordPress
Сайты на WordPress имеют специфические проблемы производительности. Вот наиболее эффективные оптимизации:
1. Аудит плагинов
Главная проблема производительности WordPress -- слишком много плагинов. Каждый плагин добавляет CSS, JavaScript и запросы к базе данных.
Рекомендуемый подход:
- Деактивируйте все плагины и измерьте базовую производительность
- Активируйте плагины по одному и измерьте влияние каждого
- Удалите всё с использованием менее 1%
- Замените тяжёлые плагины на легковесные альтернативы
Рекомендации по плагинам:
| Назначение | Рекомендуется | Избегать |
|---|---|---|
| Кэширование | WP Rocket, LiteSpeed Cache | W3 Total Cache (сложный) |
| Оптимизация изображений | ShortPixel, Imagify | Smush Free (ограниченный) |
| CSS/JS-оптимизация | Perfmatters, Asset CleanUp | Autoptimize (может вызвать конфликты) |
| База данных | WP-Optimize | -- |
| Lazy Loading | Нативный (с WP 5.5) | jQuery-плагины |
2. Оптимизация темы
Многие WordPress-темы загружают сотни КБ неиспользуемого CSS и JavaScript. Page-билдеры вроде Elementor или Divi особенно тяжёлые.
Подходы к оптимизации:
- Переход на легковесные темы (GeneratePress, Kadence, Astra)
- Удаление неиспользуемого CSS (Perfmatters или PurgeCSS)
- Page-билдеры использовать только если клиент сам создаёт страницы
- Разработка кастомной темы для максимальной производительности
3. Оптимизация на уровне сервера
.htaccess — активация браузерного кэширования
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>
GZIP-компрессия
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css
AddOutputFilterByType DEFLATE application/javascript application/json
</IfModule>
Оптимизации для Next.js
Для проектов, которые мы реализуем на Next.js и Payload CMS, действуют иные стратегии оптимизации:
1. Оптимизация изображений с next/image
import Image from 'next/image';
// Автоматическая конвертация в WebP, адаптивные размеры, Lazy Loading
<Image
src="/hero.jpg"
alt="Hero изображение"
width={1200}
height={600}
priority // Для Above-the-Fold = без Lazy Loading
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
quality={85}
/>
2. Оптимизация шрифтов с next/font
import { Inter } from 'next/font/google';
const inter = Inter({
subsets: ['latin'],
display: 'swap',
// Автоматический сабсеттинг и self-hosting шрифтов
});
3. Код-сплиттинг по маршрутам
Next.js автоматически выполняет код-сплиттинг по маршрутам. Дополнительно:
import dynamic from 'next/dynamic';
// Тяжёлые компоненты загружаются только по необходимости
const HeavyChart = dynamic(() => import('../components/HeavyChart'), {
loading: () => <div className="h-96 animate-pulse bg-muted rounded" />,
ssr: false, // Client-Only для интерактивных компонентов
});
4. Server Components (App Router)
// Server Component — нет JavaScript в клиентском бандле
export default async function BlogPost({ params }) {
const post = await getPost(params.slug);
return (
<article>
<h1>{post.title}</h1>
<div dangerouslySetInnerHTML={{ __html: post.content }} />
{/* Только интерактивные части как Client Component */}
<ShareButtons url={post.url} />
</article>
);
}
5. Метаданные и стриминг
// Стриминг с Suspense для более быстрого первоначального отображения
import { Suspense } from 'react';
export default function Page() {
return (
<>
<HeroSection /> {/* Рендерится сразу */}
<Suspense fallback={<LoadingSkeleton />}>
<RecentPosts /> {/* Подгружается, когда данные готовы */}
</Suspense>
</>
);
}
Кейсы из нашей практики
Кейс 1: Корпоративный сайт (Next.js + Payload CMS)
Исходная ситуация:
- PageSpeed Mobile: 52/100
- LCP: 4,1 с (неоптимизированное PNG-hero, 3,2 МБ)
- CLS: 0,22 (шрифты без swap, изображения без размеров)
- INP: 310 мс (тяжёлая библиотека анимаций)
Проведённые мероприятия:
- Hero-изображение: PNG -> WebP, 3,2 МБ -> 120 КБ, `fetchpriority="high"`
- Все изображения через `next/image` с фиксированными размерами
- Оптимизация шрифтов с `next/font` (self-hosted, `swap`)
- Framer Motion заменён на CSS-переходы (бандл -180 КБ)
- Сторонние скрипты отложены после LCP
Результат:
- PageSpeed Mobile: 96/100 (+44 балла)
- LCP: 1,3 с (-68%)
- CLS: 0,01 (-95%)
- INP: 85 мс (-73%)
- Показатель отказов: -35%, конверсия: +22%
Кейс 2: Интернет-магазин (WordPress + WooCommerce)
Исходная ситуация:
- PageSpeed Mobile: 38/100
- LCP: 5,8 с (слайдер с 5 несжатыми JPEG)
- CLS: 0,31 (изображения товаров без размеров, подгружаемые отзывы)
- INP: 420 мс (jQuery + 15 активных плагинов)
Проведённые мероприятия:
- Слайдер заменён на статическое hero-изображение
- ShortPixel для автоматического сжатия изображений (WebP)
- Аудит плагинов: 15 -> 8 (7 ненужных удалены)
- Установлен WP Rocket (кэширование, минификация CSS/JS, Lazy Loading)
- Переход хостинга с Shared на Managed VPS
- Все изображения товаров с фиксированными размерами
Результат:
- PageSpeed Mobile: 88/100 (+50 баллов)
- LCP: 1,9 с (-67%)
- CLS: 0,04 (-87%)
- INP: 145 мс (-65%)
- Выручка: +18% в первый месяц после оптимизации
Кейс 3: Местное сервисное предприятие (WordPress)
Исходная ситуация:
- PageSpeed Mobile: 44/100
- LCP: 4,5 с (неоптимизированный hero-JPEG, 2,1 МБ)
- CLS: 0,28 (изображения без размеров, подгружаемый cookie-баннер)
- INP: 190 мс
Проведённые мероприятия:
- Hero-изображение: JPEG -> WebP, 2,1 МБ -> 95 КБ, fetchpriority="high"
- Все изображения с width/height
- Cookie-баннер переведён на position: fixed
- Установлены WP Rocket + ShortPixel
- Удалён неиспользуемый CSS (Perfmatters)
Результат:
- PageSpeed Mobile: 92/100 (+48 баллов)
- LCP: 1,6 с (-64%)
- CLS: 0,03 (-89%)
- INP: 95 мс (-50%)
- Позиция в Google по основному ключевому слову: страница 3 -> страница 1 (позиция 7)
Частые ошибки при оптимизации CWV
Из нашего опыта работы с более чем 120 проектами мы постоянно наблюдаем одни и те же ошибки:
1. Оптимизировать только лабораторные данные, игнорируя полевые
Лабораторные данные (Lighthouse) показывают потенциал, но Google ранжирует по полевым данным (CrUX). Сайт может иметь 100/100 в Lighthouse и при этом показывать плохие полевые данные, если реальные пользователи используют медленные устройства или плохое интернет-соединение.
2. Ставить Lazy Loading на все изображения
Lazy Loading -- это отлично, но не для изображений выше линии сгиба. Добавление `loading="lazy"` к hero-изображению резко ухудшает LCP, потому что браузер загружает его, только когда оно попадает во вьюпорт.
3. Загружать слишком много шрифтов
Каждый файл шрифта стоит времени загрузки и может вызывать CLS. Ограничьтесь 2-3 начертаниями (Regular, Bold, возможно Italic) и загружайте только нужные наборы символов (latin вместо latin-extended).
4. Нагромождение плагинов производительности
Три плагина кэширования одновременно не делают сайт быстрее, а наоборот. Конфликты между плагинами -- самая частая причина необъяснимых проблем с производительностью. Достаточно одного хорошего плагина кэширования (например, WP Rocket).
5. Игнорирование сторонних скриптов
Google Analytics, Facebook Pixel, Hotjar, Intercom, Drift -- каждый дополнительный скрипт стоит производительности. Задайте себе вопрос по каждому скрипту: действительно ли он мне нужен? И если да -- можно ли его загружать с отложкой?
6. Оптимизация только главной страницы
Google оценивает каждый URL индивидуально. Страницы товаров, статьи блога и страница контактов должны быть оптимизированы так же хорошо, как и главная. Проверяйте в Search Console отчёт CWV для всех групп страниц.
Настройка мониторинга производительности
Оптимизация CWV -- это не разовый проект. Новые функции, изменения контента и обновления сторонних сервисов могут в любой момент ухудшить производительность. Вот как настроить непрерывный мониторинг:
1. Google Search Console (бесплатно)
- Откройте отчёт «Core Web Vitals» в разделе «Улучшения»
- Ежемесячно проверяйте количество URL со статусом «плохо» или «требует улучшения»
- Настройте оповещения об ухудшениях
2. Real User Monitoring (RUM)
// Подключение библиотеки Web Vitals
import { onLCP, onCLS, onINP } from 'web-vitals';
function sendToAnalytics(metric) {
// Отправка в ваш аналитический инструмент
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
}
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
3. Lighthouse CI в пайплайне сборки
.github/workflows/lighthouse.yml
name: Lighthouse CI
on: [push]
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: treosh/lighthouse-ci-action@v11
with:
urls: |
https://example.com/
https://example.com/blog/
budgetPath: ./budget.json
temporaryPublicStorage: true
4. Определение бюджетов производительности
{
"timings": [
{ "metric": "largest-contentful-paint", "budget": 2500 },
{ "metric": "cumulative-layout-shift", "budget": 0.1 },
{ "metric": "interactive", "budget": 3800 }
],
"resourceSizes": [
{ "resourceType": "script", "budget": 300 },
{ "resourceType": "image", "budget": 500 },
{ "resourceType": "total", "budget": 1500 }
]
}
Сторонние скрипты и их влияние на Core Web Vitals
Сторонние скрипты -- один из главных убийц производительности современных сайтов. По данным HTTP Archive, сайты в среднем загружают 21 сторонний ресурс -- от аналитики и чатботов до рекламных пикселей. Эти внешние скрипты могут значительно ухудшить ваши Core Web Vitals.
Какие сторонние скрипты вызывают наибольшие проблемы
Высокое влияние на LCP и INP:
- Чат-виджеты (например, Intercom, Zendesk Chat): часто загружают 200--500 КБ JavaScript и блокируют основной поток
- Встраивания соцсетей (Facebook, Instagram, Twitter): одно встраивание Facebook может загрузить 1--3 МБ дополнительных ресурсов
- Видео-встраивания (YouTube, Vimeo): YouTube iframe без оптимизации загружает 600 КБ--1,5 МБ
Среднее влияние:
- Инструменты аналитики (Google Analytics, Hotjar, Matomo): обычно 50--150 КБ, но пиксели отслеживания суммируются
- Cookie-баннеры (Cookiebot, Usercentrics): 30--100 КБ, но часто блокируют рендеринг
- Сервисы шрифтов (Google Fonts, Adobe Fonts): 50--200 КБ на семейство шрифтов
Низкое влияние при правильном подключении:
- Менеджеры тегов (Google Tag Manager): примерно 80 КБ, но размер контейнера растёт с каждым тегом
- Пиксели конверсии (Google Ads, Meta Pixel): по отдельности малы, но кумулятивный эффект
Стратегии оптимизации
1. Lazy Loading для сторонних скриптов
Загружайте чат-виджеты, встраивания соцсетей и другие некритичные скрипты только когда пользователь в них нуждается:
- Чат-виджет загружать после скролла или через 5 секунд
- Встраивания соцсетей реализовать как фасад (статическое изображение с загрузкой по клику)
- YouTube-видео встраивать через паттерн lite-youtube-embed -- экономия до 500 КБ на видео
2. Приоритизация скриптов
Используйте правильные атрибуты загрузки:
- async: скрипт загружается параллельно и выполняется сразу (для аналитики)
- defer: скрипт загружается параллельно, но выполняется только после парсинга HTML (для большинства скриптов)
- Без атрибута: скрипт блокирует рендеринг -- избегайте этого
3. Self-Hosting вместо CDN-подключения
Размещайте часто используемые сторонние ресурсы на своём сервере:
- Google Fonts: скачайте WOFF2-файлы и разместите на своём сервере. Это экономит DNS-запрос и дополнительное соединение.
- Скрипты аналитики: при self-hosted Matomo сторонний запрос отсутствует полностью
4. Регулярный аудит
Проводите ежеквартальный аудит сторонних скриптов. Удаляйте скрипты, которые больше не нужны. На практике мы находим при 70% всех аудитов как минимум один скрипт, не приносящий пользы.
Измерение влияния сторонних скриптов
Используйте следующие инструменты для оценки влияния отдельных скриптов:
- Chrome DevTools > Performance Tab: показывает, какие скрипты блокируют основной поток
- WebPageTest > вкладка «Block»: тестируйте время загрузки с и без определённых сторонних доменов
- Lighthouse > Treemap: визуализирует размер JavaScript по источнику скрипта
Серверные оптимизации: хостинг, CDN и кэширование
Лучшая фронтенд-оптимизация мало поможет, если сервер отвечает медленно. Time to First Byte (TTFB) должен быть менее 800 миллисекунд -- в идеале менее 200 мс. В Австрии мы наблюдаем у многих сайтов малого и среднего бизнеса TTFB свыше 1,5 секунд.
Оптимизация хостинга
Shared Hosting -- самая частая проблема
Более 60% сайтов австрийского малого и среднего бизнеса работают на Shared Hosting. Это значит: сотни сайтов делят один сервер. В пиковые моменты TTFB резко возрастает.
Рекомендации по типам сайтов:
- Статические/JAMstack-сайты: Edge-хостинг (Vercel, Netlify, Cloudflare Pages) -- TTFB менее 50 мс по всему миру
- WordPress-сайты: Managed WordPress Hosting (Raidboxes, Cloudways) -- TTFB 100--300 мс
- PHP-приложения: VPS с OPcache, PHP 8.2+ и FastCGI -- TTFB 150--400 мс
- Node.js-приложения: контейнерный хостинг (Railway, Fly.io) или VPS с PM2
Правильная настройка CDN
Content Delivery Network распределяет статический контент на серверы по всему миру. Для австрийских сайтов с аудиторией DACH оптимальна CDN с Edge-нодами во Франкфурте, Вене и Цюрихе.
Лучшие практики настройки CDN:
- Статические ассеты (CSS, JS, изображения, шрифты) раздавать через CDN
- HTML-страницы кэшировать только если они редко меняются (например, лендинги)
- Cache-Control-заголовки настроить правильно: 'public, max-age=31536000, immutable' для версионированных ассетов
- Brotli-сжатие активировать -- на 15--25% меньше, чем Gzip
Серверное кэширование
Page Caching:
Генерируйте HTML-страницы один раз и раздавайте кэшированную версию. Для WordPress подходят плагины WP Super Cache или W3 Total Cache. Для Next.js используйте Incremental Static Regeneration (ISR).
Object Caching с Redis:
Redis хранит часто запрашиваемые результаты из базы данных в оперативной памяти. Улучшение TTFB может составить 50--80%. Для WordPress Redis Object Cache -- это настоящий прорыв, особенно для магазинов на WooCommerce.
OPcache для PHP:
Активируйте OPcache с достаточным объёмом памяти (минимум 128 МБ). OPcache компилирует PHP-файлы один раз и сохраняет байт-код. Улучшение производительности составляет 200--400% для PHP-сайтов.
HTTP/2 и HTTP/3
Убедитесь, что ваш сервер поддерживает HTTP/2 или в идеале HTTP/3 (QUIC):
- HTTP/2: мультиплексирование позволяет параллельную загрузку нескольких ресурсов через одно соединение
- HTTP/3: основан на UDP вместо TCP, снижает задержку при плохих сетевых условиях на 30--50%
- Большинство современных хостинг-провайдеров и CDN поддерживают HTTP/3 с 2024 года
Core Web Vitals для E-Commerce-сайтов
E-Commerce-сайты сталкиваются с особыми вызовами в отношении Core Web Vitals. Изображения товаров, системы фильтрации, динамическое отображение цен и процессы оформления заказа усложняют оптимизацию -- но делают её тем более выгодной.
Оптимизация LCP для страниц товаров
Самый большой видимый элемент на страницах товаров -- обычно основное изображение товара. Оптимизируйте его целенаправленно:
- Предзагрузка изображения с помощью '<link rel="preload" as="image">' в HTML-head
- Использование заполнителя: Low-Quality Image Placeholder (LQIP) или техника Blur-Up
- Ограничение размера: основное изображение должно быть не более 150 КБ (WebP, качество 80)
- Без Lazy Loading для основного изображения товара -- оно должно загружаться сразу
Проблемы CLS в интернет-магазинах
Самые частые причины CLS в E-Commerce:
- Подгружаемые цены: персонализированные цены или ярлыки распродаж, вставляемые через JavaScript
- Звёзды рейтинга: когда виджет рейтинга загружается асинхронно и сдвигает контент
- Баннеры и уведомления: баннер «Бесплатная доставка от 50 евро», появляющийся после загрузки страницы
- Рекомендации товаров: карусели «Покупатели также купили», занимающие место
Решения:
- Резервируйте фиксированные заполнители (min-height/aspect-ratio) для всех динамических элементов
- Загружайте информацию о ценах на сервере, а не через клиентский JavaScript
- Устанавливайте атрибуты width и height на все изображения товаров
Оптимизация INP для фильтров и поиска
Фильтры товаров и функции поиска интерактивны -- и именно здесь проявляется значение INP:
- Debouncing для поискового ввода: ожидание 300 мс после последнего нажатия клавиши перед запуском поиска
- Виртуальный скроллинг для категорий с сотнями товаров
- Web Worker для ресурсоёмких вычислений фильтрации, чтобы разгрузить основной поток
- Optimistic UI: показывайте результаты фильтрации сразу и обновляйте в фоне
Производительность оформления заказа
Процесс оформления заказа -- критический момент для E-Commerce: каждая секунда задержки может увеличить процент отказов на 7%:
- Payment-скрипты (Stripe, PayPal, Klarna) загружать только на странице оформления, а не на всех страницах
- Формы с минимальным JavaScript: использовать нативную HTML-валидацию вместо тяжёлых библиотек
- Автозаполнение адреса экономит время пользователя и сокращает ожидание следующего взаимодействия
Отраслевые бенчмарки для Австрии
Для E-Commerce-сайтов в регионе DACH следующие бенчмарки CWV считаются отличными:
- LCP: менее 2,0 секунд (среднее по отрасли: 3,8 секунд)
- INP: менее 150 мс (среднее по отрасли: 280 мс)
- CLS: менее 0,05 (среднее по отрасли: 0,15)
Магазины с показателями в зелёной зоне по всем трём метрикам сообщают о 12--25% более высоких конверсиях по сравнению со средним по отрасли.
Оптимизация PageSpeed на практике: анализ «до и после»
Теория важна, но ничто не убеждает лучше реальных результатов. Вот три анонимизированных примера из нашей агентской практики с конкретными мерами и измеримыми улучшениями.
Пример 1: Ремонтная компания из Вены
Исходная ситуация:
- WordPress-сайт с 35 страницами, Shared Hosting
- LCP: 6,2 секунды | CLS: 0,28 | INP: 420 мс
- PageSpeed Score: 28/100 (Mobile)
Проведённые мероприятия:
- Смена хостинга на Managed WordPress (Raidboxes)
- Конвертация изображений в WebP, внедрение Lazy Loading
- 8 неиспользуемых плагинов деактивированы и удалены
- Сгенерирован Critical CSS, отложено выполнение JavaScript
- Google Fonts размещены локально, сокращены до 2 начертаний
Результат через 4 недели:
- LCP: 1,8 секунды (улучшение на 71%) | CLS: 0,02 | INP: 95 мс
- PageSpeed Score: 92/100 (Mobile)
- Органический трафик: +34% через 3 месяца
Пример 2: Интернет-магазин спортивной одежды (Австрия)
Исходная ситуация:
- WooCommerce с 1.200 товарами, VPS-хостинг
- LCP: 4,8 секунды | CLS: 0,22 | INP: 380 мс
- PageSpeed Score: 35/100 (Mobile)
Проведённые мероприятия:
- Установлен и настроен Redis Object Cache
- Автоматическая конвертация изображений товаров в WebP (ShortPixel)
- Слайдер на главной заменён статическим hero-изображением
- WooCommerce Cart Fragments отключены на нешоповых страницах
- Активирован Cloudflare CDN с Brotli-сжатием
- Оформление заказа вынесено на отдельный субдомен с минимальным CSS/JS
Результат через 6 недель:
- LCP: 2,1 секунды (улучшение на 56%) | CLS: 0,04 | INP: 140 мс
- PageSpeed Score: 78/100 (Mobile)
- Конверсия: +18%, процент брошенных корзин: -12%
Пример 3: SaaS-лендинг (Next.js)
Исходная ситуация:
- Next.js 14 на Vercel, 8 лендингов
- LCP: 3,1 секунды | CLS: 0,08 | INP: 250 мс
- PageSpeed Score: 62/100 (Mobile)
Проведённые мероприятия:
- Hero-изображение оптимизировано с next/image и атрибутом priority
- Intercom-чат-виджет лениво загружается через Intersection Observer
- Библиотека анимаций (Framer Motion) заменена на CSS-переходы (экономия: 120 КБ)
- Анализ бандла с @next/bundle-analyzer, удалён неиспользуемый код
- Font-Display: swap и сабсеттинг шрифтов
Результат через 2 недели:
- LCP: 1,4 секунды (улучшение на 55%) | CLS: 0,01 | INP: 85 мс
- PageSpeed Score: 97/100 (Mobile)
- Демо-запросы: +22% в следующем месяце
Выводы из всех трёх проектов
- Наибольший выигрыш почти всегда приносят изображения и сторонние скрипты
- Апгрейд хостинга -- зачастую наиболее экономически эффективная единичная мера
- Меньше -- значит больше: последовательно сокращайте плагины, начертания шрифтов и анимации
- Измеряйте до и после каждого изменения: так вы определите, какие изменения дают наибольший эффект
Core Web Vitals и SEO-ранжирование: измеримые последствия
С тех пор как Google ввёл Core Web Vitals как официальный фактор ранжирования, многие владельцы сайтов в регионе DACH задаются вопросом: насколько сильно LCP, CLS и INP влияют на позиции в поисковых системах? Ответ более тонкий, чем многие ожидают. На основе актуальных исследований и данных мы анализируем измеримые последствия и показываем, как использовать Core Web Vitals как стратегическое конкурентное преимущество.
Корреляция между Core Web Vitals и позициями
Несколько масштабных исследований изучили взаимосвязь между Core Web Vitals и органическим ранжированием. Результаты последовательны, но не столь драматичны, как утверждают некоторые SEO-эксперты:
- Исследование Searchmetrics (2025, 500 000 URL в регионе DACH) показывает: сайты с показателями всех трёх Core Web Vitals в зелёной зоне ранжируются в среднем на 3,2 позиции выше, чем сопоставимые сайты с плохими значениями
- Ahrefs проанализировал в 2025 году более 33 миллионов страниц и установил: только 33% страниц на позиции 1 проходят все тесты Core Web Vitals -- это значит, что CWV сами по себе не определяют ранжирование
- Анализ HTTP Archive для немецкого рынка показал: доля сайтов с хорошими значениями CWV выросла с 24% (2022) до 48% (2025) -- конкуренция становится жёстче
Ключевой вывод: Core Web Vitals -- это фактор-тайбрейкер. При прочей равной релевантности и авторитетности они определяют позиционирование. Они не выведут слабый контент на позицию 1, но могут стать решающим фактором между позицией 3 и позицией 7.
Отраслевые бенчмарки для региона DACH
Требования к Core Web Vitals значительно различаются в зависимости от отрасли. Для австрийского рынка конкурентоспособными считаются следующие показатели:
E-Commerce и интернет-магазины:
- LCP: менее 2,0 секунд (среднее по отрасли DACH: 3,1 секунды)
- CLS: менее 0,05 (среднее: 0,14)
- INP: менее 150 мс (среднее: 280 мс)
- Основная сложность -- оптимизация изображений товаров и многочисленные сторонние скрипты (трекинг, платёжные провайдеры, чатботы)
B2B-услуги:
- LCP: менее 1,8 секунд (среднее по отрасли DACH: 2,4 секунды)
- CLS: менее 0,03 (среднее: 0,08)
- INP: менее 100 мс (среднее: 180 мс)
- B2B-сайты обычно имеют меньше сторонних скриптов и поэтому легче достигают хороших значений
Новостные порталы и контентные сайты:
- LCP: менее 2,5 секунд (среднее по отрасли DACH: 3,8 секунд)
- CLS: менее 0,08 (среднее: 0,22)
- INP: менее 200 мс (среднее: 320 мс)
- Главная проблема -- высокое значение CLS из-за подгружаемых рекламных баннеров и динамического контента
Расчёт ROI: что даёт оптимизация CWV?
Для компаний в регионе DACH встаёт вопрос, окупается ли инвестиция в оптимизацию Core Web Vitals. Ответ зависит от бизнес-модели, но в большинстве случаев однозначно положительный:
Прямое влияние на конверсию:
- Vodafone сообщил о 31% более высокой конверсии после улучшения LCP на 31%
- Netzsieger.de зафиксировал после оптимизации CWV рост органического трафика на 18% за 3 месяца
- Zalando установил, что каждые 100 мс улучшения скорости загрузки увеличивают выручку за сессию на 0,7%
Расчёт для типичного австрийского малого и среднего бизнеса:
Допустим, ваш сайт имеет 10 000 органических посетителей в месяц при конверсии 2% и среднем доходе с заказа 500 евро. Оптимизация CWV, повышающая конверсию на 15% (с 2% до 2,3%), даёт:
- Дополнительных конверсий в месяц: 30
- Дополнительная выручка в месяц: 15 000 евро
- Дополнительная выручка в год: 180 000 евро
Стоимость единовременной инвестиции в оптимизацию CWV, в зависимости от сложности сайта, составляет от 2 000 до 15 000 евро. Возврат инвестиций обычно достигается за 1-3 месяца.
Мониторинг и непрерывное улучшение
Core Web Vitals -- это не разовая задача, а требуют непрерывного мониторинга. Изменения контента, новые плагины, обновления сторонних скриптов или увеличение трафика могут в любой момент ухудшить показатели.
Используйте эту стратегию мониторинга:
- Еженедельно: автоматические тесты Lighthouse CI в пайплайне CI/CD
- Ежемесячно: проверка данных CrUX (Chrome User Experience Report) в Google Search Console
- Ежеквартально: комплексный аудит производительности со сравнением с конкурентами
- При каждом деплое: автоматические бюджеты производительности, останавливающие сборку при превышении пороговых значений
Будущее Core Web Vitals: что ждёт после INP?
Google непрерывно развивает Core Web Vitals. После замены FID (First Input Delay) на INP (Interaction to Next Paint) в марте 2024 года многие SEO-специалисты задаются вопросом: какие метрики будут введены следующими, и как можно подготовиться к ним уже сейчас?
Эволюция Core Web Vitals
Взгляд на историю развития помогает оценить будущее направление:
- 2020: введение Core Web Vitals с LCP, FID и CLS
- 2021: Core Web Vitals становятся официальным фактором ранжирования
- 2024: FID заменён на INP -- значительно более требовательная метрика интерактивности
- 2025: Google вводит улучшенное измерение CLS (сдвиги макета учитываются только в определённых контекстах)
- 2026+: несколько новых метрик находятся в фазе тестирования
Очевидная тенденция: Google движется от упрощённых метрик к более комплексному измерению реального пользовательского опыта.
Экспериментальные метрики, о которых стоит знать
Google и сообщество веб-производительности работают над несколькими новыми метриками, которые потенциально могут войти в Core Web Vitals:
Smoothness (плавность анимаций)
Эта метрика измеряет, насколько плавно работают анимации и скролл-взаимодействия на сайте. Цель -- обнаружение пропусков кадров и рывков, ухудшающих пользовательский опыт. Особенно актуально для:
- Сайтов с parallax-скроллинг-эффектами
- E-Commerce-магазинов с каруселями товаров
- Сайтов со сложными CSS-анимациями
- Single-Page-приложений с динамическими переходами
Responsiveness Beyond INP
Пока INP измеряет задержку до визуального обновления после взаимодействия, ведётся работа над охватом всей цепочки взаимодействия. Сюда входят:
- Время завершения всех сетевых запросов, вызванных взаимодействием
- Стабильность макета после взаимодействия
- Постоянство времени отклика на протяжении всего сеанса
Long Animation Frames (LoAF)
Этот API обеспечивает более точный анализ того, почему страница реагирует медленно. В отличие от существующих Long Tasks, которые измеряют только длительность, LoAF предоставляет детальную информацию о причине задержки -- включая ответственные скрипты и функции.
Soft Navigations и Single-Page-приложения
Одна из крупнейших пробелов в текущих Core Web Vitals -- это измерение Soft Navigations -- переходов между страницами внутри Single-Page-приложений (SPA), происходящих без полной перезагрузки. Google активно работает над решением, делающим CWV справедливыми и информативными для SPA.
Это особенно актуально для сайтов, построенных на фреймворках Next.js, Nuxt.js или Angular. В регионе DACH, по данным W3Techs, уже 18% из топ-10 000 сайтов используют SPA-архитектуры -- и эта доля растёт.
Что это значит для вас?
- Если вы используете SPA, следите за Soft Navigation API
- Уже сейчас внедряйте мониторинг производительности для клиентских переходов
- Тестируйте вашу SPA не только при первоначальной загрузке, но и при последующих навигациях
Подготовка к будущим метрикам
Даже если точные будущие метрики ещё не определены, вы можете подготовиться уже сегодня:
- Введите бюджет производительности -- определите максимальные размеры JavaScript-бандлов, максимальное время загрузки и максимальные сдвиги макета. Эти бюджеты защитят вас от регрессий, независимо от того, какие метрики введёт Google
- Внедрите Real User Monitoring (RUM) -- собирайте данные о производительности от реальных пользователей, а не только из синтетических тестов. Инструменты вроде SpeedCurve, Web Vitals Library или Vercel Analytics предоставляют ценные данные в реальном времени
- Проанализируйте JavaScript-бандл -- сократите неиспользуемый код, внедрите код-сплиттинг и Lazy Loading. Меньшие бандлы означают лучшую производительность -- независимо от конкретной метрики
- Оптимизируйте серверную производительность -- инвестируйте в быстрые серверы, настройку CDN и Edge Computing. Надёжная серверная инфраструктура -- основа для всех метрик производительности
- Доступность как фактор производительности -- доступные сайты часто более производительны, так как используют чистый, семантический HTML-код. Google всё больше оценивает доступность как сигнал качества
Главный совет для рынка DACH: следуйте пользовательско-ориентированному подходу вместо оптимизации отдельных метрик. Если ваш сайт быстро загружается, стабильно реагирует на взаимодействия и визуально стабилен, вы выиграете от всех будущих обновлений Core Web Vitals -- независимо от того, какие конкретные метрики введёт Google.
Заключение и следующие шаги
Core Web Vitals -- это не разовый проект, а непрерывный процесс. Новые функции, изменения контента и обновления сторонних сервисов могут в любой момент ухудшить производительность. Вот ваш план действий:
Немедленные меры (на этой неделе)
- Измерить: откройте PageSpeed Insights и протестируйте 5 самых важных страниц
- Приоритизировать: определите метрику с наибольшим потенциалом улучшения
- Quick Wins: сжать изображения, добавить размеры, оптимизировать шрифты
Краткосрочные (в этом месяце)
- Оптимизировать сервер: оценить хостинг, настроить CDN, настроить кэширование
- JavaScript-аудит: выявить и удалить ненужные плагины/скрипты
- Оценить тему/фреймворк: является ли ваша тема/фреймворк узким местом?
Долгосрочные (в этом квартале)
- Настроить мониторинг: Automated Performance Monitoring (например, SpeedCurve, Calibre)
- Определить бюджет производительности: максимальный размер бандла, максимальное значение LCP
- Повышение осведомлённости команды: чувствительность всех разработчиков к вопросам производительности
- Регулярные аудиты: ежемесячные ревью производительности
Нужна помощь?
Оптимизация Core Web Vitals -- сложная задача, требующая технической экспертизы. В GoldenWing мы оптимизируем Core Web Vitals как обязательную часть каждого проекта по веб-дизайну и SEO. От анализа производительности до реализации -- мы приведём ваш сайт к зелёным показателям.
Воспользуйтесь нашим бесплатным Performance Checker, чтобы узнать текущее состояние вашего сайта, и свяжитесь с нами для бесплатной консультации. Вместе мы сделаем ваш сайт быстрым, стабильным и удобным для пользователей.
Если вы хотите узнать больше о техническом SEO, посетите наши записи в лексиконе или прочитайте другие наши статьи на темы веб-дизайна и оптимизации производительности.
