Het wordt steeds populairder om animaties te gebruiken op websites. Voor Frankwatching schreef ik een bijdrage over welke impact deze hebben op de gebruikservaring van de bezoeker. Een lage frame rate (beelden per seconde) kan er namelijk voor zorgen dat animaties er lelijk uit zien of dat scrollen niet goed werkt. Er zijn 5 elementen binnen de browser die onderdeel zijn van het tekenen van de pixels op het scherm en die direct invloed hebben op je frame rate. Om een optimale gebruikservaring te realiseren is het nuttig de impact van deze elementen te meten. In deze blog geef ik aan hoe je dit kunt doen en lees je hoe je met redelijk simpele aanpassingen aanzienlijke verbeteringen kunt realiseren.

Deze elementen binnen de browser zijn onderdeel van het tekenen van de pixels op het scherm en hebben direct invloed op je frame rate:

  • Javascript/CSS
  • Calculate styles
  • Layout
  • Paint
  • Compositing

Hoe kun je deze nu meten? Met behulp van debug-extensies in een browser, zoals Chrome developer tools, kunnen de metingen worden verricht om onderzoek te doen naar de beschreven onderdelen. Hieronder staat een voorbeeld waarin een animatie wordt gemeten. Deze animatie (een bewegende bol) beweegt over het scherm door CSS-regels toe te passen die ervoor zorgen dat de ‘top’ en ‘bottom’ wijzigen.

(klik voor vergroten)

Aan de duur van de frames(+- 35 ms) zien we al dat dit een behoorlijk intensieve animatie is geworden. 35 ms per frame is namelijk nog geen 30 FPS, wat dus minder dan de helft van de beoogde 60 FPS is. Onder in de event log zien we ook dat bijna alle onderdelen van het ‘pixel to screen pad’ worden doorlopen.

Dit is de CSS-regel die hiervoor verantwoordelijk is:

@keyframes move {  50% {     top: 100px;     bottom: 800px;  }

Als we https://csstriggers.com/ raadplegen zien we dan ook dat onder de web engine Blink (de huidige web engine van Chrome) wijzigingen in ‘top’ en ‘bottom’ ervoor zorgen dat het gehele ‘pixel to screen pad’ doorlopen moet worden om de pixels te wijzigen op het scherm. Dit geeft dus een goed beeld van wat de frame rate was tijdens de animatie, maar ook welke stappen er nodig waren om de animatie te tonen. Bij dit voorbeeld is de performance van de animatie slecht te noemen, de animatie schokt en scrollen voelt niet soepel aan.

Een betere manier om dit te doen is door gebruik te maken van ‘transform’ in combinatie met ‘translate’. Dit zorgt ervoor dat het onderdeel dat geanimeerd moet worden gedefinieerd wordt in een eigen layer. Hierdoor kan dit element bewegen over het scherm zonder impact te hebben op andere elementen. Als er geen impact is op de andere elementen in het scherm, is het ook niet nodig nieuwe berekeningen hierover te maken. Het meeste werk kan dan worden uitgevoerd door de GPU en dus ontlasten we de CPU enorm.

Een voorbeeld van deze CSS rule is dan:

@keyframes move {  50% { transform: translate(-100px, -800px);  }}

Met deze aanpassing hebben we dezelfde meting gedaan.

Kijk naar onderstaande en verbaas je over het resultaat wat we behalen met een wijziging van slechts 1 CSS-regel ((klik voor vergroten):

Door het element in een aparte layer te zetten kan de animatie op de beoogde 60 FPS uitgevoerd worden zonder enige vertraging door het berekenen van styles, layout of paint!

UX-design versus performance

Zoals je ziet kan een eenvoudige animatie al vervelende issues met zich meebrengen en kan het, wanneer men niet weet hoe dit te debuggen, een lange zoektocht worden om deze optimaal te laten werken. Gelukkig zijn er tools in de browser beschikbaar die ons hierbij kunnen helpen. Omdat we steeds meer vragen van onze browsers verwacht ik ook dat we dit soort tools steeds meer gaan gebruiken om de clientside-gerelateerde performance te meten. Het onderwerp ‘clientside performance’ zal vaker op de agenda komen te staan. Zo nu en dan zie je zelfs een strijd ontstaan tussen UX-design versus performance en flitsende graphics versus responsiveness. Een zeer interessante ontwikkeling waardoor mijn werk in ieder geval nooit saai wordt!

Meer weten?

Mocht je meer willen weten over dit onderwerp, lees dan onderstaande artikelen en/of neem contact met me op via jderidder@computest.nl.

Over het gebruik van layers binnen een browser.
Uitleg pixel to screen pipeline
Hoe browsers werken
Over CSS triggers
Blog over Front-end performance

zelfsturende organisatie