De Long Animation Frames API (LoAF-uitgesproken als Lo-Af) is een update van de Long Tasks API om een beter begrip te bieden van langzame updates van de gebruikersinterface (UI). Dit kan handig zijn om langzame animatieframes te identificeren die waarschijnlijk van invloed zijn op de Interaction to Next Paint (INP) Core Web Vital-metriek die de responsiviteit meet, of om andere UI-janks te identificeren die de vloeiendheid beïnvloeden.
Status van de API
Na een origin-proefversie van Chrome 116 naar Chrome 122 is de LoAF API verscheept vanuit Chrome 123 .
Achtergrond: de Lange Taken API
De Long Animation Frames API is een alternatief voor de Long Tasks API die al enige tijd beschikbaar is in Chrome (sinds Chrome 58). Zoals de naam al doet vermoeden, kunt u met de Long Task API controleren op lange taken, dit zijn taken die de hoofdreeks 50 milliseconden of langer in beslag nemen. Lange taken kunnen worden gemonitord met behulp van de PerformanceLongTaskTiming
interface, met een PeformanceObserver
:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'longtask', buffered: true });
Lange taken veroorzaken waarschijnlijk reactieproblemen. Als een gebruiker probeert te communiceren met een pagina (bijvoorbeeld door op een knop te klikken of een menu te openen) maar de hoofdthread al bezig is met een lange taak, wordt de interactie van de gebruiker uitgesteld totdat die taak is voltooid.
Om het reactievermogen te verbeteren, wordt vaak geadviseerd om lange taken op te splitsen . Als elke lange taak in plaats daarvan wordt opgedeeld in een reeks van meerdere, kleinere taken, kan het mogelijk zijn dat belangrijkere taken tussendoor worden uitgevoerd om aanzienlijke vertragingen bij het reageren op interacties te voorkomen.
Wanneer we de responsiviteit proberen te verbeteren, bestaat de eerste poging dus vaak uit het uitvoeren van een prestatietracering en het bekijken van lange taken. Dit kan via een laboratoriumgebaseerde audittool zoals Lighthouse (die een audit voor lange hoofdthreadtaken heeft), of door naar lange taken te kijken in Chrome DevTools .
Testen in een laboratorium is vaak een slecht startpunt voor het identificeren van problemen met het reactievermogen , omdat deze tools mogelijk geen interacties omvatten; als ze dat wel doen, vormen ze slechts een kleine subset van waarschijnlijke interacties. Idealiter meet je de oorzaken van langzame interacties in het veld.
Tekortkomingen van de Long Tasks API
Het meten van lange taken in het veld met behulp van een Performance Observer is slechts enigszins nuttig. In werkelijkheid geeft het niet zoveel informatie behalve het feit dat er een lange taak heeft plaatsgevonden en hoe lang deze heeft geduurd.
Real User Monitoring (RUM)-tools gebruiken dit vaak om het aantal of de duur van lange taken te bepalen of om te identificeren op welke pagina's ze plaatsvinden, maar zonder de onderliggende details van wat de lange taak veroorzaakte, is dit slechts van beperkt nut. De Long Tasks API heeft alleen een basisattributiemodel , dat u in het beste geval alleen vertelt in welke container de lange taak plaatsvond (het document op het hoogste niveau of een <iframe>
), maar niet het script of de functie die de taak heeft aangeroepen, zoals blijkt uit een typische invoer:
{
"name": "unknown",
"entryType": "longtask",
"startTime": 31.799999997019768,
"duration": 136,
"attribution": [
{
"name": "unknown",
"entryType": "taskattribution",
"startTime": 0,
"duration": 0,
"containerType": "window",
"containerSrc": "",
"containerId": "",
"containerName": ""
}
]
}
De Long Tasks API is ook een onvolledige weergave, omdat deze ook enkele belangrijke taken kan uitsluiten. Sommige updates, zoals het renderen, vinden plaats in afzonderlijke taken die idealiter samen met de voorgaande uitvoering zouden moeten worden opgenomen, waardoor die update het 'totale werk' voor die interactie nauwkeurig meet. Voor meer details over de beperkingen van het vertrouwen op taken, zie de sectie 'Waar lange taken tekortschieten' van de uitleg .
Het laatste probleem is dat het meten van lange taken alleen rapporteert over individuele taken die langer duren dan de limiet van 50 milliseconden. Een animatieframe kan bestaan uit verschillende taken die kleiner zijn dan deze limiet van 50 milliseconden, maar toch gezamenlijk het weergavevermogen van de browser blokkeren.
De API voor lange animatieframes
De Long Animation Frames API (LoAF) is een nieuwe API die een aantal tekortkomingen van de Long Tasks API probeert aan te pakken, zodat ontwikkelaars meer bruikbare inzichten kunnen krijgen om responsiviteitsproblemen aan te pakken en INP te verbeteren.
Een goede responsiviteit betekent dat een pagina snel reageert op interacties die ermee plaatsvinden. Dat houdt in dat we alle updates die de gebruiker nodig heeft, tijdig kunnen schilderen en kunnen voorkomen dat deze updates worden geblokkeerd. Voor INP wordt aanbevolen om binnen 200 milliseconden of minder te reageren , maar voor andere updates (bijvoorbeeld animaties) kan zelfs dat te lang zijn.
De Long Animation Frames API is een alternatieve benadering voor het meten van blokkeringswerk. In plaats van de afzonderlijke taken te meten, meet de Long Animation Frames API, zoals de naam al doet vermoeden, lange animatieframes . Er is sprake van een lang animatieframe wanneer een weergave-update meer dan 50 milliseconden wordt vertraagd (hetzelfde als de drempelwaarde voor de Long Tasks API).
Lange animatieframes kunnen op dezelfde manier worden waargenomen als lange taken met een PerformanceObserver
, maar in plaats daarvan kijken we naar het type long-animation-frame
:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Eerdere lange animatieframes kunnen ook als volgt uit de prestatietijdlijn worden opgevraagd:
const loafs = performance.getEntriesByType('long-animation-frame');
Er is echter een maxBufferSize
voor prestatie-items, waarna nieuwere items worden verwijderd, dus de PerformanceObserver-aanpak is de aanbevolen aanpak. De buffergrootte long-animation-frame
is ingesteld op 200, hetzelfde als voor long-tasks
.
Voordelen van het kijken naar frames in plaats van naar taken
Het belangrijkste voordeel van het bekijken hiervan vanuit een frameperspectief in plaats van vanuit een takenperspectief, is dat een lange animatie kan bestaan uit een willekeurig aantal taken die cumulatief hebben geresulteerd in een lang animatieframe. Dit betreft het laatste punt dat eerder werd genoemd, waarbij de som van vele kleinere, render-blokkerende taken vóór een animatieframe mogelijk niet naar boven komt door de Long Tasks API.
Een bijkomend voordeel van deze alternatieve kijk op lange taken is de mogelijkheid om timing-uitsplitsingen van het hele frame te bieden. In plaats van alleen een startTime
en een duration
op te nemen, zoals de Long Tasks API, bevat LoAF een veel gedetailleerder overzicht van de verschillende delen van de frameduur, waaronder:
-
startTime
: de starttijd van het lange animatieframe ten opzichte van de starttijd van de navigatie. -
duration
: de duur van het lange animatieframe (exclusief presentatietijd). -
renderStart
: de starttijd van de weergavecyclus, inclusief callbacksrequestAnimationFrame
, stijl- en lay-outberekening, waarnemer van formaat wijzigen en callbacks van intersectiewaarnemers. -
styleAndLayoutStart
: het begin van de tijdsperiode besteed aan stijl- en lay-outberekeningen. -
firstUIEventTimestamp
: de tijd van de eerste UI-gebeurtenis (muis/toetsenbord enzovoort) die in de loop van dit frame moet worden afgehandeld. -
blockingDuration
: de duur in milliseconden waarvoor het animatieframe werd geblokkeerd.
Met deze tijdstempels kan het lange animatieframe worden opgedeeld in timings:
Tijdstip | Berekening |
---|---|
Begintijd | startTime |
Eindtijd | startTime + duration |
Werkduur | renderStart ? renderStart - startTime : duration |
Renderduur | renderStart ? (startTime + duration) - renderStart: 0 |
Render: duur vóór de lay-out | styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0 |
Render: duur van stijl en lay-out | styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0 |
Voor meer details over deze individuele timings raadpleegt u de uitleg , die gedetailleerde details biedt over welke activiteit bijdraagt aan een lang animatieframe.
Betere toeschrijving
Het invoertype long-animation-frame
bevat betere attributiegegevens van elk script dat heeft bijgedragen aan een lang animatieframe.
Net als bij de Long Tasks API wordt dit aangeboden in een reeks attributie-items, waarvan elk de volgende details bevat:
- Een
name
enEntryType
retourneren beidescript
. - Een betekenisvolle
invoker
, die aangeeft hoe het script is aangeroepen (bijvoorbeeld'IMG#id.onload'
,'Window.requestAnimationFrame'
of'Response.json.then'
). - Het
invokerType
van het scriptingangspunt:-
user-callback
: Een bekende callback die is geregistreerd via een webplatform-API (bijvoorbeeldsetTimeout
,requestAnimationFrame
). -
event-listener
: Een luisteraar naar een platformgebeurtenis (bijvoorbeeldclick
,load
,keyup
). -
resolve-promise
: Handler van een platformbelofte (bijvoorbeeldfetch()
. Merk op dat in het geval van beloften alle handlers van dezelfde beloften samen worden gemengd als één "script").
-
reject-promise
: Volgensresolve-promise
, maar voor de afwijzing. -
classic-script
: Scriptevaluatie (bijvoorbeeld<script>
ofimport()
) -
module-script
: Hetzelfde alsclassic-script
, maar voor modulescripts.
-
- Afzonderlijke timinggegevens voor dat script:
-
startTime
: Tijd waarop de invoerfunctie werd aangeroepen. -
duration
: De duur tussenstartTime
en het moment waarop de daaropvolgende microtaakwachtrij klaar is met verwerken. -
executionStart
: De tijd na het compileren. -
forcedStyleAndLayoutDuration
: De totale tijd die is besteed aan het verwerken van de geforceerde lay-out en stijl binnen deze functie (zie thrashing ). -
pauseDuration
: de totale tijd die is besteed aan het "pauzeren" van synchrone bewerkingen (waarschuwing, synchrone XHR).
-
- Details van de scriptbron:
-
sourceURL
: De naam van de scriptbron, indien beschikbaar (of leeg als deze niet wordt gevonden). -
sourceFunctionName
: De naam van de scriptfunctie, indien beschikbaar (of leeg als deze niet wordt gevonden). -
sourceCharPosition
: De positie van het scriptteken, indien beschikbaar (of -1 indien niet gevonden).
-
-
windowAttribution
: De container (het document op het hoogste niveau, of een<iframe>
) waarin het lange animatieframe plaatsvond. -
window
: Een verwijzing naar hetzelfde venster.
Waar beschikbaar, kunnen ontwikkelaars dankzij de bronvermeldingen precies weten hoe elk script in het lange animatieframe is aangeroepen, tot aan de tekenpositie in het aanroepende script. Dit geeft de exacte locatie in een JavaScript-bron die resulteerde in het lange animatieframe.
Voorbeeld van een prestatie-invoer met een long-animation-frame
Een compleet voorbeeld van een prestatie long-animation-frame
, dat één enkel script bevat, is:
{
"blockingDuration": 0,
"duration": 60,
"entryType": "long-animation-frame",
"firstUIEventTimestamp": 11801.099999999627,
"name": "long-animation-frame",
"renderStart": 11858.800000000745,
"scripts": [
{
"duration": 45,
"entryType": "script",
"executionStart": 11803.199999999255,
"forcedStyleAndLayoutDuration": 0,
"invoker": "DOMWindow.onclick",
"invokerType": "event-listener",
"name": "script",
"pauseDuration": 0,
"sourceURL": "https://web.dev/js/index-ffde4443.js",
"sourceFunctionName": "myClickHandler",
"sourceCharPosition": 17796,
"startTime": 11803.199999999255,
"window": [Window object],
"windowAttribution": "self"
}
],
"startTime": 11802.400000000373,
"styleAndLayoutStart": 11858.800000000745
}
Zoals u kunt zien, levert dit een ongekende hoeveelheid gegevens op waarmee websites de oorzaak van laggy rendering-updates kunnen begrijpen.
Gebruik de Long Animation Frames API in het veld
Tools als Chrome DevTools en Lighthouse zijn, hoewel nuttig voor het ontdekken en reproduceren van problemen, laboratoriumtools die mogelijk belangrijke aspecten van de gebruikerservaring missen die alleen veldgegevens kunnen bieden.
De Long Animation Frames API is ontworpen om in het veld te worden gebruikt om belangrijke contextuele gegevens te verzamelen voor gebruikersinteracties die de Long Tasks API niet kon. Dit kan u helpen bij het identificeren en reproduceren van problemen met interactiviteit die u anders misschien niet zou hebben ontdekt.
Functie voor het detecteren van API-ondersteuning voor lange animatieframes
U kunt de volgende code gebruiken om te testen of de API wordt ondersteund:
if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
// Monitor LoAFs
}
Link naar de langste INP-interactie
Het meest voor de hand liggende gebruiksscenario voor de Long Animation Frames API is het helpen diagnosticeren en oplossen van problemen met Interaction to Next Paint (INP) , en dat was een van de belangrijkste redenen waarom het Chrome-team deze API heeft ontwikkeld. Een goede INP is de plaats waar op alle interacties wordt gereageerd binnen 200 milliseconden of minder, vanaf de interactie totdat het frame is geverfd, en aangezien de Long Animation Frames API alle frames meet die 50 ms of langer duren, moeten de meeste problematische INP's LoAF-gegevens bevatten om u te helpen bij het diagnosticeren die interacties.
De "INP LoAF" is de LoAF die de INP-interactie omvat, zoals weergegeven in het volgende diagram:
![Voorbeelden van lange animatieframes op een pagina, waarbij de INP LoAF is gemarkeerd.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/loaf-inp.png?authuser=8&hl=nl)
In sommige gevallen is het mogelijk dat een INP-gebeurtenis twee LoAF's omvat, meestal als de interactie plaatsvindt nadat het frame is begonnen met het renderen van een deel van het vorige frame, en dus de gebeurtenishandler die het in het volgende frame heeft verwerkt:
![Voorbeelden van lange animatieframes op een pagina, waarbij de INP LoAF is gemarkeerd.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/loaf-inp-two-frames.png?authuser=8&hl=nl)
Het is zelfs mogelijk dat het in zeldzame omstandigheden meer dan twee LoAF's omvat.
Door de LoAF(s)-gegevens die verband houden met de INP-interactie te registreren, kunt u veel meer informatie over de INP-interactie verkrijgen om een diagnose te kunnen stellen. Dit is vooral handig om de invoervertraging te begrijpen: u kunt zien welke andere scripts in dat frame werden uitgevoerd.
Het kan ook nuttig zijn om de onverklaarbare verwerkingsduur en presentatievertraging te begrijpen als uw gebeurtenishandlers niet de waarden reproduceren die daarvoor worden gezien, omdat er mogelijk andere scripts voor uw gebruikers worden uitgevoerd die mogelijk niet zijn opgenomen in uw eigen tests.
Er is geen directe API om een INP-item te koppelen aan de bijbehorende LoAF-item(s) , hoewel het wel mogelijk is om dit in code te doen door de begin- en eindtijden van elk te vergelijken (zie het WhyNp- voorbeeldscript ).
De web-vitals
-bibliotheek bevat alle kruisende LoAF's in de eigenschap longAnimationFramesEntries
van de INP-attributie-interface vanaf v4.
Nadat u de LoAF-vermelding(en) heeft gekoppeld, kunt u informatie opnemen met INP-toeschrijving. Het scripts
object bevat een aantal van de meest waardevolle informatie, omdat het kan laten zien wat er nog meer in die frames draaide. Door die gegevens terug te sturen naar uw analyseservice, kunt u beter begrijpen waarom interacties traag waren.
Het rapporteren van LoAF's voor de INP-interactie is een goede manier om de meest urgente interactiviteitsproblemen op uw pagina te vinden. Elke gebruiker kan anders met uw pagina omgaan en als er voldoende INP-attributiegegevens zijn, worden er een aantal potentiële problemen opgenomen in de INP-attributiegegevens. Hiermee kunt u scripts op volume sorteren om te zien welke scripts correleren met trage INP.
Rapporteer meer lange animatiegegevens terug naar een analyse-eindpunt
Eén nadeel van alleen kijken naar de INP LoAF(s) is dat je mogelijk andere potentiële gebieden voor verbeteringen mist die toekomstige INP-problemen kunnen veroorzaken. Dit kan leiden tot het gevoel dat je achter je aan zit als je een INP-probleem oplost in de verwachting een enorme verbetering te zien, maar dan ontdekt dat de volgende langzaamste interactie slechts een klein beetje beter is dan dat, zodat je INP niet veel verbetert.
Dus in plaats van alleen maar naar de INP LoAF te kijken, wil je misschien alle LoAF's gedurende de levensduur van de pagina in overweging nemen:
![Een pagina met veel LoAF's, waarvan sommige plaatsvinden tijdens interacties, zelfs als dit niet de INP-interactie is.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/all-loafs.png?authuser=8&hl=nl)
Elke LoAF-vermelding bevat echter aanzienlijke gegevens, dus u wilt deze waarschijnlijk niet allemaal teruggeven. In plaats daarvan wilt u uw analyse beperken tot enkele LoAF's of bepaalde gegevens.
Enkele voorgestelde patronen zijn onder meer:
- Observeer lange animatieframes met interacties
- Observeer animatieframes langer dan een bepaalde drempel
- Observeer de slechtste lange animatieframes
- Identificeer algemene patronen in lange animatieframes
Welke van deze patronen voor u het beste werkt, hangt af van hoe ver u zich op uw optimalisatietraject bevindt en hoe vaak lange animatieframes voorkomen. Voor een site die nog nooit eerder is geoptimaliseerd voor responsiviteit, kunnen er veel LoAF's zijn die u wilt beperken tot alleen LoAF's met interacties, of een hoge drempel wilt instellen, of alleen naar de ergste wilt kijken. Terwijl u uw algemene problemen met het reactievermogen oplost, kunt u dit uitbreiden door u niet te beperken tot alleen interacties en door drempels te verlagen, of op zoek te gaan naar bepaalde patronen.
Observeer lange animatieframes met interacties
Om meer inzicht te krijgen dan alleen het lange INP-animatieframe, kunt u naar alle LoAF's met interacties kijken (die kunnen worden gedetecteerd door de aanwezigheid van een firstUIEventTimestamp
waarde).
Dit kan ook een eenvoudigere methode zijn om INP LoAF's te monitoren in plaats van te proberen de twee met elkaar in verband te brengen, wat complexer kan zijn. In de meeste gevallen omvat dit de INP LoAF voor een bepaald bezoek, en in zeldzame gevallen waarin dit niet het geval is, komen er nog steeds lange interacties naar voren die belangrijk zijn om op te lossen, omdat dit de INP-interactie voor andere gebruikers kan zijn.
De volgende code registreert alle LoAF-vermeldingen van meer dan 150 milliseconden waarbij een interactie plaatsvond tijdens het frame. De 150 is hier gekozen omdat deze iets minder is dan de "goede" INP-drempel van 200 milliseconden. Afhankelijk van uw behoeften kunt u een hogere of lagere waarde kiezen.
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS &&
entry.firstUIEventTimestamp > 0
) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Observeer animatieframes langer dan een bepaalde drempel
Een andere strategie zou zijn om alle LoAF's te monitoren en degenen die groter zijn dan een bepaalde drempel terug te sturen naar een analyse-eindpunt voor latere analyse:
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Omdat de lange animatieframe-items behoorlijk groot kunnen zijn, moeten ontwikkelaars beslissen welke gegevens uit het item naar Analytics moeten worden gestuurd. Bijvoorbeeld de samenvattingstijden van de invoer en misschien de scriptnamen, of een andere minimale reeks andere contextuele gegevens die mogelijk noodzakelijk worden geacht.
Observeer de slechtste lange animatieframes
In plaats van een vaste drempel te hebben, willen sites mogelijk gegevens verzamelen over het langste animatieframe (of de langste animatieframes) om de hoeveelheid gegevens die moet worden beaconed te verminderen. Dus ongeacht hoeveel lange animatieframes een pagina ervaart, worden alleen gegevens voor de slechtste, vijf of hoeveel lange animatieframes absoluut noodzakelijk zijn teruggevonden.
MAX_LOAFS_TO_CONSIDER = 10;
let longestBlockingLoAFs = [];
const observer = new PerformanceObserver(list => {
longestBlockingLoAFs = longestBlockingLoAFs.concat(list.getEntries()).sort(
(a, b) => b.blockingDuration - a.blockingDuration
).slice(0, MAX_LOAFS_TO_CONSIDER);
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Deze strategieën kunnen ook worden gecombineerd: kijk alleen naar de tien slechtste LoAF's, met interacties langer dan 150 milliseconden.
Op het juiste moment ( idealiter tijdens de visibilitychange
) keert u terug naar analyses. Voor lokaal testen kunt u periodiek console.table
gebruiken:
console.table(longestBlockingLoAFs);
Identificeer algemene patronen in lange animatieframes
Een alternatieve strategie zou zijn om te kijken naar veelgebruikte scripts die het meest voorkomen in lange animatieframe-items. Gegevens kunnen worden teruggekoppeld op script- en karakterpositieniveau om recidivisten te identificeren.
Dit kan met name goed werken voor aanpasbare platforms waar thema's of plug-ins die prestatieproblemen veroorzaken op een aantal sites kunnen worden geïdentificeerd.
De uitvoeringstijd van veelgebruikte scripts (of de oorsprong van derden) in lange animatieframes kan worden samengevat en gerapporteerd om gemeenschappelijke bijdragers aan lange animatieframes op een site of een verzameling sites te identificeren. Als u bijvoorbeeld naar URL's wilt kijken:
const observer = new PerformanceObserver(list => {
const allScripts = list.getEntries().flatMap(entry => entry.scripts);
const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
const scriptsBySource= scriptSource.map(sourceURL => ([sourceURL,
allScripts.filter(script => script.sourceURL === sourceURL)
]));
const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
sourceURL,
count: scripts.length,
totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
}));
processedScripts.sort((a, b) => b.totalDuration - a.totalDuration);
// Example here logs to console, but could also report back to analytics
console.table(processedScripts);
});
observer.observe({type: 'long-animation-frame', buffered: true});
En een voorbeeld van deze uitvoer is:
(index) | sourceURL | count | totalDuration |
---|---|---|---|
0 | 'https://example.consent.com/consent.js' | 1 | 840 |
1 | 'https://example.com/js/analytics.js' | 7 | 628 |
2 | 'https://example.chatapp.com/web-chat.js' | 1 | 5 |
Gebruik de Long Animation Frames API in tooling
De API maakt ook aanvullende ontwikkelaarstools mogelijk voor lokale foutopsporing. Hoewel sommige tools zoals Lighthouse en Chrome DevTools veel van deze gegevens hebben kunnen verzamelen met behulp van traceringsdetails op een lager niveau, zou het hebben van deze API op een hoger niveau ervoor kunnen zorgen dat andere tools toegang krijgen tot deze gegevens.
Bekijk gegevens van lange animatieframes in DevTools
U kunt lange animatieframes in DevTools weergeven met behulp van de performance.measure()
API, die vervolgens worden weergegeven in de DevTools-gebruikerstimingstrack in prestatiesporen om aan te geven waar u zich op moet richten voor prestatieverbeteringen:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
performance.measure('LoAF', {
start: entry.startTime,
end: entry.startTime + entry.duration,
});
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Op de langere termijn zal het waarschijnlijk in DevTools zelf worden opgenomen, maar dankzij het vorige codefragment kan het daar in de tussentijd worden weergegeven.
Gebruik lange animatieframegegevens in andere ontwikkelaarstools
De Web Vitals-extensie heeft de waarde laten zien van het loggen van samenvattende foutopsporingsinformatie om prestatieproblemen te diagnosticeren.
Er worden nu ook lange animatieframegegevens weergegeven voor elke INP-callback en elke interactie:
![Registratie van de Web Vitals Extensieconsole.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/loaf-web-vitals-extension.png?authuser=8&hl=nl)
Gebruik lange animatieframegegevens in geautomatiseerde testtools
Op vergelijkbare wijze kunnen geautomatiseerde testtools in CI/CD-pijplijnen details over potentiële prestatieproblemen naar boven halen door lange animatieframes te meten terwijl verschillende testsuites worden uitgevoerd.
Veelgestelde vragen
Enkele van de veelgestelde vragen over deze API zijn:
Waarom niet gewoon de Long Tasks API uitbreiden of herhalen?
Dit is een alternatieve kijk op het rapporteren van een vergelijkbare – maar uiteindelijk andere – meting van potentiële problemen met het reactievermogen. Het is belangrijk om ervoor te zorgen dat sites die afhankelijk zijn van de bestaande Long Tasks API blijven functioneren om te voorkomen dat bestaande gebruiksscenario's worden verstoord.
Hoewel de Long Tasks API kan profiteren van enkele kenmerken van LoAF (zoals een beter attributiemodel), zijn wij van mening dat het focussen op frames in plaats van taken veel voordelen biedt die dit een fundamenteel andere API maken dan de bestaande Long Tasks API.
Waarom heb ik geen scriptvermeldingen?
Dit kan erop wijzen dat het lange animatieframe niet te wijten was aan JavaScipt, maar aan het grote renderwerk.
Dit kan ook gebeuren wanneer het lange animatieframe te wijten is aan JavaScript, maar waarbij de scripttoeschrijving om verschillende privacyredenen niet kan worden geleverd, zoals eerder vermeld (voornamelijk omdat JavaScript geen eigendom is van de pagina).
Waarom heb ik scriptvermeldingen maar geen of beperkte broninformatie?
Dit kan verschillende redenen hebben, waaronder het ontbreken van een goede bron om naar te verwijzen .
Scriptinformatie zal ook beperkt zijn voor no-cors cross-origin
, hoewel dit kan worden opgelost door die scripts op te halen met behulp van CORS door crossOrigin = "anonymous"
toe te voegen aan de <script>
-aanroep.
Bijvoorbeeld het standaard Google Tag Manager-script dat aan de pagina moet worden toegevoegd:
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->
Kan worden uitgebreid door j.crossOrigin = "anonymous"
toe te voegen, zodat volledige attributiegegevens voor GTM kunnen worden verstrekt
Zal dit de Long Tasks API vervangen?
Hoewel we van mening zijn dat de Long Animation Frames API een betere, completere API is voor het meten van lange taken, zijn er op dit moment geen plannen om de Long Tasks API te beëindigen.
Feedback gewenst
Feedback kan worden gegeven op de GitHub Issues-lijst , of bugs in de Chrome-implementatie van de API kunnen worden opgeslagen in de issue tracker van Chrome .
Conclusie
De Long Animation Frames API is een opwindende nieuwe API met veel potentiële voordelen ten opzichte van de vorige Long Tasks API.
Het blijkt een belangrijk instrument te zijn voor het aanpakken van responsiviteitsproblemen, zoals gemeten door INP. INP is een uitdagende statistiek om te optimaliseren en deze API is een manier waarop het Chrome-team het identificeren en aanpakken van problemen voor ontwikkelaars eenvoudiger wil maken.
De reikwijdte van de Long Animation Frames API reikt echter verder dan alleen INP en kan helpen bij het identificeren van andere oorzaken van trage updates die de algehele soepelheid van de gebruikerservaring van een website kunnen beïnvloeden.