Kapitel 4: Webbprestanda


Du läser nu boken Webb­strategi för alla.
Gå till bokens innehålls­förteckning ›

Upplevelsen är normalt sett det viktigaste och det går inte riktigt att sätta objektiva siffror på hur snabb en sida upplevs vara. Genom att iaktta flertalet tekniska detaljer kan man dock identifiera saker som på olika sätt påverkar upplevelsen – bland annat hur lång tid det tar att ladda in en webbplats. Med dessa mätvärden kan man eliminera, eller åtminstone förmildra, potentiella problem och förebygga flaskhalsar som kan inträffa exempelvis vid en mycket lyckad marknadsföringskampanj.

Relativt små proaktiva aktiviteter du bör se till att de blir gjorda, eller kravställs vid nästa ombyggnation.

En lyckad marknadsföringskampanj är en planerad händelse man kan förbereda både sig själv och sin webbplats för. Det är dock inte alltid man får den chansen. Ens webbplats kan få en ohanterbar anstormning av trafik genom att det tyngsta materialet tillfälligt blir det som besöks mest, man kan också råka ut för överbelastningar av olika slag. Här kan lite förebyggande krisplanering underlätta för webborganisationen.

Att jobba med prestandaoptimering har många fler nyttor än att förmildra fullständiga misslyckanden, särskilt numera när allt fler ansluter till webben via mobila uppkopplingar. Då man inte bör låta besökaren vänta längre än nödvändigt innan de kan interagera med en webbplats är det viktigt att inte vara slösaktig. Skicka så små datamängder som möjligt till besökarna då de ibland har ganska tveksamma uppkopplingar.

Sedan 2009 har Google jobbat hårt för att hjälpa till att förbättra prestandan på webbplatser, både genom att ge översikter i sina analysverktyg men också genom att ge motivation för att göra bra ifrån sig. Följande uttalande i en bloggpost från Google mer än antyder att man blir straffad av Google om webbplatsen har dålig prestanda:

“Like us, our users place a lot of value in speed — that’s why we’ve decided to take site speed into account in our search rankings.”
Googles Webmaster Central Blog, tba.nu/gspeedquote

Google själva har en sekund som tidsgräns för att en sida ska ladda in färdigt, när det gäller deras tjänster, enligt uttalanden från deras egna optimeringsproffs Ilya Grigorik. Undersökningar visar att det räcker med några tiondels sekunders eftersläp, eller lagg som ungdomarna kallar det för, för att en användare ska tappa känslan av flyt när de försöker använda en webbplats eller annan typ av digital produkt.

Planera för det oplanerade

Det finns gott om exempel på att det lönar sig att vara proaktiv när det gäller webbprestanda även fast det blir tydligast när något går snett. Några exempel där man stötte på problem med sin webbprestanda följer här.

Aftonbladet.se under 11:e september 2001

Bild 84: Aftonbladet.se strax efter terrorattentatet 11:e september 2001.

Bild 84: Aftonbladet.se strax efter terrorattentatet 11:e september 2001.

11:e september 2001 inträffade modern tids mest uppmärksammade terrorattentat. Händelsen filmades, sändes på tv i realtid och de som på den tiden hade tillgång till webben (kanske främst via jobbet och skola) hade Aftonbladet som mest etablerade media på webben. Det tog förstås inte lång tid innan Aftonbladets normala webbplats gick ner för räkning. Istället för den vanliga webbplatsen och dess smidiga publiceringssystem fick man växla över till en manuellt uppdaterad miniversion av webbplatsen för att ge besökarna det de sökte efter.

Fram tills dess denna extraordinära händelse inträffade var åtminstone inte jag medveten om vilken roll webben spelade, eller att webbplatser kunde gå ner på det sättet att det blev extremt stökigt att få upp dem igen. Att webbplatser var långsamma hörde till den vardagliga upplevelsen men att en webbplats var onåbar under en längre tid var rätt oväntat.

Motsvarande katastrof-scenario i ett liten, mer lokal, skala kan vara att ett tåg välter och spiller ut farliga kemikalier. Det kan utan vidare slå ut omgivande kommuners webbplatser och företaget som stod för transporten. Ju längre tid man kan hålla liv i sin webbplats desto färre personer behöver fundera på om de har en traditionell radiomottagare.

Sökmotoroptimering slår till mot trögladdade sidor

Bild 85: Plötslig ökning av besökare under första säsongen av svininfluensa. Statistik från Västra Götalandsregionens dåvarande vårdwebbplats.

Bild 85: Plötslig ökning av besökare under första säsongen av svininfluensa. Statistik från Västra Götalandsregionens dåvarande vårdwebbplats.

Upplägget för Västra Götalandsregionens webbplats med regional vårdinformation var 2009 en blandning av nationella texter och egenproducerat material. Som de flesta webbplatser hade man jobbat med sökmotoroptimering för att det skulle vara lätt att finna sajtens innehåll via sökmotorer. Plötsligt en dag under hösten blev sidor om svininfluensan väldigt populära när medierna började skriva rätt hysteriska rubriker om dödsfall, pandemi och slutet på mänskligheten i största allmänhet.

Vad var då problemet? Jo, de nu populäraste undersidorna använde nationella texter som hämtades på nytt från en extern webbservice för varje sidvisning. Innan var majoriteten av besöken på undersidor som inte hade externa beroenden. Den externa tjänsten hade redan innan mindre problem med sina svarstider, vilket innan svininfluensan inte fanns anledning att prioritera. Tjänsten var inte designad för att stödja en smidig ökning av prestandan, dels då det aldrig kravställts något sådant behov men även då vad man idag populärt kallar molnet inte direkt var etablerat.

Efter den initiala förvirringen kring varför sidan gick ned såg man till att använda redaktionellt arbete i kombination med sökmotoroptimering för att avhjälpa problemet. 2009 vägde enskilda sökord klart tyngre vid rankning hos Google jämfört med idag, därmed skapades nya undersidor som ännu bättre matchade de sökord folk använde och att man kunde leda trafiken förbi de sidor som var tunga att presentera. Webbanalys och redaktionellt jobb räddar dagen.

Energibolaget E.ONs sajt går ner under mindre storm i Sydsverige

Bild 86: E.ONs webbplats tog 37 sekunder på sig att svara och 100 sekunder att ladda färdigt.

Bild 86: E.ONs webbplats tog 37 sekunder på sig att svara och 100 sekunder att ladda färdigt.

I oktober 2013 drog en storm av kategori 3 in över södra Sverige. Tiotusentals blev strömlösa. Om det var de strömlösa kunderna, via sina mobiler, eller andra som besökte E.ONs webbplats vet jag inte men den enda gången under dagen jag kom in på deras webbplats tog den makalösa 37 sekunder på sig att svara med sin första byte. Och 100 sekunder på att ladda färdigt.

Jag tog en snabbtitt på deras prestanda, så som Google mäter den enligt sitt PageSpeed. E.ON fick 81 av 100 i betyg vilket inte på något vis är anmärkningsvärt dåligt. Som extern åskådare av deras webbplats, och även den bantade katastrofversionen, fanns dock ett och annat som kunde underlättat deras webb att visa sig utan krångel för besökarna, bland annat:

  • Inte skicka onödiga grejer som extra filer för teckensnitt för katastrofversionen av webben. Är typografi verkligen så akut i dessa situationer? Teckensnittets storlek är samma som HTML-kodens, vilket bär det faktiska innehållet till besökarna.
  • Instruera besökarnas webbläsare hur lång livslängd filer har – exempelvis att loggan och favorit-ikonen troligen är oförändrade i några dagar framöver. Då laddas inte filer in vid återbesök och kraft sparas på E.ONs servrar.
  • Optimerade bildikoner kunde spara 18 % av bildens trafik utan att försämra bildkvaliteten. Bilder är väsentligt tyngre än text och onödigt stora filer kan dessvärre göra skillnad åt fel håll när det krisar.
  • Behövs det verkligen 88Kb stilmall för att formge lite text som ”Ursäkta – vår hemsida fungerar inte just nu”? Det är tio gånger mer data än det läsbara innehållet att skicka över för att tala om att rubriker är röda och text är svart.

Vissa tar fram katastrof- och reservplaner för hur de ska hantera för mycket tryck på webbplatsen. För att köpa sig mer tid och i vissa fall kanske helt undvika att gå över i katastrofläge kan det vara värt att fundera mer på webbprestanda.

Om man går över till en katastrofversion av sin webbplats får man se till att alla gamla adresser pekar på en som fungerar när krisen inträffar. Räkna inte med att folk suddar i adressen för att nå en eventuell startsida – du har ju redan misslyckats och gjort dem besvikna över sitt kontaktförsök. Dessutom kanske de använder en mobil enhet som inte visar att de hamnat på en undersida, något som åtminstone gäller Apples mobila webbläsare Safari sedan iOS 7. Adressfältet visar bara huvuddomänen och inte huruvida man befinner sig på en undersida.

Givetvis behöver man ha fler kommunikationskanaler för att vara redo för katastrofer. Exempelvis kan man komplettera med SMS eller nå ut via media, men man vill ändå inte bli känd som den som bidrog till trafikstockningen på internet bara för att man inte tänkte till före.

Prestandaoptimering för databaser, webbservrar och publiceringssystem

Beroende på vem man frågar får man olika perspektiv på prestanda och det är flera olika yrkesrollers arbete som påverkar hur snabbt en webbplats visar upp sig för en besökare. Pratar du med en databasadministratör kommer de prata om databasers struktur och kan uttrycka viss skepsis gentemot hur bra överlämningen av data är till publiceringssystemet eller det utvecklarna byggt. En systemutvecklare fokuserar gärna på prestandaeffektiv kod, något som visserligen är viktigt men som enbart i ganska extrema fall ger en märkbar påverkan på användarens upplevelse. En gränssnittsutvecklare försöker minimera mängden kod, minska antalet gränssnittselement på sidan, minska filstorleken på bilder och minska antalet filer som skickas till besökaren.

Då detta lätt känns som en djungel för den som inte jobbat mycket med optimering tänkte jag i denna del gå igenom lite av det man behöver känna till om man är inblandad i webbplatsers förvaltning. En del kan säkert vara bekant för dig sedan tidigare.

Den här delen riskerar att vara något teknisk, men häng på och googla det du inte känner igen.

Allmän felsökning

Bild 87: I Windows händelselogg kan man se vilka fel som inträffat på den maskinen.

Bild 87: I Windows händelselogg kan man se vilka fel som inträffat på den maskinen.

Om man upplever sin webbplats som långsam och det inte är uppenbart vad som är fel är det alltid en god idé att en tekniskt lagd person tittar igenom alla loggfiler efter felmeddelanden. Inte sällan rapporterar databas-servern, webbservern, publiceringssystemet och liknande till en loggfil om den upplever problem, stora som små. Det varierar var man finner denna loggfil och det kräver så gott som alltid en del förkunskaper att förstå om innehållet är allvarligt. Om du gör detta själv så är det en god idé att googla på de fel du upptäcker (det gör nämligen även utvecklarna) då någon annan oftast lagt ut lösningen på problemet.

Om du är lite tekniskt lagd finns det nästan alltid ett granskningsverktyg för respektive del av systemet eller ett där man kan kolla igenom hela serverns hälsa.

I dagens komplicerade webbplatser med väldigt mycket interaktion direkt i webbläsaren (utan omladdning av sidan alltså) uppstår ibland fördröjning lokalt i datorn. Detta tyder på att du behöver göra något åt gränssnittskod som HTML och CSS. Kanske innehåller sidan för många gränssnittselement med för allmänna stilmallsregler som inte är tillräckligt effektiva när de försöker växla mellan att dölja eller visa tiotusentals gränssnittselement. Om övergångar och animationer i webbläsaren känns som slowmotion tyder det på att gränssnittskoden är för komplicerad. Då kan en googling efter prestandatest av CSS, user interface eller frontend troligen ge hjälp på traven om inte felet är uppenbart.

Bild 88: Tidslinjen i Chrome visar nedladdnings- information om varje fil som hämtas för att visa en webbsida.

Bild 88: Tidslinjen i Chrome visar nedladdningsinformation om varje fil som hämtas för att visa en webbsida.

Ett ytterligare test du borde utföra innan du ger upp och kallar in proffsen är att besöka den tröga webbplatsen med webbläsarens tidslinje- eller nätverksfunktion aktiverad. De flesta webbläsare erbjuder nämligen lite verktyg till utvecklare och det tidslinjen/nätverk gör är att illustrera vilken tid det tar att ladda in filer. De fynd man kan göra där är att filer skickas i fel ordning, att det är fler filer än man tror sig behöva eller att för stor andel av nedladdningstiden är väntan på att servern ska börja skicka något alls. Exempelvis när jag besökt aftonbladet.se med webbläsaren Chrome kommer information upp som att det finns en initial latens på 0,074 sekunder innan något skickas. Ofta kan man identifiera eller utesluta problem bara genom att leta mönster i vad som är långsamt. Tänk på att nätverksbekymmer och annan upplevd seghet kan bero på ens egen utrustning och uppkoppling till nätet. Det är en bra idé att testa olika enheter och anslutningar när man felsöker.

Planera för hög belastning – använd cache

Bild 89: Acceleratorn Varnish har gått ner för räkning på streamingsajten Dreamfilm.

Bild 89: Acceleratorn Varnish har gått ner för räkning på streamingsajten Dreamfilm.

Cache är en sammanställd version av exempelvis en webbsida, eller del av ett informationssystem, och ska användas om informationen som utgör sidan inte har förändrats. Poängen med en cache är att frekvent besökt innehåll inte behöver sammanställas på nytt för varje besökares skull. Det går oerhört mycket snabbare att skicka material till en besökare om det materialet redan finns i en cache-version i serverns lättillgängliga minne. Då behöver inte servern kolla i databaser eller prata med externa API:er för varje sidvisning.

Det finns många varianter av hur cache kan användas men de två mest meningsfulla för detta utvecklarperspektiv är så kallade acceleratorer som gör cachejobbet åt webbservern, den andra är den cache man har i sin egen webbapplikation.

En accelerator fungerar lite som ett filter mellan webbplatsen och besökaren. Har inte sidan ändrats skickas en cache-version av sidan direkt från acceleratorn utan att blanda in webbservern. På detta sätt har man två specialiserade programvaror; acceleratorn för att så snabbt som möjligt skicka oförändrade webbsidor, och webbservern för att sammanställa webbsidor och drifta publiceringssystemet (där redaktörerna uppdaterar sidorna).

Att köra med en accelerator löser inte alla dina prestandaproblem, dock är de svårslagna vid enorm belastning på semi-dynamiska webbplatser där egen statisk information kompletteras med exempelvis besökarnas kommentarer.

Innehållsnätverk (CDN – Content Delivery Network)

Ordlista – Statiska filer:
En fil som har exakt samma innehåll under hela sin levnad. Frekvent använd variant är Javascript-biblioteket jQuery som versionshanterar sina utgåvor, alltså är innehållet i filen för jQuery 1.9 identisk oavsett när den hämtas eller från vilken plats.

Ett CDN är ett nätverk av servrar placerade runt omkring klotet och de används till lite allt möjligt. Beroende på vad ens webbplats behöver kan dessa tjänster vara gratis eller kosta massor med pengar baserat på användningsgrad. Ett vanligt exempel som är gratis är alla som använder Googles CDN för Javascript-ramverket jQuery på sin webbplats – då hämtas jQuery inte från den besökta webbplatsen utan från ett närliggande CDN. Ett fall när det istället kostar pengar är om man behöver strömma stora mängder video, något som drar väldigt mycket trafik.

Att materialet finns så nära besökarens position är viktigt då det för den genomsnittliga besökaren tar onödig tid att vänta på att få kontakt med servern om den råkar befinna sig mycket långt bort. Internettrafiken inom kontinenter fungerar bättre än den trafik som trängs i kablarna under oceanerna. Det innebär att om man driver en tjänst som strömmar video kommer det göra väsentlig skillnad om man har servrar strategiskt utplacerade, alternativt att man hyr in sig på stora nätverk och sprider sitt material över klotet.

Exemplet ovan med att hämta in jQuery, som är vanligt förekommande på flertalet webbplatser är ett mycket bra användningsområde för ett CDN. Om din besökare nyligen varit inne på en webbplats som hämtar exempelvis jQuery 1.9 från Googles CDN kommer denne inte behöva ladda ner den filen igen om din webbplats använder samma version av filen från samma CDN. Webbläsaren konstaterar då att det är samma fil den tidigare laddat ner och läser den från det blixtsnabba lokala cacheminnet istället.

jQuery 1.9 är en statisk fil då en uppdatering innebär ett nytt versionsnummer vilket gör att man får ett nytt filnamn. Alla adresser till en ny version kommer att avvika från äldre versioner vilket korrekt instruerar webbläsaren att det är nytt material. Många bilder är egentligen hanterade på samma sätt och skulle mycket väl kunna placeras på ett mer eller mindre stort CDN för snabb överföring.

En variant man ofta får på köpet även hos små webbhotell är att skapa en subdomän i stil med media.mindomän.se där man lägger bilder, ljud och så vidare. Poängen med det är att skilja på det lite mer komplicerade tillverkandet av webbsidor genom databaser, API:er etcetera och det simplare skickandet av statiska filer. Webbserverprogramvaror som Apache och Internet Information Server är inte optimerade för att skicka stora mängder av statiska filer och kan med ett CDN eller separat funktion avlastas från denna syssla för fokus på tyngre jobb.

Databaser

För att försöka identifiera problem med databaser finns det verktyg till samtliga större databasmiljöer. Vanligast är att använda loggning och profilering för att få insyn i databasserverns utförda sysslor. Loggning är precis som namnet antyder en loggfil som i det här sammanhanget är bra att använda för att samla vilka databasfrågor som tar för lång tid att utföra eller om det uppstår fel som kan påverka prestandan.

En databasfråga får verkligen inte ta i närheten av en sekund att köra klart. Om den gör det är informationssystemet antingen feldesignat eller så behöver databasmiljön ses över. Om man aktiverar loggning av långsamma databasfrågor ser man ofta ett mönster efter att man samlat på sig några tusen loggade frågor och kan med hjälp av detta börja leta efter en lösning.

Skillnaden mellan loggning och profilering är att profilering är något man oftast övervakar manuellt för en kortare stund och sedan stänger av när man tycker sig ha funnit något värt att jobba vidare med. Profilering riskerar helt enkelt inte att självt bli ett prestandaproblem vilket loggning faktiskt kan bli om man har otur eller glömmer att stänga av det.

Ordlista – Databas-index:
Som index eller innehållsförteckning i en bok. Färdigställda paketeringar av frekvent efterfrågade uppgifter ur en databastabell. Exempelvis behöver filtrerande urvalskriterier vara med i index för att ge snabba svarstider.

Kan man på en webbsida lista produkter efter kategori är fältet för kategori i databastabellen troligen i behov av att finnas i ett index för snabb visning.
Är det en relationsdatabas (exempelvis på SQL Server eller MySQL) är det inte ovanligt att man kan behöva jobba med databasens index så de återspeglar hur databasen används. Ett index är lite som en innehållsförteckning och gör att det går att välja vilka delar i en databas som ska gå snabbt att leta upp.

Jag hade tidigare en databas med många miljoner poster i den största tabellen. Bara genom att lägga till index sänktes en typisk databasfrågas körningstid från över hundra sekunder till mindre än en tiondels sekund. Om denna optimering inte kunnat göras hade det förstås inte varit möjligt att låta en webbplats ställa frågor direkt till databasen då webbsidans svarstider handlat om minutrar.

Databasservrar är rätt komplicerade att sätta sig in i. Inte sällan är det en felaktig eller icke-gynnsam konfiguration som gör att det inte fungerar som det ska. Ibland är det så enkelt som att man vuxit ur det billiga webbhotellet man har eller kanske att man behöver en dedikerad databasserver. Jag har sett databasservrar som varit väl tilltagna men haft inställningar som gjort att bara ett fåtal samtidiga anslutningar accepterats. Det gör att när webbplatsen har många besökare ställs de på kö för att invänta en ledig anslutning till databasservern, detta trots att servern nödvändigtvis inte är överbelastad. Vid dessa tillfällen vill man gärna ha den typ av cache som nämnts tidigare för att magiskt minska behovet av att ens ansluta till databasservern.

Bland de mer drastiska åtgärderna finns att designa om databasen efter hur den används. Det kan betyda att man skapar kopior på informationen som är optimerat enbart för läsning och att originalen används för att hålla databasens integritet intakt. Andra har valt att helt eller delvis byta databasarkitektur, exempelvis att viss data ligger i så kallade NoSQL-databaser då de inte behöver lägga någon kraft på relationer inom datamängden som en relationsdatabas gör.

I större miljöer är det inte ovanligt att man har en Enterprise Search-lösning med vilken man indexerar hela databasers innehåll. Vet ens sökmotor redan allt om databasernas innehåll kan man lika gärna låta sökmotorn servera data till webbplatsen, något en sökmotor gör väldigt snabbt. Det gäller att få databasens ändringar att slå igenom snabbt nog i sökmotorn så inga fel uppstår.

Webbservrar, publiceringssystem, egen källkod och externa beroenden

Det finns tusen och en variant på hur man prestandaoptimerar sin tekniska miljö. Främst handlar det om hur mycket tid och pengar man har. I normalfallet kommer ens webbplats råka ut för växtvärk vid flera tillfällen under sin levnad på grund av tillfälliga besökstoppar men också allt eftersom innehållet växer i omfattning eller ens egen kod växer i komplexitet.

”A typical CMS is like a digestive system with no capacity to poop.”
Gerry McGovern, @gerrymcgovern på Twitter

Vanliga webblösningar i storleksordning, klenast först:

  1. Webbhotellskonto för 100 riksdaler i månaden – ingår webbserver delad med många andra och databas i separat databasmiljö som delas med många andra kunder. Billigt och smidigt att börja med för den lilla webbplatsen.
  2. Dedikerad server/colocation – man hyr plats för att ställa en fysisk maskin i någon annans serverhall. I dessa lösningar brukar visst driftstöd ingå, exempelvis omstart och byte av hårddiskar, men all programvara på servern är ens egna problem (och möjlighet).
  3. Virtuell Privat Server – hyrd virtuell server där man själv kan styra och ställa lite hur servern ska bete sig. Ofta kan man skruva upp prestanda vid behov vilket är vad många kallar för molnet.
  4. Lastbalanserad serverpark – ibland inhyrd i någons serverhall eller i egen hall om man är en större organisation. Här fördelas arbetet ut på flera samarbetande servrar att ge besökarna den information de behöver.

Det finns inget som garanterar att webbplatsen fungerar bättre på en dedikerad server jämfört med ett budgetwebbhotell. Att ha en egen server kräver kunskap och massor med tid för att fixa alla inställningar så de är optimala för webbplatsens behov. Skillnaden mellan lågbudget och de fetare lösningarna är att man över huvud taget kan göra dessa egna justeringar, men då är det samtidigt ens eget problem att drifta den miljön man skapar.

Ofta finns det en poäng i att ha sin lite större webbplats utspridd, rent arkitekturellt, över flera olika servrar för att kunna nå bästa prestanda. Gärna en server som bara serverar statiskt innehåll som bilder (lite som ett eget CDN), en server som bara sköter om databaserna och en server som sköter presentation av webbplatsen och dess publiceringssystem. Dessa olika serversysslor ställer nämligen olika krav på hårdvara och mjukvara. Delar man upp sysslorna kan de få specialiserade roller de sköter bättre än genom att vara generalister.

Beroende på vad som är tungt att driva för den enskilda webbplatsen kan man bli tvungen att utvidga sin miljö. I en EPiServer-miljö jag jobbat med behövdes det vid en viss version av EPiServer användas en extra serverinstallation för redaktörer och en annan för besökarna. Om jag minns rätt berodde detta på att det var väldigt många redaktörer i organisationen och att deras sysslor tog oerhört mycket kraft av servern. Istället för att de skulle flytta runt tusentals sidor i produktionsmiljön så speglades ändringarna en gång i timmen till produktionsmiljön, vilket gjorde att produktionsmiljön mådde bra men på bekostnad av att redaktionellt innehåll släpade efter något.

Apropå att man själv ansvarar för inställningar på egna och virtuella servrar är det en god idé att, förutom att bygga feltolerant, se över vilka externa beroenden man har och hur redo de är för en väsentligt högre belastning. Troligtvis finns inställningar i webbapplikationens konfigurationsfiler eller i webbserverns inställningar en möjlighet att justera hur länge man ska vänta på svar från API:er. En webbserver har ett begränsat antal med besökare den klarar av att jobba med samtidigt, därför vill man inte att det drar ut på tiden att servera en färdig sida till en besökare på grund av ett trögt externt API.

Pratar man med en utvecklare är det vanligt att deras erfarenhet av prestandaoptimering begränsar sig till vad man kan göra med källkoden som utgör själva applikationen. I min erfarenhet är det ytterst sällan värt att försöka bättra på källkoden, eller ens kostnadseffektivt, då det ofta finns mer prestanda att vinna i databaser, konfigurationer och att se till att ha rätt hårdvara. Hårdvara är ofta billigt jämfört med konsulttid för att granska källkod.

Det skadar förstås inte att ta en snabbtitt i källkoden och se om det finns flagranta fel. Fadäser jag skulle fixa i källkoden är onödiga konkateneringar av text (att man slår samman flera textsträngar till en), onödigt användande av databasanslutningar exempelvis som att det tar fler än en databasfråga för att hämta eller skriva information. Men det är dessvärre svårt att bedöma exakt vilken påverkan en ändring gör innan man testat en ändring.

För den som tar kodning seriöst finns det verktyg till de flesta miljöer, ReSharper till utvecklingsmiljön Visual Studio är ett exempel som håller koll på koden under tiden man skriver den. I vissa versioner av Visual Studio finns dessutom inbyggda funktioner för att belastningstesta sin webbplats. Det kan vara intressant för att se hur webbplatsen beter sig under stress. Många sådana här verktyg kan dessutom utvärdera och ge förslag på justeringar av all källkod. I större systemutvecklingsprojekt använder man ofta något som kallas för byggservrar vilket är ännu en kontrollinstans för att se att kodkvaliteten är hög nog innan den produktionssätts. I byggservrar finns det flera olika rapporter att ta del av, inte bara för prestanda.

Att mäta och förbättra gränssnittsprestanda från besökarens perspektiv

Vanliga sätt att skaffa sig en uppfattning om webbplatsens prestanda är hur lång tid en sida tar att ladda in i komplett skick. I detta döljer det sig detaljer som latens, väntetid alltså, innan webbplatsen påbörjar överföringen av information till besökaren. I vissa relativt ovanliga fall kan väntetiden vara längre än den tid överföringen tar. Då lösningarna skiljer sig åt är det viktigt att identifiera det problemen i prioritetsordning.

Nyttiga verktyg

Bild 90: Praktiskt placerat längst ner till höger i Firefox visar Lori information om varje sidvisnings svarstid, inladdningstid och tyngd.

Bild 90: Praktiskt placerat längst ner till höger i Firefox visar Lori information om varje sidvisnings svarstid, inladdningstid och tyngd.

Det finns flera sätt att få siffror på väntetid kontra överföringstid. Själv föredrar jag att ha denna information direkt i webbläsaren då man kan missa tillfället en webbplats är trög om man först efter en trög sidvisning ska testa hastigheten. Ett exempel på verktyg som mäter en webbplats svarstid är Firefox-tillägget Lori (Life-of-request info). Det har ett värde för hur lång tid det tar för servern att skicka den första ettan eller nollan till besökaren. Den siffran är värdefull då en hög sådan siffra tyder på överbelastad server eller felaktig konfiguration. Det är viktigt att poängtera att dessa värden kan variera stort mellan olika undersidor. Är du medveten om att några särskilda sidmallar har extra komplex uppbyggnad, som beroenden till externa informationssystem, är de absolut värda att testa hur de beter sig.

Man ska inte hänga upp sig på exakta siffror utan istället försöka se om det finns mönster i hur en webbplats beter sig. Värt att hålla i minnet att ens egna upplevelser är just anekdotmässiga och att man kan behöva titta efter vad den genomsnittliga besökaren upplever, detta finns i din webbstatistik. I Google Analytics hittar man detta under Behaviour -> Site speed –> Page Timings och på de webbplatser jag tittat på brukar det vara ganska enkelt att identifiera varför sidorna är tröga. Oftast beror det på att det är otroligt många uppslag av information mot databaser eller andra källor. Det känns tryggt att utgå från kvantitativ data när man börjar putsa på sin prestanda då man utan vidare kan se om en insats avhjälpte problemet eller inte.

Är du tekniskt lagd, eller kanske hittat något väldigt misstänkt, har Google Chrome ett bra tillägg i form av sin verktygslåda för utvecklare. Med den kan du få detaljerad information för alla filer som överförs mellan webbplatsen och din webbläsare. Tumregeln är att om den initiala väntetiden är hög beror det på tekniken eller konstruktionen av webbplatsen. Om överföringstiden är hög kan det i vissa fall bero på redaktionella val i form av tyngre material som bilder, men oftast är orsaken de val man gjorde vid konstruktionen. Exempelvis att man laddar in Javascript som inte behövs på samtliga sidor.

Bild 91: I Google Chrome kan man i utvecklarläget ta del av information om alla filer som tagits emot för sidvisningen.

Bild 91: I Google Chrome kan man i utvecklarläget ta del av information om alla filer som tagits emot för sidvisningen.

Sist men inte minst är Googles PageSpeed Insights ett enkelt sätt att få en övergripande koll på hur en webbplats presterar både på skrivbordsdatorer och mobiler. PageSpeed Insights når du via webben men det finns också som ett webbläsartillägg för Chrome och Firefox.

Bild 92: Provkör din sida på Googles tjänst PageSpeed Insights för att få en lista över eventuella förbättringar.

Bild 92: Provkör din sida på Googles tjänst PageSpeed Insights för att få en lista över eventuella förbättringar.

Förenklat sett finns det två grova uppdelningar man kan göra över vad som påverkar prestandan, nämligen vad redaktören bidragit med och vad som ingår i webbplatsens konstruktion.

Redaktionell påverkan på prestanda

Det en redaktör bidrar med på en webbplats begränsar sig oftast till olika sorters innehåll och att jobba i ett publiceringssystem för att publicera detta innehåll. Det är ytterst sällan man har problem med text då text inte tar upp någon nämnvärd plats att överföra. Däremot kan problem uppstå med varifrån texten kommer. I vissa publiceringssystem, exempelvis EPiServer, finns funktioner som hämtar innehåll från andra sidor på webbplatsen. Använder man sådant introducerar man extra komplexitet att presentera webbsidan för en besökare. Det behöver inte vara ett problem, men kan leda till allvarliga bekymmer om sidan man hämtar data från exempelvis blir avpublicerad då det kommer dra massor med kraft från servern att inte krascha sidvisningen.

De dramatiska tillfällen jag kunnat peka på webbredaktörers inverkan har handlat om att någon kopierat en hel nod med sidor och klistrat in på annan plats. I den noden låg tusentals sidor och webbservern tvingades räkna ut sidornas interna släktförhållande. Vid dessa tillfällen brukade databasservern ledsamt hälsa att den gått i baklås. Andra tillfällen har det handlat om att populära sidor har kastats eller fått ett bäst före-datum. Det är lite att betrakta som ett fel inom webbapplikationen, alla fel tar väldigt mycket extra kraft i anspråk och är det en välbesökt adress som skapar dessa fel får man en hel del bekymmer. Även för besökarnas skull ska man ta hand om skrotade adresser genom att skicka vidare till nytt relevant material och allra helst också se till att de som använder den gamla länken uppdaterar adressen.

När det gäller mediefiler är det vanligast att en redaktör jobbar med bilder. Video och ljud förekommer också men oftast påverkar de inte prestandan för en sidvisning då materialet antingen börjar strömmas eller är en separat adress för nedladdning. Bilder däremot inkluderas flitigt på sidor och bidrar väsentligt till längre laddningstider vid vanlig webbsurfning.

Första nivån för att inte göra bilder onödigt tunga är att välja rätt format. På webben är det främst formaten JPG, PNG och GIF som används. Om man åsidosätter filosofiska idéer kring bildformat så använder man JPG för fotografier, och bilder med väldigt många olika färger över hela bildytan, PNG för illustrationer och logotyper och GIF främst för animerade bilder. Har du ett bildbehandlingsprogram, som Photoshop, finns funktioner för att spara i webbformat vilket gör det enkelt att jämföra vilket format som är effektivast på att få ner filstorleken. Förutom att välja rätt format kan bilder optimeras för snabb visning på webben. Det innebär att bildkvaliteten sänks och bildens filstorlek minskas. Det gäller att hitta det optimala läget där bilden ser bra ut och ändå är så liten som möjligt.

Som grädde på moset finns det hjälpprogram som kan minska bilden på ett icke-förstörande sätt, alltså ett sätt som inte ska vara upptäckbart för det mänskliga ögat. Ett favoritprogram för Mac är ImageOptim där man bara drar och släpper bildfilerna i programfönstret och så skrivs filerna över med optimerade versioner.

Bild 93: ImageOptim tar bort onödig information från bilder så de blir så små som möjligt.

Bild 93: ImageOptim tar bort onödig information från bilder så de blir så små som möjligt.

Verktyget Smush.it kan fixa optimering på alla bilder för en enskild webbsida. Samma funktion finns inbakad i YSlow som plugin till Firefox eller Chrome. Det finns en uppsjö av verktyg för att fixa till dina bilder – prova dig fram för att se vad som fungerar för dig. Kanske vågar du dig på att ha en optimeringsplugin direkt i ditt publiceringssystem?

Samma princip som för bilder gäller även video och ljud. Man får välja format med omsorg och dessutom välja parametrar som upplösning och kvalitet när man sparar sin fil för publicering.

Tekniska inställningar för prestanda

Jag har byggt en tjänst för test av webbplatsers optimering på min sajt webbfunktion.com, och redan efter några tusen testade webbplatser så syntes ett tydligt mönster över vilka optimeringar som ofta saknas men är relativt enkla att fixa.

1. Glömt sätta förväntad livslängd på filer

När webbläsaren laddar ner en webbplats följer det med ett flertal filer. Förutom själva HTML-dokumentet oftast ett antal bilder, stilmallar och Javascript. Med var och en av dessa filer följer det med information till webbläsaren över hur länge filen förväntas vara aktuell – dess förväntade livslängd med befintligt innehåll alltså.

Ett allt för vanligt scenario är att favicon.ico, logotypen och andra filer som praktiskt taget aldrig uppdateras inte har någon livslängd satt. Det som händer då är att alla återkommande besökare laddar hem filer som inte uppdaterats sedan deras tidigare besök. Att filerna redan finns och försenar att sidan kan visa upp sig för besökaren. Mest logiskt är att inte ladda hem filer som en återvändande besökare redan har. Struntar man i att sätta förväntad livslängd kommer webbläsaren inte att chansa utan laddar hem allt vid varje besök.

2. Statiska textfiler skickas okomprimerat

Många filer på en webbplats består av text, exempelvis HTML-dokumentet, stilmallar och Javascript. Dessa kan överföras i befintligt skick till besökarna eller så väljer man att komprimera dem så de går snabbt att skicka. Komprimering innebär att en algoritm gör så gott den kan för att packa ihop en textfil så den blir så liten som möjligt. Algoritmen söker efter mönster och upprepningar, bland annat tjugo stycken mellanslag skulle den kunna komprimera.

Det är mycket vanligt att de som utvecklar webbplatser behåller mellanslag och tabbar för att koden ska vara läsbar och lättare att redigera vid behov. För att detta inte ska bidra till långsammare laddningstid för besökarna är komprimering en bra idé.

Komprimering effektiviserar mycket mer än bara mellanslag. Inte sällan kan man skala bort 75 % eller mer av filens storlek vid överföring vilket bidrar till en klart snabbare användarupplevelse.

3. Bilder är inte optimerade

Praktiskt taget alla webbplatser använder bilder till utsmyckning, logotyper och för att visa koncept. Bilder är det vanligast förekommande tunga materialet man lägger ut på en webbplats och har ofta en stor optimeringspotential. De bilder som kan vara värt att fokusera först på är de som laddas in oavsett vilken sida besökaren tittar på, med andra ord logotypen, ikoner och eventuella bakgrundsbilder.

Förutom att du via ditt bildbehandlingsprogram kan spara bilder för webben med lagom optimering finns det nästan alltid mer att ta bort. Det brukar ofta kallas för förlustfri optimering men är åtminstone så bra att man med blotta ögat inte ska se någon försämring.

Det är inte ovanligt att man ser att webbplatser skickar bilder som kunnat optimera bort några hundra kilobyte om man ansträngt sig. Det är inte jättemycket, åtminstone inte förrän någon på skakig mobiluppkoppling är redo att ge upp och inte tänker vänta några sekunder till.

Många organisationer använder bildsystem till sina webbplatser. De brukar ofta marknadsföras med att de “tar hand om bildförminskning och optimering” men det betyder i de fall jag sett att systemet tar bort det värsta och lämnar mycket att önska. Särskilt vaksam ska man vara med sidor med många tumnaglar då de efter min erfarenhet kan optimeras mycket mer än man tror.

4. Onödigt många filer

Problemet är främst att det ibland är på tok för många enskilda filer. Varje fil som ska laddas ner till en besökare har en ledtid för att börja skickas, vilket om det är många filer gör situationen allt värre.

Detsamma gäller ofta de som använder ikon-bibliotek där man laddar in ibland hundratals väldigt små bilder. Varje liten fil bidrar med sin egna ganska onödiga väntetid och kan slås samman med en teknik kallad CSS Sprites. CSS Sprites innebär att man har en bildfil som i sin tur innehåller flera bilder. Med hjälp av CSS får man sedan ett litet titthål gentemot bilden och kan på det sättet se en bild i taget.

Istället för att varje fil laddas in var för sig laddar man hem alla på en gång. Lite tyngre första gången men fördelen är att det endast är en fil att ladda ner.

Ofta kombinerar man all Javascript till en enda Javascript-fil och all CSS till en enda CSS-fil för att minska antalet filer att skicka till en besökare. Om ett slumpartat beteende uppstår relaterat till stilmall och Javascript se då efter om filerna kommer i rätt ordning när de slagits samman till färre filer. Ordningen på innehållet är viktigt.

5. Javascript blockerar sidans inladdning

Många moderna webbplatser använder sig av väldigt mycket Javascript för att ge ett rikt användargränssnitt och för att förenkla interaktionen med formulär med mera.

Dock är det mycket vanligt att all Javascript-kod laddas hem innan övriga filer på sidan hämtats, dessutom körs Javascript-koden ofta innan resten av webbplatsen är klar eller presenterad för besökaren. Så först väntar man på att hämta hem Javascript, sen väntar man på att det ska köra klart. Det här är mest ett problem på långsamma enheter, särskilt om de har en långsam uppkoppling, och bidrar till mycket väntande.

Inte sällan ska några hundra kilobyte Javascript både hämtas och köras i webbläsaren innan den fortsätter med något besökaren kan se på skärmen. Det gäller att prioritera att synligt innehåll visas fort på skärmen, ibland kan det vara smart att ladda in tyngre material vid behov istället för att allt laddas in direkt.

Det är inte riktigt så enkelt som att göra om en befintlig sajt till att ladda in all Javascript i efterhand, men det kan vara värt att pröva om det går att flytta några delar till att laddas in sist. Exempelvis är det många som prioriterar att sidan visas upp snabbt högre än att Javascript för webbstatistik registrerar besöket. Därmed läggs sådana skript sist i koden och laddas in sist.

Kolla din egen webbplats med Googles tjänst PageSpeed Insights. Man brukar alltid hitta något man kan göra bättre.

Räkna hem investering i webbprestanda – går det?

Innan man bestämmer sig för att satsa stort på bästa möjliga webbprestanda är det viktigt att veta vad man har för mål.

Två huvudsakliga mål med optimering av webbprestanda är; minska kostnader för driften av webbplatsen eller att potentiellt tjäna mer pengar, förbättra upplevelsen för användaren och bättre sökmotoroptimering.

Är man främst ute efter att minska kostnader för driftmiljön finns ett begränsat antal saker att fokusera på, andra saker bör man helt undvika då de istället tar mer driftkapacitet till förfogande. I detta fall går det att räkna fram en prognos för minskat investeringsbehov.

Jobba exempelvis gärna med:

  • Effektivare källkod. Manuell granskning är inte alltid värd ansträngningen, men många ramverk har verktyg som kan leta kvalitetsproblem men testa också vad din utvecklingsmiljö och byggserver kan hitta.
  • Databasfrågor i cache, eller specifika tabeller optimerade för läsning, genom att beakta användningsmönster. Bland annat är det ofta effektivare att hämta allt som matchar ett givet kriterie ur databasen även fast man bara tänker visa upp de tio första träffarna, åtminstone om användarna oftast bläddrar till nästa tio träffar. Då ligger alla träffar redan i databasserverns cache.
  • Index i databaser är mycket viktigt och de kan behöva uppdateras allt eftersom innehållet och användningen av en webbplats förändras.
  • Livslängd på filer i webbläsarens cache så filer som inte uppdaterats laddas ner i onödan. Anropas en viss version av ett Javascript-bibliotek via HTML-koden kan man lugnt räkna med att innehållet kommer leva för evigt då nästa version kommer få en ny adress.
  • Webbacceleratorer som Varnish Cache Server är en lösning att testa för den som har extrem belastning på ganska statiska webbsidor.
  • Innehållsnätverk (CDN) kan vara en lösning om det är trafiken från servern som är flaskhalsen. Med ett CDN kommer vanliga filer skickas från en annan server så det blir mer kapacitet kvar för arbetsuppgifterna man behåller på sin egen webbserver.

Har du extremt många besökare på relativt få sidor är selektiv cache för de sidorna att föredra.

Diskutera gärna detta med respektive typ av specialist innan du sätter igång. Har din webbplats inte åtminstone några hundratusen sidvisningar per månad och du ändå upplever bekymmer är problemet nog något annat. Kanske ligger din webbplats på ett webbhotell eller annat system som verkligen inte är dimensionerat för webbplatsens grundläggande behov?

Som exempel kan jag nämna att när jag jobbade som webbkonsult kom jag fram till att varje kund hade haft massiv nytta av 20 timmar specialiststöd för prestandaoptimering. Många kunde haft god nytta av en vecka och några få borde börja om på nytt med sin webbplats.

Fortsätt läsningen i kapitel 5 – om att utvärdera sin egen webbplats ›

Hoppa till andra kapitel