Sådan arbejder vi med performance i Ekstra Bladet Udvikling

Website performance er vigtigt – og her kan du læse om, hvordan vores performance-gruppe arbejder.

(Foto: Jon Davis / Wikimedia Commons)


OPDATERING / BEMÆRK:

Ikke alle arbejdsmetoderne og -processerne nævnt i denne artikel/blogindlæg er gældende. For et mere opdateret blik på vores performance-arbejde bør du læse:

‘Status: ekstrabladet.dk og performance’


Website performance (altså hvor hurtigt og smooth hjemmesider loader) har altid været en vigtig ting. Men i løbet af 2015 skete der noget, der gjorde det til et af de helt store emner for især mediehuse.

Facebook lancerede nemlig deres Instant Articles. Det går kort fortalt ud på, at for eksempel online-medier nu kan publicere deres indhold (eller, egentlig kopier af artiklerne) direkte til Facebook, så de bliver vist lynhurtigt i Facebook-app’en.

Endnu er det kun udvalgte partnere, der er med i Instant Articles, men det er på vej til at blive bredt ud. Og selv om vi i JP/Politikens Hus umiddelbart ikke er interesserede [MediaWatch.dk], så er performance-området alligevel blevet enormt vigtigt for os.

Og det gælder selvfølgelig også for os i Ekstra Bladet Udvikling.

En performance-gruppe

Derfor har vi nedsat en performance-gruppe. Den består af:

  • Undertegnede (der til daglig arbejder med brugeroplevelsen, især den tekniske del af den; altså netop performance – og som skal koordinere gruppens arbejde)
  • Vores to platformsansvarlige (desktop og mobil+tablet), der blandt andet skal løfte opgaverne videre (mere om det senere)
  • En udvikler, der agerer ‘technical consultant’ og kan grave længere ned i teknikken, end vi andre kan, og hjælpe os andre med at forstå det bedre.

Oplevet hastighed

Vores primære performance-fokus er som udgangspunkt den oplevede hastighed. Jeg har skrevet et andet indlæg her på bloggen om netop det: Derfor bruger vi SpeedIndex som udtryk for performance.

Kort fortalt har vi valgt det fokus, fordi, det er det, der siger mest om den reelle brugeroplevelse. Som jeg skriver i indlægget:

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?

Og i dét scenarie giver det ikke nødvendigvis mening at sidde og måle millisekunder. Der findes en enhed for oplevet hastighed, kaldet ‘SpeedIndex’. Den kan du læse mere om i det blogindlæg, jeg linkede til ovenfor.

Men den oplevede hastighed er naturligvis mere end blot SpeedIndex. En af fordelene ved at have (mindst) en udvikler i gruppen er, at vedkommende kan bidrage med små værktøjer, såsom en browser-knap [rasmusfrederiksen.dk], der måler frames per second (der siger noget om scroll-oplevelsen) på en hjemmeside.

Hvordan arbejder gruppen?

Da vores performance-gruppe udelukkende består af folk, der i forvejen har andre opgaver, kan vi ikke bruge al vores tid på performance-arbejdet (her er jeg dog lidt undtagelsen, da det er en meget stor del af det, jeg arbejder med).

Vi er altså ikke helt ligesom Vox Media, der i maj måned nedsatte et dedikeret performance-team [Vox Media / Product blog].

Men det har samtidig den fordel, at gruppens arbejde automatisk bliver vævet tæt ind i afdelingens andet arbejde. Vi forsøger derfor at arbejde i to ‘modes’: Planlægning og produktion/sprint.

Planlægning siger lidt sig selv. Det er her, vi samler idéer/muligheder op, prioriterer dem, sætter dem i system etc., så vi er klar til at gå i produktion.

Produktion/sprint er den periode, hvor vi får allokeret en eller flere udviklere. Bemærk, at dette ikke behøver være den udvikler, der sidder i gruppen i forvejen. Hvis vi eksempelvis skal arbejde med at performance-optimere en bestemt del af vores site, så giver det jo mest mening, at det er den udvikler, der ved mest om dette, der får opgaven.

Her følger vi den gængse arbejdsgang i afdelingen: Når vi vurderer, at vi har nok opgaver/arbejde til et sprint, tager en af de platformsansvarlige opgaven/opgaverne videre, så vi får allokeret en udvikler. Undervejs i et sprint vil jeg typisk sætte mig i nærheden af udvikleren for at hjælpe med at teste, verificere, svare på eventuelle spørgsmål etc.

Når sprintet er overstået, samler vi op: Hvad fik vi så ud af det? Var der noget, der ikke blev lavet? Hvorfor? Skal det med i næste sprint? Og så videre.

Herudover kan vi i gruppen også udarbejde anbefalinger, eksempvelvis til leverandører, der vil have elementer eller andet på vores website eller til annoncører (lidt mere om det senere).

Dokumentation

[Foto: Kheel Center / Flickr Creative Commons]
Foto: Kheel Center / Flickr Creative Commons
Jeg er typen, er elsker at have ting skrevet ned. Det betyder, at der er mindre at huske, og det minimerer i dén grad risikoen for misforståelser, da det aftalte jo er nedfældet sort på hvidt.

Og ej heller performance-området undgår min dokumentationstrang. Derfor er der naturligvis et arbejdsdokument, der indeholder vores succeskriterier (se dem herunder) og fortæller, hvorfor vi har en performance-gruppe og skitserer, hvordan den arbejder (det var det, jeg skrev lidt om tidligere).

Jeg sørger også for, at der efter hvert møde bliver sendt et referat rundt til de andre deltagere. Når referatet er godkendt, sender jeg det til min teamleder, vores udviklingschef og afdelingens udviklingsdirektør.

Derved er det nemt for dem at være opdaterede på vores arbejde i gruppen, og vi slipper for opslidende statusmøder med den evindelige ‘bordet rundt’. Det giver også en god gevinst for os i gruppen, at vi nemt kan backtracke og se, hvad vi aftale på et møde for tre uger siden.

Succeskriterier

https://commons.wikimedia.org/wiki/File:High-speed_train_warning_sign_at_Kingston,_RI,_train_station.jpg
Foto: Daniel Case / Wikimedia Commons

Når man sidder i en gruppe, er det ufatteligt vigtigt, at årsag (hvorfor er vi her?), rammer (hvordan skal vi arbejde?) og succeskriterier (hvad skal vi opnå?) er klart definerede. Det er ikke altid lige let, men det er altid givet godt ud, og rammer og succeskriterier kan man altid opdatere – selvfølgelig ikke for tit, naturligvis.

I vores performance-gruppe har vi valgt at starte ud med fem succeskriterier:

  1. Vi skal forbedre performance på ekstrabladet.dk og måle resultaterne af vores arbejde.
  2. Vi skal skabe synlighed omkring performance og vores arbejde med det.
  3. Vi skal sikre, at alle interessenter på Ekstra Bladet har en fælles forståelse af performance.
  4. Vi skal, på lidt længere sigt, have etableret en check-liste, som nye produktioner skal ‘bestå’.
  5. Vores prioriteringer skal afspejle og/eller være koordineret med, hvad der optager andre afdelinger på Ekstra Bladet.

Det er planen, at vi tager succeskriterierne op til revision om 3-6 måneder, afhængig af det kommende performance-arbejdes…performance :-)

Især det femte succeskriterium er vigtigt, og det vil jeg gå lidt mere ind i her:

Samarbejde med resten af Ekstra Bladet

I organisationer som vores (Ekstra Bladet) kan det til tider være svært at være ‘in sync’ med, hvad der optager andre. På performance-området er det vigtigt, at vi eksempelvis ikke bevæger os ud af en tangent og knokler og knokler med opgave-X, hvis problem-Y er det altoverskyggende performance-emne på redaktionen eller i vores salgsafdeling.

Derfor nedsætter vi samtidig også et performance-netværk. Det består af tre personer:

  • Undertegnede
  • En person, der arbejder med forretningsudvikling i vores salgsafdeling
  • Redaktionens ‘tekniske projektleder’, som agerer som en slags forbindelsesofficer mellem redaktionen og udviklingsafdelingen.

Netværkets fornemmeste opgave er at sikre, at performance-gruppen lever op til succeskriterium nummer 5. Hvis noget optager redaktionen eller salgsafdelingen, så bliver det taget med til og op i netværket, hvor vi sigter efter at mødes hyppigt. Netop for at undgå, at der er nogle, der kommer til at arbejde ud af tangenter.

Det kan være en undren i redaktionen over, at side-X loader langsomt, eller hvis der er et nyt annonceformat på vej, hvor det vil give god mening at teste performance inden lanceringen.

Synlighed

https://www.flickr.com/photos/diversey/4573842992
Foto: Tony Webster / Flickr Creative Commons

Når vi starter en ny gruppe til at arbejde med noget så relativt flyvsk som performance, så er det vigtigt, at der er synlighed omkring det. Derfor skal vi blandt andet være nogenlunde faste gæster på udviklingsafdelingens månedsmøder.

Herudover får vi sat en skærm op ved min plads, der viser aktuelle grafer eller andre målinger af performance på typisk ekstrabladet.dk. Det er altså ikke så meget for, at vi skal reagere på en graf, der for eksempel viser, at vores performance på forsiden pludselig halter (selvom det naturligvis vil blive gjort alligevel), men det er lige så meget for at skabe synlighed omkring arbejdet.

Og forhåbentlig får vi nogle til at snakke om det.

Hvad så med de der annoncer?

Man kan jo dårligt tale om website performance uden også at tale om annoncer; de er lidt elefanten i rummet.

Vi kan se allerede nu, at mange af de performance-issues, vi oplever på ekstrabladet.dk skyldes bannere – især bannere, der lander på vores site via det programmatiske salg. Disse annoncer kommer typisk med en rygsæk fyldt med tracking og andre scripts – eksempelvis observerede performance-gruppens udvikler et simpelt banner, der genererede syv iframes. Det er i overkanten.

Og ofte handler det netop mere om, hvordan banneret er bygget op end om, hvordan det lander på vores site. En anden af vores udviklere stiftede bekendtskab med et banner, der kom med syv JavaScript-filer i rygsækken – årsagen var, at det var bygget i et framework-program, såsom Adobe Edge Animate. Han kunne få den samme funktionalitet ind i banneret med cirka 20 linjer kode. Tal om performance-optimering.

Men den store udfordring her er naturligvis ikke at konstatere det; det er at gøre noget ved det. For en ting er, at vi nedsætter performance-gruppe og -netværk. Hvordan giver det hurtigere og bedre bannere?

Vi er heldigvis ikke uden muligheder. Dels sidder der jo i netværket en person fra vores salgsafdelings enhed for forretningsudvikling, der kan tage anbefalinger med ‘den anden vej’, så at sige. Og dels sidder vi i udviklingsafdeligen tæt på salgsafdelingen, så det er vores håb, at der her kan opstå et samarbejde og samhørighed omkring behovet.

Som vores fjerde succeskriterium siger, kunne vi godt tænke os at opstille en slags tjekliste til nye produkter, også bannere, som vi løber dem igennem, inden de kommer på sitet. Vi er endnu et stykke fra den virkelighed, men det er den rette vej at gå.

Anderledes bliver det med det programmatiske salg, som er mere ude af hænderne på vores salgsafdeling. Her må vi nok i stedet håbe på, at der generelt i branchen opstår en forståelse af, at performance er vigtigt – ligesom begrænsningens kunst kan være det.

Forfatter: Lars K Jensen

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

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *