AMP står for ’Accelerated Mobile Pages’. AMP er startet af Google som et fælles projekt mellem Google, Twitter, WordPress og NY Times mfl., i et forsøg på at gøre det mobile web hurtigere og mere brugervenligt. Præmisserne for AMP er som følger: At lave hurtige hjemmesider, at være nemt at implementere, gøre det muligt at kapitalisere på indhold og omfavne det åbne web.

Hvad er AMP?

Accelererede Mobile Sider eller AMP er i realiteten almindelige hjemmesider, der er mobiloptimeret, efter Googles forskrifter. Disse mobil-versioneringer er baseret på HTML5 men med en lang række restriktioner. Optimeringen sker igennem JavaScript, og stylingen styres igennem CSS3, og herudover caches alle sider.

AMP blev for første gang aktiveret i Googles søgeindeks tilbage i februar 2016. Til at begynde med, var det dog kun større medier og kun få udvalgte regioner, der kunne få vist deres artikler i AMP-formatet, og det skete kun i artikelkarruseller på visse mobile søgninger.

Danmark var ikke med i første udrulning
Som du kan læse i dette indlæg, insinuerede jeg også tidligere på året, at AMP ikke var live i Danmark endnu og at en korrekt implementering derfor ikke var tilstrækkeligt.

Oprindeligt var det et krav, at en artikel skulle vises under ”Top Stories” i Googles News for at blive vist i AMP-formatet, som ikke er muligt i Danmark. Derfor så vi ikke nogle danske AMP-resultater førend i september måned i år, 7 måneder efter amerikanerne første gang kunne støde på de lynhurtige mobilresultater.

Gik live i SERPs i september
Siden september i år har AMP været aktivt i de danske søgeresultater så vel som i resten af verdens søgeresultater. Du kan genkende AMP-resultaterne, ved det lille lyn-ikon:⚡, som vises ud for resultatets meta-beskrivelse.

AMP-sider er kun synlige på de enheder, der kan håndtere dem, og du skal dermed søge i Google på en mobil-enhed for at se AMP i resultaterne.

Hvordan fungerer AMP?

Google cacher AMP-sider på samme måde som et CDN cacher din hjemmeside, forskellen er dog at Google kører med revalideringsproces, der sikrer, at indholdet altid er opdateret i cachen og at dine seneste ændringer derfor er tilgængelige stort set med det samme, og i hvert fald når brugeren lander på siden.

Når en bruger finder et resultat i søgeresultaterne, der er sat op som et AMP-resultat, modtager klienten en cached version, mens dokumentet bliver forespurgt igen fra den oprindelige server, for at få cachen opdateret. I det sekund brugeren klikker på AMP-resultatet, er det opdateret, og ændringer, der måtte have været foretaget siden den pågældende AMP-side sidst blev vist i SERPs, er nu opdateret og serveres for brugeren.

Det er en rigtig smart egenskab, der dog kan give problemer. I det tilfælde at en bruger, der lander på en amp-side, vælger at dele denne side til en anden bruger (eksempelvis på Facebook eller på Twitter) bliver siden ikke opdateret, da den ikke kaldes igen, og det betyder, at artiklen ikke viser de seneste ændringer. Hvordan Google har tænkt sig at få løst den problematik vides endnu ikke, men det er i hvert fald en ikke uhensigtsmæssighed, jeg kan forestille mig, de lader stå åben i alt for lang tid.

Virker AMP på alle typer af sider?

Der er mange, der fejlagtigt tror, at det kun er muligt at lave AMP-versioneringer af blogindlæg og artikler. Det passer selvfølgelig ikke! Du kan omforme alle typer af sider, så længe du ikke bruger ikke-tilladte teknikker på de pågældende sider. Selvom du Schema-mæssigt skal definere en side, som værende eksempelvis Article, blogposting, Receipe mv.

Jeg har blandt andet implementeret AMP på en webshop, hvor alle sider og produkter kører AMP. Du kan se et eksempel på en AMP-produktside neden for:

Hvorfor bruge AMP?

Kort sagt, så skal du bruge AMP for at levere den bedste mulige mobiloplevelse af dit website. Den bedste mobiloplevelse består blandt andet i, at siden på grund af de færre elementer er nemmere at afkode for den enkelte bruger. Tydeligere font er ligeledes vigtigt ligesom det gælder plads imellem de forskellige aktive elementer.

Herudover loader siden markant hurtigere, i forhold til hvad der er muligt med din normale mobilversionering, og hastighed har efterhånden alt at sige i forhold til en brugers oplevelse af en given side – mobilbrugere forventer endnu hurtigere sider end desktop brugere.

Ifølge Gary Illyes fra Google ser udgivere, der kører med AMP højere CTR (Grundet det lille lynikon i SERPs) og får flere sidevisninger end de udgivere, der ikke kører med AMP.

Bliver AMP et rankingsignal?

AMP er på nuværende tidspunkt ikke et direkte ranking-signal, om det bliver det på et tidspunkt, er meget svært at spå om. Det betyder heller ikke det store, om AMP bliver eller er et direkte rankingsignal. Indenfor SEO arbejder vi meget med afladt effekt og virke.

Hvis brugere får en bedre oplevelse, når de besøger en AMP-versionering, vil Google registrere dette, og hvis en side loader hurtigere, vil Google opfange dette. Får du flere kliks på dit AMP-resultat, vil Google også registrere dette. Der er dermed masser af mulighed for afledt effekt, der giver bedre placeringer og gladere brugere.

Google selv har udtalt, at alt andet lige vil de altid vælge det hurtigste resultat imellem to ellers identiske sider, såsom en regulær version af en given side og en amp-versionering.

AMP versus almindelig opsætning, hastighedsmåling

Hvis du allerede har et meget hurtigt website, vil du opdage at AMP-versionen som udgangspunkt ikke er meget hurtigere end din normale side. Som det kan ses i hastighedsmålingerne neden for, er forsiden på denne blog under 100 ms langsommere end AMP-versionen.

Årsagen til at AMP-versionen stadig er et meget hurtigere resultat at lande på, er at du slet ikke forlader Google når du klikker dig ind på et AMP-resultat. Besøger du en almindelig hjemmeside, sendes du videre til denne side, hvor serveren for det første skal svare og først herefter begynder at sende dig data. I et AMP resultat, er det hele loadet og ligger parat, i det sekund du klikker på resultatet, og derfor får du også hvad der virker som øjeblikkelig adgang.

Opsætningen

Der findes nogle helt fundamentale krav for at en side kan verificeres som værende en AMP-side. Disse krav finder du beskrevet nedenfor. De skal alle være en del af en hvilken som helst AMP-versionering, før det er muligt at verificere og få den enkelte side godkendt.

• Skal begynde med<!doctype html>.
• Skal indeholde et top level<html ⚡>tag eller et (<html amp>).
• Skal indeholde <head>og<body> tags (I HTML er de ikke obligatoriske).
• Skal indeholde et<link rel=”canonical” href=”$SOME_URL” />tag i headeren, der peger på den primære HTML version af AMP-dokumentet eller til sig selv, hvis hele websitet er baseret på AMP (Ligesom AMP-projektet er)
• Skal indeholde <meta charset=”utf-8″>som første tag i head tagget.
• Skal indeholde et<meta name=”viewport” content=”width=device-width,minimum-scale=1″>tag i dens head-tag, det er også anbefalet at inkludere intitial-scale=1
• Skal indeholde<script async src=”https://cdn.ampproject.org/v0.js”></script>tagget som det sidste element i head (Loader og inkluderer AMP JS-biblioteket)

Skal indeholde følgende i head:

• <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>

Den originale artikel skal pege på AMP-versionen med følgende streng:

<link rel=”amphtml” href=”https://www.henrik-bondtofte.dk/googles-nye-mobilformat-amp/amp/”>

AMP-versionen skal pege tilbage på den primære version med følgende streng:

<link rel=”canonical” href=”https://www.henrik-bondtofte.dk/googles-nye-mobilformat-amp/” />

• CSS skal være inline og fylde mindre end 50 kb
• Skal loades med en speciel AMP-font udvidelse
• Billeder skal defineres med amp-img elementet
• Videoer skal integreres igennem HTML5 med amp-video tagget

Kræver semantisk opmærkning

Der er yderligere en hel del krav i forhold til AMP-versioneringer af en side. Blandt andet er der en række elementer, der skal tagges semantisk korrekt op med Schema.org vokabular, for at AMP-versionen kan verificere og dermed have mulighed for at blive vist i Googles søgeresultatsider.

Du skal som minimum definere følgende elementer semantisk:

• Sidetype (Blogindlæg)
• Publisher logo (60px høj og 600px bred)
• Context (Schema)
• Headline (Overskrift)
• Image
• Publiseringsdato

Sådan tester du din opsætning

AMP er et meget stringent format. Det er derfor helt nødvendigt, at alt verificerer, som det skal. Hvis dette ikke er tilfældet, vil din side ikke blive godkendt til at blive vist i AMP-format i søgeresultaterne.

Search Console
I Googles Search Console kan du se eventuelle fejl og mangler i din opsætning. Du vil blive notificeret, hvis nogle af dine sider, ligesom det er tilfældet på nedenstående screenshot, ikke verificerer.

Klikker du på knappen, føres du til AMP-oversigtsvinduet, hvor du finder langt flere detaljer omkring de fejl og mangler, din opsætning har.

Det er vigtigt, at du får testet alle dine sider godt og grundigt igennem. Til dette anbefales nedenstående værktøjer på det kraftigste. Du skal dog være opmærksom på, at Search Console meddeler fejl i et godt stykke tid efter, at de rent faktisk er blevet rettet. Nedenstående testværktøjer giver et hurtigere overbliksbillede, og du kan nemmere få verificeret dine AMP-sider.

Testværktøjer

• AMP Project Validator

Det officielle testværktøj fra AMP Project. Her bør alle dine AMP-sider validere.

• AMP Validator til Chrome

Denne Chrome-extension er meget nyttig, hvis du arbejder med AMP. Du kan nemt og lige til, tjekke AMP-implementeringen på en hvilken som helst side, direkte fra dit browser-vindue.

• Batch AMP Tester

Dette værktøj lader dig teste op mod 100 AMP-URLs på en gang, meget nyttigt på større websites, hvor man ønsker at batch-teste store dele af websites integration.

• Testværktøj til Strukturerede data

Googles eget testværktøj til strukturerede data. Indtast her din AMP-URL og ikke din almindelige webadresse, da det er din AMP-sides Schema-implementering, du skal gennemgå og ikke din normale side-versionering. Du får nu en oversigt over Schema-elementer, samt eventuelle fejl og mangler. Du kan redigere og teste live I Googles testmiljø.

Reklamer stadig en mulighed med AMP AD Landing Pages

En af de største akilleshæle for mange udgivere i forhold til AMP-teknologien er de mange begrænsninger, der kan gøre det svært for udgivere at tjene penge på deres indhold. Det er ikke muligt at overklistre sine AMP-sider med reklamer, men det er selvfølgelig muligt at køre med reklamer på sine AMP-sider gennem AMP AD Landing Pages.

AMP AD Landings Pages er landingssider bygget i AMP-HTML, der som bekendt loader meget hurtigere end en regulær side. Med ALP før-forbindes der til landingssiden, for den pågældende reklame, derfor er siden allerede delvist loadet, når en bruger klikker på den og det giver en meget hurtigere og mere flydende oplevelse.

Samtidig bliver landingssiden prefetched, og de første mange elementer på siden vil allerede være downloadet og parat, inden brugeren klikker på annoncen. Reklamer vil som udgangspunkt blive serveret på en Google Cache URL, når det er muligt, også selvom der er tale om et embed af en helt normal reklame.

Et af de elementer der kan være mest frustrerende ved at klikke på en reklame, er de mange re-directs der ofte laves, som sløver rejsen fra klik til endelig destination. Som udgangspunkt prøves det igennem AMP helt at undgå re-directs, dette gøres ved først at indlede forespørgslen, når brugeren er landet på landingssiden.

Yderligere komponenter og tags

Der er allerede på nuværende tidspunkt kommet en lang række brugbare komponenter og tags, der kan bruges i udarbejdelsen af AMP-versioneringer – her i blandt amp-analytics, amp-experiment, amp-sticky-ad mv. Der er også kommet en lang række forskellige videoafspilningsmuligheder, mulighederne til dynamisk indhold og personalisering.

Du kan finde en komplet liste over de understøttede komponenter og tags på følgende side: https://www.ampproject.org/docs/reference/components

Konklusion – Skal du i gang med AMP nu eller vente?

Om du skal implementere AMP nu eller vente, afhænger af hvilke typer af sider du benytter på dit website, og hvilke funktionaliteter de indeholder. Bruger dit nuværende website, specifikke funktionaliteter for at rendere korrekt og give den rigtige brugeroplevelse, bør du vente.

Hvis dit website blot indeholder information og ikke kræver nogle specielle funktionaliteter for at fungere i praksis, er det bare om at komme i gang med AMP. Som du har set i dette indlæg, har vi allerede implementeret det på en live webshop, og det fungerer som det skal, men vi er stadig i et tidligt stadie, og hvis du ikke er parat til at sidde og omkode hele dit AMP-setup om et par uger igen, bør du også her vente lidt endnu og se tiden an.

Det kan være relativt besværligt at implementere AMP i en lang række systemer. Der findes et hav af plugins allerede, men det er de færreste, der virker ud af boksen. Det er derfor fuldstændigt essentielt, at du får gennemtestet din implementering, hvis du vælger at gå i gang med det samme.