INP: Noua metrică critică care înlocuiește FID
Pe 12 martie 2024, Google a finalizat tranziția Core Web Vitals: FID (First Input Delay) și a ieșit, INP (Interacțiune cu Next Paint) și a intrat. O schimbare tăcută în panourile de Google Search Console, care are totuși un impact real asupra clasamentului SEO a milioane de site-uri. Potrivit i date din Raportul despre experiența utilizatorului Chrome (CrUX), the 43% dintre site-uri eșuează în continuare Pragul INP „Bun” (sub 200 ms), un număr semnificativ mai mare decât la cele 30% dintre site-urile care au eșuat FID.
FID a măsurat doar întârzierea până la prima introducere: cât timp a trecut de la utilizator a făcut clic pentru prima dată când browserul a început să proceseze acel eveniment. A fost o măsură ușor de depășit, deoarece măsura doar prima interacțiune și nu a rezistat cont de următoarea vopsea. INP este radical diferit: măsurați receptivitatea per total pe toată durata sesiunii, alegând ca punctaj final cea mai proasta percentilă de interacțiuni.
Ce vei învăța
- Cum diferă INP de FID și de ce măsoară capacitatea de răspuns reală
- INP Bun/Necesită îmbunătățire/Praguri slabe (200ms / 500ms)
- Cum să măsurați INP cu Chrome DevTools, web-vitals.js și PageSpeed Insights
- Cele mai comune cinci modele JavaScript care explodează INP
- Cum se interpretează datele de câmp CrUX vs datele sintetice Lighthouse
- Fluxul de lucru de depanare pentru a găsi și remedia interacțiuni lente
Ce măsoară INP: Definiția tehnică
INP observă toate interacțiunile utilizatorului cu pagina în timpul vizitei: clicuri, atingeri și apăsări de taste. Pentru fiecare interacțiune, măsurați timpul de la intrare al utilizatorului la momentul browserului pictează următorul cadru care reflectă răspunsul vizual la acea intrare. Acest interval se numește latența interacțiunii și este alcătuit din trei părți:
- Întârziere de intrare: timpul care trece înainte ca browserul să înceapă procesarea evenimentului (firul principal era ocupat)
- Timp de procesare: timpul de execuție a handlerelor de evenimente JavaScript
- Întârziere de prezentare: timpul necesar pentru ca browserul să dispună, să picteze și să compună noul cadru
INP ia percentila 98 dintre toate interacțiunile din sesiune (sau cel mai rău valoare dacă există mai puțin de 50 de interacțiuni). Nu media, nu valoarea tipică: aproape cea mai proastă. Acest lucru face INP mult mai sensibil la vârfurile de latență decât FID.
Pragurile INP
| Evaluare | Valoarea INP | Impact SEO |
|---|---|---|
| Bun | < 200 ms | Contribuie pozitiv la clasare |
| Necesită îmbunătățire | 200ms - 500ms | Neutru, zonă de îmbunătățire |
| Sărac | > 500 ms | Penalizare pentru clasarea Google |
FID vs INP: diferența substanțială
Pentru a înțelege de ce tranziția de la FID la INP este o schimbare importantă, luați în considerare acest scenariu: aveți o pagină de comerț electronic. La prima încărcare, utilizatorul face clic pe „Adaugă în coș” și evenimentul este procesat în 50 ms (FID excelent). Apoi navigați pe pagină, filtrați produsele, deschide un meniu derulant pentru categorii. Această a doua interacțiune durează 800 ms, deoarece este un calcul greu rulează pe firul principal.
Cu FID: scorul a fost de 50 ms - Bun.
Cu INP: scorul este de 800 ms - Sărac.
INP reflectă experiența reală a utilizatorului pe parcursul sesiunii, nu doar primul clic. Acesta este motivul pentru care multe site-uri care au avut un FID excelent acum au INP problematic.
Cum se măsoară INP
1. Chrome DevTools - Panoul de performanță
Cea mai precisă modalitate de a diagnostica INP este panoul de performanță al Chrome DevTools. Procedați astfel:
- Deschideți DevTools (F12) și accesați fila Performanţă
- Faceți clic pe cercul roșu pentru a începe înregistrarea
- Rulați interacțiunile pe care doriți să le măsurați (clicuri, tastare etc.)
- Opriți înregistrarea
- În panoul rezultat, căutați barele roșii din secțiune Interacțiuni
- Faceți clic pe o interacțiune pentru a vedea defalcarea: întârziere de intrare, timp de procesare, întârziere de prezentare
2. Biblioteca Web Vitals JS (date de câmp)
Biblioteca web-vitals de Google vă permite să măsurați INP real al utilizatorilor în producție.
Adăugați-l la proiectul dvs. și trimiteți datele la un punct final de analiză:
import { onINP } from 'web-vitals';
onINP((metric) => {
// metric.value: il valore INP in millisecondi
// metric.rating: 'good' | 'needs-improvement' | 'poor'
// metric.entries: le PerformanceEventTiming entries
console.log('INP:', metric.value, metric.rating);
// Invia a analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'INP',
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
});3. PageSpeed Insights și CrUX
PageSpeed Insights arată date reale CrUX pentru domeniul dvs. în secțiunea „Field Data”. Rețineți că datele CrUX se bazează pe utilizatorii Chrome care au sincronizarea activată, prin urmare, reflectă experiența reală pe dispozitive reale, nu rezultate sintetice Lighthouse care rulează pe hardware controlat.
Date de laborator vs date de câmp
Lighthouse și PageSpeed Insights în modul „Lab” simulează un dispozitiv mobil de gamă medie pe o conexiune 4G lentă. Datele CrUX (Field Data) reflectă utilizatori reali ai site-ului dvs. Este normal să existe discrepanțe de 30-50% între cele două măsurători. Utilizați datele de câmp ca indicator primar pentru deciziile SEO și datele de laborator pentru depanarea tehnică.
Cele mai comune modele care provoacă un INP ridicat
1. Sarcini lungi pe firul principal
Principalul vinovat al INP ridicat este prezența Sarcini lungi: sarcini JavaScript
care durează mai mult de 50 ms. Fiecare sarcină lungă blochează firul principal al browserului, împiedicându-l să răspundă
la intrarea utilizatorului. Cel mai simplu mod de a le identifica este panoul DevTools Performance
sau API-ul PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.warn('Long Task rilevato:', {
duration: entry.duration,
startTime: entry.startTime,
});
}
}
});
observer.observe({ type: 'longtask', buffered: true });2. Handlers de evenimente grele
Managerii de clic care efectuează calcule grele în mod sincron sunt o cauză frecventă a INP ridicat. Modelul tipic este un handler care:
- Filtrați sau transformați matrice mari în memorie
- Redați masiv DOM (adăugați sute de elemente)
- Calculați machete complexe sau forțați redistribuirea browserului
- Analizează JSON mare
3. Detectarea reacției/schimbărilor unghiulare nu este optimizată
În cadre precum React sau Angular, un singur eveniment poate declanșa un ciclu de detectare a schimbării care recalculează întreg arborele componente. În componente complexe sau în absența memorizării adecvat, acest lucru poate dura 100-400 ms.
În Angular, soluția este ChangeDetectionStrategy.OnPush şi utilizarea semnalelor pentru
reactivitate granulară. În React, React.memo, useMemo e useCallback
sunt instrumentele cheie.
4. Scripturi de la terți
Analitice, widget-uri de chat, scripturi publicitare și alte scripturi terță parte rulează adesea pe firul principal și poate bloca răspunsul la intrări. Pentru a le identifica, în panoul DevTools Performance căutați sarcini lungi care provin din domenii terțe.
5. Hidratarea în Cadrele SSR
În aplicațiile cu SSR (Next.js, Angular Universal, Nuxt), faza de hidratare poate fi scump. În timpul hidratării, cadrul reatașează manevrele de evenimente la DOM-ul redat partea serverului. Dacă această fază se suprapune cu o interacțiune cu utilizatorul, INP are de suferit.
Fluxul de lucru de depanare INP
Iată fluxul de lucru recomandat pentru diagnosticarea și corectarea NPI ridicat:
- Identificați interacțiunile problematice folosind panoul Performanță de DevTools. Căutați interacțiuni cu latență > 200 ms în secțiunea Interacțiuni.
- Analizați defalcarea: care dintre cele trei componente (întârziere de intrare, procesare, prezentare) este cea mai mare?
- Dacă este întârzierea de intrare: Altceva rula pe firul principal în acel moment a clicului. Căutați sarcini lungi care preced interacțiunea în cronologia.
-
Dacă și timpul de procesare: gestionatorii dvs. de evenimente sunt prea lenți.
STATELE UNITE ALE AMERICII
scheduler.yield()pentru a le sparge (vezi articolul următor). - Dacă și întârzierea prezentării: Redarea cadrului este lentă. Căutați machete thrashing, animații CSS scumpe sau straturi de compunere excesive.
INP și SEO: impactul real
Google a confirmat că Core Web Vitals, inclusiv INP, sunt factori de clasare. Greutatea Exact nu este public, dar dovezile empirice arată că trecerea de la „Slab” la „Bine” pe INP poate aduce îmbunătățiri de clasare cu 2-5% pentru paginile competitive. Pentru site-uri cu trafic organic semnificativ, aceasta se traduce printr-o creștere măsurabilă a traficului.
Prioritatea principală trebuie să fie aducerea tuturor paginilor principale (pagina de pornire, pagini de categorii, paginile produsului) la evaluarea „Bine” (< 200 ms). Paginile de conținut static au rareori probleme INP; problemele se concentrează pe pagini cu interfețe interactive complexe.
Următorii pași
Acum că știi cum să măsori și să identifici problemele INP, următorul pas este să înveți cum să faci
remediați-le: următorul articol din această serie explică modul de utilizare scheduler.yield()
pentru a despărți sarcini lungi și a elibera firul principal dintre o interacțiune și alta.
Pentru partea de randare, articolul LCP Optimization acoperă tehnici de reducere a întârzierea prezentării și accelerarea vopselei primului cadru semnificativ.
Concluzii
INP reprezintă o schimbare de paradigmă în măsurarea performanței web: nu este suficient că pagina se încarcă rapid, trebuie de asemenea răspuns rapid pe tot parcursul durata sesiunii. 43% dintre site-urile care eșuează pragul bun al INP au o oportunitate modalitate concretă de a îmbunătăți atât experiența utilizatorului, cât și clasarea SEO.
Punctul de plecare este întotdeauna măsurarea: instalați web-vitals.js în a ta
site-ul, colectează date reale despre utilizatori și folosește Chrome DevTools pentru a diagnostica interacțiunile
probleme. Doar cu date concrete vei putea lua decizii informate de optimizare.