Optimalisatie op Single Page Apps en PWA's

Single page apps (SPAs) en Progressive web apps (PWAs) zijn inmiddels niet meer weg te denken uit het digitale landschap. Steeds meer merken bieden hun bezoekers de vlottere, als app aanvoelende mobiele website op hun smartphone of tablet. Helaas betekent dat voor bijna alle optimalisatie tooling dat je de prijs moet betalen voor deze keuze: Het wordt er niet eenvoudiger of goedkoper op. Je zult meer code nodig hebben om je variaties te tonen en dat betekent meestal ook dat de kosten van je team van (externe) developers zullen gaan stijgen.

Hoe werken SPA en PWA websites?

Laten we voorop stellen dat het geen probleem zou mogen zijn om je SPA of PWA te optimaliseren. De werkelijkheid laat helaas een ander beeld zien en dat komt door hoe een SPA is opgebouwd.

Waar in een "klassieke" website elke pagina als geheel wordt geladen, wordt bij een SPA er een raamwerk voor een pagina ingeladen, en vervolgens een blok content voor die pagina. Bij elke navigatie door de gebruiker hoeft nu slechts de nieuwe informatie te worden geladen, en niet de gehele pagina (inclusief de stijlen, afbeeldingen & opmaak). Dat maakt dat de website een stuk vlotter te gebruiken is. Een PWA gaat nog een stapje verder en kan (delen van) de website bijvoorbeeld ook offline beschikbaar maken, of zichzelf installeren als icoon op je startscherm. PWA's kom je voornamelijk tegen voor mobiele devices.

Hoe optimaliseer je een SPA met een tag-oplossing?

Het is niet onmogelijk, maar vereist wel meer tijd & expertise. Het is gebruikelijk voor een tag-based tool om de code uit te voeren als de pagina geladen wordt, maar daar zit dus de crux: Er is immers maar één "echte" pageload.

Je zult dus code moeten (laten) schrijven die in de gaten houdt hoe de pagina er op een bepaald moment uitziet, zodat je de relevante variaties kunt tonen. En wellicht moet je de variaties ook weer verwijderen als de gebruiker terug navigeert naar de voorgaande pagina. En laten we het nog maar niet hebben over het flicker effect, wat potentieel nog meer zichtbaar zal zijn dan al gebruikelijk is bij een tag-oplossing. Immers, de pagina wordt eerst "origineel" in de browser getoond, en vervolgens wordt de javascript van de SPA en daarna de test-tool uitgevoerd. Ook het targeten van je experiment is er ook niet eenvoudiger op geworden, aangezien de URL structuur niet meer op de server, maar slechts in de browser bestaat.

Dit kan anders & effectiever

In tegenstelling tot tag-oplossingen heeft SiteSpect geen extern javascript nodig om alle variaties bij de gebruiker af te leveren. Sterker nog, veelal hebben we helemaal geen javascript nodig. Wij kunnen de variaties aanbrengen in de onderliggende requests die de content leveren. Of het nu een API call is, of een css-file, SiteSpect is in staat er een wijziging in aan te brengen, nog voordat de browser de pagina ontvangt.

En als dat voor een SPA niet genoeg is, dan kan SiteSpect alle wijzigingen die nodig zijn vooraf in de pagina verwerken, ondanks het feit dat sommige pagina's pas later in de browser worden getoond.

Samenvatting

Het eenvoudige verhaal is dat het voor SiteSpect absoluut niet uitmaakt of je een klassieke website of een SPA of PWA gebruikt, SiteSpect werkt hetzelfde en zorgt er voor dat je succesvol kunt optimaliseren. Een tag-based oplossing zou kunnen werken, mits je er tijd en moeite in steekt om het werkbaar te maken en een performance impact niet erg vindt.

Wil je graag met je eigen ogen zien hoe SiteSpect het optimaliseren van je SPA eenvoudig maakt? Maak dan een afspraak voor een vrijblijvende demo.