hoe de Runtime-prestaties te analyseren: Google DevTools

monitoring van de SPOORWEGPRESTATIES werd voortgezet.

Runtime performance is hoe uw pagina presteert wanneer deze draait, in tegenstelling tot het laden. Chrome DevTools zijn ideaal voor het analyseren van uw site voor de respons, animatie, en inactieve tijden van uw RAIL model prestaties. Als u niet weet wat RAIL is, raad ik afrekenen mijn vorige artikel voordat vooruit.

nu u begrijpt wat RAIL is, laten we er in duiken!

aan de slag

eerst leren hoe u het Performance panel van DevTools kunt gebruiken. We zullen dit paneel gebruiken om prestatieknelpunten op elke webpagina te identificeren.

Google docs biedt ons een handige demo-webpagina voor het gebruik van de performance-functie in DevTools. Laten we dat openen in Chrome in incognitomodus. Dit stelt ons in staat om een schone lei te hebben met dingen zoals cookies die onze site zouden kunnen vertragen, maar niet het belangrijkste prestatieprobleem zijn. Laten we nu openen DevTools (Mac: Command + Option + I of Windows / Linux: Control + Shift + I) je zou zoiets als het volgende moeten zien:

Dit is de site die we zullen profileren met DevTools Performance panel.

Wat is profileren?

Profileringshulpmiddelen worden gebruikt bij het uitvoeren van code om te bepalen welke processen de meeste tijd in beslag nemen. Profiling tools worden meestal alleen gebruikt als er een prestatieprobleem is geïdentificeerd in het systeem — als de server er lang over doet om te reageren en u geen bronprobleem kunt identificeren (e.g. gebrek aan geheugen of slecht geconfigureerde vuilnisverbinding), kan profilering uw volgende keuze van strategie.

terug naar de demo

zoals besproken in mijn vorige artikel over RAIL, hebben verschillende apparaten verschillende CPU-vermogen, wat de prestaties van een website op dat apparaat beïnvloedt. Vanwege de lagere CPU kracht van een mobiel apparaat, moeten we de pagina die we profileren op een lagere CPU simuleren met iets genaamd CPU Throttling.

Wat is CPU-Throttling?

in wezen vertraagt CPU-Throttling de verwerkingssnelheid van uw computer. Ook bekend als, dynamische frequentie schalen, het past de kloksnelheid van de CPU. Het wordt vaak gebruikt om de computer automatisch te vertragen wanneer het mogelijk is om minder energie te gebruiken en de batterij te besparen, vooral in laptops. CPU throttling kan ook handmatig worden ingesteld om het systeem stiller te maken, omdat de ventilator dan langzamer kan draaien.

dus, laten we onze demo gas geven. In DevTools:

• klik op het tabblad Prestaties.
• zorg ervoor dat het selectievakje schermafbeeldingen is ingeschakeld.
• klik op Capture Settings (het instellingenpictogram rechts onder de exit-knop). DevTools zal de instellingen met betrekking tot hoe het vangt prestaties metrics onthullen.
• voor CPU, selecteer 4x vertraging. DevTools throttles uw CPU, zodat het is 2 keer langzamer dan normaal.

nu onze demo is beperkt, kunnen we de prestaties degradatie zien als we blauwe vierkanten toevoegen aan de pagina. Als we de pagina optimaliseren, lopen de blauwe blokken soepel, maar als we de pagina niet optimaliseren, kunnen de blokken langzamer en Janker bewegen. We kunnen nu beginnen met het monitoren van de prestaties van de demo om de prestatie-bottleneck te identificeren die alles vertraagt.

Runtime-prestaties opnemen

in de linkerbovenhoek van het tabblad Prestaties van DevTools, klikt u op de cirkel” opnemen ” om te beginnen met het bijhouden van de prestatiegegevens van de demo.

wacht een paar seconden voor de tracker om wat gegevens vast te leggen. Klik vervolgens op Stoppen. DevTools zal stoppen met opnemen, verwerken van de gegevens, dan zal het de resultaten weer te geven op de prestaties Paneel. Laten we eens kijken naar de resultaten.

het analyseren van de gegevens

nu we alle gegevens hebben, kunnen we de oorzaken van de prestatievertraging op onze demo lokaliseren.

frames per seconde analyseren

de belangrijkste maatstaf voor het meten van de prestaties van animaties is frames per seconde (FPS). Zoals ik behandeld in mijn vorige artikel over RAIL, gebruikers zijn blij wanneer animaties draaien op 60 FPS.

• Kijk naar de FPS-grafiek. Wanneer u een rode balk boven FPS ziet, betekent dit dat de frame-rate zo laag is gedaald dat het waarschijnlijk de gebruikerservaring schaadt. In het algemeen geldt dat hoe hoger de groene balk, hoe hoger de FPS.

• onder de FPS grafiek zie je de CPU grafiek. De kleuren in het CPU-diagram komen overeen met de kleuren in het tabblad Samenvatting, onderaan het paneel prestaties. Het feit dat de CPU-grafiek vol kleur is betekent dat de CPU maximaal was tijdens de opname. Wanneer u ziet dat de CPU maxed out voor lange periodes, het is een cue om manieren te vinden om minder werk te doen.

• Beweeg uw muis over de FPS, CPU, of NET grafieken. DevTools toont een screenshot van de pagina op dat moment. Beweeg uw muis naar links en rechts om de opname opnieuw af te spelen. Dit heet scrubben, en het is handig voor het handmatig analyseren van de progressie van animaties.

Wat is schrobben?

scrubben verwijst naar handmatig door een animatie scrollen, vooruit en achteruit, een voorbeeld van uw animatie bekijken om frames aan uw animatie te controleren, te corrigeren of toe te voegen.

• in de Frames sectie, beweeg je muis over een van de groene vierkantjes. DevTools toont je de FPS voor dat specifieke frame. Elk frame ligt waarschijnlijk ver onder het doel van 60 FPS.

Open de FPS-meter

een ander handig hulpmiddel is de FPS-meter, die real-time schattingen voor FPS biedt terwijl de pagina wordt uitgevoerd.

1. druk op Command + Shift + P (Mac) of Control+Shift+P (Windows, Linux) om het menu opdracht te openen.
2. typ Rendering in het Opdrachtmenu en selecteer Rendering tonen.
3. schakel FPS-Meter in op het tabblad Rendering. Een nieuwe overlay verschijnt in de rechterbovenhoek van uw viewport.

nu je hebt gemeten en geverifieerd dat de animatie niet goed presteert, is de volgende vraag te beantwoorden: waarom?

• Noteer het tabblad Samenvatting. Wanneer er geen activiteiten zijn geselecteerd, toont dit tabblad u een uitsplitsing van de activiteit. De pagina bracht het grootste deel van zijn tijd renderen. Aangezien prestaties de kunst is om minder werk te doen, is het je doel om de hoeveelheid tijd die je besteedt aan het renderen van werk te verminderen.

• Breid de hoofdsectie uit. DevTools toont u een vlamkaart van activiteit op de hoofddraad, na verloop van tijd. De x-as vertegenwoordigt de opname, na verloop van tijd. Elke balk vertegenwoordigt een gebeurtenis. Een bredere bar betekent dat het evenement langer duurde. De y-as vertegenwoordigt de call stack. Wanneer je gebeurtenissen op elkaar ziet gestapeld, betekent dit dat de bovenste gebeurtenissen de lagere gebeurtenissen veroorzaakten.

• er zit veel data in de opname. Zoom in op een enkele animatie Frame vuurde gebeurtenis door te klikken, ingedrukt, en slepen met de muis over het overzicht, dat is de sectie die de FPS, CPU, en NET grafieken bevat. De hoofdsectie en het tabblad Samenvatting tonen alleen informatie voor het geselecteerde gedeelte van de opname.

• let op de rode driehoek in de rechterbovenhoek van de animatie Frame gestuurde gebeurtenis. Wanneer je een rode driehoek ziet, is het een waarschuwing dat er een probleem kan zijn met betrekking tot deze gebeurtenis.
• klik op de animatie Frame gestookte gebeurtenis. Het tabblad Samenvatting toont u nu informatie over die gebeurtenis. Let op de reveal link. Als u hierop klikt, wordt door DevTools de gebeurtenis gemarkeerd die het Animatieframe is gestart. Let ook op de app.js: 95 link. Als u hierop klikt, springt u naar de relevante regel in de broncode.

• onder de app.update event, er zijn een hoop paarse evenementen. Als ze breder waren, lijkt het erop dat elk van hen een rode driehoek zou kunnen hebben. Klik nu op een van de paarse opmaakgebeurtenissen. DevTools geeft meer informatie over de gebeurtenis in het tabblad Samenvatting. Inderdaad, er is een waarschuwing over gedwongen reflows (een ander woord voor lay-out).
• klik op het tabblad Samenvatting op de app.js: 71 link onder lay-out geforceerd. DevTools neemt je mee naar de regel code die de lay-out forceerde.

volgende stappen

de basis voor het begrijpen van prestaties is het SPOORMODEL. Dit model leert u de prestatiemetingen die het belangrijkst zijn voor uw gebruikers. Zie prestaties meten met het RAIL-Model voor meer informatie.

zoals met alles, om meer comfortabel met de prestaties panel, oefening maakt perfect. Probeer uw eigen pagina ‘ s te profileren en de resultaten te analyseren. Als u vragen heeft over uw resultaten, gebruik dan de kennis van het internet en open een Stack Overflow vraag met google-chrome-devtools. Inclusief screenshots of links naar reproduceerbare pagina ‘ s, indien mogelijk.

om de runtime-prestaties echt onder de knie te krijgen, moet u leren hoe de browser HTML, CSS en JS vertaalt naar pixels op een scherm. De beste plaats om te beginnen is het Rendering Performance overzicht. De anatomie van een Frame duikt nog meer in detail.

Last, er zijn vele manieren om de runtime prestaties te verbeteren. Deze tutorial gericht op een bepaalde animatie bottleneck om u een gerichte rondleiding door de prestaties panel, maar het is slechts een van de vele knelpunten die u kunt tegenkomen. Er zijn verschillende andere aspecten van runtime performance. Bekijk de volgende links om goede tips te krijgen over het verbeteren van runtime prestaties op elk niveau:

• het Optimaliseren van JS Uitvoering
• Verminderen van De Omvang En Complexiteit Van Stijl Berekeningen
• Vermijd Grote, Complexe lay-Outs En Lay-out Dorsen
• Vereenvoudigen Verf Complexiteit En de Verf Gebieden
• Stick Te Compositor-Alleen de Eigenschappen En Beheren Laag Count
• Ontdendering van Uw Input Handlers