LCP под 2,5 секунди — как се постига
Largest Contentful Paint разложен на четири части — сървър, откриване, изтегляне и показване. Как да намерите LCP елемента и какво да оправите във всяка част.
LCP — Largest Contentful Paint — е моментът, в който се показва най-големият елемент в първия екран: главната снимка, банерът, видеото или голямото заглавие. За посетителя това е моментът, в който страницата „е заредила“. Целта е до 2,5 секунди за поне 75% от посещенията.
Първо: кой е LCP елементът?
PageSpeed Insights го посочва в диагностиката. Често не е този, който очаквате:
- на мобилно може да е заглавието, а на десктоп — снимката до него;
- може да е фонова снимка от CSS, която браузърът открива късно;
- може да е първият кадър на слайдер или видео.
Оптимизацията зависи изцяло от това кой е елементът. Затова започваме оттук.
Четирите части на LCP
Google разделя LCP на четири последователни части. Сборът им е вашият LCP.
| Част | Какво е | Типична причина за забавяне |
|---|---|---|
| 1. TTFB | Сървърът връща HTML | Бавен хостинг, липсващ кеш, тежки плъгини |
| 2. Забавяне при откриване | Браузърът открива, че трябва да изтегли ресурса | Снимка в CSS или JavaScript, lazy loading, нисък приоритет |
| 3. Изтегляне | Ресурсът се изтегля | Твърде голяма снимка, стар формат |
| 4. Показване | Браузърът го показва на екрана | Блокиращ CSS и JS, шрифтове, скриптове, които скриват съдържанието |
Добре оптимизирана страница прекарва по-голямата част от времето в TTFB и изтеглянето — а забавянето при откриване и показването са близки до нула.
1. TTFB — сървърът
Ако HTML-ът идва за 1,5 секунди, LCP няма как да е под 2,5. Страничен кеш, актуален PHP, сървър близо до посетителите. Подробно: Хостингът и скоростта.
2. Откриване — браузърът трябва да види снимката рано
- Главната снимка да е обикновен
<img>в HTML-а, а не фон от CSS или снимка, която JavaScript вмъква по-късно. - Без
loading="lazy"за нея. fetchpriority="high"— казва на браузъра да я изтегли преди другите ресурси. WordPress 6.3+ го прави автоматично за вероятния LCP елемент, ако темата не пречи.- Ако снимката все пак е във CSS —
<link rel="preload">в<head>.
3. Изтегляне — по-лека снимка
- WebP или AVIF вместо JPEG/PNG.
- Правилният размер за екрана чрез
srcset— мобилният посетител не трябва да тегли 2000 px снимка. - Разумно качество — за повечето снимки 75–85 е достатъчно.
Повече в статията за изображенията.
4. Показване — нищо да не пречи
Дори снимката да е изтеглена, браузърът няма да я покаже, докато:
- CSS файловете в
<head>не се изтеглят — решение: критичен CSS вграден, останалото асинхронно; - синхронният JavaScript не се изпълни — решение:
defer; - анимация скрива елемента и го показва след скрипт — решение: показване без JavaScript, анимацията да е само украса;
- слайдерът не се инициализира — решение: първият слайд като обикновена снимка.
Ако LCP елементът е текст — заглавието — гледайте шрифтовете: предварително зареждане на шрифта на заглавието и font-display: swap или optional.
Пример от нашата работа
На weberbg.com мобилният LCP беше 7,2 s. Основните причини: шрифтове от външен сървър, които блокираха показването на заглавието, анимация на заглавието, която го скриваше до изпълнението на JavaScript, и отделен CSS файл. След като хостнахме шрифтовете локално с предварително зареждане, вградихме CSS-а и направихме анимацията само с CSS, мобилният LCP падна до около 3 s, а резултатът в PageSpeed — от 62 на 84–86 (измерено на 5 октомври 2026 г.).
Проверете своя LCP
Пуснете теста на скоростта за мобилно — ще видите LCP и основните причини за забавянето. Ако искате да го оправим ние — заявката е от същото място.
Въпроси и отговори
Какъв LCP е добър?
До 2,5 секунди за поне 75% от посещенията. Над 4 секунди се счита за лош.
Защо LCP елементът е различен на мобилно и десктоп?
Защото подредбата е различна. На тесен екран заглавието може да е по-голямо от снимката и тогава то е LCP елементът.
Помага ли preload за LCP?
Да, когато LCP снимката се открива късно — например е фон от CSS. Ако снимката вече е в HTML-а, fetchpriority="high" обикновено е достатъчен.
