De afgelopen jaren hebben de JavaScript application frameworks 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 internetpagina techniek die we vandaag de dag nog veel tegenkomen. In het kort komt het 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 we het eerder over gehad hebben, zoals Page Load, een totaal andere betekenis gaan krijgen. Een ander zeer groot verschil is dat je, technisch gezien, maar 1 pagina hebt, en er niet meer zoiets als pageviews bestaat en je dus ook geen gemiddelde laadtijd van een pagina meer hebt.
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 product detail informatie 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 load tijden en API response tijden zullen je hier geen inzicht in geven. Om hier inzicht in te krijgen is additionele tooling vereist.
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.
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.
In de serie over het meten van snelheid van je website hebben we het in deel 1 gehad over welke termen je vaak tegenkomt als het om het meten van snelheid gaat en hoe je deze moet interpreteren. Inzicht krijgen in de prestaties van jouw website? Download het whitepaper!