Core Web Vitals за PHP сайтове: как да коригираме LCP, INP и CLS

Core Web Vitals за PHP сайтове не са тема само за предния край. Една бавна PHP страница може да прекара секунда само в създаване на HTML и никаква оптимизация на изображения не може да възстанови това. В същото време много бързият сървър не помага, ако изображение на герой от 1,5 MB блокира най-голямата боя. Ето как подхождаме и към двете страни на нашите собствени PHP сайтове (integrono.com изпълнява PHP-FPM зад nginx и Cloudflare) и на клиентски проекти.

Какво измерва Core Web Vitals

• LCP ( Largest Contentful Paint): когато се изобразява най-големият видим елемент (обикновено изображение на герой или блок със заглавие). Добър е 2,5 секунди или по-малко.
• INP ( Interaction to Next Paint): колко бързо страницата реагира визуално след щраквания, докосвания и натискания на клавиши през цялото посещение. Добър е 200 ms или по-малко.
• CLS ( Cumulative Layout Shift): колко съдържание прескача по време на зареждане. Добро е 0,1 или по-малко.

Google ги оценява на полеви данни от реални потребители на Chrome, на 75-ия процентил, отделно за мобилни устройства и настолни компютри. Това означава, че един бавен шаблон или една бавна държава може да провали цялата група. Лабораторните инструменти като Lighthouse са за отстраняване на грешки, а не за крайния резултат.

Стъпка 1. Измерете правилния начин

1. Отворете отчета Core Web Vitals в Google Search Console, за да видите кои URL групи са неуспешни и по кой показател.
2. Проверете PageSpeed Insights за един URL адрес от всяка неуспешна група. Най-горният блок "полеви данни" е това, което се брои; блокът Lighthouse по-долу е лабораторен тест, който обяснява защо.
3. Използвайте панела за производителност в Chrome DevTools с CPU 4x забавяне и „Slow 4G“, за да възпроизведете типично мобилно изживяване.
4. За текущо наблюдение събирайте данни за реални потребители с библиотеката на JavaScript web-vitals и ги изпращайте до вашите анализи.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Стъпка 2. Първо коригирайте времето за реакция на сървъра ( TTFB).

LCP включва времето преди пристигането на първия байт. Ако генерирането на вашия HTML отнема 800 ms, вие вече сте похарчили една трета от бюджета. На PHP сайтовете обичайните лостове са:

• Активирайте OPcache и се уверете, че е достатъчно голям, за да побере всички скриптове. Без него PHP прекомпилира файлове при всяка заявка.
• Настройте PHP-FPM. Твърде малко заявки за работни опашки, твърде много изтощаваща памет. Гледайте страницата за състояние PHP-FPM за „опашка за слушане“ и „достигнати максимални деца“.
• Кеширайте цели страници за анонимни посетители (nginx fastcgi_cache, кеш на отговорите Laravel или правила за кеширане Cloudflare) и кеширайте фрагменти или резултати от заявки с Redis.
• Коригирайте бавни заявки. Включете дневника на бавните заявки, потърсете N+1 модели и добавете индекси. Страница, която изпълнява 120 заявки, е бавна, независимо от PHP версията.
• Поддържайте PHP актуален. По-новите версии на PHP са по-бързи и използват по-малко памет.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Задайте pm.max_children от реална памет: разделете паметта, която можете да дадете на PHP, на средния размер на работен процес (проверете с ps). С validate_timestamps=0 не забравяйте да презареждате PHP-FPM след всяко внедряване, в противен случай старият код остава в паметта.

На ниво уеб сървър активирайте HTTP/2 или HTTP/3, Brotli или gzip и дълготрайни кеширащи заглавки за статични файлове:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Използвайте имена на файлове с версии или ?v= заявка въз основа на времето за модификация на файла, така че „immutable“ никога да не обслужва остарели активи.

Стъпка 3. Фиксирайте LCP елемента

Намерете елемента LCP в PageSpeed Insights или панела DevTools Performance. На повечето страници със съдържание това е изображение на герой. След това:

• Не го мързеливо зареждайте. loading="lazy" на LCP изображението го забавя. Вместо това използвайте fetchpriority="high".
• Сервирайте правилния размер. Изображение от 2400 px за слот от 900 px губи байтове. Използвайте srcset и sizes.
• Използвайте WebP или AVIF. Типичните спестявания са 30 до 60 процента спрямо JPEG при подобно качество.
• Избягвайте веригите. Изображение, зададено чрез CSS фон или инжектирано от JavaScript, се открива късно. Поставете го в HTML като <img>.
• Предварително свързване или самостоятелно хостване на източници на трети страни, от които зависи LCP (шрифтове, изображение CDN).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

Това е моделът, който използва статията в този блог: два размера WebP, изрични размери и висок приоритет на извличане за героя.

Стъпка 4. Премахнете промените в оформлението ( CLS)

• Винаги задавайте width и height (или aspect-ratio в CSS) на изображения, видеоклипове и вградени рамки, така че браузърът да запази пространството.
• Запазете място за банери, известия за бисквитки и реклами. Поставете ги в контейнер с фиксирана минимална височина, вместо да натискате съдържанието надолу след натоварване.
• Шрифтове: използвайте font-display: swap или optional, заредете предварително основния файл с шрифтове и го подмножете. Изберете резервен шрифт с подобни показатели.
• Не инжектирайте съдържание над съществуващо съдържание, освен ако потребителят не го е задействал.
• Анимирайте с transform и opacity, а не със свойства, които променят оформлението (top, height).

Стъпка 5. Подобрете INP: по-малко JavaScript в основната нишка

INP е най-новият показател и този, който PHP разработчиците пренебрегват, тъй като сървърът не му влияе пряко. Причините са в браузъра: дълги задачи от големи пакети, тежки скриптове на трети страни (аналитика, джаджи за чат, мениджъри на тагове) и манипулатори, които вършат твърде много работа синхронно.

• Одит на скриптове на трети страни. Премахнете това, което никой не използва, заредете останалите с defer или след първото взаимодействие.
• Разделете дълги задачи. Разделете работата на части с requestIdleCallback, setTimeout или Scheduler API; преместете тежки изчисления към Web Worker.
• Дръжте DOM малък. Хиляди възли правят всяка актуализация бавна.
• Избягвайте принудителни синхронни оформления в цикли (последователно четене и запис на свойства на оформлението).
• Показвайте незабавна обратна връзка (натиснато състояние или въртяща се въртяща се част), преди да започнете бавна работа.

Стъпка 6. Пазете го в процеса на внедряване

Производителността намалява тихо: нов етикет, по-тежък герой, допълнителна заявка на началната страница. Добавете Lighthouse CI или планирана проверка на PageSpeed API за вашите пет най-важни шаблона, задайте бюджети ( LCP, общ размер на JS, тегло на изображението) и предупреждавайте, когато те бъдат надвишени. Сравнете TTFB преди и след всяко издание; ако скача, причината почти винаги е заявка или кеш, който вече не удря.

Реалистичен ред на работа

1. Измерете полеви данни и идентифицирайте неуспешни URL групи.
2. Активирайте OPcache, прегледайте настройките PHP-FPM, добавете кеширане на цяла страница за анонимен трафик.
3. Коригирайте изображения на герои: формат, размер, приоритет, размери.
4. Запазете място за всичко, което се зарежда късно.
5. Намаляване и отлагане на JavaScript; премахване на неизползвани трети страни.
6. Измерете отново след 28 дни, тъй като данните от полето са подвижен прозорец.

Очаквайте подобренията да се появят в Search Console постепенно: отчетът използва данни от приблизително последните 28 дни, така че корекцията, изпратена днес, е напълно видима само след около месец.

Как можем да помогнем

Ние извършваме работа по изпълнението на PHP и Laravel проекти като част от технически ангажимент за SEO и като еднократна настройка: кеширане, заявки, изображения и корекции на предния край, изпратени в код. Ако искате да знаете кои от промените по-горе биха се отплатили на вашия сайт, резервирайте консултация или анализ на сървъра. За по-широкия контролен списък относно обхождането и индексирането прочетете нашия технически контролен списък за SEO одит.