(Bemærk: Denne artikel blev oprindeligt udgivet på ebudvikling.dk)
Når man måler performance, er det vigtigt at ens måleværktøj ligner en reel brugeroplevelse så meget som muligt. Det er svært, når store dele af World Wide Web er personaliserede til den enkelte bruger, men man kan komme det nærmere med de performance-værktøjer, vi bruger i Ekstra Bladet Udvikling (og som mange andre også bruger).
Men det kræver lidt fiksfakserier. Her kan du læse, hvordan vi har grebet det an i den spæde start og se, hvordan du selv kommer i gang.
Note: This article is also available in an English translation »
Indhold:
? Udfordringen
En meget stor faktor i brugeroplevelsen er performance. Det gælder især, når man har et website, der som ekstrabladet.dk indeholder en del annoncer, der alle som en påvirker den tekniske performance.
Da jeg i juli 2016 gjorde status på vores performance-arbejde, berørte jeg hvor stor en del af vores performance, der er påvirket af teknologi, der reelt er ude af vores kontrol.
Derudover er der dog sket en del med annonceteknologien, og her er ekstrabladet.dk ingen undtagelse. Annoncørerne forsøger i højere grad at ramme brugere, som de håber, vil være modtagelige overfor deres budskaber. Det gør de ved at bruge en række teknologileverandører, der lover at hjælpe med dette, og de forsøger at matche brugerne på baggrund af blandt andet deres cookies.
Når nu der er sket så meget i kæden fra annoncør til bruger, virker det mærkeligt, at man i vid udstrækning stadig måler performance ved at kaste en række URL’er ind i et værktøj, der så besøger dem, måler og viser os resultaterne. En lang række annoncer (og teknologien, der matcher dem med brugeren) er afhængig af, at der er cookies, og det er der ikke i en “kold” browser som den, et performance-måleværktøj sender afsted mod et website.
Derfor ville det være smart, hvis man kunne “varme” test-browseren op, så den er mere attraktiv for diverse teknologier og annoncer, der lever på et website, men først viser sig, når der er noget at målrette sig mod.
? Konceptet
For et stykke tid siden læste jeg en artikel (som jeg desværre ikke kan finde til trods for gentagne forsøg…ellers havde jeg selvfølgelig linket til den), hvor et firma, der står bag et performance-værktøj, havde et bud på en løsning. De lod deres værktøj besøge en række URL’er, inden de sendte det afsted mod den URL, der egentlig skal måles.
Det har den fordel, at test-browseren bygger en cookie-profil op (over de steder, den har besøgt), og det gør, at den pludselig bliver mere interessant for diverse personaliseringsteknologier.
I artiklen viste firmaet, at den nye målemetode viste, at websitet reelt var langsommere, end man havde troet. Det vil sige, at det altså tog længere tid at loade for de rigtige brugere end for de kolde test-browsere, som er dem, rigtig mange sætter deres lid til, når de måler performance.
? Værktøjerne
For nylig satte jeg mig for, at jeg ville foretage det nogenlunde samme forsøg med ekstrabladet.dk. Her er vi godt stillet i den forstand, at de værktøjer, vi bruger til at måle performance, allerede kan dette.
Til den fortløbende måling bruger vi SpeedCurve, mens vi bruger WebPageTest til ‘ad hoc’-målingerne. Og SpeedCurve er bygget ovenpå WebPageTest, så i den forstand bruger vi reelt kun ét værktøj. Og den form for scripting, jeg brugte i WebPageTest (og som jeg vender tilbage til om lidt) understøttes i Enterprise-udgaven af SpeedCurve, som vi bruger. Hurra.
Jeg satte mig dog for først at afprøve det i nogle manuelle WebPageTest-målinger på anbefaling af Steve Souders fra SpeedCurve. Det er resultatet af disse målinger, jeg gerne vil dele med jer i denne artikel.
? Setup’et
? Find URL’erne
Første step var at få nogle gode URL’er, jeg kunne sende WebPageTest forbi for at varme test-browseren lidt op. Her talte jeg med personer fra vores Salg/BackOffice/AdOps-team, og de gav mig følgende URL-adresser, som de mente kunne være interessante:
- http://superbrugsen.dk/tilbudsavis/
- https://www.alka.dk/bilforsikring
- http://www.nykredit.dk/dit-liv/bolig/ny-bolig
- https://danskespil.dk/oddset?intcmp=top_menu_oddset_brand
- http://www.circlek.dk/dk_DK/pg1334082175653/privat/extraClub.html
Som udgangspunkt bruger vi fem adresser. Muligvis fordi jeg bad om “en håndfuld” – tallet 5 betyder altså ikke noget magisk i denne sammenhæng.
? Lav scriptet
Nu skal vi så have WebPageTest til at besøge disse URL’er, inden den besøger den artikel på ekstrabladet.dk, vi skal have en performance-måling på. Her bruger vi det scripting-interface, der er i WebPageTest.
Heldigvis er scripting en del af WebPageTest-dokumentationen, så det er nemt at komme i gang.
På den side finder du dette eksempel:
logData 0 // put any urls you want to navigate navigate www.aol.com navigate news.aol.com logData 1 // this step will get recorded navigate news.aol.com/world
WebPageTest-scripting fungerer på den måde, at du skriver en kommando (i dette tilfælde “navigate” og “logData”) og et parameter (i dette tilfælde 0/1 eller en URL). Disse to skal adskilles med en tabulator. Det er vigtigt at huske.
Eksemplet herover besøger først ‘www.aol.com’ og derefter ‘news.aol.com’. Men fordi test-browseren har fået instruksen om ikke at gemme noget data om performance-målingen (“logData” er sat til 0) noterer den ikke noget, så at sige.
Det gør den til gengæld, når den navigerer til ‘news.aol.com/world’, fordi “logData” bliver sat til 1. Det er egentlig ret logisk.
I dette tilfælde vil det være for at måle det, jeg kalder “cache-gevinsten”. Altså, hvor meget lettere en side er at loade, når brugeren tidligere har været på en anden side, der bruger nogle af de samme ressourcer (billeder, CSS, JS-filer etc.). Det kan man også måle ved at have den samme URL to gange, hvor man så kun gemmer performance-målingen for den seneste visning.
Denne funktion kan vi bruge til det, vi vil. Ikke fordi vi vil måle cache-gevinst (de fem annoncør-websites deler formentlig ikke ressourcer med ekstrabladet.dk) men fordi de data/informationer, der bliver hentet på en side bliver gemt i en cache og som cookies.
Hvis vi vil lave et script, der besøger de fem URL’er og derefter laver en performance-måling på forsiden af ekstrabladet.dk, skal det se således ud:
logData 0 navigate http://superbrugsen.dk/tilbudsavis/ navigate https://www.alka.dk/bilforsikring navigate http://www.nykredit.dk/dit-liv/bolig/ny-bolig navigate https://danskespil.dk/oddset?intcmp=top_menu_oddset_brand navigate http://www.circlek.dk/dk_DK/pg1334082175653/privat/extraClub.html logData 1 navigate http://ekstrabladet.dk
Hvis du har brug for en copy-paste-udgave af scriptet, har jeg uploadet en .txt-fil med det ?
? Definér måleområdet
I dette tilfælde har jeg valgt at kigge på performance på artikler. Meget af vores performance-arbejde indtil videre har drejet sig om forsiden, men vi er i gang med at rulle et nyt artikeldesign ud på vores site – og en del af vores tilgang er ‘mobile first’, så det gav rigtig god mening at kigge på mobiludgaven af artikler. Derfor har jeg sat WebPageTest til at emulere en iPhone 6.
Jeg har valgt at bruge den WebPageTest-server, der er lokaliseret i Irland. Der er også andre lokaliseret tæt på Danmark, for eksempel Tyskland – men jeg har længe brugt den i Irland, så for sammenligningens skyld har jeg holdt fast i den.
Bemærk i øvrigt, at når man måler fra et andet land, bør man hænge sig mindre i de faktiske værdier. Altså er en load-tid på 9 sekunder ikke nødvendigvis 9 sekunder, bare fordi en måling fra Irland sagde det. Til gengæld kan man stole mere på sammenlignelige målinger. Altså, hvis man ændre noget på sit site, så load-tiden falder fra 10 til 5, er det jo en halvering – sålænge før/efter-målingerne er foretaget fra samme sted på samme måde, naturligvis. Og sammenlignelige målinger er jo præcis, hvad vi skal lave her.
Valget faldt på artikler i vores underholdningssektion (“flash!”), da det er en af de sektioner, der har fået det nye design og medfølgende funktionalitet.
Jeg har målt på de følgende 10 artikler. Både artiklernes publiceringstidspunkter og tidspunkterne for performance-målingerne er spredt ud over flere dage:
- Ingen skilsmissekommentarer fra Aqua-Lene
- Dansk grandprixvinder er blevet gift
- Line Baun: Derfor flyttede jeg hjemmefra
- Dronningen om sin barndom: Én sætning foragtede jeg
- ‘Paradise’-deltager ville være politiker: Derfor er planen droppet
- Efter Facebook-fight: – Jeg føler mig som en beskidt luder
- Her er verdens bedst betalte kendis
- Smukke Helenas hund passer på missen
- Ærlig Line Baun om sit livs kiks: Jeg ville da ønske, jeg aldrig havde sagt det
- Ærlig Mascha Vang: Sådan påvirker terroren mig
? Husk de generelle WebPageTest-tips
Når man bruger WebPageTest på et website, der indeholder tredjepartsindhold såsom annoncer, er det vigtigt, at man får al indholdet med. Nogle teknologileverandører vil skjule eksempelvis annoncer, hvis de kan se, det er en test-browser, for ikke at spilde annoncevisninger på en maskine. Derfor er det vigtigt at du huske at sætte denne indstilling i WebPageTest, som jeg tidligere har skrevet om.
Jeg vil også anbefale dig at se videoen ‘Velocity 2014 – WebPagetest Power Users – Part 1’ [YouTube]. Det er første del af en præsentation, Patrick Meenan fra Googles Chrome-team (og manden bag WebPageTest) holdt ved performance-konferencen ‘Velocity’ i 2014.
Her anbefaler han blandt andet at man kører et ulige antal kørsler, da WebPageTest vælger udfra medianen, når den vælger den mest retvisende måling. Han understreger også, at det er vigtigt at have mere end en kørsel, da den første kørsel varmer DNS-cachen, serveren, databasen etc. op.
Jeg har valgt at have fem kørsler i mine test. Herudover kører jeg den samme test 10 gange (altså 50 kørsler i alt), som jeg samler i et regneark og udregner gennemsnit ud fra.
? Måleresultaterne
Det hele kan hurtigt blive lidt abstrakt, hvis vi ikke har de samme data at kigge på. Derfor har jeg lagt mit regneark op på Google Docs, så du kan kigge med der. Der finder du også links til hver eneste WebPageTest-måling.
Der er intet hemmeligt i disse målinger. Alle kan måle performance på ekstrabladet.dk-artikler med WebPageTest. Jeg har blot kopieret resultaterne ind, lavet gennemsnit og sammenlignet målinger med de fem URL’er med målinger uden. That’s it.
Det mest interessante er selvfølgelig sammenligningerne, så de resultaterne får du her. Tilgiv mig, at jeg bare har taget screenshots fra Excel; jeg gad ikke bruge en halv arbejdsdag på at få dataene over i HTML-tabeller:
Et hurtigt kig ned igennem tallene afslører hurtigt, at det er Speed Index-værdien, der sker mest med. Speed Index er (udover at være dokumenteret) et udtryk for, hvor hurtigt den første visning (viewport) er klar/dukker op på brugens skærm. Det er med andre ord et (tilsigtet) udtryk for den oplevede performance – eller en stor del af den, i hvert fald.
For at få et mere generelt indtryk af forskellen i målingerne, kan vi tage gennemsnittet af de procentvise forskelle. Bemærk, at dette egentlig er total uholdbart, da der er stor forskel på artiklerne (og der trods alt kun er 10 af dem), men det kan give en form for overblik og identificere tendenser.
Her kan vi tydeligt se, at der sker noget, hvad angår netop Speed Index – nærmest en tredjedel bliver det forbedret. Det er signifikant.
Denne graf (der formentlig kan nomineres til en af verdens grimmeste grafer) illustrerer tydeligt faldet – artiklerne er sat sammen parvis efter farve:
? Konklusionen
Til trods for, at der ikke sker de store ting med de andre værdier, så ser det ud til, at den første visning bliver loadet pænt hurtigere, når testværktøjet har besøgt de fem URL’er og bygget en (indrømmet, sparsom) cookie-profil, inden den besøger artiklen på ekstrabladet.dk.
Det betyder som sådan ikke noget for brugeroplevelsen på ekstrabladet.dk, ligesom vi ikke behøver ændre noget på vores site på baggrund af disse opdagelser.
Men det er alligevel vigtigt. For det indikerer, at vores site muligvis performer bedre (i hvert fald hvad angår Speed Index-værdien, ser det ud til) for vores brugere, end vores værktøjer viser – fordi en test-browser med en cookie-profil minder meget mere om en rigtig bruger.
Ergo bør vi overveje at kigge på at ændre vores setup for performance-målinger; det vil jeg vende tilbage til om lidt.
Samtidig er det interessant, at der sker meget lidt med selve load-tiden på artiklerne. Selve artiklen loader altså ikke hurtigere hos brugeren (eller, test-browseren), men den første visning er hurtigere klar. Det kan tyde på, at der er nogle ting, der bliver hentet i en anden rækkefølge, således at det øverste på siden bliver hentet først – hvilket giver rigtig god mening ud fra et performance-synspunkt.
Derudover er det interessant, at vi faktisk ser det modsatte af, hvad jeg havde forventet. Jeg havde regnet med, at vi ville finde ud af det samme som folkene i den artikel, jeg desværre ikke kan finde; nemlig at vi så, at vores site reelt er langsommere hos de rigtige brugere end i et testværktøj.
I stedet ser vi, at i hvert fald Speed Index forbedres, når vi begynder at imitere en rigtig bruger-browser. Det er en glædelig nyhed (skønt det kan være omvendt med flere eller andre URL’er) – men hvordan kan det være sådan?
? Et bud på årsagen – og fremtiden
Disse test (skønt der er tale om en del kørsler) afslører ikke umiddelbart, hvorfor artiklerne har en bedre oplevet performance, hvis test-browseren er udstyret med cookies.
En teori, som jeg deler med en kollega i BackOffice/AdOps-team er, at profilen ganske enkelt bliver mere “attraktiv” for diverse teknologier. En del annoncer forsøger jo at ramme de rigtige brugere, blandt andet på baggrund af cookies – så denne konklusion ligger jo lige for.
Noget af det, vi skal i gang med at undersøge nu er, om det er en “binær” tilstand (altså om det er i ‘cookies’ eller ‘ingen cookies’ den store forskel ligger), eller om det er en mere levende størrelse, så det måske kan give endnu bedre performance/Speed Index, hvis vi har 25 URL’er at besøge i stedet for 5.
Det kan selvfølgelig også være, at der er et ‘glitch’ i WebPageTest. At test-browseren af en eller anden grund bliver hurtigere til at hente den første visning/viewport, når den tidligere har besøgt andre sites. Jeg tror det ikke – men i det tilfælde vil det alligevel ikke ændre på det faktum, at der er usikkerheder omkring de værktøjer, vi måler performance med.
Og med disse 10 artikler oplevede vi, at Speed Index faldt. Det kan være, det er noget andet næste gang – for eksempel har jeg netop kørt en kontrol-test på en anden artikel fra samme sektion, hvor Speed Index faldt med cirka 20 procent, mens load-tiden faldt med mere end 10 procent (i eksemplet ovenfor stod den nærmest stille).
*
Så hvad skal der ske nu? For det første skal vi måle mere.
Som nævnt ovenfor skal vi have fundet ud af, om der er en forskel i antallet af URL’er, der besøges, inden selve performance-målingen. Dette er ikke rigtig noget, vi kan bruge på vores site – men vi kan bruge det til at sætte bedre performance-test og -målinger op.
Når en brugeroplevelse er så dynamisk, som den efterhånden er, er det ekstremt vigtigt, at vores performance-målinger minder så meget om ‘rigtige’ browser-besøg som muligt.
Jeg kunne også godt tænke mig at foretage lignende målinger, hvor annoncerne (og lignende tredjepartsteknologi) bliver holdt ude af ligningen. Min tese er, at forskellen i Speed Index vil forsvinde – men det skal selvfølgelig bekræftes/afkræftes igennem test.
Når vi har fundet det setup, der fungerer bedst muligt, skal vi have ændret vores målinger i SpeedCurve, som vi bruger til de løbende performance-målinger. Her kommer vi til at stå med en interessant diskussion: For skal vi så også ændre på de målinger af andre sites, vi benchmarker op imod? Og vil de i så fald være de samme X antal URL’er, der skal besøges inden målingen – eller er der nogle, der er mere oplagte til andre sites?
I den forbindelse må vi også tage stilling til, om dette setup skal vedligeholdes, så vi fra tid til anden udskifter/tilføjer URL’er på listen.
Hvis du selv arbejder med performance på et website med annoncer eller anden personaliseringsteknologi, vil jeg anbefale, at du gør noget af det samme. Tal med andre i din organisation om, hvilke URL’er, der kan være interessante at bruge i jeres målinger.
Det kan sagtens være, du finder ud af, at der ikke er nogen forskel – men så ved I det. Og husk at holde målingerne ved lige og gentag dem, så I konstant træffer beslutninger på det bedst mulige grundlag.
? What is real?
Uanset hvad er der ingen tvivl om, at performance-målinger er et meget…levende felt, hvor man aldrig kan være helt sikker på, at man rent faktisk måler det, brugerne oplever.
Som Morpheus siger til Neo i ‘The Matrix’:
What is real? How can you define real?
Alle disse målinger understreger en pointe, som andre har fremført; nemlig at personaliseringsteknologier gør, at vi hver især oplever vores eget World Wide Web.
Det gør det umuligt at definere, hvad der er den ‘virkelige’ brugeroplevelse – og det betyder, at performance-målingerne på et website som vores altid vil være et generelt udtryk for, hvordan sitet formentlig opleves hos flest mulig brugere.
*
Foto: Pexels / Negative Space