Zo meet je de snelheid van Single Page Applications

JavaScript application frameworks hebben een sterke vlucht genomen. De ervaring die gebruikers hebben bij het gebruik van een native app op hun mobiele telefoon was veel beter dan ‘ouderwetse’ webpagina’s. En dus popten de afgelopen jaren diverse frameworks op die deze applicatie-achtige ervaring naar de browser brachten. De websites die met deze techniek gebouwd worden, worden Single Page Applications (SPA’s) genoemd.

Naast SPA’s heb je nog Progressive Web Apps (PWA’s) en deze worden vaak over één kam geschoren. Ze werken functioneel hetzelfde en zijn in grote lijnen op dezelfde techniek gebaseerd. Daarom beperken we ons voor nu tot het benoemen van SPA. Het meten van SPA’s en PWA’s gebeurt op dezelfde manier.

SPA’s werken totaal anders dan de losse internetpaginatechniek die we vandaag nog veel tegenkomen. Het komt erop neer dat er een basispagina ingeladen wordt zonder enige content en dat er een flinke hoeveelheid JavaScript gedownload wordt die de verdere opbouw van de pagina op zich neemt.

Dit betekent dat de KPI’s waar ik het eerder over had, zoals Page Load, een totaal andere betekenis gaan krijgen. Een ander zeer groot verschil is dat je, technisch gezien, maar één pagina hebt, en er niet meer zoiets als pageviews bestaat en je dus ook geen gemiddelde laadtijd van een pagina meer hebt.

Hoe meet je dan snelheid in een SPA?

Een SPA bestaat bij de gratie van REST API’s. REST API’s zijn de bron van alle content op het scherm. Het is dus zeer belangrijk dat deze API calls snel zijn. Gelukkig is het monitoren van API calls redelijk eenvoudig. Via tooling is goed te meten hoe lang het opvragen van bijvoorbeeld detailinformatie duurt.

Een snelle API is één, maar dit betekent nog niet dat je ook een snelle SPA hebt. Het kan namelijk best goed zijn dat de API snel data aanlevert, maar dat de code rondom het ophalen en verwerken van het resultaat zo inefficiënt is dat het opbouwen van het scherm nog steeds langzaam is. Page loadtijden en API responsetijden zullen je hier geen inzicht in geven. Om hier inzicht in te krijgen is additionele tooling vereist.

Een andere manier van meten: APM

Wil je precies weten hoe de snelheid van je SPA is, dan ben je aangewezen op een Application Performance Monitoring (APM) tool. Via deze tooling meet je van binnen uit hoe lang alle onderdelen binnen je applicatie duren.

Van binnen uit betekent dat er een stukje JavaScript in je applicatie gezet wordt die alles in de gaten houdt. Alle meetresultaten worden naar een server doorgestuurd. Via dashboards kun je vervolgens inzicht krijgen in hoe de snelheid van je SPA is. Dit noemen we ook wel RUM: Real User Monitoring.

In tegenstelling tot het meten van snelheid vanaf een snelle server meet je dus hoe de snelheid is bij de gebruikers zelf. Dit is zeer waardevolle informatie! Deze manier van RUM via een APM tool is overigens niet alleen weggelegd voor SPA’s. Ook traditionele websites kunnen gemonitord worden door deze tools. Enkele bekende APM tools zijn New Relic, DynaTrace, Stackify Retrace en DataDog.

De nieuwe methode

Met de komst van Single Page Applications moeten we de manier waarop we snelheid meten herzien. De gebruikelijke Page Load is niet langer leidend, de kwaliteit van de code en de snelheid van je API zijn veel belangrijker.

Weet wat je meet

In de serie over het meten van snelheid van je website ging het in deel 1 over welke termen je vaak tegenkomt als het om het meten van snelheid gaat en hoe je deze moet interpreteren.

Deel 2 behandelde hoe je de snelheid van je website op verschillende manieren kunt meten, en dat dit direct invloed heeft op de resultaten. Tot slot hebben we het gehad over dat je moderne web applicaties (single page applications/progressive web apps) heel anders moet meten dan de traditionele manier.