Wat is Interaction to Next Paint?
Interaction to Next Paint is een methode om een goede web performance door te meten, specificiek interacties op een webpagina. Het heeft te maken met frontend-development keuzes. Op dit moment is het een veelbesproken onderwerp, omdat het op 12 maart 2024 FID (First Input Delay) zal vervangen als één van Google's 3 Core Web Vitals. INP wordt gemeten door Chromium-browsers (Chrome, Edge, Opera) en houdt alle interacties bij, maar zal alleen de langzaamste interactie die een gebruiker binnen een pagina heeft rapporteren.(uitschieters uitgezonderd).
Simpel uitgelegd meet INP hoe lang de browser erover doet om de gewenste actie weer te geven. Je zou zelfs kunnen zeggen dat we het allemaal de call-to-action (CTA) metric* zouden moeten noemen! En mensen die moeten wachten en gefrustreerd worden als ze op een CTA drukken, is wel het laatste wat we willen, toch? Dus, bedankt Google, voor het visualiseren van het probleem!
*Iedere web-performance expert in de wereld - inclusief Erwin Hofman, die dit artikel samen met mij schrijft voor het technische gedeelte - kijkt me schuin aan omdat ik het zo beschrijf. Nuances in aantocht, mensen!
Wat betekent Interaction to Next Paint?
Het eerste deel van de naam spreekt voor zich: interactie. In de webperformance community wordt dit gedefinieerd als een gebruikersactie op een webpagina.
Voorbeelden van een gebruikersinteractie zijn:
- Klikken of (op touch screens) tikken, bijvoorbeeld om
- Een FAQ samen te vouwen
- Een navigatie uit te klappen
- Een product aan het winkelwagentje toe te voegen
- Gebruik van toetsenbord/toetsaanslagen
Voor de Interaction to Next Paint wordt het volgende niet gemeten:
- Scrollen
- Ergens met je muis overheen zweven
Belangrijk om in de gaten te houden: wat wordt gemeten in de Core Web Vitals kan soms veranderen, houd de lijst met veranderingen in de gaten: Chrome Speed - Interaction to Next Paint Changelog
Een interactie starten betekent dat de browser nu een actie moet uitvoeren, zoals iets nieuws weergeven dat je hebt aangevraagd en dat bij die interactie hoort. Dit is het "To Next Paint" gedeelte. Er is ook een midden moment in deze gebeurtenis, de verwerkingstijd.
Hieronder is een voorbeeld van een INP event in actie:
Wat definieert een slechte INP en waarom zou je je er druk om maken?
Google heeft een benchmark vastgesteld voor wat een gezonde INP is: deze moet minder dan 200 ms zijn. Meer dan 500 ms wordt als slecht beschouwd. Het meet de slechtste ervaring die een gebruiker heeft gehad met een gebeurtenis/interactie op je pagina. Er wordt rekening gehouden met uitschieters, zo wordt de slechtste 2% van ervaringen eruit gefilterd. Als je precies wilt weten hoe dat werkt, kun je terecht bij Google's eigen documentatie.
Als een INP slecht is, kan dat heel vervelend zijn voor je gebruikers. Je kunt er zelfs conversies door verliezen.
Voorbeelden van een slechte INP
Stel je voor dat je op een knop klikt, zoals "toevoegen aan winkelwagentje", en hij werkt niet!
- Je probeert het opnieuw en opeens werkt het wel. Maar met een merkbare vertraging. Dat is een slechte INP.
- Een ander voorbeeld: je probeert een formulier in te vullen, maar de letters verschijnen traag op het scherm. Ook een slechte INP.
- Je bent aan het navigeren in een webshopnavigatie, maar het voelt alsof een nieuwe subcategorie er te laat inschuift. Slechte INP
Waarom FID wordt vervangen door INP
De meeste tijd die een gebruiker op een pagina doorbrengt is nadat deze is geladen, namelijk 90%. In een artikel dat we samen met Google hebben geschreven, hebben we ontdekt dat de meeste vertragingen op mobiel optreden nadat de gebruiker al 10 seconden op de pagina heeft doorgebracht. Daarom is het belangrijk om na te denken over deze ervaringen en ervoor te zorgen dat ze de bezoeker niet frustreren. Je moet streven naar een website die snel reageert op de acties van gebruikers om zo bounce te voorkomen, de omzet te verhogen en ervoor te zorgen dat klanten terugkomen.
Hoewel First Input Delay (FID) de reactiesnelheid ook probeerde te meten, kon het alleen de eerste interactievertraging van de gebruiker duidelijk maken en schetste het dus een onvolledig beeld, omdat het de rest miste. Hierom slaagde bijna iedereen voor de FID. Dit is ook de reden dat het aantal sites dat slaagt voor de Core Web Vitals aanzienlijk zal dalen met ingang van de INP.
Dit is het aantal sites dat momenteel de FID passeert:
- Desktop: 99.9%
- Mobiel: 94,1%
Het is overigens niet zo dat Google je hiermee opzettelijk probeert te irriteren. De vertraging gebeurde ongeacht of Core Web Vitals INP meet of niet. Interaction to Next Paint is juist ontworpen om je te helpen met visualiseren waar het gebeurt en hoe slecht het is. Zodat jij de gebruikerservaring van jouw websitebezoekers weer kan verbeteren.
Wat meet een Interaction to Next Paint precies?
Om dit goed uit te leggen moeten we een beetje technisch worden en gaan we naar de basis van hoe een browser werkt.
- Een browser is altijd hard aan het werk om je de laatste versie te laten zien van het exacte punt van de webpagina waar je je bevindt.
- Hij probeert de pagina heel vaak te verversen, 60 keer per seconde om gebruikers de illusie te geven dat alles soepel verloopt. Sneller zou niet merkbaar zijn voor mensen.
Maar browsers kunnen om verschillende redenen verhinderd worden om die 60 frames per seconde te bereiken of daadwerkelijk te renderen.
Javascript en renderen
Javascript is de natuurlijke vijand van INP. Dat komt omdat een browser wacht tot de Javascript-bestanden zijn gecompileerd, geparsed en uitgevoerd voordat hij verder gaat met het renderen (painten) van de rest van de pagina. En het maakt niet uit of je meerdere code-gesplitste Javascript-bestanden hebt of één grote bundel, beide kunnen een vertraging veroorzaken. Of misschien zelfs meerdere binnen één paginabezoek. Dit is allemaal afhankelijk van de hoeveelheid werk die een taak teweegbrengt.
Het is misschien niet altijd een UX-risico, maar wel als zo'n taak plaatsvindt tijdens interactie, of als een lange taak wordt geactiveerd als gevolg van gebruikersinteractie. De uitdaging hier is dat browsers performant proberen te zijn door Javascript-taken samen te voegen in plaats van het scherm bij te werken bij elke afzonderlijke Javascript-taak.
Dat is een goede aanpak, maar omdat ‘paints’ worden uitgesteld totdat de gebundelde Javascript-taken klaar zijn, wordt het gemakkelijk te begrijpen hoe en waarom een nieuwe ‘paint’ - en in feite het meest opvallende en dus belangrijkste onderdeel voor je typische bezoeker - kan worden uitgesteld.
Kort samengevat: browsers zijn net mannen, ze kunnen niet multitasken. En dit is het basisprobleem in een INP.
De 3 fases van wat er gebeurt in een INP
Zoals je in de bovenstaande grafiek kunt zien, is Interaction to Next Paint niet slechts een moment in de tijd. Het meet eigenlijk alle gebeurtenissen die plaatsvinden om van de interactie tot de nieuwe "paint" te komen. De INP metric berekent dan de som van al deze gebeurtenissen. Vertragingen kunnen om verschillende redenen optreden, dus ik heb ook een paar voorbeelden toegevoegd.
1. Input delay
Input delay is de tijd die verstrijkt tussen het moment dat een gebruiker begint te interageren met een pagina en het moment dat de bijbehorende acties of event callbacks beginnen te lopen.
Voorbeeld: Je hebt op een hamburgermenu geklikt, maar precies tijdens de interactie was er nog een ander script aan het draaien. Dit kan Facebook zijn, een chatwidget of hydration van je SPA/ PWA. Daardoor kon de browser niet meteen bij het deel komen dat verantwoordelijk is voor het uitschuiven van het menu.
2. Verwerkingstijd
Wanneer het systeem de invoer van de gebruiker krijgt, moet het deze verwerken om erachter te komen wat het vervolgens moet doen. De verwerkingstijd is de hoeveelheid tijd die het systeem nodig heeft om de invoergegevens te bekijken, uit te zoeken wat ze betekenen en om eventuele berekeningen of bewerkingen uit te voeren.
Voorbeeld: Je hebt op het hamburgermenu geklikt, maar het thema of de developer heeft een zeer complex Javascript-mechanisme geschreven om het menu daadwerkelijk te activeren. De oorzaak van de INP is dan het werk met betrekking tot de interactie van de gebruiker.
3. Vertraging in de presentatie
Naast Javascript moet er na de gebruikersinteractie vaak ook nog lay-out- en renderwerk worden gedaan. Dit houdt in dat de pixels op het scherm moeten worden gewijzigd om de gebruikers een verwacht resultaat te geven. Wanneer de verwerkingstijd ervoor zorgt dat veel elementen opnieuw moeten worden vormgegeven of wanneer veel nieuwe HTML-elementen worden ingevoegd, wordt een browser gedwongen meer elementen te renderen.
Voorbeeld: Nadat je Javascript de browser heeft verteld om het menu uit te schuiven, verwacht je een visuele verandering. Maar veel menu-elementen hebben misschien ook een nieuwe kleur gekregen, waardoor er een langere vertraging optreedt voordat een nieuw bijgewerkt frame kan worden weergegeven.
Laten we eens kijken naar de duur van deze 3 stappen bij het klikken op "cookies toestaan", cumulatief oplopend tot een INP van 539 milliseconden.
Afhankelijk van hoe de cookiemelding op de interactie reageert, kan de verwerkingstijd en dus de totale INP lager zijn wanneer cookies worden geweigerd in plaats van geaccepteerd.
Waarom je voor je bezoekers de nieuwste en duurste telefoon moet kopen om INP op te lossen
De grootte van het geheugen/CPU van je apparaat heeft een grote invloed op hoe snel je browser taken kan uitvoeren zoals hierboven beschreven. Dit betekent dat mensen op mobiel bijna altijd een slechtere INP hebben dan mensen op desktop. Als we inzoomen op INP in het HTTP-archief technologierapport, zien we dat op desktop 99,35% van de Hyvä sites een goede INP hebben. Op mobiel heeft echter slechts 76,59% een goede INP.
Maar niet alle mobiele telefoons zijn hetzelfde! Als een snelle oplossing om uw INP-problemen op te lossen stellen we als grap voor:
Een beetje duur, maar er zit wel een kern van waarheid in. Als je hier echt diep in wilt duiken, raad ik je aan om The Performance Inequality Gap, 2024 te lezen. Daarin wordt uitgelegd hoe het hebben van een goede telefoon de prestaties enorm bevordert.
Factoren die een rol spelen
Niet alleen de specificaties van een telefoon hebben invloed op de prestaties, maar ook andere factoren kunnen een belangrijke rol spelen. De temperatuur kan bijvoorbeeld invloed hebben op hoe goed je apparaat werkt. Als je een ice pack op je mobiele apparaat bevestigt, kan het 15% sneller werken. Hetzelfde apparaat gebruiken in Groenland en Zuid-Afrika levert waarschijnlijk verschillende resultaten en dus ervaringen op. Dit illustreert de verschillende redenen waarom je apparaat traag kan werken, of dat nu constant is of af en toe.
Laten we eens kijken naar enkele INP-cijfers uit de echte wereld, berekend op basis van onze eigen RUMvision dataset: de grafiek hieronder toont een genormaliseerde weergave van de echte ervaringen van gebruikers met INP. Aan de breedte van de groene balken kunnen we zien dat gebruikers met minimaal 8 GB apparaat geheugen vaker een gezonde INP hadden dan gebruikers met 2 GB of minder.
Simpel gezegd: als je bezoekers veel goedkopere/oudere telefoons hebben, zal je INP waarschijnlijk slechter zijn, waardoor site-eigenaren harder moeten werken om hun publiek een goede ervaring te bieden. Zelfs binnen Europa kan het lanceren van een bestaande winkel met een Scandinavisch publiek in Spanje, terwijl de stack precies hetzelfde blijft, je dwingen om iets meer te optimaliseren.
Maar ongeacht het apparaat dat wordt gebruikt en alle andere variabelen, zal het verbeteren van de INP van bezoekers alle gebruikers ten goede komen. En sommige zullen uiteindelijk meer profiteren van je inspanningen om de prestaties te optimaliseren dan andere! En het goede nieuws is dat we dat precies kunnen meten en visualiseren. Voor elke website en elk publiek!
Deze gegevens zijn afkomstig van een analyse van INP-prestaties met behulp van echte RUMvision-gegevens, uitgevoerd door Rick Viscomi, die deel uitmaakt van Chrome's Web Performance DevRel-team. Om tot deze bevindingen te komen, analyseerde hij de geanonimiseerde dataset van RUMvision, onze monitoringoplossing voor echte gebruikers. Groen is goede INP, oranje betekent "behoeft verbetering", rood betekent slechte INP. Het is trouwens een geweldig artikel om INP beter te begrijpen, zeker een must read!
Betekent dit dat webwinkels die dure producten verkopen geen probleem hebben om de INP te halen?
Als je besluit om producten te verkopen aan rijkere consumenten, dan heb je misschien geen probleem omdat je publiek dan waarschijnlijk meer budget heeft voor en dus ook gebruik maakt van duurdere apparaten. Een groter deel van je bezoekers zal daardoor in de 8GB-emmer belanden. De kans is dus groot dat de verkoop van duurdere producten INP 'helpt'.
Maar zonder monitoring ben je blind voor veranderingen in gebruikte apparaten, verandering van publiek, enzovoort. En als we het over Core Web Vitals hebben, hebben we het niet over hypotheses, maar over je echte publiek en inkomsten - met een paar factoren om in gedachten te houden:
- Mensen die dure dingen kopen, hebben niet altijd dure telefoons. Het is moeilijk om toe te geven, maar ik laat mijn telefoon minstens één keer per jaar vallen of maak hem kapot, dus ik koop er geen die meer dan 300 euro kost. Maar het gebruik van een mid-end mobiel weerhoudt me er niet van om te shoppen op jullie webshop met high-end producten.
- Core Web Vitals zijn gebaseerd op informatie die is verzameld van Chrome-browsers. Als iPhone-gebruikers met Safari browsen, worden die gegevens geen onderdeel van de CrUX-dataset, wat betekent dat ze je niet helpen om voor de Core Web Vitals te slagen.
- Wat verwachten gebruikers als ze je high-end webshop bezoeken? Zoals we hebben vastgesteld, is een goede INP-score 200 ms voor de langzaamste interactie op een pagina, in een gemiddelde van gebruikerservaringen over uw hele site op het 75e percentiel. Zonder hier te diep op in te gaan - we kunnen hier een hele blogpost aan wijden - zijn er twee belangrijke overwegingen. Namelijk: het 75e percentiel betekent dat 25% van je gebruikers een slechtere ervaring had, maar dat ze misschien nog steeds bij je winkel willen kopen. Optimaliseren om ervaringen te verbeteren tot het 80e of misschien zelfs 90e percentiel kan je veel meer geld opleveren. Een andere factor is dat mensen die surfen op high-end telefoons 200 ms als erg traag kunnen ervaren, omdat ze gewend zijn aan snelle reactietijden.
Als je dit allemaal overweegt, snap je waarom je er niet zomaar van uit kunt gaan dat het hebben van een high-end winkel je niet een vrijstelling geeft van het optimaliseren van INP.
Een echt voorbeeld is de nieuwe Hyvä webshop van Citizen Watch. Zij waren altijd al een high-end merk, maar door het verbeteren van Core Web Vitals werden hun conversies veel beter, vooral op mobiel.
Dit is ook waar het hebben van een echte gebruikersmonitoringoplossing die laat zien wat mensen precies ervaren heel praktisch wordt. Je kunt namelijk niet verbeteren wat je niet meet.
Hoe meet je INP?
In de wereld van webprestaties is Interaction to Next Paint gebaseerd op wat we "fielddata" noemen.
Lab data
In lab data- zoals Lighthouse - is de Total Blocking Time (TBT) de meting die het dichtstbij field data in de buurt komt, maar dit heeft tekortkomingen. Zo meet het meestal een nieuwe ongecacheerde pagehit waarbij cookies niet worden geaccepteerd en de meeste derde partijen niet worden geladen. Er wordt ook niet gescrold of geklikt, dus het is mogelijk dat lazyloaded Javascript niet wordt uitgevoerd tijdens zo'n synthetische labtest.
En zelfs als je zou proberen om interacties te simuleren, heeft elke gebruiker een andere perceptie van wanneer hij kan beginnen met interacteren en zal zullen ze op verschillende momenten interacteren. Een pagina zal zich elke keer anders gedragen, gebruikers zullen op verschillende momenten interacteren. Dit maakt de correlatie tussen TBT en echte UX relatief zwak.
Niettemin biedt Google op web.dev strategieën om langzame interacties in het lab te reproduceren.
Field data
Dat betekent dat je gegevens nodig hebt van echte bezoekers en echte interacties uit het veld. Dit is wat Google doet met Core Web Vitals, waarbij dergelijke informatie naar het Chrome User Experience Report (CrUX) wordt gestuurd.
Als je site voldoende bezoekers heeft, krijg je een field data rapport te zien boven de vouw wanneer je PageSpeed Insights gebruikt. De score die je bovenaan ziet, wordt als "goed" beschouwd als ten minste 75% van alle pageview-ervaringen binnen de geteste pagina minder dan 200 ms is - waarbij je in gedachten moet houden dat INP slechts een van de traagste van de vele interacties op een pagina vertegenwoordigt.
Google stelt voor om te beginnen met RUM om giswerk en verspilde moeite te voorkomen
Idealiter begint je reis naar het optimaliseren van INP met field data. In het beste geval geeft field data van Real User Monitoring (RUM) je niet alleen de INP-waarde van een pagina, maar ook contextuele gegevens die duidelijk maken welke specifieke interactie verantwoordelijk was voor de INP-waarde zelf, of de interactie plaatsvond tijdens of na het laden van de pagina, het type interactie (klik, toetsaanslag of tik) en andere waardevolle informatie.
Hoewel de openbaar beschikbare CrUX-gegevens van Google nuttig zijn om je te duidelijk te maken dat er een probleem is op een hoog niveau, bieden ze vaak niet genoeg details om het probleem volledig duidelijk te maken. Met een RUM-oplossing kun je dieper ingaan op de pagina's, gebruikers of gebruikersinteracties die trage interacties ervaren. De mogelijkheid om INP toe te schrijven aan individuele interacties voorkomt giswerk en verspilde moeite.
Hoe RUMvision je kan helpen bij het visualiseren van INP problemen
Je moet Google waarderen om je business case te maken, en wij bij RUMvision doen dat zeker! Omdat wij als monitoringoplossing voor echte gebruikers al deze dingen doen, en nog veel meer. Alle situaties die in dit artikel worden beschreven, zijn problemen die wij kunnen meten en visualiseren. Dit omvat INP per template, INP per apparaat geheugen, INP per element, INP per land en INP-uitsplitsing.
Verzamel realtime metingen van uw eigen bezoekers door simpelweg onze kleine Javascript snippet te installeren en ga aan de slag met het debuggen van INP. De inzichten die RUMvision biedt stoppen hier echter niet.
Maak kennis met LoAF
Google wil je helpen om INP te verbeteren. De nieuwste API in hun toolset om te helpen bij het debuggen van INP heet LoAF, wat staat voor Long Animation Frame API. Dit is een game changer als het gaat om het observeren van wat er gebeurt binnen een INP, of specifieker, een lange taak die de main thread - en daarmee ook de interactie van gebruikers - blokkeert.
Zoals inmiddels wel duidelijk is geworden, is Javascript vaak de grootste boosdoener. Maar wiens Javascript veroorzaakt de problemen, dat van jezelf of van derden? En welke derde partij precies? Hoe vaak komen ze voor? En waar? Je kan de API zelf gebruiken, of profiteren van onze inspanningen om dit in bulk te verzamelen namens jouw winkel.
RUMvision visualiseert en groepeert de verzamelde gegevens, zodat zowel technische als minder technische geïnteresseerden kunnen zien wat er aan de hand is en het kunnen hebben over de onderwerpen INP kunnen verbeteren.
Een impressie van het dashboard van derden zoals aangeboden door RUMvision en verzameld door gebruik te maken van de LoAF API.
En wist je dat wij de eerste RUM waren die deze API gebruikten en embedden? Onze inspanningen en resultaten hebben Google geholpen om te bevestigen dat deze API waardevolle inzichten biedt en op de goede weg is. De LoAF API zal zelfs stabiel worden in Chrome 123.
Door deze informatie in bulk te verzamelen, kan RUMvision je benchmarks tonen om een derde partij die je winkel gebruikt te vergelijken met andere -misschien meer performante- derde partij oplossingen binnen dezelfde niche.
Als je INP wilt meten om te debuggen, denk ik eerlijk gezegd dat RUMvision op dit moment de beste oplossing is om dat te doen.
Andere manieren om INP te meten
Naast het monitoren van echte gebruikers is mijn favoriete manier om problemen met Interaction to Next Paint op te lossen het prestatiepaneel in DevTools. Zo kun je een opname starten en een de ervaring van gebruikers doorlopen. Je ziet dan vlamgrafieken en welke taken moeten worden uitgevoerd wanneer jij en je gebruikers klikken.
4 tips om INP problemen op te lossen
Elke webshop en de omstandigheden van hun gebruikers zijn anders, maar ik heb pagespeed consultant Erwin Hofman gevraagd om wat tips te geven over problemen die hij vaak tegenkomt en hoe je die kunt oplossen. Hij deelde ze graag.
Lees ook ons master artikelen om de Interaction to Next Paint te verbeteren.
Tem je third parties
Een van de belangrijkste redenen dat er INP-problemen optreden bij webwinkels, is wanneer scripts van derden zich gaan bemoeien met de hoofdtaak van de browser. We zagen dit ook al terug in het LoAF-gedeelte van dit artikel. Als je INP wilt verbeteren, stel ik voor dat je begint met het onder controle krijgen van je derden. Dit omvat een aantal best practices:
- Als je A/B-tests wilt uitvoeren, draai ze dan niet op 100%;
- Kies derden die prioriteit geven aan prestaties en hun Javascript beperken;
- Heb je echt een heatmap nodig? En zo ja, heb je die dan altijd nodig? Of kan het soms worden uitgeschakeld om al je gebruikers te helpen?
- Zijn er derde partijen die u niet gebruikt? Of heel weinig? Verwijder ze dan;
- Zijn er derde partijen die elkaar overlappen? Kun je één oplossing gebruiken die meerdere functies biedt in plaats van meerdere bibliotheken te laden?
Vertraag niet alle third parties/GTM totdat er een interactie is
Dit wordt van tijd tot tijd geadviseerd. En het zal waarschijnlijk je labgegevens en dus Lighthouse-scores verbeteren. Het kan echter uiteindelijk je INP en echte gebruikerservaringen belemmeren.
Je kunt overwegen om in plaats daarvan de main-thread op te heffen. Herinner je je het voorbeeld van de cookiemelding? Een Consent Management Platform (CMP) hoeft niet alle gebeurtenissen meteen naar je GTM te sturen nadat je op de knoppen "Cookies toestaan" hebt geklikt.
In plaats daarvan moet een CMP prioriteit geven aan het verbergen van het cookietoestemmingsvenster. Dit kan worden bereikt door sommige taken (het verzenden van gebeurtenissen waardoor derde partijen worden geladen) uit te stellen tot na het voltooien van de visuele feedback.
Houd je DOM-grootte in de gaten
Om te voorkomen dat de kosten oplopen, moet je spaarzaam gebruikmaken van event handlers, de DOM-grootte klein houden of besluiten om het renderen van elementen die niet eens zichtbaar zijn over te slaan door de content-visibility CSS-eigenschap te gebruiken.
Vloeiende animaties
Wanneer je DOM-knooppunten animeert, zorg er dan voor dat je CSS-eigenschappen gebruikt die automatisch worden overgeheveld naar de GPU van de browser. Dit voorkomt dat stijl-, lay-out- en renderwerk wordt uitgevoerd, waardoor de main-thread van de browser vrij blijft voor andere taken.
Iedereen profiteert hiervan: ander JS- en CSS-werk wordt sneller voltooid, je animaties lopen soepeler en INP profiteert er waarschijnlijk ook van.
Je vraagt je misschien af hoe je dit moet doen; houd je gewoon aan de transform en opacity CSS-eigenschappen en je kunt een veel verschillende animaties maken. Een voorbeeld hiervan zijn cookiemeldingen: de meeste gebruiken nog steeds de onderste CSS eigenschap in plaats van transform: translateY(-100%).
Conclusie
Ik hoop dat dit artikel je heeft geholpen om Interaction to Next Paint beter te begrijpen. We hebben ontdekt dat er geen twee gebruikers zijn die dezelfde verwachtingen, laadpercepties, apparaten of omstandigheden hebben. Ook zijn er geen twee winkels, producten of prestatie-uitdagingen hetzelfde. Slechte Interaction to Next Paint kan worden veroorzaakt door integraties van derden, je eigen Javascript of een combinatie van beide. Het is niet altijd Javascript, maar het is bijna altijd Javascript. En zoals we ook hebben geleerd, zijn browsers net mensen en kunnen ze niet multitasken.
Je kunt niet verbeteren wat je niet meet. Gebruik beschikbare tools en (nieuwe) API's, zoals DevTools en LoAF.
Maar om echt te begrijpen wat je publiek ervaart, moet je veel gegevens verzamelen. Als je je Core Web Vitals wilt verbeteren, met name de Interaction to Next Paint, is Real User Monitoring (RUM) een geweldige manier om te beginnen. Dat is ook waarom Google het aanbeveelt. Het laat mensen met verschillende niveaus van technische kennis weten wat er gebeurt en waar het gebeurt. Het is nu dus gemakkelijker om deze problemen op te lossen, zoals het beperken van third-party's en het in de gaten houden van de grootte van je DOM. Het verbeteren van INP maakt de gebruikerservaring voor iedereen beter.
Want het belangrijkste is dat je gebruikers een goede ervaring hebben, in plaats van gefrustreerd raken. Om terug te komen op mijn oorspronkelijke uitspraak: je kunt zien waarom de pagespeed-gemeenschap INP misschien niet de "Call to Action-metric" wil noemen. De "Respond to Action-metric" past daar misschien beter bij. En deze nieuwe metric is sowieso belangrijk om ervoor te zorgen dat conversies plaatsvinden. Veel succes!
