Навчання
Оптимізація LCP: як покращити Largest Contentful Paint і швидкість сторінки
Глибокий гайд про Largest Contentful Paint: чотири фази, з яких він складається, як визначити свій LCP-елемент і які виправлення справді його рухають.
Запусти свіжий аудит DomainLens і використовуй звіт як список пріоритетів.
Що вимірює LCP
Largest Contentful Paint (LCP) фіксує момент, коли завершує рендеритись найбільший елемент контенту у viewport — зазвичай hero-зображення, постер відео або великий блок тексту. Це метрика, що найкраще відповідає на питання «коли сторінка справді стала готовою на вигляд?», і саме тому вона так тісно повʼязана з відчуттям швидкості.
Хороший LCP — 2.5 секунди або менше на 75-му перцентилі реальних користувачів; понад 4 секунди — погано. Оскільки метрику міряють у полі на найповільнішій чверті візитів, сторінка, що здається миттєвою на офісному зʼєднанні, все одно може провалюватись.
Чотири фази LCP
Найкорисніше, що можна зробити, — перестати сприймати LCP як одне число й розкласти його на чотири підчастини. Майже кожне виправлення цілиться в одну з них, тож вимірювання розкладу показує, куди реально йде час:
- Time to First Byte (TTFB): скільки часу сервер віддає перший байт. Тут живуть повільний бекенд, відсутність кешу й далекий хостинг.
- Resource load delay: проміжок між першим байтом і початком завантаження LCP-зображення браузером — зазвичай через пізнє виявлення або низький пріоритет.
- Resource load time: скільки саме LCP-зображення завантажується. Тут завеликі, нестиснуті, у неправильному форматі зображення.
- Element render delay: час від завантаження зображення до його фактичного відмалювання — зазвичай блокується render-blocking CSS або JavaScript.
Як знайти свій LCP-елемент
Не можна виправити те, чого не визначив — а LCP-елемент відрізняється за шаблоном і viewport.
- У панелі Performance запиши завантаження й поглянь на маркер «LCP» у треку Timings; він називає точний елемент.
- Запусти PageSpeed Insights і прочитай діагностику «Largest Contentful Paint element», що показує вузол і розклад по фазах.
- Перевір і mobile, і desktop — LCP-елемент часто є різним зображенням на кожному.
- Звіряйся з field data, щоб оптимізувати той елемент, на який чекають реальні користувачі, а не той, що випадково обрав швидкий лабораторний тест.
Як прискорити появу LCP-елемента
- Зменш TTFB: кешуй HTML на edge/CDN, прогрівай повільні запити до бази й розміщуй хостинг ближче до аудиторії.
- Зроби LCP-зображення одразу помітним: додай його в початковий HTML із fetchpriority="high" і роби preload, якщо воно задається через CSS або вставляється JavaScript-ом.
- Ніколи не роби lazy-load для LCP-зображення — loading="lazy" на hero це одна з найчастіших самозаподіяних регресій.
- Зменш файл: віддавай коректно розмірене зображення в сучасному форматі (AVIF/WebP) з адаптивним srcset, щоб mobile не тягнув desktop-hero.
- Прибери render-blocking: інлайни критичний CSS, відкладай некритичні CSS і JavaScript і не вставляй hero клієнтським фреймворком після hydration.
Помилки, що роздувають LCP
- Оптимізувати лабораторний score Lighthouse, ігноруючи польовий TTFB, який лабораторія недооцінює.
- Робити preload усього, що забиває мережу й відкладає той єдиний ресурс, що має значення.
- Віддавати hero з повільного стороннього origin без preconnect.
- Рендерити основний контент лише після клієнтського запиту даних, тож LCP чекає на JavaScript і round-trip до API.
Як перевірити LCP
Перезапиши трасу в Performance й переконайся, що фаза, у яку ти цілився, справді зменшилась — нижчий TTFB, ранній запит зображення або прибраний render-blocking. Потім стеж, як польовий LCP у Search Console йде вниз наступні тижні, бо він агрегує 28 днів реальних візитів.
У DomainLens читай LCP разом із часом відповіді сервера й render-blocking ресурсами, які він показує: найшвидша перемога — зазвичай зробити так, щоб справжнє hero-зображення запитувалось раніше й вантажилось меншим, на тому мобільному зʼєднанні, яким користуються твої відвідувачі.