Pelle Sten

Två dagars hårdträning i AMP och PWA hos Google

pwautbildningiberlin_cristoffer_tomas_calle

Tre av våra utvecklare, Cristoffer Carlberg, Tomas Billborn och Carl Salmonsson, åkte till Berlin för att lära sig mer om Accelerated Mobile Pages och Progressive Web Apps direkt hos Google. Carl sammanfattar.

Trots att Googles Berlin-kontor är ett av företagets mindre kontor märks det snabbt att det är just Google som sitter i lokalerna. Vi möts direkt av den färgrika logotypen i stor skala på väggen utanför dörren. Inte heller innanför dörren kan vi gå miste om var vi är. En stor Google-logotyp skapad med post-its, sparkcyklar som ligger i en hög, en gammal klassisk men fullt fungerande fotoautomat, en mängd teknikprylar och en godisbehållare fyller upp det första rummet. Efter en mindre frukost är det dags för oss och de andra utvecklarna att grotta ner oss i ”AMP & PWA Training for Web Developers”.

Accelerated Mobile Pages (AMP)
Mer än 1,5 miljarder AMP-sidor har publicerats hittills och det blir bara fler. Det är förståeligt när vi kollar på laddningstider för den här typen av sidor. Vanligtvis har en AMP-sida laddat färdigt på under en sekund. Den snabba laddningen sker bara när besökaren kommit in via en sökning på Google. Det är nämligen så att Google börjar ladda de AMP-sidor som finns i topp bland resultaten redan innan besökaren klickat på något av resultaten. Den korta laddningstiden är minst sagt intressant med tanke på att 53% mobilbesökare lämnar sidor om de laddar mer än tre sekunder. Det är onekligen något att ha i åtanke när vi bygger webbsidor för mobila enheter.

En stor del av denna kompetensutveckling var att skriva egen kod för att testa olika tekniker. Första delen i detta var att utforska och testa olika AMP-komponenter. Här visade sig några begränsningar. AMP bygger på att utvecklare använder färdiga komponenter som har skapats av Google, att lägga in egen JavaScript är inte lätt. För att exempelvis rendera flera objekt i en lista så används komponenten "amp-list" som förväntar sig en viss struktur på JSON-svaret från den URL man anger. Anropet sköts bakom kulisserna i ett script som inkluderas i toppen av HTML-dokumentet. Varje enskild komponent kräver att dess tillhörande script inkluderas i HTML-dokumentet annars kommer sidan inte fungera. Andra funktioner som frontend-utvecklare tar för givet, till exempel villkorlig rendering, är svårt eller omöjligt i AMP eftersom vi inte kan använda egna script.

AMP Playground är det lätt att bygga sin första AMP-sida och eftersom färdiga komponenter återanvänds går det väldigt snabbt att få ihop en färdig sida. Ett fel i koden kommer visa ett felmeddelande med förslag på en lösning, exempelvis att en komponents script inte inkluderats. Det finns stora fördelar med att kunna bygga en sida så snabbt och som dessutom laddar så snabbt. För en kampanjsida skulle detta vara väldigt passande men för webbsidor som kräver interaktioner eller mer avancerade funktioner så har vi svårt att se hur det ska göras med en AMP.

Progressive Web Apps (PWA)
Den andra dagens genomgång av Progressive Web Apps cementerade våra höga förväntningar på PWA som en intressant och användbar teknik. En webbsajt med stöd för PWA suddar ut gränserna mellan en vanlig mobil webbsida och en traditionell mobilapp. I grunden är det en webbsida som med hjälp av en service worker möjliggör funktionalitet som tidigare bara var möjlig med en app.

I en PWA kan användaren tillfrågas om att lägga till en genväg på hemskärmen som på många sätt fungerar som en traditionell app. Genvägen blir då en ikon på hemskärmen vars utseende bestäms av informationen angiven i Web Manifest. I Web Manifest kan vi exempelvis ange att ikonen ska ha en blå bakgrund och att webbsidan ska visas i helskärm (utan webbläsarens adressfält) när den öppnas via genvägen.

Det är Service workers som hanterar cachen och notifieringar. På så vis kan användare utnyttja webbsajtens funktioner även utan uppkoppling samt få notiser, på samma sätt som med en mobilapp. Med andra API:er kan PWA-sajten även få tillgång till platsinformation, kamera och annat i telefonen. Självklart förutsätter det att användaren först tillåter denna service worker, ungefär på samma sätt som det fungerar i dagens appar. Många funktioner fungerar redan i Android men stödet i iOS ligger efter. Stödet i iOS förväntas förändras till det bättre i samband med nästa större iOS-release.

För oss webbutvecklare är omställningen till att jobba med PWA inte så stor eftersom vi fortfarande kan använda de tekniker vi gillar mest. Utöver det kan vi jobba med service workers för att få till funktionalitet som vi tidigare förknippat med appar. För organisationer som i dag behöver underhålla både webbsida, iOS-app och Android-app ser vi att det blir avsevärt mindre underhållstid om dessa kan bakas ihop till en PWA. Förutom enkelheten med att bara ha en kodbas för alla enheter så försvinner även ledtider för godkännande i app-butiker, som exempelvis iOS App Store. Med en PWA ser vi att friheten och möjligheterna blir större och underhållskostnaderna lägre.

Det har varit väldigt roligt och givande att vara med på denna kompetensutveckling hos Google. Vi ser fram emot fler samarbeten med Google samt att använda vår kunskap från dessa dagar i konkreta projekt.