Як прискорити перший екран WordPress і покращити LCP

Largest Contentful Paint вимірює, коли у видимій частині сторінки відобразився найбільший текстовий або графічний елемент. На корпоративному сайті ним часто стає hero-зображення, великий заголовок або фон першої секції.

За актуальною документацією web.dev, добрий LCP — до 2,5 секунди щонайменше для 75% відвідувань. Проте число без діагностики не пояснює, що саме затримує сторінку.

Крок 1. Визначте фактичний LCP-елемент

Відкрийте Performance або Lighthouse у Chrome DevTools і перевірте, який елемент позначено як LCP. Повторіть тест для мобільної ширини, сторінки без авторизації та чистого кешу. На різних шаблонах елемент може відрізнятися.

Польові дані Chrome User Experience Report показують досвід реальних користувачів, але новому або маловідвідуваному URL їх може бракувати. Лабораторний тест потрібен для налагодження, польовий — для оцінки реального результату.

Крок 2. Розкладіть LCP на чотири частини

• TTFB. Час до першого байта HTML.
• Затримка початку завантаження ресурсу. Коли браузер дізнався про зображення.
• Тривалість завантаження. Розмір, мережа й сервер зображень.
• Затримка рендерингу. Час між готовністю ресурсу та його появою.

Оптимізація має працювати з найбільшою частиною, а не з випадковою рекомендацією зі списку.

TTFB: початок усієї послідовності

Перевірте кеш сторінки, запити бази, зовнішні API, PHP workers і географію сервера. Якщо HTML починає завантажуватися пізно, браузер пізно знаходить CSS, шрифти й hero-зображення.

Кеш не повинен приховувати критичні помилки персоналізації. Спочатку визначте, які сторінки можуть бути повністю кешовані, а які мають динамічні фрагменти.

Hero-зображення має бути видимим у HTML

Коли LCP-зображення задається через пізній JavaScript або вкладений CSS background, браузер відкриває його із затримкою. Для змістовної ілюстрації краще використовувати елемент img або picture у початковому HTML.

Вкажіть width і height, коректний srcset для різних екранів та сучасний формат. Не віддавайте мобільному пристрою файл, підготовлений для великого 4K-монітора.

Не відкладайте LCP-зображення

loading="lazy" корисний нижче першого екрана, але може зашкодити головному hero. Для підтвердженого LCP-ресурсу можна застосувати fetchpriority="high". Preload доречний, якщо браузер інакше знаходить ресурс пізно, але URL та атрибути повинні відповідати фактичному зображенню.

Не ставте високий пріоритет усім картинкам: вони почнуть конкурувати між собою.

Шрифти й великий текстовий LCP

Якщо LCP — заголовок, затримку може створювати вебшрифт. Зменште набір накреслень, використовуйте WOFF2, локальне розміщення, правильний font-display і preload лише реально критичного файлу. Fallback-шрифт добирають близьким за метриками, щоб уникнути стрибка після заміни.

Критичний CSS

Великий CSS-файл, імпорти та невикористані стилі блокують малювання. У Bricks варто покладатися на глобальні класи й компоненти, а не дублювати стилі на кожному елементі. Перевіряйте, чи оптимізатор не змінює порядок стилів і не створює короткий «неоформлений» екран.

JavaScript і затримка рендерингу

Важкі слайдери, анімаційні бібліотеки, сторонні чати й аналітика можуть зайняти головний потік перед відображенням hero. Перший екран не повинен залежати від складної анімації, щоб стати видимим. Відкладіть некритичні скрипти й перевірте довгі задачі в Performance.

Слайдер на першому екрані

Слайдер часто завантажує кілька великих зображень і JavaScript заради контенту, який більшість користувачів не побачить. Якщо він не підтверджений даними, статична сильна пропозиція зазвичай простіша, доступніша й швидша.

Послідовність перевірки

1. Зафіксуйте LCP-елемент і базовий trace.
2. Перевірте TTFB і час відкриття ресурсу.
3. Оптимізуйте розмір, формат і responsive images.
4. Приберіть lazy loading з LCP та за потреби задайте пріоритет.
5. Скоротіть блокуючий CSS, шрифти й JavaScript.
6. Повторіть тест на основних шаблонах.
7. Після випуску спостерігайте польові дані.

Загальний контекст показників пояснює матеріал про Core Web Vitals, а формати зображень — порівняння WebP і AVIF. Комплексна діагностика доступна в межах оптимізації швидкості сайту.

FAQ

Поширені запитання

Яке значення LCP вважається добрим?

Актуальна рекомендація web.dev — не більше 2,5 секунди для щонайменше 75% відвідувань. Оцінювати потрібно окремо мобільні й десктопні дані.

Чи потрібно lazy-load для hero-зображення?

Зазвичай ні, якщо воно є LCP-елементом у першому екрані. Відкладене завантаження може пізніше почати запит і погіршити показник.

Чи допоможе WebP автоматично виправити LCP?

Формат зменшує передачу даних, але не усуває повільний сервер, пізнє відкриття ресурсу, блокуючий CSS або затримку рендерингу.

Чому PageSpeed і Search Console показують різні результати?

PageSpeed лабораторно моделює окремий запуск, а Search Console використовує агреговані польові дані реальних користувачів за період. Обидва джерела потрібні для різних задач.

Чи слід preload усі важливі ресурси?

Ні. Надлишковий preload конкурує за пропускну здатність. Пріоритет дають лише ресурсам, які точно потрібні рано, насамперед підтвердженому LCP-зображенню або критичному шрифту.