Runtimeprestaties zijn hoe uw pagina presteert wanneer deze actief is, en niet wanneer deze wordt geladen. In deze zelfstudie leert u hoe u het prestatiepaneel van Chrome DevTools gebruikt om de runtimeprestaties te analyseren. In termen van het RAIL -model zijn de vaardigheden die u in deze zelfstudie leert nuttig voor het analyseren van de respons-, animatie- en inactieve fasen van uw pagina.
Ga aan de slag
In deze zelfstudie gebruiken we het prestatiepaneel om een prestatieknelpunt op een livepagina te vinden. Om te beginnen:
- Open Google Chrome in de incognitomodus . De incognitomodus zorgt ervoor dat Chrome schoon werkt. Als u bijvoorbeeld veel extensies heeft geïnstalleerd, kunnen die extensies ruis veroorzaken in uw prestatiemetingen.
Laad de volgende pagina in uw incognitovenster. Dit is de demo die u gaat profileren. Op de pagina ziet u een aantal kleine blauwe vierkantjes die op en neer bewegen.
https://googlechrome.github.io/devtools-samples/jank/
Druk op Command + Option + I (Mac) of Control + Shift + I (Windows, Linux) om DevTools te openen.
Simuleer een mobiele CPU
Mobiele apparaten hebben veel minder CPU-kracht dan desktops en laptops. Wanneer u een pagina profileert, kunt u CPU-throttling gebruiken om te simuleren hoe uw pagina presteert op mobiele apparaten.
- Klik in DevTools op het tabblad Prestaties .
- Zorg ervoor dat het selectievakje Screenshots is ingeschakeld.
- Klik op voor opname-instellingen . DevTools onthult instellingen die verband houden met de manier waarop prestatiestatistieken worden vastgelegd.
Voor CPU selecteert u 4x vertraging . DevTools beperkt uw CPU zodat deze 4 keer langzamer is dan normaal.
Zet de demo op
Het is moeilijk om een runtime prestatiedemo te maken die consistent werkt voor alle lezers van deze website. In deze sectie kunt u de demo aanpassen om ervoor te zorgen dat uw ervaring relatief consistent is met de schermafbeeldingen en beschrijvingen die u in deze zelfstudie ziet, ongeacht uw specifieke configuratie.
- Blijf op 10 toevoegen klikken totdat de blauwe vierkantjes merkbaar langzamer bewegen dan voorheen. Op een geavanceerde machine kan dit ongeveer 20 klikken duren.
Klik op Optimaliseren . De blauwe vierkanten moeten sneller en soepeler bewegen.
Klik op Optimaliseren ongedaan maken . De blauwe vierkanten bewegen langzamer en weer met meer ruk.
Registreer runtime-prestaties
Wanneer u de geoptimaliseerde versie van de pagina hebt uitgevoerd, bewegen de blauwe vierkanten sneller. Waarom is dat? Beide versies zouden elk vierkant dezelfde hoeveelheid ruimte in dezelfde tijd moeten verplaatsen. Maak een opname in het deelvenster Prestaties om te leren hoe u het prestatieknelpunt in de niet-geoptimaliseerde versie kunt detecteren.
Klik in DevTools op Opnemen
. DevTools legt prestatiestatistieken vast terwijl de pagina wordt uitgevoerd.Wacht een paar seconden.
Klik op Stoppen . DevTools stopt met opnemen, verwerkt de gegevens en geeft vervolgens de resultaten weer in het paneel Prestaties .
Wauw, dat is een overweldigende hoeveelheid gegevens. Maak je geen zorgen, het zal binnenkort logischer worden.
Analyseer de resultaten
Zodra u een prestatie-opname heeft, kunt u analyseren hoe slecht de prestaties van de pagina zijn en de oorzaak(en) achterhalen.
Analyseer frames per seconde
De belangrijkste maatstaf voor het meten van de prestaties van elke animatie zijn frames per seconde (FPS). Gebruikers zijn blij als animaties op 60 FPS draaien.
Kijk naar het FPS- diagram. Wanneer u een rode balk boven FPS ziet, betekent dit dat de framerate zo laag is gedaald dat dit waarschijnlijk de gebruikerservaring schaadt.
Onder het FPS -diagram ziet u het CPU- diagram. De kleuren in het CPU- diagram komen overeen met de kleuren op het tabblad Samenvatting onder aan het paneel Prestaties . Het feit dat de CPU- grafiek vol kleur is, betekent dat de CPU tijdens de opname maximaal is benut. Telkens wanneer u ziet dat de CPU gedurende langere perioden maximaal wordt gebruikt, is dit een signaal 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 wordt scrubbing genoemd en is handig voor het handmatig analyseren van de voortgang van animaties.
Beweeg in het gedeelte Frames uw muis over een van de groene vierkanten. DevTools toont u de FPS voor dat specifieke frame. Elk frame ligt waarschijnlijk ruim onder het doel van 60 FPS.
Bij deze demo is het natuurlijk vrij duidelijk dat de pagina niet goed presteert. Maar in echte scenario's is het misschien niet zo duidelijk, dus het is handig om al deze tools te hebben om metingen uit te voeren.
Bonus: open de FPS-meter
Een ander handig hulpmiddel is de FPS-meter , die realtime schattingen geeft van de FPS terwijl de pagina wordt uitgevoerd.
- Druk op Command + Shift + P (Mac) of Control + Shift + P (Windows, Linux) om het Commandomenu te openen.
- Begin met het typen van
Rendering
in het Commandomenu en selecteer Rendering weergeven . Schakel Renderingstatistieken weergeven in het deelvenster Rendering in. Er verschijnt een nieuwe overlay in de rechterbovenhoek van uw viewport.
Schakel de FPS-meter uit en druk op Escape om het Rendering- paneel te sluiten. Je zult het niet gebruiken in deze zelfstudie.
Zoek het knelpunt
Nu je hebt gemeten en geverifieerd dat de animatie niet goed presteert, is de volgende vraag die je moet beantwoorden: waarom?
Let op het tabblad Samenvatting . Als er geen evenementen zijn geselecteerd, toont dit tabblad een overzicht van de activiteiten. De pagina besteedde het grootste deel van de tijd aan weergave. Omdat prestatie de kunst is om minder werk te doen, is het uw doel om de hoeveelheid tijd die u aan renderingwerk besteedt, te verminderen.
Vouw de sectie Hoofd uit. DevTools toont u een vlamdiagram van de activiteit op de hoofdlijn, in de loop van de tijd. De x-as vertegenwoordigt de opname in de loop van de tijd. Elke balk vertegenwoordigt een gebeurtenis. Een bredere balk betekent dat het evenement langer duurde. De y-as vertegenwoordigt de call-stack. Als je gebeurtenissen op elkaar gestapeld ziet, betekent dit dat de hogere gebeurtenissen de lagere gebeurtenissen veroorzaakten.
Er staan veel gegevens in de opname. Zoom in op een enkele Animation Frame Fired -gebeurtenis door te klikken, vast te houden en met de muis over het overzicht te slepen. Dit is de sectie met de FPS- , CPU- en NET -grafieken. Op de tabbladen Hoofdsectie en Samenvatting wordt alleen informatie weergegeven voor het geselecteerde gedeelte van de opname.
Let op de rode driehoek in de rechterbovenhoek van de taak- en lay-outgebeurtenissen. Wanneer u een rode driehoek ziet, is dit een waarschuwing dat er mogelijk een probleem is met deze gebeurtenis. Een rode driehoek bij een taak betekent dat het een lange taak was.
Klik op de gebeurtenis Animation Frame Fired . Op het tabblad Samenvatting wordt nu informatie over die gebeurtenis weergegeven. Als u op de link naast Geïnitieerd door klikt, markeert DevTools de gebeurtenis die de Animation Frame Fired -gebeurtenis heeft geïnitieerd. Let ook op de app.update@-link . Als u hierop klikt, springt u naar de relevante regel in de broncode.
Onder het app.update- evenement bevinden zich een aantal paarse evenementen. Als ze breder waren, lijkt het alsof ze allemaal een rode driehoek hebben. Klik nu op een van de paarse Layout- gebeurtenissen. DevTools biedt meer informatie over de gebeurtenis op het tabblad Samenvatting . Er is inderdaad een waarschuwing over gedwongen terugvloeiingen (een ander woord voor lay-out).
Klik op het tabblad Samenvatting op de link naast app.update @ onder Invalidatie van eerste lay-out . DevTools brengt u naar de coderegel die de lay-out heeft geforceerd.
Pff! Dat was veel om in te verwerken, maar je hebt nu een solide basis in de basisworkflow voor het analyseren van runtimeprestaties. Goed gedaan.
Bonus: analyseer de geoptimaliseerde versie
Gebruik de workflows en tools die u zojuist hebt geleerd en klik op Optimaliseren in de demo om de geoptimaliseerde code in te schakelen, maak nog een prestatieregistratie en analyseer vervolgens de resultaten. Van de verbeterde framerate tot de vermindering van gebeurtenissen in de vlammengrafiek van het hoofdgedeelte , je kunt zien dat de geoptimaliseerde versie van de app veel minder werk doet, wat resulteert in betere prestaties.
Volgende stappen
De basis voor het begrijpen van prestaties is het RAIL-model. Dit model leert u welke prestatiestatistieken het belangrijkst zijn voor uw gebruikers. Zie Prestaties meten met het RAIL-model voor meer informatie.
Om meer vertrouwd te raken met het Performance-paneel: oefening baart kunst. Probeer uw eigen pagina's te profileren en de resultaten te analyseren. Als u vragen heeft over uw resultaten, opent u een Stack Overflow-vraag met de tag google-chrome-devtools
. Voeg indien mogelijk schermafbeeldingen of links naar reproduceerbare pagina's toe.
Om een expert te worden in runtime-prestaties, moet je leren hoe de browser HTML, CSS en JS vertaalt naar pixels op een scherm. De beste plaats om te beginnen is het Rendering Performance Overview . The Anatomy Of A Frame duikt nog dieper in.
Ten slotte zijn er veel manieren om de runtimeprestaties te verbeteren. Deze tutorial concentreerde zich op één specifiek knelpunt in de animatie om u een gerichte rondleiding door het paneel Prestaties te geven, maar dit is slechts een van de vele knelpunten die u tegen kunt komen. De rest van de Rendering Performance-serie bevat veel goede tips voor het verbeteren van verschillende aspecten van runtime-prestaties, zoals:
- Optimalisatie van JS-uitvoering
- Verminder de reikwijdte en complexiteit van stijlberekeningen
- Vermijd grote, complexe lay-outs en het geselen van de lay-out
- Vereenvoudig de verfcomplexiteit en verminder verfgebieden
- Houd u aan de eigenschappen die alleen voor de componist gelden en beheer het aantal lagen
- Debounce uw invoerbehandelaars