Begrijp hoe de nieuwe INP-statistiek de ervaring beïnvloedt van sites die zijn gebouwd met JavaScript-frameworks en -bibliotheken.
Chrome heeft onlangs een nieuwe experimentele responsiviteitsstatistiek geïntroduceerd in het Chrome UX Report- rapport. Deze statistiek, die we nu kennen als Interaction to Next Paint (INP), meet de algehele responsiviteit op gebruikersinteracties op de pagina. Vandaag willen we inzichten delen over de positie van websites die zijn gebouwd met moderne JavaScript-frameworks in relatie tot deze statistiek. We willen bespreken waarom INP relevant is voor frameworks en hoe Aurora en frameworks werken aan het optimaliseren van de responsiviteit.
Achtergrond
Chrome gebruikt First Input Delay ( FID ) als onderdeel van Core Web Vitals ( CWV ) om de laadresponsiviteit van websites te meten. FID meet de wachttijd vanaf de eerste gebruikersinteractie tot het moment dat de browser de aan de interactie gekoppelde gebeurtenishandlers kan verwerken. Het omvat niet de tijd om de gebeurtenishandlers te verwerken, daaropvolgende interacties op dezelfde pagina te verwerken of het volgende frame te schilderen nadat de gebeurteniscallbacks zijn uitgevoerd. Responsiviteit is echter cruciaal voor de gebruikerservaring gedurende de hele levenscyclus van de pagina, omdat gebruikers ongeveer 90% van de tijd op een pagina doorbrengen nadat deze is geladen.
INP meet de tijd die een webpagina nodig heeft om te reageren op gebruikersinteracties vanaf het moment dat de gebruiker de interactie start tot het moment dat het volgende frame op het scherm wordt weergegeven. Met INP hopen we een geaggregeerde maatstaf mogelijk te maken voor de waargenomen latentie van alle interacties in de levenscyclus van de pagina. Wij zijn van mening dat INP een nauwkeurigere schatting zal geven van de belasting van webpagina's en de runtime-responsiviteit.
Omdat FID alleen de invoervertraging van de eerste interactie meet, is het waarschijnlijk dat webontwikkelaars de daaropvolgende interacties niet proactief hebben geoptimaliseerd als onderdeel van hun CWV-verbeteringsproces. Sites, vooral sites met een hoge mate van interactiviteit, zouden daarom hard moeten gaan werken om het goed te doen op dit gebied.
De rol van raamwerken
Omdat veel websites afhankelijk zijn van JavaScript om interactiviteit te bieden, wordt de INP-score voornamelijk beïnvloed door de hoeveelheid JavaScript die op de hoofdthread wordt verwerkt. JavaScript-frameworks vormen een essentieel onderdeel van moderne front-end webontwikkeling en bieden ontwikkelaars waardevolle abstracties voor routing, gebeurtenisafhandeling en compartimentering van JavaScript-code. Ze spelen dus een centrale rol bij het optimaliseren van de responsiviteit en gebruikerservaring van websites die ze gebruiken.
Frameworks hebben mogelijk stappen ondernomen voor een betere responsiviteit door de FID voor websites eerder te verbeteren. Ze zouden nu echter de beschikbare metrische gegevens over het reactievermogen moeten analyseren en eraan moeten werken om eventuele vastgestelde lacunes aan te pakken. Over het algemeen heeft INP doorgaans lagere slagingspercentages, en het verschil in het meetproces vereist aanvullende code-optimalisatie. De volgende tabel vat samen waarom.
Het Aurora- team in Chrome werkt met open-source webframeworks om ontwikkelaars te helpen verschillende aspecten van de gebruikerservaring te verbeteren, waaronder prestaties en CWV-statistieken. Met de introductie van INP willen we voorbereid zijn op de verandering in CWV-statistieken voor op frameworks gebaseerde websites. We hebben gegevens verzameld op basis van de experimentele responsiviteitsstatistiek in CrUX-rapporten. We zullen inzichten en actiepunten delen om de overgang naar de INP-metriek voor op frameworks gebaseerde websites te vergemakkelijken.
Experimentele metrische gegevens over reactievermogen
Een INP lager dan of gelijk aan 200 milliseconden duidt op een goed reactievermogen. De gegevens van het CrUX-rapport en het CWV Technology Report voor juni 2023 geven ons de volgende informatie over de responsiviteit voor populaire JavaScript-frameworks.
De tabel toont het percentage herkomsten op elk raamwerk met een goede responsiviteitsscore. De cijfers zijn bemoedigend, maar laten ons zien dat er nog veel ruimte is voor verbetering.
Welke invloed heeft JavaScript op INP?
INP-waarden in het veld correleren goed met de Total Blocking Time (TBT) waargenomen in het laboratorium. Dit zou kunnen impliceren dat elk script dat de hoofdthread voor een lange tijd blokkeert, slecht zou zijn voor INP. Zware JavaScript-uitvoering na een interactie kan de hoofdthread voor langere tijd blokkeren en de reactie op die interactie vertragen. Enkele veelvoorkomende oorzaken die leiden tot het blokkeren van scripts zijn:
Niet-geoptimaliseerd JavaScript: overtollige code of slechte strategieën voor het splitsen en laden van code kunnen ervoor zorgen dat JavaScript opzwelt en de hoofdthread voor lange perioden blokkeert. Het splitsen van codes, progressief laden en het opbreken van lange taken kunnen de responstijden aanzienlijk verbeteren.
Scripts van derden: Scripts van derden , die soms niet nodig zijn om een interactie te verwerken (bijvoorbeeld advertentiescripts), kunnen de rode draad blokkeren en onnodige vertragingen veroorzaken. Door prioriteit te geven aan essentiële scripts kan de negatieve impact van scripts van derden worden verminderd.
Meerdere gebeurtenishandlers: meerdere gebeurtenishandlers die aan elke interactie zijn gekoppeld en die elk een ander script uitvoeren, kunnen elkaar hinderen en tot grote vertragingen leiden. Sommige van deze taken zijn mogelijk niet-essentieel en kunnen worden gepland op een webwerker of wanneer de browser inactief is.
Framework-overhead bij gebeurtenisafhandeling: Frameworks kunnen extra functies/syntaxis hebben voor gebeurtenisafhandeling. Vue gebruikt bijvoorbeeld v-on om gebeurtenislisteners aan elementen te koppelen, terwijl Angular gebruikersgebeurtenishandlers omhult. Voor het implementeren van deze functies is aanvullende raamwerkcode boven standaard JavaScript vereist.
Hydratatie: Bij gebruik van een JavaScript-framework is het niet ongebruikelijk dat een server de initiële HTML voor een pagina genereert, die vervolgens moet worden aangevuld met gebeurtenishandlers en applicatiestatus, zodat deze interactief kan zijn in een webbrowser. Dit proces noemen we hydratatie. Dit kan een zwaar proces zijn tijdens het laden, afhankelijk van hoe lang het duurt voordat JavaScript is geladen en hoe lang het duurt voordat de hydratatie is voltooid. Het kan er ook toe leiden dat pagina's er interactief uitzien, terwijl dat niet het geval is. Vaak vindt hydratatie automatisch plaats tijdens het laden van de pagina of lui (bijvoorbeeld tijdens gebruikersinteractie) en kan dit van invloed zijn op de INP of verwerkingstijd als gevolg van taakplanning. In bibliotheken zoals React kun je gebruik maken van
useTransition, zodat een deel van een componentweergave zich in het volgende frame bevindt en eventuele duurdere bijwerkingen aan toekomstige frames worden overgelaten. Gezien dit gegeven kunnen updates in een transitie die leiden tot urgentere updates zoals klikken een patroon zijn dat goed kan zijn voor INP.Prefetching: Het agressief vooraf ophalen van de bronnen die nodig zijn voor daaropvolgende navigatie kan prestatiewinst opleveren als het goed wordt gedaan. Als u SPA-routes echter synchroon vooraf ophaalt en rendert, kan dit een negatieve invloed hebben op INP, aangezien al deze dure weergavepogingen in één enkel frame worden voltooid. Vergelijk dit met het niet vooraf ophalen van uw route en in plaats daarvan het benodigde werk starten (bijvoorbeeld
fetch()) en het deblokkeren van verf. We raden u aan opnieuw te onderzoeken of de aanpak van uw raamwerk op het gebied van prefetching de optimale UX oplevert en welke invloed dit (of helemaal niet) op INP kan hebben.
Voor een goede INP-score zullen ontwikkelaars zich vanaf nu moeten concentreren op het beoordelen van de code die wordt uitgevoerd na elke interactie op de pagina en het optimaliseren van hun chunking, rehydratie, laadstrategieën en de grootte van elke render()-update voor beide eerste- scripts van derden en derden,
Hoe pakken Aurora en frameworks INP-problemen aan?
Aurora werkt met raamwerken door best practices te integreren om ingebakken oplossingen voor veelvoorkomende problemen te bieden. We hebben met Next.js, Nuxt.js, Gatsby en Angular gewerkt aan oplossingen die binnen het raamwerk sterke standaardwaarden bieden om de prestaties te optimaliseren. Hieronder volgen de hoogtepunten van ons werk in deze context:
React en Next.js: De Next.js Script-component helpt bij het oplossen van problemen die worden veroorzaakt door het inefficiënt laden van scripts van derden. In Next.js is granulaire chunking geïntroduceerd om kleinere chunks voor gedeelde code mogelijk te maken. Dit helpt de hoeveelheid ongebruikte algemene code die op alle pagina's wordt gedownload, te verminderen. We werken ook samen met Next.js om INP-gegevens beschikbaar te maken als onderdeel van hun Analytics- service.
Angular: Aurora werkt samen met het Angular- team om verbeteringen aan de weergave en hydratatie op de server te onderzoeken. We zijn ook van plan om te kijken naar verfijningen in de afhandeling van gebeurtenissen en de detectie van wijzigingen om de INP te verbeteren.
Vue en Nuxt.js: We onderzoeken mogelijkheden voor samenwerking, voornamelijk met betrekking tot het laden en weergeven van scripts.
Hoe denken raamwerken over het verbeteren van INP?
Reageren en Next.js
Met React.js time slicing , geïmplementeerd via startTransition en Suspense , kunt u zich aanmelden voor selectieve of progressieve hydratatie. Dit betekent dat hydratatie geen synchroon blok is. Het wordt gedaan in kleine stukjes die op elk moment kunnen worden onderbroken.
Dit zou de INP moeten helpen verbeteren en u in staat moeten stellen sneller te reageren op toetsaanslagen, zweefeffecten tijdens de overgang en klikken. Het helpt ook om React-apps responsief te houden, zelfs voor grote overgangen zoals automatisch aanvullen.
Next.js heeft een nieuw routeringsframework geïmplementeerd dat standaard startTransition gebruikt voor routeovergangen. Hierdoor kunnen Next.js-site-eigenaren React-time-slicing toepassen en de responsiviteit van route-overgangen verbeteren.
Hoekig
Het Angular-team onderzoekt verschillende ideeën die ook zouden moeten helpen bij INP:
- Zoneloos: Vermindert de initiële bundelgrootte en de vereiste code die moet worden geladen voordat een app iets kan weergeven.
- Hydratatie: hydratatie in eilandstijl om te beperken hoeveel van de app moet worden gewekt voor interactie.
- Verminder de overhead van CD: maak bijvoorbeeld het detecteren van wijzigingen goedkoper, zoek manieren om minder van de app te controleren en maak gebruik van reactieve signalen over wat er is veranderd.
- Gedetailleerdere codesplitsing: maak de initiële bundel kleiner.
- Betere ondersteuning voor laadindicatoren:: bijvoorbeeld tijdens het opnieuw renderen van SSR, tijdens routenavigatie en bij luie laadbewerkingen.
- Profileringstools: betere ontwikkelingstools om de interactiekosten te begrijpen, vooral als het gaat om de kosten voor het detecteren van wijzigingen voor specifieke interacties.
Door deze verbeteringen kunnen we verschillende problemen aanpakken die leiden tot een slechte responsiviteit en gebruikerservaring, en de CWV-statistieken en de nieuwe INP-statistiek voor op frameworks gebaseerde websites verbeteren.
Conclusie
We verwachten dat de INP-score een beter kompas zal bieden voor websites om de responsiviteit en prestaties in de toekomst te verbeteren. We zullen voortbouwen op onze bestaande INP-gids om in 2023 meer bruikbare tips voor raamwerkontwikkelaars te bieden. We hopen dit te bereiken door:
- Kanalen creëren voor gemakkelijke toegang tot veldgegevens op INP voor frameworks en webontwikkelaars.
- Werk met raamwerken om functies te bouwen die INP standaard verbeteren.
We verwelkomen feedback van framework-gebruikers wanneer ze aan hun INP-optimalisatietraject beginnen.