WebperfDet finns mycket att tänka på innan man startar ett nytt webbprojekt. Nedan punkter är sådant jag skulle vilja påstå allt för sällan diskuteras innan projekt kommer igång på allvar.
Dessa punkter (i outvecklad form) har jag tagit fram till min arbetsgivare, men i denna bloggpost försöker jag fylla respektive punkt med innehåll - berätta gärna i kommentarerna vad du tycker, om något saknas, etc.
Tanken är att man använder nedan rubriker i ett dokument som följer med projektet fram till leverans - och sedan lämnas över till ens egen kontrollinstans (ens egen webbanalytiker?) för att se till att man inte glider ifrån den initiala överenskommelsen.
Ska vi använda någon annans innehållsnätverk?
Innehållsnätverk (Content Delivery Networks) används ofta för att slippa ha filer lokalt på en egen webbplats. I många fall ger det snabbare nedladdningstid eller andra prestandafördelar för besökaren. Vanligaste varianten lär vara att hämta spårningskod för webbanalysverktyg som Google Analytics på detta vis. Däri ligger också den största anledningen till att man behöver fundera igenom sin användning av innehållsnätverk - de inkräktar mer eller mindre mycket på besökarens personliga integritet.
Exempel utöver Google Analytics är de webbplatser som har ett flöde från Facebook integrerat, eller de med knappar för att dela inlägget i sociala medier. Nästan alltid när man får en kod att klistra in från en tjänst kommer denna problematik på köpet. Tänk inbäddningskod från videotjänster, så fort en bild eller annat visuellt ska visas hämtas det ofta från tjänstens egna webbservrar.
Man kan driva sitt eget innehållsnätverk, men där kan du förstås inte placera Facebooks nyhetsflöde eller Google Analytics spårningskod. Men mycket annat, som bilder, video, designramverk som jQuery som används för att få webbplatsen att fungera som det är tänkt. Då kan man hämta hem lite av den vinsten som ett innehållsnätverk erbjuder. För dig som driver en mycket liten webbplats kan du kolla exempelvis på webbhotellstjänster som Loopias Autobahn som är specialgjord för att snabbt skicka filer som sällan eller aldrig uppdateras - statiska filer.
Jag föreslår att man kanske delar denna frågeställning i två; hur gör vi med webbanalys, samt, hur gör vi med alla andra fiffiga externa innehållsnätverk. Du som vill läsa en längre problematisering av detta kan kolla in inlägget om hur man skyddar besökarens integritet på sin webbplats.
Vilka acceptanskriterier blir det?
Det är inte alltid man har några acceptanskriterier alls, ibland har man inte stöd för dem i det avtalet med leverantören. Där jag arbetar har vi en ganska omfattande dokumentation om hur man definierar att man är färdig med ett mjukvaruprojekt, men det täcker inte in alla faktorer. Men har du någon dokumentation som definierar ett gott hantverk, eller hittar en du gillar, så diskutera med leverantören (eller dig själv) vilka delar projektet måste leva upp till.
Själv har jag nyligen kompletterat de, ofta, IT-navelskådande listorna med en lista om mätbara leveranskriterier för det som i slutändan landar ute hos en besökare av en webbplats. Det som utvecklare kallar frontend, men det har också en hel del med tillgänglighet och webbprestanda att göra. Man måste inte nödvändigtvis välja alla dessa punkter - det skulle i alla fall inte jag göra.
Dokumenterad buy-in från alla leverantörer?
Har samtliga leverantörer fått uppdragshandlingen och alla annan projektdokumentation de behöver? Även ens egna eventuella IT-avdelning? Min erfarenhet är att det inte alltid så att uppdragets exakta formuleringar som följer med till alla inblandade. Bland annat så schabblade vi på min arbetsplats nyligen till det med hur de, av många hatade, cookie-meddelandet skulle se ut och fungera på alla våra webbplatser. Vi är väl ett extremfall, men vi har cirka 2700 webbredaktörer till den mängd av webbplatser vi driver. Med andra ord är det stickprov som gäller för att veta att en uppdragshandling jag skrivit verkligen slagit igenom med full kraft på samtliga webbplatser.
Så hur förebygger man att någon kan säga att de inte visste? Bra fråga. Kanske genom att ha en tydligare, och högtidligare, dokumentation om precis vad man menar, vem respektive uppdrag måste stämmas av med innan leverans. Detta är säkert inget problem om man bara har ett fåtal webbplatser och är få inblandade. Men det kanske inte skadar att göra ändå.
Finns nollmätning?
Jag kan tycka att all dokumentation ska innehålla en nollmätning om det är möjligt. Ett nuläge inför en väntande ändring av en webbplats. Då kan man se i konkreta siffror så inget blev sämre och om en utlovad förbättring faktiskt inträffade.
En liten insyn i detta, fast för intranät, kan du läsa om i mitt intranätanalys-kapitel i boken Intranät som skapar värde. Intranät är också webbplatser :)
Dessa nollmätningar kan handla om så oerhört mycket mer än det du får i din webbstatistik. Bland annat kan det vara efterlevnad till uppsatta mål om tillgänglighet enligt WCAG, språkliga grejer som vilka förkortningar man accepterar, vilken svarstid webbservern har till vad Google anser om ens samlade prestanda för mobila besökare.
Gemensamt dokument med nollmätningar och prioriteringar för framtida releaser.
Har ni en testsida för mätning av leverans?
För att man inte ska jämföra äpplen och päron så är det viktigt att ha en eller flera testsidor som är designade att inte ändra förutsättningarna mellan respektive mätning. Med andra ord kanske det är bäst att inte sätta den publika startsidan som en officiell testsida då dess redaktionella bidrag blir en okänd faktor som kan göra resultat både bättre och sämre.
Sen finns ju mätningar som måste göras på hela webbplatsen, inklusive det redaktörer lägger till, exempelvis språkligheter. Men det gäller att vara noggrann med vem man hissar eller dissar, och om de verkligen kan påverka resultatet.
För att recensera sina webbutvecklare och tekniska konsulter tycker jag att man i samråd med dessa skapar ett antal testsidor som gör det möjligt att kontrollera ett antal olika vinklar av hur webbplatsen fungerar. En testbar startsida, en landningssida, en bildgallerisida och så vidare. Då kan du se om ett byte konsulterna kallade för "bättre gridd och responsivt system" påverkade ert Google Pagespeed-betyg för mobilanvändare, där du kan luta dig tillbaka på projektdokumentationen om att inget någonsin får bli sämre utifrån era utvalda acceptanskriterier.
Varför har man då testsidor? Då kan leverantören kolla sin leverans mot testsidan innan de anser att de är klara och ropar "Färdig!" :)
