INP: de nieuwe kritische maatstaf die FID vervangt
Op 12 maart 2024 voltooide Google de transitie van Core Web Vitals: FID (First Input Delay) en verliet, INP (Interaction to Next Paint) en ging naar binnen. Een stille verandering in de panelen van Google Search Console, wat echter reële gevolgen heeft voor de SEO-ranglijst van miljoenen sites. Volgens ik gegevens uit het Chrome User Experience Report (CrUX), de Nog steeds faalt 43% van de websites INP "Goed"-drempel (minder dan 200 ms), een aanzienlijk hoger aantal dan aan de 30% van de sites die FID faalden.
FID heeft alleen de vertraging tot de eerste invoer gemeten: hoeveel tijd er was verstreken sinds de gebruiker voor de eerste keer werd geklikt toen de browser die gebeurtenis begon te verwerken. Het was een gemakkelijk te verslaan statistiek omdat het alleen de eerste interactie meet en geen stand houdt rekening met de volgende verf. INP is radicaal anders: meet de reactievermogen in het algemeen voor de gehele duur van de sessie, met keuze als eindscore het slechtste percentiel van interacties.
Wat je gaat leren
- Hoe INP verschilt van FID en waarom het de werkelijke responsiviteit meet
- INP Goed/Verbetering nodig/Slechte drempels (200 ms / 500 ms)
- Hoe INP te meten met Chrome DevTools, web-vitals.js en PageSpeed Insights
- De vijf meest voorkomende JavaScript-patronen die INP exploderen
- Hoe CrUX-veldgegevens versus synthetische Lighthouse-gegevens te interpreteren
- De foutopsporingsworkflow om langzame interacties te vinden en op te lossen
Wat INP meet: de technische definitie
INP observeert alle gebruikersinteracties met de pagina tijdens het bezoek: klikken, tikken en toetsaanslagen. Meet voor elke interactie de tijd sinds de invoer van de gebruiker op het moment dat de browser werd gebruikt schildert het volgende frame dat weerspiegelt de visuele reactie op die input. Dit interval wordt genoemd latentie van interactie en bestaat uit drie delen:
- Ingangsvertraging: de tijd die verstrijkt voordat de browser de gebeurtenis begint te verwerken (de hoofdthread was bezet)
- Verwerkingstijd: de uitvoeringstijd van JavaScript-gebeurtenishandlers
- Presentatie vertraging: de tijd die de browser nodig heeft om het nieuwe frame op te maken, te schilderen en samen te stellen
INP neemt de 98e percentiel van alle interacties in de sessie (of de ergste waarde als er minder dan 50 interacties zijn). Niet het gemiddelde, niet de typische waarde: bijna de slechtste. Dit maakt INP veel gevoeliger voor latentiepieken dan FID.
De INP-drempels
| Beoordeling | INP-waarde | SEO-impact |
|---|---|---|
| Goed | < 200 ms | Draagt positief bij aan de ranking |
| Verbetering nodig | 200 ms - 500 ms | Neutraal, verbeterpunt |
| Arm | > 500 ms | Google-rankingstraf |
FID versus INP: het substantiële verschil
Om te begrijpen waarom de overgang van FID naar INP een belangrijke verandering is, kunt u het volgende scenario overwegen: u heeft een e-commercepagina. Bij de eerste keer laden klikt de gebruiker op "Toevoegen aan winkelwagen". de gebeurtenis wordt verwerkt in 50 ms (uitstekende FID). Navigeer vervolgens door de pagina, filter producten, opent een vervolgkeuzelijst met categorieën. Deze tweede interactie duurt 800 ms omdat het een zware berekening is het draait op de hoofdthread.
Met FID: de score bedroeg 50 ms - Goed.
Met INP: de score bedraagt 800 ms - Arm.
INP weerspiegelt de daadwerkelijke gebruikerservaring gedurende de sessie, niet alleen de eerste klik. Dit is de reden waarom veel sites met een uitstekende FID nu een problematische INP hebben.
Hoe INP te meten
1. Chrome DevTools - Prestatiepaneel
De meest nauwkeurige manier om INP te diagnosticeren is het prestatiepaneel van Chrome DevTools. Ga als volgt te werk:
- Open DevTools (F12) en ga naar het tabblad Prestatie
- Klik op de rode cirkel om de opname te starten
- Voer de interacties uit die u wilt meten (klikken, typen, enz.)
- Stop met opnemen
- Zoek in het resulterende paneel naar de rode balken in de sectie Interacties
- Klik op een interactie om de uitsplitsing te zien: invoervertraging, verwerkingstijd, presentatievertraging
2. Web Vitals JS-bibliotheek (veldgegevens)
De bibliotheek web-vitals van Google kunt u de echte INP van gebruikers in productie meten.
Voeg het toe aan uw project en stuur de gegevens naar een analyse-eindpunt:
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 en Crux
PageSpeed Insights toont echte Crux-gegevens voor uw domein in het gedeelte 'Veldgegevens'. Houd er rekening mee dat de Crux-gegevens gebaseerd zijn op Chrome-gebruikers die synchronisatie hebben ingeschakeld. daarom weerspiegelen ze echte ervaringen op echte apparaten, en geen synthetische Lighthouse-resultaten die op hardware gecontroleerd draaien.
Labgegevens versus veldgegevens
Lighthouse en PageSpeed Insights in "Lab"-modus simuleren een mobiel apparaat uit het middensegment op een trage 4G-verbinding. CrUX-gegevens (veldgegevens) weerspiegelen echte gebruikers van uw site. Het is normaal dat er tussen de twee metingen verschillen van 30-50% bestaan. Gebruik veldgegevens als indicator primair voor SEO-beslissingen en laboratoriumgegevens voor technische foutopsporing.
De meest voorkomende patronen die een hoge INP veroorzaken
1. Lange taken op de hoofdthread
De belangrijkste boosdoener van hoge INP is de aanwezigheid van Lange taken: JavaScript-taken
die langer dan 50 ms duren. Elke lange taak blokkeert de hoofdthread van de browser, waardoor deze niet kan reageren
aan gebruikersinvoer. De eenvoudigste manier om ze te identificeren is het DevTools Performance-paneel
of de API 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. Afhandelaars van zware evenementen
Klikhandlers die synchroon zware berekeningen uitvoeren, zijn een veelvoorkomende oorzaak van hoge INP. Het typische patroon is een handler die:
- Filter of transformeer grote arrays in het geheugen
- Geef de DOM massaal weer (voeg honderden elementen toe)
- Bereken complexe lay-outs of forceer browser-reflow
- Parseert grote JSON
3. Detectie van reactie-/hoekverandering niet geoptimaliseerd
In raamwerken zoals React of Angular kan een enkele gebeurtenis een veranderingsdetectiecyclus activeren waarmee de gehele componentenboom opnieuw wordt berekend. In complexe componenten of bij gebrek aan memoisatie Dit kan 100-400 ms duren.
In Angular is de oplossing: ChangeDetectionStrategy.OnPush en het gebruik van signalen voor
granulaire reactiviteit. In reactie, React.memo, useMemo e useCallback
zij zijn de belangrijkste hulpmiddelen.
4. Scripts van derden
Analytics, chatwidgets, advertentiescripts en andere scripts van derden draaien vaak op de hoofdthread en kan de reactie op invoer blokkeren. Om ze te identificeren, in het DevTools Performance-paneel zoek naar lange taken afkomstig van domeinen van derden.
5. Hydratatie in SSR-frameworks
In toepassingen met SSR (Next.js, Angular Universal, Nuxt) kan de hydratatiefase zijn duur. Tijdens hydratatie koppelt het raamwerk gebeurtenishandlers opnieuw aan de weergegeven DOM serverzijde. Als deze fase overlapt met een gebruikersinteractie, lijdt de INP.
De INP-foutopsporingsworkflow
Hier is de aanbevolen workflow voor het diagnosticeren en corrigeren van hoge NPI:
- Identificeer problematische interacties via het Prestatiepaneel door DevTools. Zoek naar interacties met latentie > 200 ms in het gedeelte Interacties.
- Analyseer de storing: welke van de drie componenten (invoervertraging, verwerking, presentatie) is het grootst?
- Als en de ingangsvertraging: Er draaide op dat moment iets anders op de hoofdthread van de klik. Zoek naar lange taken die voorafgaan aan de interactie in de tijdlijn.
-
Als en de verwerkingstijd: Uw gebeurtenishandlers zijn te traag.
VS
scheduler.yield()om ze te breken (zie volgend artikel). - Als en de presentatievertraging: Frameweergave is traag. Zoek naar rommelige lay-outs, dure CSS-animaties of overmatige compositielagen.
INP en SEO: de echte impact
Google heeft bevestigd dat Core Web Vitals, inclusief INP, rankingfactoren zijn. Het gewicht Het is precies niet openbaar, maar empirisch bewijs toont aan dat de overgang van ‘slecht’ naar ‘goed’ op INP kan 2-5% rankingverbeteringen opleveren voor concurrerende pagina’s. Voor sites met verkeer aanzienlijk organisch, dit vertaalt zich in een meetbare toename van het verkeer.
De hoogste prioriteit moet zijn om alle hoofdpagina’s (homepage, categoriepagina’s, productpagina's) naar de beoordeling 'Goed' (< 200 ms). Pagina's met statische inhoud hebben dit zelden INP-problemen; de problemen concentreren zich op pagina's met complexe interactieve interfaces.
Volgende stappen
Nu u weet hoe u INP-problemen kunt meten en identificeren, is de volgende stap het leren hoe u dit kunt doen
repareer ze: in het volgende artikel in deze serie wordt uitgelegd hoe u ze kunt gebruiken scheduler.yield()
om lange taken op te splitsen en de rode draad tussen de ene interactie en de andere vrij te maken.
Wat de weergavekant betreft, behandelt het artikel LCP-optimalisatie technieken om de presentatie vertragen en versnellen de verf van het eerste belangrijke frame.
Conclusies
INP vertegenwoordigt een paradigmaverschuiving in het meten van webprestaties: het is niet genoeg dat de pagina snel laadt, moet ook antwoord snel overal de duur van de sessie. 43% van de sites die niet voldoen aan de Goed-drempel van INP, hebben een kans concrete manier om zowel de gebruikerservaring als de SEO-ranking te verbeteren.
Het uitgangspunt is altijd meten: installeren web-vitals.js in de jouwe
site, verzamel echte gebruikersgegevens en gebruik Chrome DevTools om interacties te diagnosticeren
problemen. Alleen met concrete gegevens kunt u weloverwogen optimalisatiebeslissingen nemen.