LCP: що це таке і як оптимізувати для SEO

LCP є критичною метрикою користувацького досвіду і фактором ранжування Google. Коли користувач переходить на вашу сторінку, його не цікавить загальний час завантаження. Його цікавить, коли він побачить основний контент і зможе почати читати чи взаємодіяти. LCP вимірює саме цей момент: коли найбільший елемент контенту стає видимим. Якщо LCP у порядку, ваша сторінка здається швидкою. Якщо ні, вона здається повільною, навіть якщо інші метрики хороші.

Оптимізація LCP потребує триступеневого підходу: покращити час відповіді сервера (TTFB), усунути ресурси, що блокують відображення, і оптимізувати зображення. Кожен підхід усуває різні вузькі місця LCP. Разом вони дають разюче покращення.

Що таке LCP і як його вимірюють

Largest Contentful Paint (LCP) є часом відображення найбільшого видимого елемента контенту на вашій сторінці. Це може бути велике зображення, відео, заголовок або текстовий блок. LCP вимірюється від моменту, коли користувач переходить на вашу сторінку, до моменту, коли цей елемент стає видимим. Документація Google щодо LCP містить детальну технічну інформацію та стратегії оптимізації.

LCP не є бінарною метрикою «пройдено/не пройдено». Це безперервна оцінка. Google визначив, що LCP менш ніж 2,5 секунди є «хорошим», LCP між 2,5 і 4 секундами потребує покращення, а LCP понад 4 секунди є поганим. Користувачі сприймають сторінки з LCP менш ніж 2 секунди як дуже швидкі. Сторінки з LCP 3-4 секунди відчутно повільніші. Сторінки з LCP понад 5 секунд часто покидають.

LCP змінюється під час завантаження сторінки, коли з'являються більші елементи контенту. Якщо величезне зображення завантажується на позначці 3 секунди, LCP стрибає з 1 секунди до 3 секунд. Це важливо: не можна оптимізувати лише час початкового відображення. Потрібно подбати, щоб усі великі елементи контенту завантажувалися швидко.

Що таке Time to First Byte (TTFB)

Time to First Byte (TTFB) є часом від початку навігації до моменту, коли сервер повертає перший байт HTML-документа. TTFB задає нижню межу для LCP. Якщо TTFB становить 2 секунди, LCP не може бути кращим за 2 секунди, бо браузер ще навіть не отримав HTML. Скорочення TTFB є передумовою скорочення LCP.

Хороший TTFB: менш ніж 600 мілісекунд. TTFB між 600 і 1800 мс потребує покращення. TTFB понад 1800 мс є поганим. Якщо ваш TTFB повільний, спершу зосередьтеся на оптимізації сервера. Жодна оптимізація фронтенду не компенсує повільний сервер.

Типові причини повільного TTFB: неефективний код бекенду, запити до бази даних або перевантаження сервера. Повільний хостинг також спричиняє високий TTFB. Спільний хостинг часто надзвичайно повільний. Перейдіть на VPS або хмарний хостинг для кращої продуктивності. Використовуйте CDN, щоб скоротити TTFB, віддаючи контент із серверів поблизу ваших користувачів.

PageSpeed Insights показує ваш TTFB у розділі «Час відповіді сервера». Якщо TTFB є вузьким місцем, його буде виділено як пріоритет.

Визначення найбільшого елемента контенту

LCP залежить від того, що є найбільшим елементом контенту на вашій сторінці. У публікації блогу найбільшим елементом може бути велике головне зображення. На сторінці товару це може бути фото товару. На новинному сайті це може бути заголовок статті. Визначити елемент LCP: перший крок до його оптимізації.

Використовуйте Chrome DevTools, щоб визначити елемент LCP. Відкрийте DevTools, перейдіть на вкладку Performance, почніть запис і перезавантажте сторінку. У записі Performance знайдіть позначку «Largest Contentful Paint». Наведіть на неї курсор, щоб побачити, який елемент спричинив LCP. Коли ви знаєте елемент, оптимізуйте його.

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

Попереднє завантаження критичних ресурсів

Попереднє завантаження (preload) наказує браузеру почати завантаження ресурсу заздалегідь, до того як він знадобиться для відображення. Попередньо завантажуйте зображення LCP або інші критичні ресурси за допомогою тегів `` у head HTML. Це наказує браузеру «почати завантаження цього ресурсу негайно».

Приклад: `` наказує браузеру негайно почати завантаження головного зображення, не чекаючи розбору CSS. Це може скоротити LCP на 100-500 мс залежно від розміру ресурсу.

Будьте обережні з попереднім завантаженням. Попереднє завантаження надто багатьох ресурсів марнує пропускну здатність. Попередньо завантажуйте лише найкритичніші ресурси (головне зображення, критичні шрифти, необхідний CSS). Посібник Google з оптимізації Core Web Vitals пояснює найкращі практики попереднього завантаження.

Оптимізація зображень для LCP

Якщо вашим елементом LCP є зображення, оптимізуйте розмір файлу зображення та стратегію його завантаження. Три тактики:

Стискайте зображення. Використовуйте інструменти на кшталт TinyPNG, ImageOptim або Squoosh для стиснення без втрати якості. Стиснення JPEG може зменшити розмір файлу у 10-40 разів. Кожні 100 КБ розміру зображення додають 100-200 мс до LCP у мережах 4G. Стиснення дає високий ROI.

Використовуйте сучасні формати. WebP на 25-35% менший за JPEG. AVIF ще менший. Використовуйте HTML-елемент ``, щоб віддавати WebP сучасним браузерам і JPEG старішим для зворотної сумісності. Лише вибір формату може покращити LCP на 200-400 мс.

Вказуйте розміри зображень. Атрибути ширини й висоти запобігають зсуву макета й дають браузеру змогу зарезервувати місце до завантаження зображення. Це безпосередньо не покращує LCP, але покращує Cumulative Layout Shift (CLS), іншу метрику Core Web Vitals.

CSS і JavaScript, що блокують відображення

CSS, що блокує відображення, не дає браузеру відобразити сторінку, доки CSS не завантажено й не розібрано. Великі файли CSS затримують відображення. Мінімізуйте CSS, що блокує відображення, вбудовуючи критичний CSS і відкладаючи решту.

Критичний CSS є CSS, потрібним для контенту на першому екрані. Вбудуйте цей CSS у `