Wat wij hebben meegenomen van de workshop New Front-End Adventures

Optimalisatie van de performance op mobiel

De workshop startte met een verrassende vraag: “hoeveel van de aanwezige bezoekers is bekend met een OPPO A83 of een XIAOMI REDMI 5 PLUS?”. Wij (Johan en Wietze) hadden er in ieder geval nog nooit van gehoord. Met deze vraag werd het onderwerp van de workshop ingeleid: de performance van deze low-end-toestellen, in verhouding tot het percentage van alle verkochte toestellen. In onze beleving heeft iedereen een iPhone of een ander gelijkwaardig high-end-toestel en overal een snel 4G netwerk. Dit is echter natuurlijk niet altijd het geval.

Performance is natuurlijk niet alleen belangrijk voor mobiel internet, maar er zijn nog genoeg plaatsen waar het internet vele malen slechter is dan dat wij gewend zijn. Al met al genoeg redenen om de performance van de hedendaagse Front-End eens onder de loep te nemen: hoe kunnen we deze optimaliseren?

Aantal bytes verminderen

Een eerste stap om de performance te verbeteren, is het verminderen van het aantal bytes dat we over het Net versturen. Zo kunnen we vanuit de UX/Front-End experimenteren met onder andere adaptive serving: verschillende content per device, afhankelijk van de kwaliteit van de verbinding.

figuur 1: voorbeeld van Adaptive Serving

Een andere manier is om predictive asset prefetching toe te passen, waarbij aan de hand van statistieken een bepaalde verwachte set met content vooraf wordt opgehaald.

Door kritieke elementen te laden, hoeft de gebruiker minder lang te wachten. Hiervoor moet er wel bepaald worden wat de kritieke elementen zijn. In de Front-End kunnen we er bijvoorbeeld voor zorgen dat de CSS die gebruikt wordt in het eerste gedeelte (170px) als vaste CSS in de html-code staat, voordat de overige CSS-bestanden geladen worden. Voor de overige data, die nog niet direct zichtbaar hoeft te zijn, kunnen we dan gebruikmaken van lazy loading. Ook kunnen we nog de belangrijkste CSS-bestanden splitsen in individuele media queries: de browser laadt dan kritieke CSS-bestanden als eerste in, waardoor de belasting op een mobiel device minder is. Doordat we er al zorg voor gedragen hebben dat de kritieke CSS als eerste geladen is, kunnen we de overige CSS-bestanden asynchroon preloaden. De beleving is dat het in zijn geheel alsnog snel geladen wordt.

Meerdere kleine JavaScript-bestanden

De grootste kosten qua performance met JavaScript zitten niet in het parsen of compileren, maar in de uitvoering van het script. Om zo veel mogelijk winst te behalen is het raadzaam om geen monolithische architectuur met bestanden van meer dan 50KB te gebruiken, maar deze op te delen in kleinere JavaScript-bestanden. Waar je ook rekening mee kunt houden is de Time to Interactive: wat heeft een gebruiker minimaal nodig om gebruik te kunnen maken van de applicatie? De overige bestanden kunnen dan op de achtergrond worden ingeladen. Als scripts niet afhankelijk zijn van bepaalde styles, kan je ervoor kiezen de scripts boven de styles te plaatsen. Dit komt de Time to Interactive ten goede. Als je gebruik maakt van Third-party JavaScript, is het van belang om hiervan de impact te bepalen en als het kan deze asynchroon te laden.

Fonts; zelf hosten of preloaden

Een belangrijk element van een ontwerp of een identiteit is het font. Omdat we niet meer enkel afhankelijk willen zijn van fonts als Times New Roman of Arial, maken we steeds vaker gebruik van fonts die niet standaard zijn in de browsers. Dit geeft de nodige belasting op de performance, omdat we deze fonts via een externe bron extra moeten laden. Als we gebruikmaken van een subset van de fonts met initieel alleen de karakters die we nodig hebben en we deze zelf hosten, maken we al veel van het performanceverlies goed. Ook kunnen we de fonts preloaden en gebruik maken van service workers. Of we gebruiken variabele fonts die zich met CSS gedragen als multiple fonts (Bold, Italic enz). Het nadeel van variabele fonts is wel dat nog niet ondersteund wordt door alle browsers. De browser zal het font dan wel laden, maar er is nog geen aansturing op de manier waarop ze worden getoond.

Om tekst sneller te kunnen serveren, kunnen we gebruikmaken van Brotli, waarvan de compressie 14-25% beter is op basis van een level 4 compressie. Brotli is enkel te gebruiken via https. We zien dat ondertussen de meeste browsers Brotli ondersteunen (op IE 11 en Opera mini na). Brotli heeft ook het voordeel dat het snel grotere bestanden kan verwerken op trage verbindingen.

JAMstack

Deze workshop was niet “all about the JAMstack”, maar het sluit er wel zijdelings bij aan. Een groot voordeel van JAMstack is dat het al goede performance geeft door o.a.:

• De pagina’s statisch in te laden
• Met API’s de content te verrijken
• Gebruik te maken van een microservice architectuur

Als we dan ook nog eens de tips & tricks van deze workshop toepassen op onze webapplicatie, weten we zeker dat deze een optimale performance geeft!