Eind 2015 kondigde Google Accelerated Mobile Pages aan. Om het mobiele internet sneller te doen laden werd het AMP framework geïntroduceerd. AMP is snel omdat het veel beperkingen kent in interactiviteit en styling. Zonder digitale toeters en bellen en een nadruk op content laden AMP pagina’s over het algemeen veel sneller dan reguliere HTML pagina’s.
Ondertussen, minder dan 2,5 jaar verder, maken meer dan 900.000 domeinen gebruik van AMP om meer dan 2 miljard pagina’s aan snellere content te serveren. Klinkt allemaal geweldig maar AMP is zeker niet zonder controverse, verre van. Een aantal discussiepunten zijn al sinds de introductie van AMP een hot topic, maar het meest belangrijke punt heb ik nog niet voorbij zien komen. Voordat ik dit artikel van Ferdy Christant las. De werkelijke reden waarom AMP zo snel is en waarom we erg goed na moeten denken voordat we klakkeloos deze ‘standaard’ implementeren.
Zoals in het artikel waar deze post op is gebaseerd loop ik kort door de controverse rond AMP van de afgelopen jaren heen:
AMP is niet zonder controverse. Het ‘HTML framework’ is weliswaar ontwikkeld in samenwerking met meer dan 30 grote online partijen (waaronder Twitter, LinkedIn en WordPress) maar de technische standaard is geheel buiten de W3C om tot stand gekomen. De W3C, verantwoordelijk voor webstandaarden en specificaties die door alle software partijen kunnen worden gebruikt, is niet betrokken bij de totstandkoming van AMP.
In plaats van voort te bouwen op door W3C vastgestelde standaarden heeft AMP zijn eigen standaarden, welke in strijd zijn met algemeen geaccepteerde webstandaarden, waaronder HTML. Wanneer AMP, een op HMTL gebaseerd framework, tegen de W3C meetlat voor HTML wordt gelegd vormt het verre van geldige HTML. Browsers kunnen prima met slecht ‘gevormde’ HTML omgaan in quirks mode, daar niet van. Het is wel een zorgelijke ontwikkeling dat standaardorganen geheel omzeild kunnen worden door een commerciële partijen die de markt zijn wil op kan leggen.
Een veel groter en minder theoretisch probleem is dat, wanneer je je content in AMP publiceert, dit vaak vanaf het Google domein wordt geladen. Google slurpt namelijk je content op en zet het in haar eigen cache. Wanneer een gebruiker van de zoekmachine een AMP pagina opvraagt gaat deze bezoeker daarom niet naar de site van de publisher, maar blijft op het Google domein.
Kort gezegd houdt dat in dat je de controle over je content overgeeft aan Google, en de mogelijkheden van het AMP framework. Je wordt door de AMP standaard beperkt over wat je wel en niet kunt doen, niet alleen nu maar ook in de toekomst. AMP is zeer strikt – om redenen van snelheid – wat wel en niet wordt toegestaan binnen het framework. Heb je een leuke manier bedacht om je content te monetizen maar is dit niet mogelijk binnen AMP? Jammer, dan gaat het niet door, niet binnen AMP in ieder geval.
Kiss goodbye to naar jouw wensen vormgeven van content en controle over de gebruikerservaring wanneer je met AMP gaat werken. Ja, je kunt enige styling op je content toepassen binnen AMP maar met grote beperkingen. Zo wordt alle AMP content een eenheidsworst zonder al te veel diversiteit in presentatie.
Goed, zul je zeggen, uiteindelijk is de gebruiker gebaat bij een sneller ladend internet. AMP maakt dat mogelijk. Als je zelf wel eens een AMP pagina vanuit de zoekmachine hebt bekeken weet je hoe ongekend snel het laadt. Zo veel sneller dan een site die alle Pagespeed Insights lessen heeft toegepast en een score van 100 heeft behaald. Het is gewoon onmogelijk een reguliere pagina even snel te laten laden als een AMP pagina.
Om te testen of AMP werkelijk zo snel is heb deze AMP pagina van The Guardian direct benaderd – dus niet via Google cache. Het grappige is dat, wanneer ik de laadsnelheid van deze pagina check in Webpagetest.org (welke automatisch een 3G verbinding voorselecteert) de pagina er best heel lang over doet om te laden.
Webpagetest.org doet drie tests, in de eerste test duurt het 13,12 seconden voordat de pagina zichtbaar is (first view). MEER DAN 13 SECONDEN – dit is een AMP pagina! In de tweede poging doet de pagina er 12,67 seconden over en in de derde poging 10,38 seconden. Ik zou zeggen, probeer het zelf eens.
Ik hoop hiermee duidelijk te hebben gemaakt AMP op zich helemaal niet zo snel is. Maar hoe komt het dan dat AMP pagina’s zo lightning fast laden? Enerzijds ligt dat aan de Google CDN / servers waar cache content vanaf wordt geladen.
Anderzijds, en nu komt ‘ie, blijkt het dat Google AMP pagina’s in de browser al laadt voordat ze worden bezocht. In andere woorden is het zo dat een stuk van jouw mobiele bandbreedte wordt gebruikt om content te laden die je nooit gaat bekijken. Omdat de pagina’s door je mobiele browser al zijn binnengehaald voelt het als een supersnelle ervaring als je op een AMP artikel klikt en deze (ogenschijnlijk) ongelofelijk snel laadt. Dat komt omdat je de pagina al had geladen, alleen had je er nog niet voor gekozen hem te vertonen.
Misschien zegt je dit niet veel maar ter volledigheid een screenshot van de resources van een mobiele Google zoekpagina die door je mobiele browser worden geladen. Zie je al die AMP resources? Dat zijn de artikelen die achter het carousel hangen – en dus al geladen zijn voordat je ze hebt bekeken.
Het grote probleem hiermee is dat Google de door haar geïntroduceerde AMP standaard voortrekt in de zoekresultaten. Publishers worden gedwongen om op AMP over te stappen, met alle bovenstaand omschreven gevolgen, gebruikers wensen een snelle mobiele ervaring. Alleen de snelle mobiele ervaring van AMP is grotendeels een wassen neus. Wanneer reguliere HTML (en CSS, Javascript) content ook pre-loaded zou worden zouden deze pagina’s ook vele, vele male sneller lijken te laden. Lijken te laden want dat is dus precies wat AMP doet – snel lijken te laden.
Zo worden publishers min of meer gedwongen over te stappen op een standaard die eigenlijk helemaal geen onafhankelijke standaard is. Een standaard die wat betreft laadtijd helemaal niet zulke enorme voordelen biedt als wel lijkt te worden beloofd.
