Visualisering av mobil användbarhet och webbprestanda i offentlig sektor

Tableau Desktop vid visualisering av data från Google Pagespeed

Om du missat inlägget med genomsnittsvärden för svensk offentlig sektors webbprestanda & användbarhet kan det vara lämpligt att börja läsa där – då får du reda på hur mätningen gått till och för enskilda sajters prestation kan du kolla in Excel-filen. Nu två veckor efter publiceringen är det dags att nyansera dessa siffror. Och tack till Emil Öberg som föreslog att utöka jämförelsen på detta vis.

Du som läst min bok om webbanalys kanske fnissade till kring begreppet ”data puking – att rapportera siffror och inte enbart insikt – det är ungefär det som genomsnittsvärden handlar om. Denna bloggpost ska nyansera dessa siffror, sätta perspektiv på siffrorna och ger dig en chans att upptäcka eventuella knepigheter. Med andra ord kommer här en möjlighet att se hur de olika webbplatserna sprider ut sig på respektive mätvärde. På så vis kan man få en uppfattning om ifall det finns olika grupper inom datamängden.

“Risken med att titta på genomsnittsvärden (och att inte segmentera) är att det genomsnittliga värdet inte alltid är representativt för majoriteten av användare. Att allt ses ur ett så genomsnittligt synsätt att det inte finns några meningsfulla slutsatser att dra. För att dra ett exempel så är det fullt möjligt att inte bottna i en sjö som i genomsnitt endast är en meter djup. Det värdet säger väldigt lite om hur djupt det är som djupast.”

Ur boken Webbanalys – förstå och förbättra användarens upplevelse (2016)

Till min hjälp har jag haft programvaran Tableau för att smidigt bygga upp visualisering baserat på den data jag släppte i samband granskningen. Du som själv råkar ha Tableau installerat kan kolla i slutet på denna bloggpost för att ladda ner antingen extraktet eller hela arbetsboken.

Ordlista: Prevalence / prevalens betyder att, i vissa fall, är inte alla webbplatser med i samtliga mätvärden. Extremfallet är prevalens för hur mycket Adobe Flash som finns. Endast en webbplats har Flash över huvud taget, då anges genomsnittet enbart för den webbplatsen. I de allra flesta fall är samtliga webbplatser med, men det kan du se antingen i Excelfilen eller i nedan länkad visualisering hos Tableau Public.

Statistik

Nog för att genomsnittsvärden kan vara intressant, men kanske finns det två eller fler grupper för hur webbplatserna presterat. Det är vad du kan se på bilderna nedan. Det är fortfarande webbplatsernas egna genomsnitt som är med i siffrorna, men det är en början på att nyansera hur webbplatserna ser ut sinsemellan. Ett logiskt nästa steg vore att titta på all insamlad data, men innan det är möjligt måste jag komma över en dator med mer arbetsminne än 8Gb.

Notera att: För att inte göra staplarna för spretiga har värdena grupperats efter 10, 1000 och så vidare. Det anges på respektive bild hur den är grupperad. Om första stapeln har värdet ”0” och den andra ”10” betyder det att första stapeln symboliserar alla webbplatser som har 0 eller mindre än 10 som värde. Stapeln med ”10” har från 10 men mindre än 20, och så vidare.

Usability / Användbarhet

Usability - Google Pagespeed

Sammanvägt betyg mellan 0 och 100, högt är bra. Exakt vilka bristerna är finns listat under rubriken ”Förbättringspotential” nedan, men ofta handlar det om att sidan inte är responsivt byggd, att innehåll inte får plats på en mobil skärm och att duttbara designelement är placerade för tätt inpå varandra. Det är vanligt att webbplatser får 98 i betyg på användbarhet och att Pagespeeds API beklagar sig främst över att länkar/knappar är för tätt inpå varandra. Det är nog var som förklarar att majoriteten har 90-99 i betyg här. De som ligger mellan 60-69 är säkert inte responsivt byggda eller har på tok för många mobila hinder för att hålla måttet enligt Google.

Pagespeed

Pagespeed - Google Pagespeed

Ur Googles dokumentation: ”The PageSpeed Score ranges from 0 to 100 points. A higher score is better and a score of 85 or above indicates that the page is performing well.”

Intressant spridning tycker jag. Låt säga att webbplatsen har 70 eller mer i Pagespeed är den alltså bland den bättre femtedelen av testade webbplatser.

Datakvalitet och sample-rate

Här visar sig också brister i datakvaliteten upp sig (beroende på hur man ser på saken) då Karlsborgs webbplats vid testtillfället fick fullt betyg. Kollar man idag får de 81 / 100 för mobil och häpnadsväckande låga 11 / 100 för dator. Det goda resultatet i mitt test beror på att det fanns ett väldigt begränsat antal sidor att testa och att dessa sidor just då var bra anpassade för mobilt.

Om det här testet skulle behövt vara mer exakt för respektive webbplats skulle det behöva köras ett flertal gånger och att man räknar ut ett medel över hur webbplatserna såg ut under mer än en dag. Vissa sajter kan haft missöden just den dag de analyserades, som att de haft ovanligt många felsidor, eller att de stängt av bildvisning eller sådant. Därför ska du i vanlig ordning se kritiskt på innehållet, det är mer av indikativ natur.

Number CSS Resources

Number CSS Resources - Google Pagespeed

Ur Googles dokumentation: ”Number of CSS resources referenced by the page.”

Detta handlar om hur många CSS-filer som anropas för en genomsnittlig sidvisning. När jag föreläste om den prestandabudget jag fått igenom på jobbet för ett gäng prestandaentusiaster fick jag en undrande fråga från publiken. Hen undrade varför vi ”tillät” mer än en endaste CSS-fil i prestandabudgeten för Västra Götalandsregionen. Frågan är absolut befogad, men om man är för nitisk med detta medför det merkostnader för att ens utvecklare ska behöva göra omställningen. Mitt förslag är att man skärper till sig när man gör ett rejält omtag av webbplatsen nästa gång.

Men att var fjärde webbplats har 10 eller fler CSS-filer är en ordentlig underprestation i min mening. Den som gör antagandet att många filer är helt ofarligt för användarupplevelsen behöver uppmärksamt kolla in Ilya Grigoriks föreläsning på Google i/o 2016. Det är samma Ilya som släppt sin bok High Performance Browser Networking gratis på nätet – han kan det där.

Number Javascript Resources

Number Javascript Resources - Google Pagespeed

Ur Googles dokumentation: ”Number of JavaScript resources referenced by the page.”

Samma som ovanstående men för Javascript-filer (eller anrop som identifierar sig som Javascript med sin content-type). Att det var vanligt med cirka tio Javascript-filer visste jag, men att det finns fall av 40 eller fler gör mig nyfiken att gräva vidare i datakällan (när jag har mer arbetsminne till datorn).

”Nope, _mina_ användare har Javascript aktiverat!”

Det finns ett allt för vanligt antagande bland dagens webbutvecklare, nämligen att det bara är idioter som inte har Javascript ”aktiverat” i sin webbläsare. ”Jag menar, vem stänger av Javascript, det är ju ett dumt och högst aktivt beslut som den personen borde få stå för.” Sorry, det där är en kondensat av allt jag hört av de webbutvecklare som inte varit med sedan 1990-talet. Det råkar vara så att man för varje Javascript som behövs för att en sida ska fungera gör en kedja av antaganden att allt gått vägen. Att det är högst orimligt kan du se i videoklippet med prestandagurun Ilya Grigorik länkat under CSS-rubriken ovan.

Särskilt för mobilanvändares skull borde vi utgå från att inget Javascript kom fram och försöka få den upplevelsen bra nog. Det är själva essensen av webbstandard och det bland många webbutvecklare av idag okända begreppet Progressive Enhancements. Vill du läsa mer om det och dess motsats Graceful Degradation finns det i min första bok, Webbstrategi för alla

Number Resources

Number Resources - Google Pagespeed

Ur Googles dokumentation: ”Number of HTTP resources loaded by the page.”

Här listas antalet filer totalt som behövs per genomsnittlig sidvisning på respektive webbplats. Det man behöver tänka på är att testet utgått ifrån respektive webbplats startsida och där samlat länkar till undersidor att testa. I de fall där startsidan/webbroten inte har många länkar till undersidor kommer färre undersidor späda ut den bild av webbplatsen som startsidan ger. Det kan också vara så att startsidan och de sidor den länkar till inte är ett representativt genomsnitt för webbplatsen – men jag har inte listat ut något sätt att normalisera dessa data.

Kan inte tycka att resultatet är särskilt förvånande, dock är det lite tråkigt om man tänker på att väldigt många av dessa filer handlar om sådant som inte delats upp för användarens skull.

HTTP/2 ändrar praxis något

Om ens webbplats gått över till att skicka filer via den nya versionen av protokollet HTTP är det istället god praxis att dela upp sina filer. Åtminstone lite grand, och åtminstone om man inte primärt vänder sig till folk med gamla Internet Explorer.

Jag gissar att väldigt få inom offentlig sektor tagit detta steg redan. Kanske har någon som byggt nytt börjat använda innehållsnätverk (CDN – Content Delivery Network) som drar nytta av HTTP/2, säkert har någon också valt att låta ”någon annan” drifta deras Jquery-filer i molnet och på den vägen fått HTTP/2 på köpet.

Number Static Resources

Number Static Resources - Google Pagespeed

Ur Googles dokumentation: ”Number of static (i.e. cacheable) resources on the page.”

Skillnaden mellan dessa filer och de som nämnts i rubriken innan är att dessa anser Google borde gå att ha i en cache, eller buffer som det heter på svenska. Det innebär att Google tycker de verkar vara av mer eller mindre statisk karaktär och borde ha en lång livslängd (TTL – Time To Live) specificerad så de inte laddas ner på nytt i onödan.

Du som läst det mesta av vad jag skrivit kring prestanda har nog inte missat mitt ständiga exempel om att de flesta av oss kan anta att webbplatsens logotyp har en förväntad livslängd på mer än fem minuter i taget 🙂
Inte minst kan det verka underligt om man på sin kriswebb anger loggans tänkta livslängd till bara några minuter. Som om man inom kort mest hela tiden har beredskap att byta ut logotypen! 😛

Låt filerna leva – länge…

Min rekommendation brukar vara att sätta minst 30 dagars förväntad livslängd på alla filer man inte har för anledning kommer ändras. Om något ändå ska ändras får man helt enkelt döpa den uppdaterade filen till något nytt och ladda upp den och de filer den möjligen är beroende av. Det blir lite som en pakethantering, vilket de flesta utvecklarna bör vara bekanta med sedan länge.

Gör du på detta sätt kommer filer inte skickas i onödan och sidan blir användbar oerhört mycket snabbare.

Number Hosts

Number Hosts - Google Pagespeed

Ur Googles dokumentation: ”Number of unique hosts referenced by the page.”

Den här är extremt intressant apropå Dagens Nyheters granskning av offentlig sektors bristfälliga värnande om användarnas integritet. Så som du ska läsa ovan staplar är att drygt 20 % blandar in minst 10 olika parter för att visa upp en sida. En enskild webbplats kan absolut själv stå för fler än en enda part, exempelvis på följande sätt för en sidvisning:

  1. www.webbplats.se
  2. bilder.webbplats.se
  3. javascript-och-css.webbplats.se
  4. piwikstatistik.webbplats.se

Just dokument – som PDF och Word – räknas dock inte in här vad jag kunnat utröna, eftersom de inte laddas in automatiskt (om de nu inte iframeas in).

Troligtvis beror dessa höga siffror på att man använder Google Analytics, Facebook, Twitter, övriga dela-knappar, hämtar diverse kod från innehållsnätverk och lånar in filer i största allmänhet. Man kan definitivt diskutera vad god praxis är här med tanke på att man historiskt för många webbläsares skull hade begränsade möjligheter att skicka många filer samtidigt från en enda domän. Därför gick många över till att lägga bilder separat, samt att ha även egen webbplatsspårning på en egen subdomän. Personligen känns det helt normalt med 4-5 stycken.

Image Response Bytes

Image Response Bytes - Google Pagespeed

Ur Googles dokumentation: ”Number of response bytes for image resources on the page.”

Bilden kan klickas på för att se fler detaljer. Varje stapel är uppdelad i grupper om 100 Kb, alltså har nästan hälften av webbplatserna under 200 Kb bilder på en genomsnittlig undersida. Sedan finns det ett gäng absurda undantag på över en Megabyte bilder per sidvisning – kolla rubriken ovan angående datakvalitet om min hypotes kring detta.

Nu var det tiotusentals sidor på dessa 557 webbplatser som undersökts. I de fall där startsidan fått oproportionellt stort inflytande på genomsnittet kan webbplatsen framstå som tyngre än vad den är. Samtidigt kan vi jämföra med den statistik som httparchive samlat in om hur webbplatser såg ut i november 2016, då är det i genomsnitt 1,6 Mb med bilder. Så detta resultat kan tyckas vara i underkant. Samtidigt är det kanske inte fyllt så mycket en upplevelse i bilder som är eftertraktat på webbplatser från svensk offentlig sektor?

HTML Response Bytes

HTML Response Bytes - Google Pagespeed

Ur Googles dokumentation: ”Number of uncompressed response bytes for the main HTML document and all iframes on the page.”

Detta avser den strukturella kod och ofta majoriteten av innehållet, det vill säga HTML-koden. Eftersom det varierar om webbplatserna drar nytta av komprimering uppges dessa siffror i okomprimerad version. Ifall komprimering används är det ofta så pass effektivt att det i praktiken bara blir en tiondel så mycket att skicka.

Inte bara vettigt innehåll i HTML

Många med äldre webbplatser som bygger på Microsofts webbteknik har en massa nonsens inblandat i HTML-koden. Det kallas för view state och var ett försök att få användarnas webbläsare att komma ihåg saker åt webbservern, exempelvis vad som var ifyllt i ett formulär. Man försökte göra webben mer lik klassisk systemutveckling. Jag har själv försökt koda bort detta i äldre versioner av Episerver men kan konstatera att det inte är värt det, det är bättre att uppgradera till MVC som designparadigm.

CSS Response Bytes

CSS Response Bytes - Google Pagespeed

Ur Googles dokumentation: ”Number of uncompressed response bytes for CSS resources on the page.”

Här kommer webbsidans presentation in. Om jag får lov att raljera så lägger man enligt denna visualisering praktiskt taget alltid mer krut på hur något ser ut (CSS) än vad man har att säga (HTML). CSS är de designinstruktioner som berättar för webbläsaren hur något ska se ut. Det är oerhört vanligt att man baserar sin webbplats på något ramverk – likt Bootstrap – och passar man sig inte noga kommer det med en massa extra på köpet.

CSS 101 – det som behövs när det behövs

Optimalt vore förstås att bara skicka det som behövs. Det var lite åt det hållet folk tänkte kring designprincipen Adaptive Web Design, vars beundrare beklagade sig över hur slösaktiga de flesta responsiva webbplatser var när de började dyka upp 2012. Samtidigt kan man undra varför en person som via en mobil kollar en webbplats ska få en massa CSS som endast gäller mycket större skärmar?

Många välbyggda webbplatser som är byggda helt nyligen är visserligen mycket bättre på detta, men ofta får man ta emot instruktioner för hur en bildkarusell ska se ut även fast du aldrig besökt en undersida som dragit nytta av den koden. När man går över till HTTP/2 blir det god praxis att dela upp sina filer, då är det verkligen dags att tänka designkomponenter och bara skicka det som behövs just när det behövs – och det kommer gå snabbare!

Javascript Response Bytes

Javascript Response Bytes - Google Pagespeed

Ur Googles dokumentation: ”Number of uncompressed response bytes for JS resources on the page.”

Precis som med CSS är det spännande att de flesta webbplatser skickar mer kod för att sköta interaktioner (Javascript) än det faktiska innehållet man ska interagera med (HTML). Några webbplatser skickar säkert en del av innehållet med Javascript, men snarare än att slå sig för bröstet borde man då kolla in videoklippet ovan med Ilya Grigorik och kolla in designprincipen Progressive Web Apps. Man kan nämligen inte räkna med att varenda Javascript når fram i någon särskilt stor utsträckning på ett mobilnät.

Text Response Bytes

Text Response Bytes - Google Pagespeed

Ur Googles dokumentation: ”Number of uncompressed response bytes for text resources not covered by other statistics (i.e non-HTML, non-script, non-CSS resources) on the page.”

Vad jag förstått handlar detta oftast om egna teckensnitt, kanske också bilder som kodats om med base64. Just när det gäller teckensnitt brukar de väga in på 60 Kb för att man ska få vanlig, fet, kursiv. Vissa använder dessutom flera teckensnitt på sin webbplats. Som du säkert listat ut så blir dessa teckensnitt några extra filer att ladda ner.

Other Response Bytes

Other Response Bytes - Google Pagespeed

Ur Googles dokumentation: ”Number of response bytes for other resources on the page.”

De allra flesta har inget eller väldigt lite av andra sorters filer än de som redan angetts.

Total Request Bytes

Total Request Bytes - Google Pagespeed

Ur Googles dokumentation: ”Total size of all request bytes sent by the page.”

Det här handlar om den HTTP-förfrågan som skickas för att hämta en sida. Egentligen behövs väldigt lite skickas mellan användarens pryl och webbservern, främst är det lite identifikation om vilken sorts prylen är (så kallad user agent) och vilket innehåll som efterfrågas. Dock gömmer sig cookies i denna förfrågan. Ett inte helt ovanligt misstag är att man aktiverat cookies även från sitt innehållsnätverk, då kommer det helt i onödan att skickas cookies tillsammans med en bild, exempelvis.

Response code

Responsecode - Google Pagespeed

Ur Googles dokumentation: ”Response code for the document. 200 indicates a normal page load. 4xx/5xx indicates an error.”

En webbsidas statuskod är vad som på tekniskt språk anger om sidans innehåll kunde levereras på ett bra sätt. Nummer du säkert känner igen är 200 (för att det gick bra), 301 & 302 (för att vi vill skicka vidare användarna), 404 (för att sidan inte kunde hittas) och du har säkert stött på 500 någon gång när webbplatsen bokstavligen landat på ansiktet. Siffrorna i denna visualisering är genomsnitten per webbplats grupperade efter 20 för att inte göra det så spretigt i kolumnerna. Man kan konstatera att det nästan alltid funkar som det ska, men att det finns webbplatser med ganska höga genomsnittlig kod, 320 och mer är mycket illa.

Förbättringspotential

Hur ser sajterna ut generellt när det gäller den förbättringspotential som Google gärna ser enligt sin syn på en mobilanvändares behov. Låga siffror i nedan visualiseringar är bra, det betyder att det inte finns mycket att förbättra. Siffrorna är viktade efter hur allvarlig dess inverkan är på en mobilanvändares upplevelse av användbarhet och prestanda.

Den måttstock som Google har – alltså hur de definierar prestanda – handlar om två aspekter på snabbhet, nämligen:

”PageSpeed Insights measures how the page can improve its performance on:

  • time to above-the-fold load: Elapsed time from the moment a user requests a new page and to the moment the above-the-fold content is rendered by the browser.
  • time to full page load: Elapsed time from the moment a user requests a new page to the moment the page is fully rendered by the browser.”

About Pagespeed Insights

Det är alltså vad som kallas syntetisk prestanda, motsatsen till RUM (Real User Monitoring). Det är inget fel i sig med syntetisk testning, men det går definitivt att diskutera ifall en syntetisk förbättring har ett märkbart genomslag i den upplevda prestandan av en livs levande användare.

Configure Viewport

Configure Viewport - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that your page does not specify a viewport, or specifies a viewport that does not adapt to different devices.”

Detta är en av aspekterna av användbarhet, specifikt här för en mobil användare. Det är förstås viktigt att idag erbjuda en webbplats som visar upp sig på en mobilanvändares villkor, det vill säga skalar innehållet bra på en mobilskärms något begränsade yta. Väldigt många inom offentlig sektor har byggt sina webbplatser responsiva, men även bland dem hittar jag ibland icke-responsiva felsidor, specialsidor och att man av diffus anledning landar på en inloggningssida ämnad för de egna webbredaktörerna.

Kör man detta test på sina egna webbsidor tycker jag inte man ska acceptera att någon endaste sida har annat än nollresultat.

Size Content To Viewport

Size Content To Viewport Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that the page content does not fit horizontally within the specified viewport size, thus forcing the user to pan horizontally to view all the content.”

Detta är en av aspekterna av användbarhet. Vanliga misstag är att bilder inte gjorts responsiva, tabeller som inte få plats på små skärmar eller att man huvudlöst slängt in en iframe för att få med något uråldrigt system man inte kan ge upp riktigt ännu. I de flesta fall presterar dessa webbplatser riktigt bra, men det finns några extrema undantag (som kan ha varit tillfälliga just när testet kördes).

Ska man välja en nivå till sin prestandabudget tycker jag nog att åtminstone samtliga sidor som identifierats som viktiga ska ha nollresultat.

Size Tap Targets Appropriately

Size Tap Targets Appropriately Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that certain tap targets (e.g. buttons, links, or form fields) may be too small or too close together for a user to easily tap on a touchscreen.”

Detta är en av aspekterna av användbarhet. Väldigt ofta placeras länkar på höjd i listor, eller att knappen för att skicka ett formulär ligger alldeles för nära knappen som rensar innehåll (en knapp jag aldrig förstått att vi behöver). Detta är väldigt vanligt även bland de responsiva webbplatser som får över 90 i användbarhetsbetyg, kanske den vanligaste bristen på i övrigt välbyggda webbplatser.

Fulhacka CSS för att nå 100 av 100 i användbarhet

Det här går ofta att avhjälpa i efterhand med att justera lite i CSS:en. Sätt extra mycket margin-bottom på punkterna i en lista med länkar och knuffa isär knappar så kommer du långt. Tänk dig att du ska träffa rätt varje gång med din ovana tumme, eller ha en sportslig chans att träffa rätt med armbågen. Detta är viktigt både för den mobila användare men har alltid varit viktigt för de med motoriska funktionsnedsättningar (vilket kan vara vem som helst som inte lyckas sänka finkänsligheten på en spelmus).

Ska man välja en nivå till sin prestandabudget tycker jag nog att åtminstone samtliga sidor som identifierats som viktiga ska ha nollresultat.

Use Legible Font Sizes

Use Legible Font Sizes Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that text in the page is too small to be legible.”

Detta är en av aspekterna av användbarhet, det är högst grundläggande för oss seende att vi ska kunna uppfatta text. I detta fall är åtminstone delar av texten på tok för liten för att vara lätt att läsa. Även här drabbas mobilanvändarna extra mycket då man utomhus inte kan räkna med helt ergonomiska ljusförhållanden, samt att skärmen är liten. Det här är vad som kallas för responsiv typografi, att man planerat textens storlek och utseende efter varierande förhållanden runt användaren. En högst grundläggande början är att man ser till att text kan förstoras om användaren så önskar, men det börjar vara länge sedan jag såg någon webbplats där det inte var möjligt.

Ska man välja en nivå till sin prestandabudget tycker jag nog att åtminstone samtliga sidor som identifierats som viktiga ska ha nollresultat.

Optimize Images

Optimize Images - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that the images on the page can be optimized to reduce their filesize without significantly impacting their visual quality.”

Det finns massor med knep om hur man minskar en bilds storlek, många av dem finns att läsa i min bok Webbstrategi för alla

Google beklagar sig för ett antal olika saker här. Dels kollar de om det laddas in en onödigt högupplöst bild (som skalas ner av webbläsaren) men också om bilden är sparad för webben på ett kompetent sätt. Många av oss inom offentlig sektor har diverse bildsystem för att avhjälpa webbplatsen med bildhantering. Ur denna synvinkel är det inte alltid de systemen är så värst hjälpsamma, eller lätta att konfigurera. Det är också en svår balansakt att hitta ett generellt bra förhållande mellan bildkvalitet och filstorlek – så ja, detta är nästan värt att göra manuellt på de viktiga sidorna på webbplatsen.

Grafen ovan går hela vägen till 320 vilket är en intressant avvikelse. Det finns sidor som laddar ner upp till 10 Mb stora bilder, så har en sådan webbplats haft få andra sidor med normala bilder hamnar den långt ut i skamvrån i denna jämförelse.

Om man vill ta med bildoptimering i sin prestandabudget är det nog klokt att de viktiga sidorna har som högst 5-10 i detta mätvärde, men helt klart vill man fånga upp egna avvikelser på över 30. Kanske ska det larmas till någon redaktionsbrevlåda om en sådan bild hamnar på den publika webbplatsen?

Prioritize Visible Content

Prioritize Visible Content Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that additional network round trips are required to render the above the fold content of the page.”

Den här regeln kallas ibland för 14Kb-regeln då det är i paket om cirka 14,6 KB som innehåll hämtas från webbservern. I de första 14 Kb som skickas är det önskvärt om allt innehållet som syns innan användaren börjar skrolla kan rymmas (den så kallade above the fold). Om det är möjligt att få plats med HTML-innehållet, samt CSS och nödvändig Javascript. 14 Kb är egentligen ganska mycket data, men definitivt försumbart om du finns siffrorna från avsnittet om webbplatsernas statistik.

Critical path – above-the-fold CSS

Ett förhållningssätt till denna utmaning har varit att stoppa in CSS-kod inline i HTML-dokumentet, den CSS som behövs för ”critical path” – det ovanför vecket i tidningsliknelsen vi lånat från trycksaksbranschen. Det finns hjälp på nätet för att generera fram den CSS-kod som behövs för detta, men som användbarhetsexperten Peter Antonius snällt nog påvisat för mig är det inte alltid det som visar upp sig snabbt går att börja interagera med. Mitt förslag här är att anlita någon som är expert på frontend/gränssnittsprogrammering om man får ett betyg man inte kan leva med.

Enable Gzip Compression

Enable Gzip Compression Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that compressible resources were served without gzip compression.”

Idag finns det två populära komprimeringstekniker, den ena är Gzip som används generellt för diverse textfiler, men mer nyligen har även Brotli dykt upp. Brotli kan komprimera de teckensnittsfiler du i min mening gärna ska undvika att ens ha. Om du inte använder Gzip kan helt vanliga textfiler ta tio gånger så lång tid att skicka, till ingen nytta. Som visualiseringen visar sköter de flesta sig ganska bra, men med några extrema undantag.

Googles viktning är inte öppen

Exakt hur Google viktar dessa faktorer är mig veterligen inte något de berättat öppet. Så hur stor påverkan en tung textfil har jämfört med en liten textfil är inte känt. Jag gör ett kvalificerat antagande att de som får uselt betyg på detta (högre än 20) är desamma som skickar väldigt mycket Javascript och CSS. Jag tycker att en tung HTML-fil borde vara mer ok då den kan antas ha ett innehåll användaren kan ta del av – inte bara utseende och interaktion.

Leverage Browser Caching

Leverage Browser Caching Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that the response from your server does not include caching headers or if the resources are specified to be cached for only a short time.”

Ett väldigt vanligt problem med detta mätvärde är att webbplatsstatistik som använder klientteknik av nödvändighet måste undvika att hamna i webbläsarens cache. Där ingår Googles egna produkt Analytics. Åtminstone fram till nyligen var det inte möjligt att få fullt prestandabetyg om man använde Google Analytics, något som är både ironiskt men också ärligt om vilken påverkan externa Javascript har på prestandan.

Störst problem brukar dock ha med helt andra saker att göra. Som att bilder, Javascript och CSS-filer inte är konfigurerade att stanna en vettig tid i webbläsarens cache. Poängen här är att en återkommande besökare inte ska behöva ladda hem filer som inte förändrats sedan det föregående besöket.

Det går förstås oändligt mycket snabbare att _inte_ skicka en fil, så en cache-strategi är på sin plats när man bygger om lite mer nästa gång. Men på många webbplatser jag inspekterat är det en smal sak att aktivera en förlängd cache-tid på statiska filer. Till WordPress finns det plugin som hjälper till med TTL (time to live) och att ange HTTP kod ”304 NOT MODIFIED”.

Main Resource Server Response Time

Main Resource Server Response Time Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that your server response time is above 200 ms.”

I de fall jag inspekterat extremvärden gällande detta mätvärde har det alltid handlat om dålig prestanda på huvuddomänen, aldrig att innehållsnätverk eller tredjeparter varit långsamma. Det är högst anekdotiskt, men som bilden visar är det för det mesta frid och fröjd vilket gör det svårt att lära sig av när det felar.

Även fast Google inte är öppna om hur denna viktning går till kan det göra nytta i en prestandabudget, åtminstone för att reglera de viktigaste sidorna. Är det stor skillnad mellan olika sidor på webbplatsen kan det peka på stor komplexitet bakom kulisserna, att en utvecklare borde kolla om det behövs någon form av cache i bakgrunden eller om det är värt att inspektera koden backend.

Minify CSS

Minify CSS Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rules triggers when PageSpeed Insights detects that the size of one of your resources could be reduced through minification.”

Det är tydligt att det nästan aldrig är värt att minifiera sin CSS-kod. Minifiering går ut på att man försöker effektivisera kod genom att ta bort sånt som inte måste vara där. Bland annat att ta bort extra mellanslag, tabbar, kommentarer i koden, m.m. De webbplatser som har 10 eller mer i detta mätvärde har nog större problem än just detta.

Minify HTML

Minify HTML Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rules triggers when PageSpeed Insights detects that the size of one of your resources could be reduced through minification.”

Det här är extremt sällan ett faktiskt problem. Minifiering av HTML-kod är precis som för CSS- och Javascript, man tar bort sånt som inte måste vara där för att webbsidan ska fungera. Den som får lida för det är den som av någon anledning vill läsa koden bakom sidan. Hamnar du i det problemet ska du välja att inspektera koden i en modern webbläsare – inte välja ”Visa källa”.

Minify Javascript

Minify Javascript Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rules triggers when PageSpeed Insights detects that the size of one of your resources could be reduced through minification.”

Att man ändå kan ha lite nytta – enligt Google – med att minifiera sina Javascript-filer har nog mer med filernas storlek att göra, tror jag. Men visst är det värt att kolla om ens egen webbplats har sidor med 10 eller mer på detta mätvärde, men troligen är problemet då större än att putsa på Javascripts innehåll.

Minimize Render Blocking Resources

Minimize Render Blocking Resources Rule Result - Google Pagespeed

Ur Googles dokumentation: ”This rule triggers when PageSpeed Insights detects that a page includes render blocking external stylesheets [och Javascript], which delay the time to first render.”

Avslutar potentialen med den största utmaningen vi har med dagens responsiva webbplatser – de är ofta blanka länge i väntan på att ladda in allt som krävs, eller måste ritas om för att något interaktivt förändrats.

Inte direkt enkelt att fixa :/

Det här är definitivt inget man fixar beer o’clock en fredagseftermiddag. Visst går det att laborera med att försöka skjuta upp vissa Javascript till att ladda in i efterhand eller först vid behov, men det är sällan lika enkelt i praktiken som när man leker med tanken. Det närmsta fulhack jag hittat är att kolla så Javascript och CSS kommer i rätt ordning, lite försiktigt flytta kod inline samt att försöka minska antalet filer. Men bygger man om är detta något man bör ha hög ambition kring då det har stor potential kring upplevd prestanda hos riktiga användare – det är ju det som räknas i slutändan.

Ladda ner filer, läs dokumentation eller lek med Tableau-filerna

Missa inte att kolla in webbanalys-boken! Den kan köpas av förlaget Intranätverk (för bästa pris), Adlibris eller Bokus

Boken om webbanalys tar upp tips på fler verktyg än Tableau för att visa upp det som ska analyseras. Bland annat kan Kibana (ur ELK-stacken) vara bra för att ge ett mer statiskt analysverktyg inom en större organisation. Dessutom tas fler mätmetoder upp – Google Pagespeed är bara en i mängden 🙂