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?
PWA in plaats van AMP? Lees waarom PWA geen oplossing is voor performance issue.
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.
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:
- Optimale TTFB: uitvoertijden van 0.001 tot 0.04 (afhankelijk van caching-instelling);
- Critical Render Path;
- Defer unused CSS;
- Resource hints;
- Automatisch comprimeren van afbeeldingen;
- Lazy loading van afbeeldingen;
- Geoptimaliseerde webp-afbeeldingen;
- Gebruik van WWW tegen cookie-verkeer/network latency;
Hiermee behalen we regulier betere laadtijden dan dat een AMP equivalent vanuit de Google AMP-CDN behaalt.
Conclusie
AMP is 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 equivalent (bijvoorbeeld om eerder genoemde reden), dan kan de realisatie van AMP versies van de webpagina's een antwoord zijn.
