Webframeworks zoals Angular, React, Vue en Svelte maken het eenvoudiger om complexe webapplicaties op grote schaal te schrijven en onderhouden.
Deze frameworks introduceren echter een abstractielaag bovenop het applicatiemodel van de browser. De code die ontwikkelaars met deze abstracties schrijven, wordt uiteindelijk vaak omgezet in onleesbare, geminimaliseerde en gebundelde code. Het kan dan ook een uitdaging zijn voor ontwikkelaars om de kracht van de DevTools volledig te benutten om deze apps te debuggen en te profileren.
Wanneer u bijvoorbeeld een Angular-applicatie profileert met het paneel Prestaties in DevTools, ziet u het volgende:
Met de informatie die op deze manier wordt gepresenteerd, kan het lastig zijn om te achterhalen welke prestatieknelpunten er in je codebase bestaan. De context van de frameworkconstructies ontbreekt immers en een groot deel van de getoonde informatie bestaat uit geminimaliseerde code. Het is ook lastig om onderscheid te maken tussen de activiteit die direct verband houdt met de code die je hebt geschreven, de interne werking van het framework en andere code van derden die mogelijk op dezelfde pagina draait.
Een veelvoorkomende motivatie voor framework- en abstractieontwikkelaars is het implementeren van hun eigen DevTools-extensies die profileringsgegevens presenteren in termen van de frameworkconcepten. Deze tools zijn erg handig bij het debuggen en profileren van applicaties die met een specifiek framework zijn gebouwd. Vaak zult u echter de frameworkgegevens in de profiler van uw framework moeten correleren met de runtime-informatie van de browser in het DevTools Performance- paneel. Het afzonderlijk presenteren van deze twee gegevensbronnen in onafhankelijke tools maakt het moeilijk om knelpunten te identificeren en op te lossen, vooral naarmate de applicatie complexer wordt. Hier is een voorbeeld van een profielvisualisatie in Angular DevTools Profiler:
In een ideale wereld zouden ontwikkelaars over een weergave beschikken waarin de twee gegevensbronnen samen in dezelfde context worden weergegeven, gekoppeld aan dezelfde tijdlijn.
Daarom hebben we samengewerkt met het Angular-team om Angular-runtimegegevens rechtstreeks in het Performance- paneel te integreren met behulp van de Performance Panel Extensibility API . In dit bericht bekijken we wat de API kan en hoe deze in het Angular-framework is gebruikt om dit te bereiken. De implementatie kan dienen als voorbeeld voor andere frameworks en abstracties die hun ontwikkelaarservaring willen verbeteren door hun eigen tools te instrumenteren en ontwikkelaars te helpen bij het gebruik van Chrome DevTools.
Wat is de API voor uitbreidbaarheid van het Prestatiepaneel?
Met de API kunt u uw eigen timinggegevens toevoegen aan de trace van het Prestatiepaneel , binnen dezelfde tijdlijn als de rest van de browsergegevens. Er zijn twee mechanismen waarmee u dit kunt doen:
- De API voor gebruikerstiming
- De
console.timeStampAPI
De API voor gebruikerstiming
U kunt performance.mark en performance.measure gebruiken om de vermeldingen als volgt toe te voegen:
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
performance.measure("Component rendering", {
start: renderStart,
detail: {
devtools: {
dataType: "track-entry",
track: "Components",
color: "secondary",
properties: [
["Render reason", "Props changed"],
["Priority", "low"]
],
}
}
});
Dit resulteert erin dat het Componenten -spoor aan uw tijdlijn wordt toegevoegd met de meting:
Met deze API kunt u de items toevoegen aan de Prestatietijdlijnbuffer en ze tegelijkertijd weergeven in de gebruikersinterface van het Prestatiepaneel van DevTools.
Meer informatie over deze API en het devtools -object vindt u in de docs .
De console.timeStamp API
Deze API is een lichtgewicht alternatief voor de User Timing API. Met hetzelfde voorbeeld als hiervoor zou je het volgende kunnen doen:
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
console.timeStamp(
"Component rendering",
/* start time */ renderStart,
/* end time (current time) */ undefined,
/* track name */ "Components",
/* track group name */ undefined,
/* color */ "secondary"
);
Deze API biedt een krachtige methode voor het instrumenteren van applicaties: in tegenstelling tot het alternatief van de User Timing API creëert deze geen gebufferde data. Deze API voegt uitsluitend data toe aan het paneel **Prestaties** in DevTools. Dit betekent dat wanneer DevTools geen trace registreert, de aanroepen van de API geen ops (ze doen niets), wat de API aanzienlijk sneller en geschikter maakt voor prestatiegevoelige hot paths. De keuze om positionele argumenten te gebruiken in plaats van een object met alle aanpassingsparameters dient ook om de API zo licht mogelijk te houden.
Meer informatie over het gebruik van console.timeStamp om het paneel Prestaties uit te breiden en de parameters die u kunt doorgeven, vindt u in de documentatie .
Hoe Angular de DevTools-extensibiliteits-API heeft geïntegreerd
We bekijken hoe het Angular-team de extensibility API heeft gebruikt om te integreren met Chrome DevTools.
Vermijd overhead met console.timestamp
Angular's instrumentatie met de API voor uitbreidbaarheid van het Performance- paneel is beschikbaar vanaf versie 20. Het gewenste granulariteitsniveau voor prestatiegegevens in DevTools vereist een snelle API. Daarom koos de pull-request ( 60217 ) die de instrumentatie toevoegde voor de console.timeStamp API. Dit voorkomt dat de runtimeprestaties van de applicatie worden beïnvloed door de potentiële overhead van de profilerings-API.
Geïnstrumenteerde gegevens
Om een goed beeld te krijgen van welke Angular-code wordt uitgevoerd en waarom deze überhaupt wordt uitgevoerd, worden meerdere onderdelen van de opstart- en rendering-pipelines geïnstrumenteerd, waaronder:
- Toepassings- en component-bootstrapping.
- Maken en bijwerken van componenten.
- Uitvoering van gebeurtenislisteners en levenscyclus-hooks.
- Veel andere (bijvoorbeeld het dynamisch aanmaken van componenten en het uitstellen van blokrendering).
Kleurcodering
Kleurcodering wordt gebruikt om de ontwikkelaar te laten weten in welke categorie een bepaalde meting valt. Zo zijn de kleuren die worden gebruikt voor de items die de uitvoering van door de ontwikkelaar geschreven TypeScript-code markeren, anders dan de kleuren die worden gebruikt voor code die door de Angular-compiler is geproduceerd.
In de onderstaande schermafbeelding ziet u hoe dit resulteert in toegangspunten (zoals wijzigingsdetectie en componentverwerking) in het blauw, gegenereerde code in het paars en TypeScript-code (zoals gebeurtenislisteners en hooks) in het groen.
Houd er rekening mee dat het kleurargument dat aan de API wordt doorgegeven geen CSS-kleurwaarde is, maar een semantisch token dat wordt toegewezen aan een kleur die overeenkomt met de gebruikersinterface van DevTools. De mogelijke waarden zijn primary , secondary en tertiary, met hun respectievelijke -dark en -light varianten, evenals een error .
Sporen
Op het moment van schrijven worden alle Angular runtime-gegevens toegevoegd aan dezelfde track (gelabeld als "🅰️ Angular"). Het is echter mogelijk om meerdere tracks aan de trace toe te voegen en zelfs om je tracks te groeperen. Bijvoorbeeld, gegeven de volgende aanroepen van de console.timeStamp API:
console.timeStamp("Component 1", componentStart1, componentEnd1, "Components", "Client", "primary");
console.timeStamp("Component 2", componentStart2, componentEnd2, "Components", "Client", "primary");
console.timeStamp("Hook 1", hookStart, hookEnd, "Hooks", "Client", "primary");
console.timeStamp("Fetch data base", fetchStart, fetchEnd, "Server", "primary");
U ziet dat de gegevens op de volgende manier in tracks zijn georganiseerd:
Het gebruik van aparte tracks kan bijvoorbeeld handig zijn bij asynchrone activiteiten, meerdere taken die parallel lopen of wanneer activiteitsgroepen zo verschillend zijn dat het de moeite waard is om ze in verschillende delen van de gebruikersinterface te scheiden.
Waarom dit belangrijk is voor Angular-ontwikkelaars
Het doel van deze directe integratie is om een intuïtievere en uitgebreidere prestatieanalyse-ervaring te bieden. Door de interne prestatiegegevens van Angular direct in het **Prestaties**-paneel weer te geven, krijgen ontwikkelaars:
- Verbeterde zichtbaarheid: Angular-specifieke prestatiegebeurtenissen, zoals componentrendering, detectiecycli voor wijzigingen en meer, worden zichtbaar in de bredere tijdlijn van de browser.
- Beter begrip: Dankzij contextrijke informatie over de interne processen van Angular kunt u prestatieknelpunten effectiever opsporen.
Integratie mogelijk maken
Het gebruik van de extensibility API is officieel beschikbaar in ontwikkelversies vanaf Angular versie 20. Om deze te activeren, moet u de globale util `ng.enableProfiling()` uitvoeren in uw app of in de DevTools-console. Zie voor meer informatie over de integratie de [Angular Docs]( https://angular.dev/best-practices/profiling-with-chrome-devtools )
Andere overwegingen
Enkele belangrijke overwegingen waarmee rekening moet worden gehouden.
Bronkaarten en geminimaliseerde code:
Bronkaarten zijn een veelgebruikt hulpmiddel dat de kloof tussen gebundelde/geminimaliseerde code en de door uzelf geschreven versie ervan moet overbruggen.
Zouden bronkaarten het probleem van geminimaliseerde code in gebundelde apps niet moeten oplossen?
Hoewel bronkaarten inderdaad nuttig zijn, lossen ze de uitdagingen bij het profileren van complexe geminimaliseerde webapps niet volledig op. Bronkaarten stellen DevTools in staat om de geminimaliseerde code terug te koppelen aan je oorspronkelijke broncode, wat debuggen eenvoudiger maakt. Alleen op bronkaarten vertrouwen voor prestatieanalyse kan echter nog steeds enkele beperkingen met zich meebrengen. Zo is het kiezen van de manier waarop de interne werking van het framework en de geschreven code visueel worden gescheiden, complex met alleen bronkaarten. De extensibility API biedt daarentegen de flexibiliteit om dit onderscheid te maken en het te presenteren op de manier die de ontwikkelaar het meest geschikt acht.
Chrome DevTools-extensies:
Chrome-extensies die gebruikmaken van de DevTools API zijn een veelgebruikt hulpmiddel om DevTools uit te breiden.
Zijn speciale profilers (bijvoorbeeld Chrome DevTools-extensies) nu overbodig of worden ze afgeraden nu deze API beschikbaar is?
Nee, deze API is niet bedoeld om de ontwikkeling van speciale profilers zoals Chrome DevTools-extensies te vervangen of te ontmoedigen. Deze kunnen nog steeds gespecialiseerde functies, visualisaties en workflows bieden die zijn afgestemd op specifieke behoeften. De API voor uitbreiding van het Prestatiepaneel is gericht op een naadloze integratie van aangepaste gegevens met de browservisualisaties in het Prestatiepaneel .
De weg vooruit
Het vooruitzicht van de uitbreidbaarheids-API.
Werk met meer frameworks en abstracties
We zijn enthousiast over andere frameworks en abstracties die de API gebruiken om de profileringservaring van hun ontwikkelaars te verbeteren. React heeft bijvoorbeeld een experimentele implementatie van de API voor hun framework geïmplementeerd. Deze instrumentatie brengt zowel client- en servercomponentrendering als React-scheduling-API-gegevens aan het licht. Lees meer hierover en hoe u het kunt inschakelen op de pagina van React .
Productie bouwt op
Een van de doelen van deze API is om samen te werken met frameworks en abstractieproviders in het algemeen om de instrumentatie in productieversies te implementeren en mogelijk te maken. Dit zou een grote impact kunnen hebben op de prestaties van apps die met deze abstracties worden ontwikkeld, omdat ontwikkelaars de applicatie kunnen profileren zoals hun gebruikers die ervaren. Wij zijn ervan overtuigd dat de console.timeStamp API dit mogelijk maakt, gezien de snelheid en lage overhead. Momenteel experimenteren frameworks echter nog met de API en onderzoeken ze welke soorten instrumentatie schaalbaarder en nuttiger zijn voor ontwikkelaars.