Status: ekstrabladet.dk og performance

Hvad har vi lært efter halvandet års fokuseret arbejde med performance? Læs om, hvor vi er, og hvor vi gerne vil hen.

‘Hastværk er lastværk’. Sådan lyder et kendt ordsprog. Det gælder dog ikke i performance-arbejde, hvor indholdet helst skal vises så hurtigt som muligt.

Jeg har arbejdet fokuseret med det tekniske performance-arbejde i godt og vel halvandet år. Her er en status på, hvad vi har lært i den tid, hvor vi er nu og hvordan vi i fremtiden gerne vil arbejde med performance for et af Danmarks største og travleste websites.

Performance er noget, man oplever

Noget af det vigtigste for os er den oplevede performance. Altså ikke hvor mange (milli)sekunder et givent kald er om at blive besvaret, men hvordan det opleves hos brugeren.

I juni sidste år skrev jeg i den forbindelse om, hvorfor vi bruger Speed Index som udtryk for performance:

Derfor fokuserer vi i Ekstra Bladet Udvikling på den oplevede hastighed.

Forestil dig for eksempel to sider: Side A er 10 sekunder om at loade færdig, Side B er kun 7 sekunder om det. Men… Side A har det første skærmbillede parat efter 3 sekunder, mens Side B skal loade heeelt færdig, inden der kommer noget frem overhovedet.

Hvilken side vil brugeren opleve som den hurtigste?

Oplevet hastighed kan være en flygtig størrelse, men heldigvis findes der en måleenhed, kaldet Speed Index.

For at arbejde mere fokuseret og handlingsorienteret med performance nedsatte vi i slutningen af 2015 en performance-gruppe, og du kan læse om, hvordan gruppen arbejdede. Jeg skriver “arbejdede”, for gruppen findes ikke længere. Årsagerne er flere; primært at udvikleren i gruppen sagde op, og at det ikke rigtig gav mening for os at have en særskilt performance-gruppering. Performance-arbejdet vedrører alle.

I stedet er vi nu et bedre sted, hvor både vi i Udvikling og vores kolleger på redaktionen og i salgsafdelingen går op i god performance. Vi har især opbygget en god relation til vores Back Office-team.

Out of Control

Det samarbejde er ekstremt vigtigt, da de største ’skurke’ i forbindelse med performance på ekstrabladet.dk er tredjeparts-kode, især annoncer. Altså ting, der i høj grad er uden for vores direkte kontrol.

Vi bruger værktøjet SpeedCurve til at måle performance, men vi har haft den udfordring, at vi ikke kunne måle annoncer.

Det skrev jeg en artikel om: ‘Wanted: An Automated Performance Tool That Measures Ads’ – her er et uddrag derfra:

We dug deeper into the tests in SpeedCurve and there we found our problem: The ads weren’t there! For some reason they weren’t included in the tests in SpeedCurve. Instead we were looking at the performance of our own HTML, images, scripts etc., mostly. And it did good compared with the competition. That’s a pat on the back for our developers — but our users really don’t care about that. They get the full page, ads included.

(Artiklen er skrevet på engelsk for at nå ud til et bredere publikum 😉)

Efter den artikel gik vi i dialog med SpeedCurve, der tilbød os en ny feature, så vi kan få annoncerne med i vores performance-målinger:

This means that we can now (once again) measure the performance of our entire website. I can’t stress enough how important it is for us (and others with ads on their website) to have the full page (everything your users are seeing) rendered in your performance measuring tool.

As I explained in my earlier article, banner ads (plus the way some of them are found programmatically) are a huge performance culprit. If you don’t have these in your tests you are practically analyzing or optimizing blindfolded.

Det kan du læse mere om i denne artikel: ‘How good is your ad tech performance?’

At tredjepartsteknologi, især annoncer, har enorm stor betydning for ekstrabladet.dk’s performance er tydeliggjort af nogle SpeedCurve-grafer, som jeg har behandlet i artiklen ‘Your ads performance is your performance’.

Den vigtigste graf  fra den artikel er denne (klik/tryk for større udgave):

Tredjeparts-forespørgsler og deres betydning for hele ekstrabladet.dk
Tredjeparts-forespørgsler og deres betydning for hele ekstrabladet.dk

Her ses det tydeligt, at et fald i antallet af tredjeparts-forespørgsler giver et lignende fald i antallet af samtlige forespørgsler på forsiden af ekstrabladet.dk.

Det understreger tydeligt det paradoks, vi står med (og som andre også har, som du kan se mere om herunder): At de største udfordringer hvad angår performance er fremmed teknologi.

Derfor har vi brug for et godt samarbejde med vores Back Office-team, som jeg også nævner i den artikel:

We can, and do, continue the great cooperation we have with our Sales department, the Back Office team in particular. They have various products they use to monitor ad performance (which is obviously important for them as well) and they can reach out to where these ads are coming from, call out those ads that are performing poorly and hopefully, we will surely but safely change the world of ad performance for the better.

Hvad med et performance-budget?

Som det kan ses på graferne herover, bevæger det sig meget op og ned, afhængig af ting som, hvor tunge bannere, der er i spil. Det gør det til en interessant udfordring at sætte et performance-budget, hvilket ellers vil være en oplagt ting at gøre, når man skal arbejde med performance.

For hvordan skal budgettet se ud? Hvornår er siden for tung eller langsom – hvornår er det for meget? Og hvad, hvis vi overskrider budgettet? Kan vi så gøre noget..? Hvis det er tredjeparts-teknologi, der er årsagen, vil svaret mange af gangene være ‘nej’.

Til gengæld har vores Back Office-team som nævnt nogle måleværktøjer, de gør brug af, hvor de har sat begrænsninger på bannerne. Så det er langt fra det vilde vesten, som man ellers måske kan tro som bruger 😉.

Indstilling: Bedre tredjeparts-performance

Vi er ikke de eneste, der kæmper med performance og tredjepart. I denne video kan du se Yoav Weiss fra Akamei tale om udfordringerne ved, at tredjeparts-produkter, påvirker performance-negativt:

Han gennemgår en række muligheder – men han erkender samtidig, at ingen af de pt. tilgængelige tiltag sådan rigtigt løser problemet. I stedet har han sammen med andre foreslået en ‘Content Performance Policy’.

Den overordnede policy er inddelt i fire underemner:

  1. Feature Policy: Skal give dig som ‘website owner’ mulighed for at sætte begrænsninger for dit website, så du for eksempel forhindrer synkrone scripts og document.write.
  2. Resource Size Limits: Giver sig selv – sæt begrænsninger på størrelsen på de ressourcer/elementer, der kan kaldes/hentes. Det kan være størrelsesbegrænsninger på eksempelvis JavaScript, CSS etc.
  3. CPU and bandwidth priority: Lige nu ved browseren ikke, hvilket indhold, der er vigtigt, og hvilket der er mindre vigtigt. Man kan heller ikke skelne mellem kritisk tredjeparts-indhold og knapt så kritisk trejdeparts-indhold. Det skal gøres muligt, lyder forslaget.
  4. User Experience: Denne er svær at arbejde med, da det er besværligt at afgøre, om for eksempel en bannerannonce er irriterende.

Det er alt sammen spændende tanker, men det er formentlig et stykke ude i fremtiden. Så det er ikke noget, vi lige kan hive op af en skuffe og implementere.

Herudover er der etableret et økosystem omkring annoncerne på ekstrabladet.dk, som ikke sådan lige er til at lave om på, naturligvis. Derfor arbejder vi i stedet med prototyper og ‘Proof of Concept’-løsninger, der kan illustreres, hvordan det kan fungere med et hurtigere banner-load.

Hvad så nu?

Artikelmålinger

Vi har indtil videre koncentreret vores performance-målinger på vores mest besøgte side; forsiden. Men artikelskabelonen er jo vist langt mere end forsiden, og den gængse ekstrabladet.dk-bruger ser flere artikelsider, end de ser forsiden. Derfor er et logisk næste step, at vi skal i gang med at måle performance på artikler.

Her kan SpeedCurve blive lidt svært at danse med, da det kører på URL-basis. Altså: Vi kan ikke fortælle det, at det skal scanne en masse (eller få) artikler og så komme med en slags gennemsnit. Vi kan måle udvalgte artikler – med de fejlkilder, det medfører; om artiklen er tilstrækkelig repræsentativ for artikler etc.

CPU-målinger

De ting, vi kan måle i værktøjer som SpeedCurve og WebPageTest er ‘transport-størrelser’: Hvor meget fylder siden og de enkelte ressourcer?; hvor mange requests er der?; hvor lang tid tager det at hente? Etc.

Men et af de steder, hvor brugerne især oplever dårlig performance er, når for eksempel et banner er så tungt og kræver så meget processor-/CPU-kraft at blive renderet/vist, at siden begynder at hakke.

Dette kaldes ‘jank’, og det er svært at måle med værktøjer som disse (men ikke umuligt), og det afhænger meget af klient-maskinen, altså brugerens computer. Vores BackOffice har værktøjer, der kan måle dette, men de måler på et banner af gangen, og ikke den samlede oplevelse for brugeren og dennes CPU.

Værktøjer

Det til trods, så bliver vi på SpeedCurve. Vi mener, det er det bedste værktøj for os (skønt det perfekte værktøj næppe findes), og skal man foretage manuelle målinger, kan man lave dem på WebPageTest (som SpeedCurve er bygget ovenpå).

Herudover har vi tidligere haft adgang til Ghosterys ‘MCM Tracker Map’ i en prøveperiode. Kort fortalt er det en scanner, der viser dig de tredjeparts-tjenester, der bliver kaldt, når en given side bliver loadet. Den 22. februar så det således ud for ekstrabladet.dk:

Tredjepartstjenester, der bliver kaldt fra ekstrabladet.dk's forside
Tredjepartstjenester, der bliver kaldt fra ekstrabladet.dk’s forside

(Du kan selv prøve at køre en scanning på sitescan.ghostery.com.)

Vi overvejer at gøre brug af Ghosterys værktøj, men endnu har vi ikke foretaget os noget efter prøveperioden – men det er et værktøj, der også vil kunne være interessant for vores BackOffice, da det er nemt at se forsinkelser i fødekæden.

Som med performance-budgettet gælder det også for Ghostery-map’et, at vi skal være klar over, hvordan vi skal kunne bruge det i vores arbejde.

Performance-“modenhed”

For nylig faldt jeg over artiklen ‘Where are you on the Performance Maturity Model?’ [NCC Group]. Modellen arbejder med fire stadier for, hvor langt en organisation er nået med performance-arbejdet:

  1. Uvidende / Intet kendskab
  2. Taktisk
  3. Fokuseret
  4. Strategisk

Ud fra et hurtigt slag på tasken vil jeg nok placere os i den taktiske zone. Det er nok et meget almindeligt sted at placere sig selv, i hvert fald hvis man skal tro artiklen.

For one thing, it hints at the fact that it’s not enough for individuals – or even departments – within companies to care about the website’s performance. No one really thinks they’ve ‘cracked it’. Yes, people are working to make their websites faster, but buy-in from the rest of the business is limited, and that makes their job harder.

Vores ledelse, også i koncernen, er klar over, at performance er vigtigt. Men derfor kan det sagtens være svært at “crack it”.

Hvad er god performance værd?

Eksempelvis kan det være svært at få sat kroner og ører på god performance. På wpostats.com kan du se en række eksempler på, at dårlig performance koster tid og penge for giganter som Google og Amazon. Men de har også begge et klart ‘flow’, de skal have brugeren igennem. Det er altså noget andet, når det handler om annoncer, hvor prisen varierer meget – især med det programmatiske salg.

Det nærmeste vi kommer er nok Financial Times’ arbejde med performance [Financial Times / Engine Room blog]:

Financial Times added a one second delay to every page view and saw a 4.9% drop in the number of articles users read over a 7 day window. A two-second delay resulted in a 4.4% drop, and a three second delay saw a 7.2% drop. After twenty-eight days the two and three second variants both resulted in further drops in engagement.

Det handler om engagement. Det kan Financial Times så bruge til at sige noget om, at også antallet af sign-ups (nye abonnenter) falder med dårligere performance. Det er en erfaring, vi kan bruge i forbindelse med Ekstra (vores område for indhold, der koster penge at læse), men det siger ikke noget om den kommercielle værdi af annoncer i forbindelse med annoncer.

Vi vil meget gerne arbejde os hen imod at kunne afklare, hvad god og dårlig performance henholdsvis giver og koster på pengepungen. Men det er formentlig et svar, vi ikke kan måle os til – i stedet er vi nødt til at eksperimentere og skrue hist og her for at blive klogere.

Spørgsmål?

Hvis du synes, der er noget, jeg mangler at berøre i dette indlæg, eller hvis du har nogle spørgsmål, så læg en kommentar herunder.

Referencer


(Foto: Lee Cannon / Flickr Creative Commons)


 

Forfatter: Lars K Jensen

Lars er uddannet journalist og arbejder med teknikken bag journalistikken i udviklingsafdelingen. Han er også redaktør her på bloggen. Twitter: @larskjensen |

Skriv et svar