Zoeken op Blue 2 Blond

AMP en PWA als antwoord op laadtijd en performance

Zelden ben ik kort van stof als er een onderwerp binnen mijn vakgebied wordt aangesneden. Omdat het antwoord te lang was voor LinkedIn op het vraagstuk of AMP een oplossing is voor een goede ranking in de zoekmachine resultaten en welke andere oplossingen er zijn, dit artikel.

Deze vraag kan ik enkel vanuit (pagespeed/performance)techniek beantwoorden, maar dat maakt het antwoord er niet zwart-witter op. Accelerated Mobile Pages (AMP) kun je namelijk in verschillende gradaties uitrollen. Een webshop is uitgebreider dan een website dat als online visitekaart fungeert. Oftewel: welke functionaliteiten moeten wel of niet overgenomen worden?

Automatische AMP

Binnen het CMS dat we gebruiken, wordt HTML en CSS door een trechter gegooid om tot een AMP equivalent te komen; niet gebruikte CSS wordt automatisch gestript en HTML (bijvoorbeeld voor video/audio/analytics) wordt geconverteerd. Het kan dus automatisch, maar maatwerk AMP zal voor meer specifieke functionaliteit altijd nodig zijn, wat in praktijk budget vergt.
Een oplossing is: Een button op de plek van interactie, waarmee de bezoeker naar de reguliere webpagina wordt verwezen om de bezoeker een interactie als bestellen of reageren aan te laten gaan. Zo kan een basis AMP equivalent toch snel gerealiseerd worden.

Voor een eenvoudige website, is een AMP traject op basis van bovenstaand vervolgens bijna een formaliteit (Wordpress kent AMP-plugins, die sinds december 2018 ook niet-blogpagina's kan omzetten naar AMP). Voor een omvangrijkere online toepassing, zal het echter een vraagstuk moeten zijn met wat voor versie (en vooral aanwezige functionaliteiten) genoegen kan worden genomen.

JavaScript libraries

De winst in AMP zit hem vooral in de inzet van JavaScript, of beter, gebrek aan JavaScript. Alleen libraries die gebruikt gaan worden, worden in geval van een AMP pagina ingeladen. Hiermee vervalt het voordeel van caching (direct een groot nadeel van AMP); Reguliere websites of webshops laden direct een hele jQuery, VueJs of React framework in, ook als niet de gehele codebase van de library gebruikt wordt.

Het voordeel van direct inladen:

  • het CMS hoeft niet geconfigureerd te worden om alleen hetgeen voor te schotelen dat gebruikt wordt;
  • client side caching wordt benut, de (JS) resource is geheel geladen en direct beschikbaar bij volgende paginabezoeken;
  • eventueel kan een CDN gebruikt worden, aangezien de resource in zijn geheel ingeladen wordt, in plaats van in delen.

Dit brengt één nadeel met zich mee:

  • Het gehele bestand moet gedownload en geparsed worden door de browser. Dit veroorzaakt al snel een grotere impact op Time to Interactive dan in het geval van een AMP webpagina.

AMP: instant delivery?

Waar een AMP pagina nog het predicaat "instant delivery" verdient, verdient een website dat gebruik maakt van een JS framework dit minder snel. Een reden voor Netflix om ReactJS de deur te wijzen voor hun desktop homepagina.

vergelijking tussen AMP en PWA

Nog steeds kun je te grote afbeeldingen of onnodig veel CSS toepassen binnen AMP. AMP dwingt met zijn standaarden hooguit af, dat basis performance meer out-of-the-box aanwezig is. Echter, AMP's best-practices omtrent performance, zijn ook gewoon toepasbaar in reguliere webpagina's (denk aan lazy-loading, gebruik van CDN, gebruik van beperkte JavaScript, animaties via Hardware Acceleration), maar is arbeidsintensiever als een website al éénmaal gebouwd is.
Smartphones zijn bovendien ook al in staat om non-AMP pagina's 'in-app' te tonen (wat juist één van de grote voordelen van AMP was).

AMP 4 keer sneller?

AMP zou 4 keer sneller moeten laden dan normale webpagina's. Maar deze statistiek gaat natuurlijk alleen op, als er bij de bouw van de eigenlijke website slechts minimaal is omgekeken naar performance. In dezelfde vergelijking, is hosting pas echt meetbaar sneller dan een ander, wanneer er een zwaar (en langzaam) platform gebruikt wordt.

Ik ben dus vooral van mening dat er binnen de reguliere website geoptimaliseerd zou kunnen (en zelfs moeten) worden, waarmee AMP overbodig wordt. Dat dit niet moeilijk hoeft te zijn, bewijzen we met het CMS dat wij gebruiken:

Hiermee behalen we regulier betere laadtijden dan dat een AMP equivalent vanuit de Google AMP-CDN behaalt.

PWA

Dit maakt Progressive Web Apps (PWA) ook direct een lastig onderwerp. Alhoewel PWA een oplossing kan zijn voor een snellere website/webshop ervaring, is PWA geen oplossing voor betere initiele performance. Pas bij opvolgende pagehits, komt de toegevoegde waarde van PWA om de hoek kijken. De basis webpagina zal dus reeds optimaal moeten zijn.
Hier zit direct het wrange: Om een webpagina technisch bruikbaar te maken voor PWA doeleinden, wordt veelal de gehele content via deze techniek gevuld en dus komt er veel JavaScript bij kijken. Vaak ondersteund middels JS frameworks om de ontwikkeltijd door developers optimaal te houden, waardoor het impact heeft op de Time to Interactive. Ondanks een poging om de performance middels PWA te verbeteren, behaalt het hiermee wellicht juist in bijvoorbeeld Google's Lighthouse performance test een lagere score.

Wanneer wel PWA

Grijp dus niet naar PWA omwille van performance alleen. Offline ondersteuning kan een argument zijn, maar vind ik (net als deze kritische blog) als argument niet zwaar wegen. Toepassing van notificaties is dit bijvoorbeeld wel. Zet PWA dus in wanneer het functioneel iets toevoegt en beschouw caching voordelen en daarmee verdere performance-verbetering als praktische bijkomstigheid.

PWA en AMP

Overigens kan PWA ook op een AMP website uitgerold worden. Het gevaar is hooguit dat AMP een langzame dood sterft en het dan zonde van de investering is als PWA is toegespitst op de AMP equivalent.

Conclusie

Ik volg zowel PWA als AMP ontwikkelingen (de huidige website kent ook een AMP-versie), maar met een kritische blik.

  • PWA heeft vooral vanwege functionele toepassingen en potentie (offline bereikbaarheid, notificaties en daarmee goed alternatief op native apps) toegevoegde waarde en dicht ik om die reden langere houdbaarheid toe. Het is echter geen oplossing op een slechte performance-score;
  • AMP is op zijn beurt overbodig te maken als de eigenlijke website of toepassing geoptimaliseerd kan worden (en vaak kan dit, maar zorgt het gebruikt platform ervoor dat het een arbeidsintensief traject kan worden).

Mijn advies zal dus altijd zijn: optimaliseer primair de eigenlijke website, voordat naar AMP of PWA wordt gegrepen.
Vallen kosten voor performance optimalisatie hoger uit dan de bouw van een AMP of PWA equivalent (bijvoorbeeld om eerder genoemde reden), dan kan de realisatie van AMP versies van de webpagina's of PWA ondersteuning een antwoord zijn.

Laat ons weten wat je hiervan vindt!

  • Houd reacties relevant aan het onderwerp en wees redelijk en billijk naar anderen. Houd je bij het plaatsen van een reactie aan de Nederlandse wet.
  • Uw emailadres zal enkel gebruikt worden om u, indien aangegeven, op de hoogte te houden van nieuwe reacties op dit bericht.
  • Indien u er voor kiest uw emailadres weer te geven, zal deze voor bots onleesbaarder worden gemaakt.