Core Web Vitals для PHP-сайтаў: як выправіць LCP, INP і CLS

Core Web Vitals для PHP-сайтаў - гэта не толькі тэма франтэнда. Павольная PHP-старонка можа марнаваць секунду проста на генерацыю HTML, і ніякая аптымізацыя карцінак гэтага не верне. І наадварот: хуткі сервер не дапаможа, калі найбуйную адмалёўку блакуе hero-карцінка на 1,5 МБ. Так мы падыходзім да абодвум бакам на сваіх PHP-сайтах (integrono.com працуе на PHP-FPM за nginx і Cloudflare) і ў праектах кліентаў.

Што вымяраюць Core Web Vitals

• LCP ( Largest Contentful Paint): калі адмаляваны самы вялікі бачны элемент (звычайна hero-карцінка або блок загалоўка). Добра - 2,5 секунды і менш.
• INP ( Interaction to Next Paint): як хутка старонка візуальна рэагуе на клікі, дотыку і націску клавіш за ўсё наведванне. Добра - 200 мс і менш.
• 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. Выкарыстоўвайце панэль Performance у Chrome DevTools з запаволеннем CPU у 4 разы і сеткай "Slow 4G", каб прайграць тыповы мабільны вопыт.
4. Для сталага маніторынгу зьбірайце дадзеныя рэальных карыстальнікаў бібліятэкай 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 мс, траціна бюджэту ўжо выдаткавана. На PHP-сайтах асноўныя рычагі такія:

• Уключыце OPcache і пераканайцеся, што яго памеру хапае для ўсіх скрыптоў. Без яго PHP кампілюе файлы зноўку пры кожным запыце.
• Наладзьце PHP-FPM. Занадта мала воркераў ставіць запыты ў чаргу, зашмат вычэрпвае памяць. Сачыце на старонцы статусу PHP-FPM за "listen queue" і "max children reached".
• Кэшуйце старонкі цалкам для ананімных наведвальнікаў (nginx fastcgi_cache, кэш адказаў у Laravel ці правілы кэшавання Cloudflare), а фрагменты і вынікі запытаў - у Redis.
• Выпраўце павольныя запыты. Уключыце slow query log, знайдзіце патэрны N+1 і дадайце азначнікі. Старонка са 120 запытамі павольная пры любой версіі 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 або панэлі Performance у DevTools. На большасці кантэнтных старонак гэта hero-карцінка. Далей:

• Не выкарыстоўвайце для яе лянівую загрузку. loading="lazy" на LCP-малюначку затрымлівае яе. Замест гэтага пастаўце fetchpriority="high".
• Аддавайце патрэбны памер. Малюнак 2400 px для слота 900 px – лішнія байты. Выкарыстоўвайце srcset і sizes.
• Выкарыстоўвайце WebP або AVIF. Звычайная эканомія - ад 30 да 60 адсоткаў у параўнанні з JPEG пры падобнай якасці.
• Пазбягайце ланцужкоў. Малюнак, зададзеная фонам у CSS ці ўстаўленая JavaScript, выяўляецца позна. Пакладзіце яе ў HTML як <img>.
• Выкарыстоўвайце preconnect або свой хостынг для іншых крыніц, ад якіх залежыць 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, відавочныя памеры і высокі прыярытэт загрузкі для hero.

Крок 4. Прыбярыце зрухі макета ( CLS)

• Заўсёды задавайце width і height (або aspect-ratio у CSS) для малюнкаў, відэа і iframe, каб браўзэр рэзерваваў месца.
• Рэзервуйце месца пад банеры, апавяшчэнні аб cookie і рэкламу. Устаўляйце іх у кантэйнер з фіксаванай мінімальнай вышынёй, а не ссоўвайце кантэнт пасля загрузкі.
• Шрыфты: выкарыстайце font-display: swap ці optional, перадзагружайце асноўны файл шрыфта і рабіце subset. Падбярыце запасны шрыфт з падобнымі метрыкамі.
• Не ўстаўляйце кантэнт над ужо паказаным, калі гэта не вынік дзеяння карыстальніка.
• Анімуюць праз 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. Выпраўце hero-карцінкі: фармат, памер, прыярытэт, памеры.
4. Зарэзервуйце месца для ўсяго, што загружаецца позна.
5. Скароціце і адкладзяце JavaScript, прыбярыце непатрэбныя іншыя скрыпты.
6. Вымерайце паўторна праз 28 дзён: палявыя дадзеныя - слізгальнае акно.

Паляпшэнні будуць з'яўляцца ў Search Console паступова: справаздача выкарыстоўвае прыкладна апошнія 28 дзён, таму выпраўленне, выпампаванае сёння, цалкам выявіцца прыкладна праз месяц.

Чым мы можам дапамагчы

Мы займаемся прадукцыйнасцю PHP і Laravel праектаў у рамках тэхнічнага SEO і асобнымі працамі: кэш, запыты, выявы і праўкі фронтэнда прама ў кодзе. Калі жадаеце зразумець, якія з змен вышэй акупяцца менавіта на вашым сайце, запішыцеся на кансультацыю або аналіз сервера. Больш за шырокі чэк-ліст па сканаванні і індэксацыі - у артыкуле тэхнічны SEO-аўдыт.