Del 4: Aktivitetsplan

För att jobba strategiskt med din webbanalys bör du eller någon inom webbteamet sätta upp en aktivitetsplan som tydligt tar dig från nuläge till ett önskat läge. Denna del av boken tar upp en mängd exempel på aktiviteter och mätvärden du kan välja att stoppa in i din egen aktivitetsplan.

Det är hygienfaktorerna på webbplatsen som skapar förutsättningar för en värdefull webbplats. Att börja med alla på en gång är dumt, de tar tid. Kolla igenom dem och välj ut fem till tio stycken att utföra (och bemästra) under det kommande året. Det är bättre att du sätter ett mål du kan uppnå.

Hygienfaktorer

Poängen med att försöka leva upp till denna dels hygienfaktorer är att ha något mätbart sätt att förhålla sig till de teknikaliteter som påverkar besökarnas upplevelse. Dessutom är de ett sätt att försöka säkerställa att webbplatsen inte försämras över tid, utan snarare kontinuerligt förbättras för varje uppdatering.

Listan med de aktiviteter du har valt ut kan komplettera de testprotokoll som systemutvecklarna har. De flesta som bygger större webbplatser har redan ett systematiskt sätt att verifiera att ett webbprojekt håller rätt kvalitet. Rätt många har sedan länge använt så kallade byggservrar för att ha kontroll över kodkvalitet för ett större team utvecklare. Flera av de verktygen har möjligheten till insticksprogram som kan göra några kontroller automatiskt åt dig. Så gör gärna en inventering av utvecklingsarkitekturen. Snubblar du över något för Continuous Integration⁶³ så är det värt att leta insticksprogram. Det är möjligt att automatiskt stoppa produktionssättning av nya funktioner om det inte lever upp till kvalitetskraven man satt upp.

Om du driver en större webbplats är det en bra idé att intressera dig lite för vilka tester utvecklarna har för att försäkra sig om att rätt kvalitet uppnås. Dessa tester kan vara allt från helt manuella till fullständigt automatiserade. Men var förberedd på att det kan vara minerad mark. Reaktionen kan verkligen vara allt från att de blir glada att man är intresserad till att var och en borde sköta sina egna problem.

Eftersom verktyg och knep för att kolla dessa faktorer inte alltid lever för alltid kan du vända dig till en sida på min webbplats där jag har en aktuell lista⁶⁴ med verktyg jag själv använder för stunden.

Startpaket för din aktivitetsplan

Listan som följer är sånt du själv kan kontrollera för att säkerställa att webbplatsen fungerar som du vill. Självklart kan du byta ut värden om du vill sikta högre eller lägre. Välj ut vilka punkter du tycker är rimligt att varje undersida på webbplatsen ska leva upp till och diskutera dem med din webbutvecklare (ibland behöver man nämligen resonera annorlunda).

Som du inser när du läser listan finns saker man behöver lägga till beroende på hur ens webbplats är tänkt att användas. Exempelvis de som har valt att köra mobile first så bör en aktivitet in på listan för att man inte använder eller länkar till PDF-filer på webbplatsen (de är oftast ovänliga mot de med små skärmar).

Men nu är det dags för ett gäng förslag på aktiviteter.

Införa HTTP/2 och HTTPS

Innan jag eller någon du möter fullständigt frälser dig kring glädjebudskapet om att HTTP/2 är det bästa sedan Jösses H. Kristus gick i kortbyxor så tänk kritiskt kring vilka användare du lämnar bakom dig. De som inte har utrustning som stödjer det nya webbprotokollet. I skrivande stund är det främst de på äldre versioner av Internet Explorer som tillhör denna grupp. Innan du tar steget bör du veta hur stor andel av dina användare och tilltänkta målgrupp som gynnas.

I Microsofts värld är det först Internet Explorer 11 som stödjer HTTP/2, medan alla andra moderna webbläsare haft det sedan länge (och som till skillnad från Internet Explorer inte brukar leva på övertid). Att webbservrarna du använder stödjer protokollet är inte självklart, men många hade stöd redan under 2016. Om både användarens pryl och alla inblandade webbservrar stödjer HTTP/2 kommer det automatiskt att användas. Dessutom kommer webbläsaren ihåg att webbservern erbjöd HTTP/2 så nästa besök kommer att gå ännu fortare då webbläsaren redan vid sin fråga till webbservern säger att den vill prata HTTP/2.

Att våga ta steget

I många fall kommer det inte bli någon merkostnad eller manuell ansträngning att aktivera HTTP/2 på sin webbplats. Använder man redan ett externt CDN (alltså innehållsnätverk) är det rent utav troligt att filerna där redan drar nytta av HTTP/2. Däremot behöver man kanske göra vissa prestandaoptimeringar ogjorda för att dra nytta av det nya protokollet. En utmaning här blir hur man optimerar webbplatsen både för de på HTTP 1.1 och HTTP/2 eftersom god prestanda-praxis skiljer sig åt, detta kommer vi in mer på senare.

Under många år kommer HTTP 1.1 leva parallellt med HTTP/2, i någon utsträckning. Det är en aktivitet vi som jobbar med webbanalys behöver återkomma till. Vilka system vi använder kan börja jobba med version 2, och vad innebär det i praktiken?

För dig med en liten Wordpress-webbplats är detta en liten åtgärd jämfört med stora organisationer där massvis med nya, gamla och ibland förhistoriska system samarbetar för att servera innehåll till webben.

Anledningen till att HTTP/2 lite grand vänder upp och ner på de kvalitetskrav man ställer på ett webbsystem som kör version 1.1 är för att man tänkt till ordentligt kring hur webben av idag ser ut. Bland annat är den nya versionen bättre på flera samtidiga filer och att hålla en öppen kanal för att skicka filer lite när de behövs. Att det per automatik ingår säkerhet motsvarande HTTPS kan vi se som en bonus.

De system du tittar på först är de som skickar fler än en fil till besökaren per sidvisning. Givetvis själva webbservern, men också om du har ett innehållsnätverk (CDN), separat bildsystem, etc.

Ha detta i åtanke när du läser resten av denna del i boken – att dela upp innehåll i några stycken filer är god praxis med HTTP/2, men dålig praxis i HTTP 1.1. Det gör att om du optimerar prestandan efter HTTP/2s villkor kommer det straffa de som kör äldre teknik, så fundera på när det är värt att ta steget.

Denna punkt handlar mer om att bevaka vad som förväntas av en modern webbplats. I skrivande stund är HTTPS något sånär praxis för att få en extra knuff inom sökmotoroptimering och förr eller senare är det version 2 av HTTP, det vill säga HTTP/2, som kommer vara något som uppmuntras inom SEO.

Om HTTP/2

Du som inte har en aning om vad HTTP är för något så kan jag i korta ordalag förklara att det står för HyperText Transfer Protocol, vilket antyder att det är protokollet för Hypertext – det vill säga HTML. Man kan säga att HTTP är det hemliga språket din dator pratar med den webbtjänst som du ansluter till. Du har säkert sett det i adressfältet när du surfat på nätet. När det istället står HTTPS betyder det att det ligger ett lager av säkerhet ovanpå HTTP, detta i form av något som kallas för TLS (står för Transport Layer Security).

Den version av HTTP vi har nu standardiserades på 1990-talet och kräver en del lappande och lagande för att det ska fungera så som webben ser ut idag. Därför startade Google arbetet med SPDY, vilket blev startskottet för den nu standardiserade HTTP/2 (namnet på version 2).

Det HTTP/2 erbjuder är att göra våra webbaserade tjänster snabbare, enklare och mer robusta. Detta görs på teknikerspråk genom att stödja full multiplexing, vilket minskar väntetiden. Målet är att ungefär halvera tiden det tar att ladda in en webbsida. Dessutom införs komprimering på HTTP-huvudet vilket betyder att innehållet i omfattande cookies inte kommer sänka prestandan fullt så mycket.

Du som har läst på om HTTP kan dock vara lugn. Egentligen är det inget av det du lärt dig som förändras, det är samma namn på fält och samma metoder som tidigare. På grund av detta är en övergång till HTTP/2 ganska odramatisk.

Det är en god idé att proaktivt undersöka om man kan stödja HTTP/2 med sin webbplats, till en början utan att det stör i de fall en stor andel består av mindre sofistikerade besökare med HTTP 1.1.

Nu kan webbplatser pusha notifieringar

En helt ny grej med HTTP/2 är att webbservern själv kan ta initiativet till en kontakt med en klient/webbläsare. Tidigare har webben gett sken av att kunna ha tvåvägs-kommunikation. Men på en teknisk nivå råkar webbservern ut för en minnesförlust mellan varje anslutning och klienten var tvungen att med jämna mellanrum påminna om sin existens. Det vill säga, klienten gjorde konstant förfrågningar om servern hade något nytt att säga.

Att webbservern nu kan ta initiativet till denna kontakt bör även spara på slösad trafik, minska belastningen på datorer vilket gör att de drar lite mindre ström. Detta har man fram tills nu försökt lösa genom en teknik kallad websocket, men där kan det ske utveckling framöver.

Webbhotell eller egen server?

Ligger din webbplats på ett webbhotell får du nog snällt vänta tills de bestämmer sig för att erbjuda detta. Men om den ligger på en egen server kan det vara värt att kolla vad som går att göra. Det är på inget sätt bråttom att göra en övergång till HTTP/2, men vid nästa översyn av webbplatsen är det definitivt läge. Om webbplatsen ännu inte kör HTTPS bör även det utvärderas. Det HTTPS visar för din besökare är att dennes integritet är värdefull, att formulär som postas inte kan snokas upp på vägen mellan webbläsaren och webbplatsen. Samt att innehållet på respektive sida är hemligt för de som administrerar alla nätverk på vägen mellan besökaren och webbplatsen.

Samtliga webbläsartillverkare har lovat att implementera HTTP/2, så då återstår bara att din webbserver får stöd för att du och dina användare ska kunna dra nytta av denna nya version av HTTP.

Se till att spårning av webbplatssök, outbound links, felsidor och nedladdningar fungerar

Förvånansvärt ofta när jag hjälpt till med kollegors och kunders webbplatsstatistikverktyg har man inte spårat vilka sökord som används på webbplatsens egen sökfunktion. De flesta har idag en sökfunktion och som du kan läsa i denna boks djupdykning i ämnet sökanalys är det en värdefull resurs.

För den som tänker att man kan nöja sig med att ha koll på sökord folk använder på externa sökmotorer som Google så har man missat en helt avgörande skillnad. De som söker på Google är öppna för förslag om vem av alla som kan hjälpa dem vidare, medan de som söker väl inne på er webbplats söker efter vad de tror finns på er webbplats. På så sätt kan man i klarspråk få reda på användarnas förväntan och förhoppning. Dessutom är det intressant att kolla vad som eftersöks då det tyder på att användarna kan ha svårt att hitta just det innehållet. Kanske behöver det lyftas fram?

Inte bara spårning av sökningar är sådant som du ska konfigurera i ditt verktyg, det finns säkert mycket mer. Problemet med att inte göra dessa inställningar proaktivt är att det inte alltid går att återskapa i efterhand när du inser att de är bra. Kanske börjar du på ruta ett.

Se också till att spårningen av utgående länkar görs korrekt, du vill kunna veta till vem du driver trafik. Givetvis är du intresserad av att veta om när användarna hamnar på felsidor, och är det möjligt att spåra även mer allvarliga fel så kan det visa sig nyttigt. Erbjuder du nedladdningar på webbplatsen, eller har en massa innehåll uppladdat, så säkerställ att du vet om hur det används. Utomstående kanske direktlänkar till ert innehåll utan att ni förstår vad som händer.

Ibland kan man gruppera olika sorters innehåll i sin webbplatsstatistik. Låt säga att man har artiklar för inspiration, produktsidor och supportsidor så kan det vara intressant att se hur de bidrar till helheten.

Inte råka läcka person- eller kunduppgifter till webbanalysverktyg eller andra tredjepartssystem

Utan att man tänker på det kan mer eller mindre känsliga uppgifter hamna i system där de inte hör hemma. Mest anmärkningsvärt är väl om man läcker känsliga personuppgifter till tredje part, men även om det hamnar personuppgifter i fel verktyg kan det innebära en risk för missbruk.

Så fort man samlar in personuppgifter så ansvarar man också för hur dessa hanteras, vem som kommer åt dem, etc. I de flesta länder finns lagar som reglerar integritet och dataskydd. Det kan vara värt att göra lite research kring detta för den marknad man agerar på så det inte kommer som en obehaglig överraskning senare.

Vill man prata med utvecklarna på utvecklarspråk, eller kravställa det i sin prestandabudget, kodningsstandard eller vad man vill kalla det, så är det att man förväntar sig att innehåll och formulär använder POST-metoden i HTTP. Som avdankad utvecklare kan jag väl medge att många utvecklare inte är så jäkla bra på HTTP. Om man exemplifierar det med att man inte ska använda GET kanske det klarnar. Om det behövs mer förtydligande så nämn något med att det inte är tänkt att ett postat formulärs fält ska visas i klartext i adressfältet.

Faktum är att denna typ av hantering dessutom gör det lite krångligare att få översikt, eftersom man får fler unika adresser till en och samma vy i webbplatsen. Om det omständliga inte var argument nog, eller att det är dålig praxis, så är det också ett brott mot bland annat Google Analytics avtal att skicka dem personuppgifter. Det är väl bäst att låta bli innan man får sitt konto helt brutalt nedstängt för avtalsbrott.

Tre eller färre stilmallar

Stilmallar är svenska för CSS (Cascading Style Sheet) vilket är en lösning, tro det eller ej, från 90-talet, skapat av Microsoft. Tanken är att skilja formgivning från innehållet och strukturen på en webbsida.

Det är svårt att argumentera för att en besökare på en webbplats har nytta av att stilmallen är uppdelad på många olika filer. För utvecklaren som skapade webbplatsen däremot kan det vara mycket smidigt att ha flera stilmallar.

Hur många CSS-filer behöver vi?

En stilmall som nollställer alla avstånd till webbläsarens ytterkanter är inte ovanligt (så kallad reset.css), en till för grundläggande design, och en till för gemensamma färger så man följer den grafiska profilen. En ytterligare CSS-fil för att webbplatsen ska följa responsiv webbdesign (vilket ofta är ett tillägg på befintlig webb), sen en till för att sätta färger på den lokala versionen av webbplatsen.

Sedan tillkommer det inte sällan några stycken beroende på dina tillägg i Wordpress (eller fulhackande webbkonsulter). Men låt oss nöja oss med 5 CSS-filer att ladda ner, så vi är på säkra sidan i ett litet matematiskt exempel.

Varför minimera antalet stilmallar?

Anledningen till varför du vill ha få stilmallar, CSS-filer alltså, är för att varje fil som ska laddas ner har en väntetid innan den börjar skickas till besökaren. Detta beror på vad kidsen av idag kallar för lagg. Exakt hur lång denna väntetid är beror på åtminstone tre faktorer:

1. Den webbserver som sänder filen.
2. Nätverket mellan servern och besökaren.
3. Besökarens egna uppkoppling till nätet.

På grund av denna väntetid vill man normalt sett ha så få filer som möjligt att skicka till en besökare. Ju fler filer desto mer tid som går till spillo på väntan.

Ta exemplet ovan med fem CSS-filer. I bästa tänkbara scenario kommer det inte märkas alls, då räknar vi kallt med att besökarna sitter på en trådad uppkoppling, solen skiner, alla utom dina besökare är ute i någon stadspark och grillar korv å dricker rosévin. Just din tilltänkta målgrupp är de enda som använder Internet och din server mår bra.

I ett mer rimligt scenario kommer åtminstone någon i din tilltänkta målgrupp vara i den sitsen att de har en tveksam mobil 3G-uppkoppling med svarstider på 0,1 sekunder. Det innebär att det går åt en halv sekund för att vänta på att få reda på hur innehållet ska se ut, vilka färger och teckensnitt som används och hur högerkolumnen ska falla in i botten på sidan för mobila besökare. Då har vi inte räknat in tiden det tar att överföra CSS-filernas faktiska innehåll – bara den tid det tar att vänta på att filerna ska börja skickas.

Varför har man mer än en endaste stilmall?

Ja, det kan man faktiskt undra. Om jag spekulerar, och drar växlar på mina erfarenheter som webbutvecklare, skulle jag påstå att det beror på lättja i kombination med oprecisa krav från beställaren. Man skyller ifrån sig och menar att kunden ska kunna webbutveckling bättre än de webbutvecklare man i upphandlingen sålde in som landets främsta experter.

Det är alltid lite för enkelt att skylla på beställaren. Just i detta fallet kan det tillkomma fler CSS-filer för användaren att ladda ner för varje ”snabbfix” som görs på en webbplats. Eller om du nu kör Wordpress får du passa dig för vilka extrafiler ett plugin behöver.

Fulhack, snabbfix, latmaskar, okunskap eller ingen yrkesheder?

Jag har dessvärre varit med om att kollegor lagt in en till CSS-fil på en sida. När jag frågade varför de valde att tillföra ytterligare en fil som fördröjer inladdningen av en webbplats fick jag ofta till svar att det var den snabbaste lösningen. Är man inte överens om någon form av lägstanivå av kvalitet är det tyvärr bara att hålla med, det är absolut enklast och snabbast att göra fulhack – det är därför det heter fulhack…

3 eller färre Javascript-filer

Inte sällan laddas det ner en massa Javascript man som användare aldrig kommer ha användning för. Ofta är de uppdelade i flera filer vilket bidrar till extra väntetid. Som vi alldeles nyss konstaterat är det normalt sett en fördel ju färre filer som behöver skickas till en besökare.

Du kanske frågar dig varför man gör på detta uppenbart slösaktiga sätt och delar upp innehållet i flera filer? Ja, det enkla svaret är att det är enklare att räkna på kostnaden för att en utvecklare ska bli färdig snabbt än all den tid man slösar på användarnas bekostnad.

Givetvis behöver det ske en avvägning av intressen här. Därför behöver man ha någon form av måttstock över vad som är ok när det gäller användning av Javascript. Just denna punkt handlar om antalet Javascript-filer, att man ska slå ihop dem, men det finns förstås en gräns för hur stor filen får lov att vara för att man ska vinna något.

Vanligt förekommande uppdelning av Javascript

Inte sällan har man några olika kategorier av Javascript-material, exempelvis Javascript som:

• Omvandlar menyn på små skärmar, sätter dit en sån där hamburgermeny vilket sparar massor med plats.
• Stödjer interaktion i formulärfält, exempelvis genom att tala om vilka obligatoriska fält användaren glömt fylla i vid postning.
• Följer med designramverk, exempelvis Bootstrap, vilket hjälper till med designkomponenter som dialogrutor, hur felmeddelanden ska visas (och en massa ytterligare designmagi man valt att inte använda på just sin egen webbplats).
• Jquery-biblioteket slängs ofta med av vana, men ganska ofta krävs det som komponent av andra komponenter.

Förutom dessa har man ofta fått ett eller flera Jquery-baserade tillägg för bildgallerier, betygsättning av sidor och annat.

Om man inte passar sig får man dessa Javascript i varsin Javascript-fil. För den som väljer att försöka göra ett bra jobb ställs inför vilka Javascript man ska kombinera till en enda fil (om nu inte alla). Problemet är att du måste göra en avvägning mellan att skicka Javascript-kod som inte kommer användas av varenda besökare och att dela upp det hela i flera logiska grupperingar. Alla dina besökare kommer inte se bildgalleriet, exempelvis, så alla behöver inte de Javascript-filerna.

En sak är dock klar, latmaskversionen allt för många kör med är att all Javascript laddas ner från varsin fil oavsett om de ens behövs på den sida som anropar dem.

Säg exempelvis att man valt att ha massor med enskilda Javascript-filer, då bör bara de som behövs för en viss undersida laddas ner. Alltså laddas inte Javascript för formulärvalidering ner på en sida som saknar formulär.

Alternativt sätt är lazy loading

Lazy loading är ett designmönster som går ut på att det som behövs för en sidvisning laddas ner lite senare, eller endast vid behov. Precis som att bilder i sidfoten inte behöver laddas ner för majoriteten om bara ett fåtal skrollar sig ner dit, på samma sätt kan Javascript-filer laddas ner när de kommer till användning.

Motivationen till detta är givetvis att inte tynga ner mer än nödvändigt. Kritiken mot att slå samman alla Javascript-filer är att då får användaren ta emot massor med data som är onödigt för just deras besök.

Det lazy loading förutsätter är att svarstiden behöver vara mycket låg, det vill säga att det går oerhört snabbt att från besökarens webbläsare få något överfört från webbservern. Det är definitivt inte fallet om besökaren har en trådlös uppkoppling via 3G- eller Edge-nätet. Däremot är det utmärkt för 4G-nätet och givetvis alla modernare trådade uppkopplingar. Så frågan är vilken typ av besökare din webbplats har, och hur stor andel av dina besökare är försumbara för det designmönster du väljer.

Det finns som du förstår anledning att ha en viss prutmån, och i min värld är tre Javascript-filer den prutmånen, särskilt då det utan särskilt stor ansträngning vid nybyggnation av en webbplats kan vara en enda Javascript-fil.

Utöver antalet Javascript vill man helst inte att de laddas in innan sidan kan visa upp sig, detta kan du kolla i Google Pagespeed numera, tror det står att man ska prioritera synligt innehåll om de tycker att man fallerat (”above the fold”).

3 eller färre bilder för utseendet

Utvecklare bör använda CSS istället för bilder i så stor utsträckning som möjligt. I forntiden, då när man gjorde layout med tabeller, använde man bilder, som blank.gif, för att knuffa bokstäver in från vänstermarginalen. Dessutom kunde man inte räkna med att CSS funkade i äldre webbläsare.

Idag finns det lösningar på de flesta av dessa problem. De kallas för polyfills, shims och en del annat, men poängen är att de lappar och lagar på gamla usla webbläsare. Det gör att frontend-utvecklaren (den som skriver CSS, HTML och Javascript) kan använda modern webbstandardiserad kod.

Anledningen till att vi vill hålla nere antalet filer är samma som jag skrivit tidigare, extra filer bidrar med extra väntetid – vilket särskilt drabbar de med svajig internetuppkoppling. Bäst är som alltid att skicka så lite som möjligt och bara det som man absolut måste.

”Men då slänger jag in en webbfont, en SVG-fil, och en CSS sprite!”

Javisst, men dessa tre lösningar är ju i många fall lösning på samma behov. Men då har man hållit sig till max tre vilket är min rekommendation, även fast det kan kännas lite slösaktigt.

Webbfonter kan förutom att beskriva utseendet på text innehålla ikoner man använder på sin webbsida. Kanske ett hus för hem, ett kuvert för kontakt m.m. Webbfonter är dessutom skalbara och passar därför bra på webben idag när man inte vet vilken storlek på skärm besökaren kan tänkas ha eller om den är högupplöst.

En responsiv webbplats kan också använda SVG (Scalable Vector Graphics). Med SVG kan du rent utav visa olika mycket detaljer i illustrationer från SVG-filen beroende på vilken yta som finns tillgänglig – responsiv ikonhantering med andra ord.

Bild 62: Glyphicons som används i ramverket Bootstrap

Den mer inarbetade lösningen är CSS sprites. Det går ut på att man har massor av bilder sammansatta till en enda bild. Sedan använder man CSS för att ha ett litet ”titthål” mot den bildkartan. Man positionerar alltså bildkartan bakom ett titthål och då syns bara önskad bild.

Ladda bara in det som behövs, när det behövs

Denna aktivitet bör inte tolkas bokstavligen men ses som en vägledande princip. Ett vanligt exempel är att först när användaren vill lämna en kommentar börjar man ladda in de filerna som behövs för just den delen. Säg att du använder en tredjepartstjänst, som Disqus för kommentarer, så laddas de filerna in vid behov istället för vid varenda sidvisning.

Även när det gäller filer som ska skickas från ens egen webbserver kan man jobba på detta sätt. Detta är särskilt intressant om man uppgraderat till HTTP/2 då det inte är lika kostsamt, prestandamässigt, att skicka en ny fil. Men glöm som sagt inte bort att ha koll på upplevelsen för de användare som ännu inte stödjer HTTP/2 med den utrustning de använder. Här ska du tänka precis som med designprincipen om progressiva förbättringar – alla ska ha en bra upplevelse, men de med väldigt modern utrustning kan få en ännu bättre upplevelse.

Ett första steg åt det här hållet är att paketera olika sorters innehåll i olika grupper. Att filer på en webbplats kan ha interna beroenden av varandra kallas för AMD (Asynchronous Module Definition)⁶⁵ och det finns kodramverk, som Require.js, som hjälper till. Det här är mer något att titta på när man bygger om eller bygger nytt.

Se till att du har tillgång till bra data för webbanalys

Åtminstone i större organisationer så har man ganska komplicerade IT-miljöer. Saker som jag snubblat över inte bara där jag jobbat utan även på publika webben är att man får felmeddelanden, skickas till en inloggningssida eller stoppas av någon annan anledning. För att ha full koll på användarens upplevelse behöver du se till att ha data om dessa avvikelser, du kan inte räkna med att allt sådant samlas in i ditt webbstatistiksystem.

Som allra lägst bör ditt verktyg för webbanalys samla in data när användare landar på din Error 404-sida, men det finns en driva till med felmeddelanden. Exempelvis att man inte har behörighet till sidan och behöver logga in, eller att sidan kraschat av någon annan anledning.

Ibland är det kanske inte ens tekniskt möjligt att samla in dessa händelser till ditt verktyg för webbanalys. Men inte ens då ska du ge upp! Om det är något man kan ge sig f-n på är att tekniker som tar fram utrustning har haft någon form av loggning för deras egen skull. Försök komma över den loggen. Innehållet är kanske inte särskilt vackert eller begripligt, dock är det viktigt att nå vetskap om användarens upplevelse. Det finns verktyg som kan hjälpa dig att ständigt ha koll. Vill du ständigt veta hur läget är nu eller nyss kan du kolla på logganalys-plattformar som ELK (Elasticsearch Logstash Kibana). Men vill man hålla hårdare i pengarna kan man kolla på självhjälpsverktyg för det växande området kring data science, exempelvis Tableau (som även finns i en gratis-version, kallad Public).

Validera enligt WCAG 2.0 nivå AA

Från och med första januari 2015 blev det olagligt att på sin webbplats diskriminera de med funktionsnedsättningar. Det brukar dröja ett tag innan lagar prövats i domstolarnas alla nivåer, därför är det inte glasklart var gränserna går. Det finns förstås olika nivåer av hur stort övertramp man gör mot en funktionsnedsatt persons rättigheter. Att helt bli utestängd på grund av sin funktionsnedsättning är ju ett fall som förhoppningsvis blir svårt att slingra sig ur, medan domstolarna nog inte lär ingjuta gudsfruktan i de som glömt skriva alternativtext till en bild.

Ganska omgående blev Göteborgs Universitet anmälda till diskrimineringsombudsmannen (DO) för diskriminering av blinda personer. Den som anmält menar att hen utestängts genom att anmälningsformuläret för utbildningen inte var tillgängligt för blinda.

Om du inledningsvis inte ens kan söka kursen själv utan måste be om hjälp, då visar det att du kommer att få problem under kursens gång också.
- Stina Hörberg, synskadad som tillsammans med DO anmälde Göteborgs Universitet för diskriminering⁶⁶

Väl antagen till utbildningen visar det sig att den lärplattform som erbjuds eleverna inte går att använda för blinda. Det går inte att ta emot meddelanden från lärare eller ta del av tentaresultat. Göteborgs Universitet är dock medvetna om detta och svarar Sveriges Radio:

Vi håller på och se över vår tillgänglighet ur en rad olika synpunkter. Bland annat det som anmälan tar upp.
- Helena Lindholm Schulz, prorektor på Göteborgs Universitet

Om inte den svenska lagstiftningen är motivation nog så kom EU under maj 2016 fram till att det blir ett gemensamt ”Webbdirektiv”. Det kommer gälla offentlig sektor, de privata aktörer som bedriver service på uppdrag av offentlig sektor och det som avses är webbplatser, intranät och appar⁶⁷.

Ett sätt att slippa orda om exakt vilka grejer man vill leva upp till och sedan argumentera detaljer med sina leverantörer av webbsystem, eller webbutvecklare, gör det klokt att välja en etablerad standard. WCAG 2.0 (Web Content Accessibility Guidelines) är en sådan standard. WCAG erbjuds av webbstandardorganisationen W3C.

Det finns tre olika nivåer, nämligen A, AA och AAA. Ju fler A desto striktare efterlevnad till funktionsnedsattas behov. Vilken nivå du väljer är upp till dig, men följer du nivå AA skulle jag tippa på att du inte riskerar att fällas på grund av varken diskrimineringslagen eller EU:s webbdirektiv, men jag är ju inte jurist :)

Hmm, vad innebär detta med WCAG?

Egentligen bör väldigt lite av de krav WCAG ställer vara nyheter för någon som jobbat ett tag med publicering på webben. Bland annat betyder detta att man ska erbjuda textalternativ, exempelvis att bilder ska ha en alternativtext. Gör du videoklipp får du då även tänka på att ha ett textalternativ för det som talas.

Det ställs också krav på kontrastförhållandet mellan text och dess bakgrund. Hur hög kontrasten ska vara avgörs på textens storlek. Apropå text så ska den gå att skala om, något som skapar problem för dig om du är van att lägga text i bilder exempelvis vid skapandet av bildpuffar eller banners.

Mer om tillgänglighet och testverktyg

W3C har en lista med verktyg⁶⁸ för att testa tillgängligheten på en webbsida. Eftersom det finns olika regelverk är det värt att kolla så du lever upp till minimikraven där du har verksamhet. Exempelvis 508 Checker för att inte bryta mot den amerikanska lagstiftningen.

Om du har notifieringar så följ upp dem!

Det blir allt vanligare att webbplatser har notifieringar. Antingen på gammaldags sätt att man inne i gränssnittet har siffror eller andra markeringar om att det bakom en knapp döljer sig olästa eller nya grejer. Men på senare tid kan webbplatser notifiera även om webbläsaren inte är synlig på skärmen.

Du som använt jobbnätverket Linkedin.com kan inte ha undgått att deras notifieringssystem varit trasigt sedan begynnelsen. Microsofts Yammer har också visat en liten indikation om att påkalla uppmärksamhet när därunder inget nytt skymtas. De är säkert inte ensamma på långa vägar. I och med att användare kan vara anslutna mot samma tjänst via flera samtidiga kanaler, som app, mobilwebb och webb på en dator (för stunden i viloläge i ryggsäcken).

Har din webbplats notifieringar så se till att följ upp ifall det fungerar som det är tänkt. Enklaste lösningen är väl att fråga sina användare eller själv använda sin tjänst flitigt.

Ett annat alternativ är att designa tjänsten så man kan följa upp det. Det går att bygga in loggning av användargränssnittet. Exempelvis om en knapp haft statusen ”nya meddelanden” och om det ändå bara varit lästa meddelanden efter ett klick.

Numera kan ju även datorer ta emot denna typ av notifieringar, så vi riskerar att framstå som mer än lovligt inkompetenta om det plingar lite överallt men inget nytt finns att se.

Viktiga utlänkar ska leda till tillgängliga webbplatser

Dels hjälper du de av dina egna besökare som har en funktionsnedsättning, samtidigt styr du med hjälp av dina utlänkar din webbplats förtroende och kraft mot sidor som har samma värderingar som du har.

Exempel på verktyg för att kolla webbplatsers allmänna tillgänglighet görs med verktyg som WAVE⁶⁹, eller om du vill automatisera kontrollen kan du kolla in Tenon.io⁷⁰ - du kanske inte kan räkna med att webbredaktörer tar sig tiden.

Sidvisningar ska vara på under en sekund?

En vinkel på varför det är viktigt för dig är sökmotoroptimering (så kallad onpage-optimering). Google ger dig en viss tid för deras indexering. Då är det ju bra om de hinner med många sidor, eller hur?

För att löpande hålla koll på sökjättens resonemang kring webbprestanda är det deras prestandaguru Ilya Grigorik du ska följa. Vill du läsa in dig på teknikaliteter har han lagt ut sin bok gratis på nätet – High Performance Browser Networking⁷¹.

Bättre användbarhet på webbplatsen vilket leder till högre konvertering

En annan anledning till varför en webbplats behöver vara snabb är för användarnas skull. De tappar känslan av flyt och upplever att de väntar ungefär när det gått en sekund. Då riskerar man att tappa sin användare innan de uppnått det du eller hen ville med besöket.

Rekommendationen är att servera en sida på cirka 0,1 sekund. Då upplevs det som att interaktionen är omedelbar. Tar det mellan 1–10 sekunder börjar användaren uppleva att de väntar. Även fast studier visar att de flesta klarar av att hålla koncentrationen på vad de håller på med så börjar tekniken att irritera användaren.

Slösar inte med webbserverns resurser

En ovanlig vinkel på varför en webbplats ska ladda snabbt är för att webbservern som skickar sidan inte kan hantera ett obegränsat antal samtidiga överföringar. Det faktiska antalet varierar förstås med hur kostsam lösning man har men det finns potential att sänka sina serverkostnader, klara sig längre på befintliga servrar eller kanske att vara mer redo för en trafiktopp vid en kris eller en lyckad kampanj.

Gratis verktyg för att mäta en sidas laddningstid

Vill du göra det enkelt för dig så kolla in Googles verktyg Pagespeed Insights, den varnar om serverns svarstid är för lång. Samtidigt, Pingdom har ett flertal tjänster för detta, men intressantast är den som mäter webbplatsens svarstid flera gånger i timmen. Då får du ett diagram över prestandan över tid och kan också ta emot varningar via en mobilapp.

Google Pagespeed mobilt ska vara minst 80 av 100

Google Pagespeed är ett konkret mått på hur bra prestanda en webbplats har, något som både Google och riktiga användare bryr sig om. En anledning till varför du kanske nöjer dig med Googles synsätt är för att vi ändå är i deras våld när det gäller SEO.

Nu kanske det inte är 80 av 100 det just du ska välja. Dock behöver du välja en nivå, något som stämmer överens med din ambition kring webbplatsens prestanda. Du kanske ska höja nivån och välja 90? Om mobila kunder är de viktigaste för dig. Eller så väljer du 50 om din webbplats har en lång väg att gå för att bli bra i mobilen.

Google själva har dock en åsikt om vad de tycker är en bra nivå (min fetning):

The PageSpeed Score ranges from 0 to 100 points. A higher score is better and a score of 85 or above indicates that the page is performing well. Please note that PageSpeed Insights is being continually improved and so the score will change as we add new rules or improve our analysis.
- Googles dokumentation om Pagespeed Insights⁷²

Skapa en testsida för att utvärdera förändringar i webbdesign

För att det ska vara en rättvis jämförelse från en mätning till en annan behöver man testa under samma förutsättningar. Med andra ord måste man sätta upp en representativ testsida på sin webbplats. Just den sidan är den man gör tester mot för att veta att resultatet är jämförbart över tid. Det som kan skilja är webbserverns svarstid, annars ska sidans innehåll i redaktionell mening i mångt och mycket vara samma från en gång till en annan.

Gör du på detta sätt vet du om förändringar i webbdesign gjort läget bättre eller sämre. Det kan vara att du prövar att byta tema om du kör Wordpress, att dina webbkonsulter uppgraderat något eller möjligen gjort en nyutveckling.

Hur man utformar sin testsida

För att din testsida ska vara meningsfull gäller det att den ur redaktionell utformning är praktiskt taget densamma över en längre tid. Om du ska kunna jämföra resultatet före en uppgradering av publiceringssystemet med efter gäller det att innehållet är snarlikt.

Mitt förslag är att du skapar en undersida enbart avsedd för test. Den sidan ska innehålla text, bilder och sådant som är normalkomplext för en vanlig sida på webbplatsen. Det är inte här du bäddar in en massa konstiga externa tjänster, widgets, videoklipp eller sånt varken du eller dina utvecklare har kontroll över.

Gör en nollmätning

När du har din testsida gör du en första mätning hos Google Pagespeed, sedan stämmer du av resultatet med alla inblandade och dokumenterar det någonstans (så folk fattar att detta får de lov att leva med framöver). På något lagom högtidligt sätt borde man säkert förklara att det inte är acceptabelt att resultatet blir sämre.

Eventuellt är du ju din egen motpart, då är en jurist något överflödigt och du får säga åt dig själv att skärpa dig :)

Bilder ska bearbetas för webben

Det finns mycket att tänka på när man utsmyckar sin webbplats, men också när man fyller den med redaktionellt innehåll. De som utsmyckar är oftast proffs på bildhantering, men inte alltid lika proffsiga på vad som gäller för webben och vilka villkor som webben ställer.

Sedan finns det redaktörer och alla användare som laddar upp material till webbplatser. Det är inte alltid vi får till det, inte heller säkert att vi får hjälp av de verktyg vi erbjuds.

Ibland har man bilder via en mediabank, där mediabanken som gör jobbet åt en, ibland laddar man upp dem manuellt. I dagsläget när alla till sist köpt in på att webbplatser måste vara responsiva ner till en mindre skärm så uppstår ännu ett bekymmer. Nämligen att de små skärmarna ofta har högre upplösning än de stora, och därför kan dra nytta av mer detaljrika bilder (samtidigt är inte skärpan saliggörande).

Men de små skärmarna, mobiltelefoner i de flesta fall, är också behäftade med den stora nackdelen av att ha en trådlös och ibland svajig uppkoppling. Det innebär att även normalupplösta bilder kan upplevas som jättesega att ladda ner.

Bildhantering för webben är med andra ord svårare än någonsin.

Bilder bör vara i den upplösning som de ska visas

Ett ytterligare krux är att de flesta responsiva webbplatser har flytande kolumnbredd. Så som nästan alla designat det så finns bilder som fyller hela kolumnens bredd, vilket leder till att vi inte på förhand vet exakt i vilken storlek bilden kommer att visas upp.

Ta då som ett tankeexempel att mittkolumnen kan vara från 300 till 500 pixlar bred. Bilden som visas i toppen i den kolumnen behöver vara lika bred som kolumnen för att det ska se ”harmoniskt” ut.

Väljer du då att ladda upp bilder som är 500 eller 300 pixlar breda?

Låt oss räkna på skillnaden. Säg att bilden har ett 2:1-förhållande i sin storlek. Då blir den större varianten 125 000 pixlar (500 x 250). Är den istället 300 bred blir det totalt 45 000 pixlar (300 x 150). Det är en väldans skillnad på bildyta och ditt val kommer definitivt att påverka prestandan.

Som lök på laxen har vi utmaningen med högupplösta skärmar. Vad Apple-användare kallar för retina. Det innebär ofta dubbelt så hög upplösning, det vill säga att varje pixel blir fyra för att nå maximal skärpa – så det inte ser suddigt ut för de som vant sig vid skärpan.

Ovan bild skulle alltså vara 500 000 pixlar för att vara riktigt skarp (1000 x 500). Det är tio gånger så mycket data jämfört med om du väljer att skicka bilden i 300 x 150.

Vågar du skicka en sådan högupplöst bild till en mobiltelefon som emellanåt är uppkopplad på ett tveksamt mobilnät? Här får du göra en avvägning, men som jag hoppas du förstått är detta inget man kan göra utan eftertanke. Grundregeln är förrädiskt enkel: bilder ska vara i den upplösning som de visas, samt att man inte ska skala ner dem med HTML eller CSS.

Oroar du dig över detta så läs gärna på om responsiva bilder på nätet, dessutom har jag lite mer om det i min bok Webbstrategi för alla.

Bilder ska sparas i lämpligt format

Grundregeln är att bilder ska vara sparade i det format som möjliggör minst filstorlek i relation till en bibehållen bildkvalitet.

De flesta känner till formaten GIF (uttalas tydligen ”jiff” enligt tyckare), JPG och PNG som något man stöter på på webben. Dessa format har sina styrkor och svagheter, extremt kortfattat:

• GIF stödjer animationer och transparens, men endast 256 färger. Effektivt just för animationer och ibland enkla illustrationer, som logotyper.
• JPG är ett format för fotografier. Väldigt bra på alla bilder som saknar ytor med en och samma färg – om sånt inträffar brukar de ”blöda” och visa rosa och gröna fläckar om det komprimerats.
• PNG har två varianter, en på 8 bitar och en på 24 bitar. Den på 8 bitar har likheter med GIF då man kan ha maximalt 256 färger. Vid 24 bitar får man även transparens samt att den då stödjer miljontals färger. PNG är mest effektiv som 8 bitars och för illustrationer, informationsgrafik, logotyper med mera.

Sedan tillkommer initiativ som WebP, skapat 2010. Något som Google, Ebay och Facebook har bedrivit kampanj för. De råkar ju visa väldigt mycket bilder så det ligger absolut i deras intresse att få ett brett stöd bland webbläsarna. WebP-bilder är enligt tester jag läst upp till 25 % mindre i storlek jämfört med den av de tre andra som presterar bäst. Så det är något att hålla ögonen på.

Bilder behöver sparas för webben

När du valt rätt format behöver en bild sparas optimerat för webben. Detta finns i alla bildbehandlingsprogram jag stött på. Det kan vara så att om du tvekar på att du valt rätt format kollar de andra formaten när du väl sparar för webben. Åtminstone Photoshop stödjer detta genom att man högst upp i högra hörnet på dialogrutan kan välja format.

Om du väljer PNG så kolla gärna om filen blir mindre och fortfarande ser ok ut som 8-bitars, gärna med så få färger som möjligt. Efter ett tag får man rätt bra känsla för vilka bilder som kanske funkar som annat bildformat.

Med JPG-filer kan du dels lite grovhugget välja nivå av komprimering, men det finns också ett reglage där du kan välja mellan 0–100 hur mycket kvalitet du vill bevara. Var vaksam på ytor med samma färg eller nyans, och särskilt vaksam ska man vara kring ytor av hud på människor där vi tycks vara extra känsliga. Personen på bild kan upplevas som sjuk om bilden optimerats för hårt.

Det du kommer se vid för hård optimering är att detaljrikedomen tycks försvinna, att det uppstår missfärgade rutor av oftast grönt och rosa. Klipp in en bit vitt i ett foto och komprimera stenhårt så ser du vad jag menar.

Med en GIF-fil resonerar du som en 8-bitars PNG.

Kör bilder genom icke-förstörande optimering

Nu har du redan tagit tre steg för att en bild ska gå snabbt att ladda hem. När blir vi klara egentligen? Ja, detta är det sista steget i den process jag själv tar.

Det vi nu gör är att ta bort helt onödig data ur bilden – så kallad icke-förstörande optimering. Poängen är att optimeringen inte ska gå att upptäcka med blotta ögat, men ibland kan filerna bli väldigt mycket mindre. Räkna med att minst 5 % går att hyvla bort på precis vilken bild som helst.

Bild 63: Imageoptim skalar bort upp till tre fjärdedelar av bilders filstorlek.

Jag som kör Mac använder det fantastiska programmet Imageoptim. Det funkar så förträffligt att jag drar en massa bilder (kanske hela webbens bildmapp) till programmets fönster och sedan optimeras alla bilder och skrivs över på sin nuvarande plats. Efter det laddar man upp bilderna igen.

För dig som inte kör eller har tillgång till en Mac finns webbtjänster som gör samma sak fast lite mer omständligt. Det finns också tillägg till ens webbplats så detta kan göras automatiskt (så man inte behöver komma ihåg det). Till mina Wordpress-webbplatser har jag kört med ett plugin som heter Ewww Image Optimizer⁷³.

Inte använda teckensnitt som behöver laddas ned

Många gånger har en pappersfokuserad kommunikations- eller marknadsavdelning valt ett särskilt teckensnitt man vill använda i all sin kommunikation. Kanske tvingas man genom sin grafiska profil. Där ska inte webben sticka ut som ett undantag och då har man sett till att skicka teckensnitt (du vet det där som bestämmer hur bokstäverna ska se ut) även till besökare på webben.

Sedan finns det tillfällen när ett designramverk webbutvecklarna använt för att spara tid gör att besökaren måste ladda ner teckensnitt för att visa webbsidan. Dessa teckensnitt är inte alltid avstämda med identitetsansvarig inom organisationen.

Som vi tidigare konstaterat är det klokt att försöka ha så få filer att ladda ner som möjligt. Detta särskilt om man har en stor andel användare som inte har en jättebra internetuppkoppling.

Apropå sämre internetuppkopplingar så ska man också vara medveten om att det kanske inte blir exakt som man tänkt sig med det där fina teckensnittet. Det finns ett ganska självförklarande begrepp, Flash of Unstyled Text (FOUT)⁷⁴, som belyser problemet med att text kan hinna visas upp med ett standardteckensnitt och sedan blinkar det till när teckensnittet man just skickat appliceras. Det finns fler varianter på detta problem, Flash of Invisible Text som på bilden här intill.

Bild 64: Vi har nog alla väntat på osynlig text. Som dessa sociala knappar utan text. (Källa: SimonW på Twitter).

Webbtypografi

Även om man inte valt ett udda teckensnitt är det inte säkert att det teckensnitt man valt ut är det som visas för besökarna. Hur dina teckensnitt funkar kan du kolla på Font Family Reunion⁷⁵. Jag har själv hittat halvextrema typografiska avvikelser där ett teckensnitt utan klackar (så kallad sans-serif) ersatts med ett annat teckensnitt som har klackar (så kallad serif).

Ladda in teckensnitt via Google Fonts?

Använd gärna Google Fonts som tjänst för att ladda ner teckensnitt (om du nu måste). Fördelen är att om teckensnittet är vanligt bland andra webbplatser som använder Google Fonts finns chansen att teckensnittet redan finns i webbläsarens cache hos dina besökare och därmed inte behöver laddas ner på nytt.

Nackdelen är att det i många fall inte redan är nedladdat, men troligen är Googles servrar snabbare än dina. En annan nackdel är att du har lite av samma integritetsproblematik som med webbanalysverktyget Google Analytics om du låter Google hjälpa dig med att servera innehåll till dina användare.

Som du förstår så är det här med webbtypografi inte heller det något man ska lämna åt slumpen. Vill man ta den enkla vägen ut är tipset att inte ha några extra teckensnitt utan välja något vanligt förekommande teckensnitt som har ett högt läsvärde – ett teckensnitt som inte behöver laddas ner.

Följa W3C:s rekommendationer för HTML, CSS och Javascript

Praktiskt taget alla webbplatser består av HTML för sitt innehåll och struktur, CSS för hur det ska se ut visuellt och Javascript för att stödja interaktion. Det finns flera sätt att skriva kod i dessa språk men det finns också rekommendationer. Att se till att ens kod fungerar i många webbläsare, för så många som möjligt, utan att ställa en massa krav är det som kallas för att man följer webbstandard. Webbstandard är en god praxis att följa om man inte har exceptionellt goda skäl att låta bli.

Hur vet jag att vi följer webbstandard?

Det finns ingen certifieringsorganisation (vad jag känner till) som delar ut Ok-stämplar till dem som följer webbstandard. Dessutom är det nog, åtminstone i juridisk mening, ett alldeles för luddigt begrepp för att sammanfatta allt som ska stå i ett avtal mellan beställare och utförare.

Istället får man koka ner det till att följa de rekommendationer standardorganisationen W3C (World Wide Web Consortium) satt upp för den gränssnittskod som skickas till besökarna.

Följer man rekommendationerna ökar sannolikheten att det ser ut som det ska och fungerar oavsett vilken webbläsare eller typ av pryl användaren väljer.

Men alla fräna nymodigheter jag vill använda då?

En nyttig motvikt till vår naturliga nyfikenhet på att testa nya häftiga möjligheter är den allt mer stränga lagstiftningen inom tillgänglighet. Att det är diskriminering att begränsa folks möjligheter att använda webben.

Ett sätt att försöka jämka ihop flera intressenters behov är att utgå från designstrategin kallad progressive enhancement. Den går ut på att standardläget är att alla ska vara välkomna, men att man utan att försämra funktionsnedsattas upplevelse kan erbjuda finesser till de vars tekniska förutsättningar medger sådant.

Ett ytterst simpelt exempel på detta är hur CSS 3 fungerar i webbläsare, stöds det inte visas inte runda hörn på boxar. Det försämrar inte den grundläggande upplevelsen för någon, möjligen berikar den upplevelsen för vissa.

En annan designstrategi är graceful degradation. Den börjar till skillnad från progressive enhancement från andra hållet – att finesser skalas bort utan att ställa till det.

Min personliga rekommendation är att köra progressive enhancement men att tänket från graceful degradation används i felhantering och de felmeddelanden man lämnar ut till användare.

W3C har en tjänst, Markup Validation Service, som hjälper dig att kolla om en webbsida följer kodstandard den utger sig att följa.

Minifiera frontend-kod

Läser du koden bakom webbsidor? Det vill säga HTML, CSS och Javascript? De flesta gör inte det och det är ju förstås inte därför man har en webbsida. Man kan fråga sig varför det är så vanligt att webbutvecklare prioriterar sin egen yrkesgrupps intresse av läsbar kod framför besökarnas behov av en snabb upplevelse.

För en webbutvecklare är det jättesmidigt med läsvänlig kod när något behöver kollas på en webbplats som ligger ute skarpt på webben. Webbutvecklare sysselsätter sig mer än gärna åt nästintill religiöst fundamentalistiska ställningstagande kring hur man bör använda mellanslag istället för tabbar, eller tvärt om, när man ska radbryta kod etc.

Däremot du som försöker betala räkningarna på internetbanken skiter ju fullständigt i hur lättläst koden är för den extremt lilla grupp som producerar webbplatser, det enda du bryr dig om är att det fungerar bra och snabbt.

Minifiering i praktiken

All gränssnittskod (också kallad frontend-kod på svengelska) bör minifieras om det kan minska filstorleken nämnvärt. Det gör filen mindre tung att ladda ner. Det gäller förstås bara textfiler men med tanke på hur mycket Javascript och CSS många webbplatser använder kan det göra rätt stor skillnad. Jag har sett allt mellan 5 och 90 % mindre storlek på filer som minifierats, det påverkar som du förstår hastigheten en del.

Hur man börjar minifiera (som utvecklare eller på Wordpress)

Det finns flera sätt att införa minifiering på en webbplats. När jag byggt på Microsofts ASP.NET-plattform har jag valt att köra med byggskript (så kallade MSBuild) vilket gör att när kod paketeras för publicering tvättas allt från att göra utvecklaren glad till att istället möta användarnas behov. I mitt fall körde jag med Yahoos YUI Compressor. Många som kör med utvecklarverktyget Visual Studios projektmallar för ASP.NET MVC väljer att köra med automatisk bundling (sammanslagning av filer) och minifiering. Automatiken är åtminstone bättre än att låta bli.

Byggskript funkar fint för små team men är inte klockrent om man jobbar med kontinuerlig integration/uppdatering. Då behöver man bygga in detta i sin byggserver eller var i arbetsflödet det nu kan tänkas passa in.

Bild 65: Minifiering ingår i Cloudflares gratis- abonnemang.

För den som kör Wordpress kan man utvärdera diverse tillägg, eller så kan det finnas som ett tillval för den som har CDN/innehållsnätverk som frontar ens webbplats. Behöver man manuellt minifiera filer kan du gå till webbtjänster som Minify Code.

Det enda högst giltiga motargumentet jag hört så här långt är att om ens webbplats skickar alla textfiler komprimerat är just insatsen med minifiering inte lika avgörande. Komprimering går, högst förenklat, ut på att hitta mönster som tekniskt kan beskrivas. Ett sådant mönster är 20 tomma rader i HTML-koden, eller att varje rad inleds med massor med mellanslag för indrag. I de fallen kommer komprimeringen göra en del nytta. Om du bara vill välja en insats med hur du bearbetar textfiler så tycker jag att du prioriterar komprimeringen högre.

Och nej, det är inte synd om utvecklare om man gör koden mindre läsvänlig. Utvecklare löser gärna sina egna problem först och det finnas ett flertal tjänster för att göra kod läsvänlig igen. Bland annat under namn som ”HTML Formatter”, ”Online Javascript beautifier” för Javascript-kod och ”Format CSS Online” för CSS-kod.

Nu borde alla kunna vara nöjda – samtidigt :)

Skicka textfiler komprimerat

Väldigt stor andel av webben består av textfiler. Det kan vara HTML för innehåll som ska visas i webbläsare. Formgivningen på webbplatser stöttas av CSS (också känt som stilmallar) vilket också är ”vanlig” text. Detsamma gäller Javascript som hjälper till med bland annat interaktion. Sedan finns det massor med andra filer i textformat. Man kan argumentera att alla filer består av text men det ignorerar vi just nu.

Varför komprimera?

Praktiskt taget alla textfiler har överflödig information. För webbkod kan det vara att webbutvecklaren behållit en snygg formatering (full av mellanslag m.m.) för att den ska vara lättläst, men även i löptext finns ofta upprepningar eller sådant som kan packas ihop av en smart komprimeringsalgoritm.

Poängen med komprimering är att göra saker mindre. På webben komprimeras text innan den skickas till en besökare med hjälp av Gzip just för att filen ska vara så liten som möjligt och ta så kort tid som möjligt att föra över. Man försöker erbjuda en så snabb upplevelse som man kan.

Hur komprimerar jag i Wordpress, eller i .NET?

Vill du laborera så kan du kolla efter tillägg som gör komprimeringen åt dig. För Wordpress finns det en fil i webbplatsens hemkatalog, den har det udda namnet .htaccess och hanterar bland annat inställningar för komprimering.

På .NET-plattformen kan man ställa in detta i sin web.config-fil för webbplatsen.

Följa webbriktlinjer.se

Svenska myndigheter har tagit fram Vägledning för webbutveckling, ofta kallat webbriktlinjer.se, för att etablera en standard för webbutveckling inom offentlig sektor. För dig som varit med ett tag så är detta den nya tappningen av det som tidigare kallades för 24-timmarsvägledningen, då när många av oss fick tjata om att det inte var ok att myndigheter stängde av sin webbplats efter kontorstid.

Gäsp, vem bryr sig?

Även den som inte har med offentlig sektor att göra kan ha nytta av de hjälpsamma tips som finns i vägledningen. Särskilt med tanke på att de flesta punkterna stötts och blötts av landets främsta inom alla tänkbara inriktningar av webbutveckling. Om du inte idag har valt en standard för hur webbplatsen ska fungera är detta en utmärkt början.

Vägledningen finns där av en anledning. Det är ett sätt att inte internt fastna i diskussioner som ”men så har vi ju alltid gjort” eller att vid osäkerhet köpa någons argument med hull och hår.

Där jag jobbar har vi en massa dåliga vanor och organisatoriska egenheter. Bland annat är jag trött på att ständigt förklara varför man inte ska öppna länkar i nytt fönster. Istället för att argumentera brukar jag nu hänvisa till vägledningen, i detta fall riktlinje nr 97 om att bakåtknappen ska fungera:

Låt användarna själva välja om de vill öppna länkar i nya fönster eller inte. De flesta webbläsare har funktioner för att öppna länkar i nya fönster eller flikar.
- Webbriktlinjer.se, riktlinje 97⁷⁶

Om man öppnar länkar i nytt fönster kan man inte backa i webbläsaren. Användarna märker inte alltid att ett nytt fönster öppnats vilket bidrar med användbarhetsproblem helt i onödan.

Nu kanske man inte måste följa alla riktlinjerna så nitiskt att man stoppar all utveckling och memorerar alla riktlinjer. Dock är det en god idé att välja ut några man alltid följer och om diskussion uppstår om vad som är ”best practice” tycker jag att man följer vägledningens rekommendation om man inte har extremt goda skäl att låta bli.

För din bekvämlighet är riktlinjerna dessutom prioriterade, så du vet vad som är viktigast. Den första riktlinjen, som är prio 1, är faktiskt att följa tillgänglighetsstandarden WCAG 2.0 nivå AA, vilket vi redan tagit upp i aktivitetslistan.

Filers livslängd default till 30 dagar

Innan man börjar jaga hundradelar av en sekund på att föra över material till en användare bör man först luta sig tillbaka och ta en nypa frisk luft. Vad kan vara bättre än en snabb överföring? Jag skulle nominera en överföring som inte behövs. Något som inte inträffar borde vara oerhört mycket snabbare än det som händer.

Mitt förslag är att för filer man inte räknar med ska förändras på länge per automatik ska ha minst 30 dagars förväntad livstid. Varför just 30 dagar? Det är inte meningsfullt att sätta 20 år eftersom webbläsarna automatiskt tömmer sina cacheminnen med jämna mellanrum – 30 dagar duger gott.

Det man hoppas på är att en återkommande besökare redan har en stor del av webbplatsens filer i webbläsarens tillfälliga minne (dess cache). Vid ett återbesök kommer inte oförändrade filer skickas till besökaren utan endast de som är förändrade eller som inte laddades ner vid förra besöket (kan ju vara en annan undersida än vid föregående besök).

Detta är en del av den dolda information som webbservern lämnar över som instruktion till webbläsaren vid ett besök.

Vilka filer kan leva länge i webbläsarens cache?

Det här är förstås inte magi, det är inte heller en silverkula. Man måste använda huvet, alternativt börja i den fega änden av dessa möjligheter. Det finns filer som inte uppdateras nästan någonsin. Logotyper exempelvis, eller favoritikoner.

Inkluderar du Javascript-ramverket Jquery version 2.1.3 kommer den filen troligen aldrig att uppdateras, däremot ersättas av en nyare version. Med andra ord kan du lugnt sätta 30 dagars livslängd på filer vars filnamn indikerar dess version.

Nackdelen är dock att detta behöver göras med eftertanke, annars kan det uppstå lite oönskade bieffekter i webbdesignen. Många filer på en webbplats har interna beroenden, exempelvis får man oftast utseendet på webbplatsen i ett paket. Då gäller det att hela paketet uppdateras och alla ingående filer får nya adresser.

Precis som med Jquery borde du eller dina utvecklare jobba med versionsnumrering på filer som är en del av webbdesignen.

En annan sak att vara uppmärksam på är hur en bildbank levererar bilder direkt ut på din webbplats. Om bilderna uppdateras i verktyget men filnamnet är identiskt före och efter uppdateringen kan du inte räkna med att förändringen slår igenom. Därför är det inte bara att fulhacka in lång livslängd på ett system som inte är redo. Detta kan du reda ut med din webbutvecklare (eller dig själv).

Okay, men om jag nu panikartat måste få ut en ny logga?

Byt namn på filen och se till att den omdöpta filen används på webbplatsen. Svårare än så är det inte. Psst! Om din omdöpta fil enbart används via en oförändrad CSS- eller Javascript-fil kan även de behöva döpas om. Betrakta det som ett paket av beroenden.

Sätta livslängd i Wordpress (Apache) och i .NET

Som så många andra tekniska inställningar för Wordpress görs detta i filen .htaccess som ligger i webbplatsens hemkatalog. Det kan vara så att den är dold för det program du använder när du letar efter den, den där inledande punkten är UNIX sätt att säga att en fil ska döljas.

Kör du däremot med Microsofts .NET-plattform kan du välja om du ställer in det via din web.config-fil i webbplatsens hemkatalog eller om du gör inställningen i webbservern Internet Information Server.

Vettiga adresser

Det finns massor att tänka på när man utformar en vettig URL-struktur (URL – Uniform Resource Locator, URL och webbadress är samma sak). Till att börja med ska den vara läsbar så man förstår vem som är avsändaren och vad innehållet är.

Vad en URL inte ska innehålla…

Men det kanske är enklare att förklara vad man ska låta bli? En sak vi ser allt mindre ofta på den publika webben är sessionsunik information i adressfältet. Det är ett användbarhetsproblem om adressen du har i adressfältet inte kan skickas till någon annan för att se exakt samma sak som du såg på den adressen. Här får man verkligen tänka till när det gäller inloggade tjänster på webben, så adressen går att använda för att ge support, inte bjuder in till säkerhetshål, med mera.

Ett annat problem med sessions-ID i URLar är att sökmotorer kommer att få nya adresser vid varje indexering och det gillas inte att ha mängder med adresser till ett och samma innehåll. Ett sätt att hantera adresser som är varianter på en huvudadress är det som kallas kanonisk adress. Då anges det i metadata i sidans källkod vilken adress som är originalet, alltså den kanoniska adressen som är den man ber sökmotorer att indexera istället.

För att inte bråka med användbarheten ska man låta bli understreck och mellanslag. Detta gäller i de flesta fall även filnamn för filer som laddas upp och blir tillgängliga på webben, som dokument och bilder. Anledningen till detta är att en utskriven adress som blir klickbar på webben ofta är understruken, då är det svårt för den som läser adressen att vara säker på om det är understreck eller mellanslag. Istället ska man konsekvent använda bindestreck för mellanrum och läsbarhet.

Stora eller små bokstäver i en URL?

Man ska gärna låta bli att använda stora bokstäver. En av anledningarna är att man utsätter sin användare för den kognitiva bördan att göra skillnad på små och stora bokstäver – oftast i onödan. Man bör konsekvent köra med små bokstäver.

Hur dynamisk adress står man ut med?

Du har säkert sett adresser som har ett frågetecken i sig, följt av en massa ord och likamed-tecken? Detta är vad som brukar kallas för en dynamisk adress, där motsatsen är en friendly-URL som istället har snedstreck och en intern mappstruktur – ofta med föräldrar och barn.

En väldigt dynamisk adress – med tre eller fler frågeparametrar – kan förvirra sökmotorer, förutom att de oftast är mer svårförstådda för människor. Helst ska du undvika dynamiska adresser.

Kvalitetsindikatorer för en URL

Nedan tio punkter är hämtade från boken Webbstrategi för alla, där finns en mer grundlig genomgång än vad som är meningsfullt i denna bok.

1. Vara utformad för att kunna bestå över mycket lång tid.
2. Ange vem som är avsändaren.
3. Beskriva vad som finns på adressen.
4. Vara så kort som möjligt, inte innehålla oväsentligheter och vara enkel att memorera eller läsa upp över telefon.
5. Följa namngivningsstandard, det vill säga inte innehålla specialtecken, inga stora bokstäver etc.
6. Ha funnits ett tag, det är ett tecken på seriositet för en sökmotor.
7. Innehålla något unikt, med andra ord ska det inte finnas flera sätt att nå exakt samma innehåll.
8. Vara funktionell. Om adressen är hierarkisk ska det gå att sudda delar av adressen för att nå en högre nivå i strukturen.
9. Ge korrekt statuskod enligt HTTP. Saknas sidan är det 404 som gäller, är den flyttad skall man hänvisa vidare med status 301.
10. Ha någon form av rättstavningsfunktion så den klarar av felaktigheter som www som prefix, med eller utan avslutande snedstreck etc.

Många av dessa potentiella problem fångar du upp automatiskt med verktyget Optimizr.com, men jag rekommenderar alltid att göra manuella kontroller när tid för reflektion prioriteras – gärna kvartalsvis.

Responsiv typografi

Har du kollat igenom alla dina undersidor på en mobil eller annan liten skärm? Antagligen inte. Om man gör det så kommer det säkert dyka upp en och annan rubrik som orsakar att man måste skrolla i sidled för att kunna läsa hela ordet då svenska språket är uppbyggd av sammansättningar av ord.

Det här problemet gäller främst rubriker då de är av större storlek än brödtext, därför tar varje bokstav mer bredd i anspråk och långa ord får inte alltid plats. Men tänk gärna på tillgänglighetsaspekten, att vissa av dina användare antagligen kör med förstorad text, så det som gäller på din skärm återspeglar inte nödvändigtvis alla andras situation.

Mjuka bindestreck för avstavning vid behov

Lösningen på problemet är att sätta in mjuka bindestreck, som till skillnad från vanliga bindestreck endast avstavar ett ord om utrymmet kräver det. Mest uppenbara exemplet är väl huvudrubriken sedd på en mobils skärm, men det här kan lika gärna uppträda som ”hissläsning” – alltså ett ord per rad – om man har smala kolumner i sin design när den inte visas i fullskärm på en datorskärm.

Ett mjukt bindestreck kan skrivas in manuellt i ordet där du vill göra en eventuell avstavning, skriv bara in ­ vilket står för soft hyphen. Exempelvis:

<h1>Riksdags&shy;ledamot</h1>

Har du otur funkar det inte i ditt webbsystems vanliga textfält, då får någon utvecklare se till att man får skriva HTML även i dessa textfält. Ofta är problemet att systemet försöker konvertera bort &-tecknet vilket havererar ditt mjuka bindestreck.

Verktyg för detta är något mer omständligt än annars (än så länge). Du kan kolla sidors omdöme på textalyser.net vilket fungerar bäst med engelsk text men du får också en överblick över hur långa ord du har i en text.

En annan lösning för dig med en funktionsrik egen sökmotor är att tvinga den att rapportera på vilka sidor på din webbplats den hittar långa ord. Exakt hur långa ord som fungerar är svårt att svara på, men du vill nog gärna ha dem ordnade efter vilken längd som finns (och glöm nu inte att ha marginal så de som kör med förstorad text inte glöms bort).

Google Pagespeed Insights fångar problemet i sin användbarhetskontroll under ”Anpassa storleken på innehållet efter visningsområdet” när text inte får plats inom synlig yta. I skrivande stund – i version 2 – tycks den inte kunna varna om detta även när det gäller scenariot att användaren förstorat texten ett eller flera steg.

Innehåll publiceras som strukturerad data

Praktiskt taget varje webbplats har information som är av en strukturerad typ, men det är inte alltid som det publiceras på ett strukturerat sätt. Jag pratar här om innehåll som vi som människor hur enkelt som helst kan identifiera som en kalenderhändelse – som en sommarfest – eller en geografisk plats, att ”Stockholm” troligen avser den svenska huvudstaden snarare än den lilla hålan i USA.

Denna egenskap att förstå vad innehållet är eller avser har inte datorer. Du som är intresserad av sökmotoroptimering har nog inte missat allt prat om RDFa. Det är en av teknikerna för att märka upp innehåll så att en sökmotor förstår. Så till och med en maskin förstår innehållet.

Microdata, Schema.org och Microformats.org

Google tröttnade på att Microformats.org var så sega med uppdatering och släppte då Schema.org tillsammans med Microsoft, Yahoo, med flera.

Tar du en titt på webbplatsen så inser du att nästan all form av innehåll du publicerar kan släppas i ett strukturerat format. En av fördelarna är att man kan få mer utrymme i Googles träfflistor, exempelvis har du säkert sett recensioner och små kalendrar i träfflistan hos Google. Exakt på vilket sätt det visas upp är något som åtminstone Google ständigt experimenterar med. Att märka upp vem som författat en artikel eller bloggpost var något de bara visade upp under ett år innan de tog bort det.

Sökmotoroptimering, men inte nödvändigtvis högre ranking

Egentligen anses det inte bland sökmotoroptimerare att ens webbplats klättrar högre i Googles träfflista om man har strukturerade data. Däremot så får man i flertalet fall mer utrymme i träfflistan vilket definitivt är på bekostnad för de som ligger under ens sida i listan.

Vad som är rekommenderad mängd strukturerad data beror lite på vad din webbplats har för typ av verksamhet, men självklart ska din kärnverksamhet beskrivas strukturerat om det går. Exempelvis om du listar mottagningar för kunder så ange deras geografiska position, kontaktuppgifter m.m.

För att verifiera att dina strukturerade data är korrekta kan du testa med Google Structured Data Testing Tool⁷⁷.

Hänvisas till filer som inte hittas eller inte fungerar

Bara för att en webbsida laddas in utan att ge ett felmeddelande betyder det inte att allt är frid och fröjd. Bakom kulisserna gömmer sig ibland fel i någon av alla de filer som behövs för att webbsidan ska bli komplett, som den är tänkt.

Det finns flera orsaker till dessa fel. Vanligast när jag sett dem är att webbutvecklarna lyckats fumla bort någon fil när man lyft över ändringar från utvecklingsmiljön till produktionsmiljön. Då orsakar man ett 404-fel på en eller ett fåtal filer.

Det kan också vara så att det är ett serverfel som inträffar, det vill säga något i 500-serien. På vissa webbplatser skapas stilmallar, Javascript och till och med bilder av webbservern. De är alltså inte statiska filer på en hårddisk. Om ett fel i detta skapande inträffar – mer eller mindre tillfälligt – kommer servern dels inte skicka filen men också skapa ett fel.

Men varför är detta ett problem?

Anledningen till att detta är ett problem hänger ihop med vilken fil som saknas eller inte fungerar. Säg att det är stilmallen för utskrift så är det få som kommer upptäcka det men det gör utskrifter sämre än det är tänkt.

Sen riskerar alla typer av fel att ge dåliga signaler till sökmotorer när de ska ranka din webbplats. Att konstant ha problem med webbplatsen inger inte förtroende hos användarna.

Hur hittar jag dessa fel?

De avancerade sätten är ofta bara tillgängliga för större organisationer, men vi börjar här. Om du har tillgång till webbserverns loggfiler kan du ofta få detaljerad insikt i serverns syn på sitt välmående. Dessa loggfiler vill du helst slippa läsa som text så kolla gärna vilka analysverktyg som finns tillgängliga, kanske har du du Event Viewer i Windows Server, någon logganalys likt Kibana eller Splunk. Kanske kan du få loggfilerna och kör in dem i ett verktyg för preparering av data, som Tableau.

Att inspektera loggfiler och att övervaka fel bör intressera alla som inte är teknofober. Det är en indikator på hur en webbplats mår, om den utvecklats på ett kompetent sätt och om dess drift fungerar.

Du med webbplats på webbhotell

Har man en mindre webbplats är man ofta något mer begränsad i vilka val man har av analys. Men det är inget att hänga läpp över. Dina utgifter för att hålla igång webbplatsen är försumbara jämfört med vad ovan nämnda verktyg kostar :)

Förutom det uppenbara att vara uppmärksam på underligheter när man själv agerar användare på sin egen webbplats finns det verktyg som kollar detta åt dig. Enklast är de nätverksverktyg som finns i alla moderna webbläsare. Dem hittar du under respektive webbläsares utvecklarmeny. Där ser man alla filer som laddas in för en sidvisning, om de genererar fel eller inte. Det är främst HTTP-serierna 400 och 500 du behöver fundera på, har du gott om tid är det värt att fundera på 300-serien också då det inte är effektivt att anropa filer som hänvisar vidare.

Svagheten med den metoden är att man gör stickprov, en sida i taget och man måste göra det manuellt. Ett annat verktyg som gör detta lite mer automatiserat och på massor av sidor på din webbplats är gratisverktyget Optimizr.com – med nackdelen att du får vänta in rapporterna de skickar ut emellanåt. Optimizr.com fungerar för ganska passiv webbanalys och kan vara ett bra insteg för de flesta.

Fel statuskoder skickas – webbplatsen ljuger

Det tillhör gott uppförande att svara ärligt och konkret på frågor. Dessvärre är det inte alltid detta prioriteras när vi låter datorer kommunicera med varandra.

Praxis för HTTP (protokollet som transporterar webbsidor över internet) är att man talar öppet om ifall något gick bra (200 Ok), ifall materialet flyttat (301 redirect), försvunnit (410 Gone) eller liknande. För den mer oseriösa så finns till och med statuskoden 418: I’m a teapot om din smarta tekanna behöver kunna kommunicera över internet :)

HTTP statuskoder för att maskiner ska förstå varandra

För att webben ska fungera optimalt och maskiner förstå varandra behöver man följa dessa uppsatta regler för kommunikation. För icke-mänskliga användares skull, som Googles crawlers och andra botar, skall man följa HTTP:s statuskoder, punkt. Annars kan de inte veta om en adress eller sida upphört att existera, aldrig funnits eller inte kan hittas. Hur ska annars en maskin lista ut vad som hänt, de kan ju inte läsa och förstå text, något som inte ens behövs om man nu bara skickar rätt siffra, rätt statuskod.

Skickar du exempelvis statuskod 301 eller 302 så instrueras botar att adressen permanent eller tillfälligt flyttats till en annan adress. Inte alls svårt, egentligen.

Största avvikelserna på detta område är hur man väljer att berätta att något gick fel. Under 2015 gjorde jag en koll av Sveriges kommuners sätt att hantera 404-felmeddelanden. Testet gick ut på att utvärdera ifall de skickade 404 som meddelande på en uppenbarligen felaktig adress. 6,2 procent av de 290 kommunerna skickade ”200 Ok” istället för ”404 Not found”. De låtsas alltså som att inget fel inträffat.

Detta blir ett problem lite beroende på vilket innehåll man visar upp i samband med sin 200 Ok-sida. Att presentera sin startsida istället för ett felmeddelande är en naiv form av välvilja men fortfarande ganska vanligt. Då råkar man få väldigt många alternativa adresser till sin startsida vilket i SEO-sammanhang kan straffa sig beroende på om man tror på straff för duplicerat innehåll (och har glömt sätta kanonisk URL i sidans källkod).

Hur man hittar felaktig felhantering

En sak du kan göra är att manuellt skriva in en felaktig adress och se vad som presenteras. För att kolla vilken statuskod som servern ger kan du exempelvis kolla i nätverkspanelen som ofta följer med moderna webbläsare för datorer. Om du vill ha full koll på HTTP finns Firefox-tillägget Tamper Data⁷⁸.

Tänk också på ifall det är andra system som bidrar till webbplatsen. Exempelvis har ofta större organisationer specialiserade system för dokumenthantering, mediafilhantering, med flera och då behöver även dessa testas.

För en mer passiv webbanalys kan du anmäla din publikt tillgängliga webbplats till Optimizr.com och invänta de rapporter som skickas när de känner att de kollat din webbplats färdigt.

Går att kravla och indexera webbplatsen

Att ens webbplats inte är tekniskt tillgänglig kan vara precis vad man är ute efter, men det gäller sällan för en publik webbplats. Där är istället poängen att alla bör vara välkomna, både människor och maskiner, på majoriteten av innehållet.

Hinder som finns kan vara av olika art. Dels den mjuka varianten där man ber om att bli lämnad ifred alternativt försöker instruera botar att inte ta med sidan i index. Sen finns det där jättehöga hindret som att behörighet saknas.

Lägre hinder som kan vara problematiska

Det finns ett flertal mindre dramatiska sätt att försöka tala om för maskiner hur man önskar få sin webbplats behandlad. En klassiker som styr hela webbplatsens inställningar är att ha en fil kallad robots.txt som placeras i webbplatsens hemkatalog. I robots.txt brukar man ange vilka mappar sökmotorer och andra maskiner ska låta bli, var webbplatsens sitemap är placerad, med mera.

Huruvida en sida ska tas med i en sökmotors index kan också detaljstyras genom sidans egen metadata i HEAD-taggen. Där kan man även placera metadata som talar om sidans kanoniska förhållande inom webbplatsen, det vill säga om sidan är en variant av en annan. I så fall anges den andra, viktigare, sidans URL som canonical-URL. Det är ett sätt att kunna ha flera adresser till potentiellt samma innehåll, men att man talar om vilken huvudadressen är.

Det går också att på länkar ha instruktioner om hur maskiner ska bete sig, som att länkar inte behöver följas. Detta görs genom attributet rel=”nofollow” på respektive länk.

För många år sedan, 2008 närmare bestämt, råkade webbplatsen jag byggde på för Västra Götalandsregionen ut för att bli exkluderad från Google så sakteliga under min semester. Efter en massa frustration och felsökning så visade det sig att en uppdatering till mjukvaran bakom webbplatsen automatiskt hade satt upp en önskan om att inte bli indexerad. Google gjorde tyvärr som mjukvaran från Microsoft bad om. Det är förstås bra ju tidigare man upptäcker dessa problem.

Högre hinder för webbåtkomst

Sen finns ju de mer strikta sätten att stänga ute maskiner och det är att blockera dem eller kräva inloggning för att få åtkomst. Du har säkert råkat ut för att få upp en inloggningsdialog när du surfat på webben, men man kan inte alltid räkna med att ens få chansen att försöka logga in. Ibland blir man blockerad för att man inte sitter inom det godkända nätverket, inte har rätt IP-adress eller vad någon nu har satt upp för krav.

Verktyg för att upptäcka detta problem

Ett smidigt verktyg är SEO Doctor⁷⁹ som tillägg för Firefox. Om inte sidan kan indexeras visas en röd varningssymbol där du placerat tillägget i din webbläsare. Ett annat sätt att göra stickprov är Pingdoms Full page test⁸⁰.

Ska du leta efter behörighetsproblem så är det bland annat HTTP:s statuskoder 401 Unauthorized och 403 Forbidden du är ute efter. Det är inte omöjligt att detta loggas på din webbserver, men har du din webbplats på ett webbhotell kanske du inte kommer åt denna logg.

Optimizr.com har med även detta i sina rapporter, men då förutsatt att de indexerat hela din webbplats, annars får du leta efter andra alternativ.

Länkar till sidor som inte finns

Det är inte bara när sidor saknas på din webbplats som du ska bry dig. Om du länkar till en sida på någon annans webbplats och de kastar den så går det ut över dina användare som följer den länken.

Att inte har koll på de sidor man länkar till har blivit en allt mer het potatis inom sökmotoroptimering och lösningen är inte att sluta länka externt. Snarare ska du börja följa upp att de länkar du har faktiskt fungerar. Har du inte koll på dina utlänkar ger det en tydlig signal till sökmotorer att du inte arbetar aktivt med din webbplats redan etablerade material och att man bör betrakta din webbplats med misstro. Räkna med sämre ranking.

Börja kolla utlänkar

Om du känner för att kolla detta manuellt, vilket vi alla bör göra emellanåt, så börja med de sidor som används mest på din webbplats eller de som du tycker är viktigast. Kolla igenom alla utgående länkar så att de pekar på fungerande sidor och med förväntat innehåll. Inte sällan har de vi länkar till flyttat på det materialet länken avsåg eller rent utav tagit bort det. Se din länkvård som att påta i trädgården. Du blir skitig om händerna och får krökt rygg men det lönar sig på sikt.

Vill du istället kolla utlänkarna efter hur populära de är att klicka på så kan det vara något din webbplatsstatistik redan spårar. Outgoing links loggas i alla fall automatiskt i mina konton på Google Analytics.

Den ambitiösa och automatiserade kollen

Vill du göra detta i massiv skala kan du ha nytta av att ha egen sökteknik. Har du en organisationsintern sökmotor har den säkert möjlighet att indexera även webbplats-externa länkar och kan då samla på sig 404-fel med mera. Som du nog förstår kommer sökmotorn inte att begripa om det är ”fel” innehåll länken pekar på, så likt förbaskat behöver du göra manuella insatser emellanåt.

Finns stort intresse för webbanalys och översikt kan du säkert räkna på kostnaden att någon utvecklar en semi-automatisk kontroll. Utgå från webbplatsens sitemap, hämta ner alla sidor och sålla fram alla organisationsexterna länkar – sen kollar du om länkarna ger annat än HTTP statuskod 200 Ok.

Optimizr.com har med detta i sina rapporter, men det förutsätter att de bemödat sig med att kolla på hela din webbplats.

Servern ger felmeddelande i 500-serien

Felmeddelanden i 500-serien brukar ofta utvecklarna vara skyldiga till, eller så är det en teknisk driftstörning. Oavsett vilket är det värt att stanna upp och omgående ta tag i dessa problem. Jag kan inte föreställa mig något möte jag skulle stannat kvar i om jag fått reda på att vi hade HTTP-status 500 på vår webbplats.

Förutom det uppenbara problemet att det drabbar dina användare så ger det en dålig signal till sökmotorer. Din webbplats tycks inte vara robust eller pålitlig nog att skicka besökare till. Med andra ord bör du ha koll på dessa fel även om de aldrig inträffar när det är högt tryck på din webbplats.

Det måste inte vara hela sidor som är drabbade av serverfel, delar av det som krävs för en sidvisning kan var och en för sig lämna serverfel. Exempelvis om din stilmall genereras på webbservern eller kanske om du har någon hemmaknackad statistiklösning som skapar dolda bilder.

När kan man förvänta sig HTTP-status 500?

Det kan vara en driftsättning av ny kod som gått snett. Så om du vet med dig att det är driftsättningsdag kan du kanske lugna dig en stund innan du börjar jaga de som förhoppningsvis redan jobbar på en lösning.

Det kan också vara så att det är en överbelastning av webbplatsen. Ett sådant tillfälle jag själv genomlidit var när en långsam extern tjänst gjorde att hela webbplatsen gick ner. Du vet det där om att ingen kedja är starkare än sin svagaste länk. I det fallet fick webbservern vänta på svar från en allt för långsam extern tjänst. Eftersom en webbserver inte kan hantera oändligt många samtidiga användare så börjar den refusera nya besökare genom att svara med Error 500 mest hela tiden. Gränsen för just den webbplatsen gick vid cirka 140 000 sidvisningar per dag.

Överbelastningsattack?

Om det nu är en attack man råkar ut för eller annan inte legitim trafik kan detta vara en förvarning om att ta kontakt med dem som hanterar webbplatsens infrastruktur. I bästa fall finns ett filter att sätta in för att skydda webbplatsen men ändå släppa fram vanliga användare.

För många år sedan utfördes ett ”bus” mot Polisen.se från massor med webbplatser. De ville ge igen med anledning av tillslaget mot serverhallen där The Pirate Bay hade sina servrar. Attacken gick ut på att man läste in en tung PDF-fil från polisen.se vid varje sidvisning på de egna webbplatserna. På så sätt blev alla besökarna av dessa webbplatser även besökare (ovetande) på polisens webbplats – som stundtals gick ner för räkning.

Lösningen var inte nödvändigtvis att ta bort PDF-filen, då kanske alla 404-fel istället skulle sänka webbplatsen, däremot kunde man säkert ha kollat i nätverket var lejonparten av trafiken kom ifrån. Om man innan webbservern filtrerat bort trafik från webbforum, som hamsterpaj.net med flera, skulle webbservern fått lite andrum. Exakt hur denna episod slutade minns jag inte, men dessa kampanjer tenderar att inte vara så långvariga.

Verktyg för att hålla koll på 500 Internal Server Error

Google Search Console har en alldeles utmärkt vy för fel i både 500 och 400-serierna. Du kan till och med få mejl om det inträffar oväntat många fel. Ytterligare en anledning till varför alla webbansvariga måste registrera sig på Google Search Console (och Bings motsvarighet förstås).

Om du kan få statistik över serverfel för en längre tidsperiod är det intressant att bevaka eventuella trender av fel. Det är lite surt att inse att webbplatsen en dag sjönk till botten på grund av ökad komplexitet bakom kulisserna och att den ropat på hjälp via error 500-meddelanden i flera månader.

Vill du göra manuella stickprov fungerar Pingdoms Full Page test bra.

Bra och lagom lång sidtitel

Sidtiteln är det där som syns högst upp i webbläsarfönstret, på datorer åtminstone. Det är inte nödvändigtvis samma som huvudrubriken men det brukar finnas ganska stora likheter. Det är också det som blir den klickbara texten på sökmotorns resultatsida och kommer vara namnet i webbläsarflikar, bokmärken etc.

Varför sidtiteln är så viktig

Sidtiteln är en av de viktigaste delarna att jobba med för att du ska kunna nå ut på en sökmotor och övertyga folk att gå in på just din webbplats. Dessutom ska de ord folk söker efter gärna ingå i din sidtitel då det är en av de starkaste rankningssignalerna du har att spela med.

Med tanke på antalet flikar folk har i sina webbläsare på datorer inser du snart att du har 1-2 ord på dig att namnge sidan i just det användningsfallet. Google visar dock betydligt fler tecken. Exakt hur många är något som de tenderar att justera. Oavsett Googles syn på saken ska du skriva vettiga sidtitlar som är anpassade efter människor. Med andra ord kan du ha följande tumregler:

• Tänkta nyckelord ska ingå tidigt i sidtiteln, så man inte måste läsa långt för att få reda på att det är en relevant sida.
• Sidtiteln behöver vara ganska kort, i skrivande stund är det 50–60 tecken som rekommenderas men då har man nog inte tänkt på andra typer av interaktion. På riktigt små skärmar man har på lite avstånd – smartklockor bland annat. Om det ens är visuella gränssnitt det handlar om i framtiden.
• Den behöver vara unik inom din webbplats, hur ska annars en besökare kunna göra skillnad på två sidor om de har identisk sidtitel?
• Inte automatiskt ta med webbplatsens namn i sidtiteln, åtminstone inte om det är för att det ska vara lätt att hitta till webbplatsen vid sökning på dess namn (där har du nog ingen konkurrens att tala om).

För att följa upp detta kan du använda Google Search Console. Där finns en vy där du kan se vilka sidtitlar som återkommer mer än en gång på webbplatsen (av det Google känner till om din webbplats, alltså).

Rimliga storlekar på dina filer

Ordet ”rimligt” är precis så underbart vagt som det svenska ”lagom”. Vad en rimlig filstorlek är går väl inte att sätta en siffra på, egentligen. Men ju större filstorlek desto längre tid tar de att ladda ner både för dina besökare och även sökmotorer när de väljer vad de ska inkludera i sina index.

Storleken på innehållet, HTML-filen alltså, kanske du inte måste vara så restriktiv med. Dels för att det går att komprimera ner till en tiondels storlek vid överföring men kanske främst för att det är en droppe i havet jämfört med andra filer vi har på våra webbplatser. Bilder, video och ljud däremot tar så oerhört mycket mer utrymme – särskilt det som lagts dit redaktionellt.

Det är nu du behöver en prestandabudget

För att försöka råda bot på problemet med överfulla webbsidor eller åtminstone sätta upp någon form av mätbar ambition kan man dokumentera kraven i en prestandabudget. Det går i korthet ut på att etablera och följa en riktlinje om hur tung och hur långsam allt som hör till en sidvisning får lov att vara. Att sätta upp krav på en sidas tyngd är ganska rakt på sak. Sätt ett vettigt värde där man har god marginal till vad folk står ut med på den marknad där webbplatsen vänder sig. Säg exempelvis att ingen sida får väga in på mer än 399 Kb. Det finns gott om mer eller mindre vettiga knep som gör att man kanske vill ha undantag från denna regel. Men börja med en regel och sedan får de som känner för att avvika från regeln argumentera för fiffiga tekniker, som lazy-loading, gentemot de krav som ställs på webbplatsens alla undersidor.

En utmaning att specificera acceptabel hastighet i sin prestandabudget

Jämfört med en sidas tyngd är hastigheten lite mer klurig att definiera. Det som räknas här är den upplevda hastigheten då det är den individuella upplevelsen som styr ifall användaren saknar flyt. Dessutom har inte alla samma förutsättningar till hastighet. Bland annat skiljer sig kvaliteten på uppkoppling, något jag märkt som alldeles för sent fick 4G. Jag har väntat evigheter på ”responsiva” bildkaruseller med enorma högupplösta bilder (till min lilla skärm). Den upplevda hastigheten påverkas också av hur mycket kraft som finns i prylen användaren har. Det påverkar hur många designelement webbläsaren orkar jonglera med för att visa upp sidan.

Precis som med sidans tyngd tycker jag att man kan börja med att göra det enkelt för sig i sin prestandabudget, men att man får vara beredd på ovanstående beskrivna problematik. För en webbplats som endast vänder sig till användare i Sverige kan prestandabudgetens krav vara att ingen sida får ta längre tid än 10 sekunder att ladda ner komplett. Då mätt från en 3G-uppkoppling inom Sveriges gränser. Som en bortre gräns.

Beräkna inverkan av din prestandabudget utan att förflytta dig

Vill du relativisera detta och göra teoretiska mätningar från skrivbordet kan du kolla med Bredbandskollen vilka hastigheter folk har runtomkring i landet. Då kan du snabbt få en bild av vad din prestandabudget innebär i praktiken i Ekshärad mitt ute i de värmländska skogarna, eller för den som väntar på ett försenat tåg i Bastuträsk – 10 mil från närmsta hamburgerbar i Västerbotten.

Kriskommunikation ställer lite andra krav på prestanda. Om du är en samhällsaktör bör du för allas vår skull också ta höjd för att det vid en kris kan vara ytterst viktigt att inte vara slösaktig. Vid kriser kan kommunikation via mobilnätet vara det enda logiska alternativet för merparten av de drabbade och de som hjälper till. Mobilnätet är faktiskt en ändlig resurs. Din kriswebb bör inte skicka med en massa teckensnitt, högupplösta versioner av loggan eller 2 Mb med Javascript för att kunna rita upp avancerade kolumnsystem på olika stora skärmar. Håll det enkelt!

Filstorlekar i designen

Ju mer man slösar med tunga filer för designen av sin webbplats, med stilmallar, Javascript, teckensnitt och designbilder, desto mindre utrymme finns för redaktionellt innehåll. Alltså det innehåll som besökaren kom dit för att ta del av!

Det som drabbar din besökare tack vare dina utvecklare och designers kan sammanfattas i två kategorier; textfiler, eller mediefiler.

När det gäller bilder finns massor med knep. Bland annat att välja rätt format, att optimera dem och sedan köra extra icke-förstörande komprimering. Samma tillvägagångssätt finns för video och ljud. Var uppmärksam på nya format! Det lanseras ständigt nya idéer och knep du kan dra nytta av. Under 2015 märktes det skämtsamt namngivna projektet Piper Pied⁸¹, de komprimerar människors ansikten mindre hårt vilket gör att resten av bilden kan komprimeras hårdare utan att det ser fullt så illa ut.

För dig med tillgång till en Windows Server kan du installera Search Engine Optimization Toolkit⁸². Den programvaran kan gå igenom hela din webbplats och listar sedan filstorlekar, bland mycket annat. Men det finns även med i Optimizrs alla rapporter.

Inga kopior av innehåll

Det ska endast finnas en adress till ett unikt innehåll. Svårare än så är det egentligen inte. Men om du nu har dubbletter av innehåll, i alla fall när det gäller webbsidor, så bör du tala om dess ”kanoniska adress”. Det innebär att med metadata peka ut den sidan som är ursprunget eller originalet, den av alla varianter du vill att sökmotorer ska indexera. Det är vad som kallas för dess canonical-URL och fungerar i alla fall för HTML-filer.

Att innehållet ska vara unikt på en adress gäller mer än själva sidorna, vilket kan vara lätt att missa om man inte gräver tekniskt. Ibland snubblar man över webbsidor som hämtar in samma Javascript-ramverk två gånger - fast från två olika adresser. Förutom att det är klantigt gjort av utvecklarna så är det slöseri med besökarnas uppkoppling och en signal om rätt låg ambitionsnivå till sökmotorer när de ska välja vilken webbplats som ska rankas högst.

Allt ska vara så unikt som möjligt

Något som många nog inte tänker på är att allt ska vara så unikt som möjligt. Jag kan fnissa lite åt de webbplatser som fortfarande har en uppifrån-å-ner-syn på nyckelord på sin webbplats, att de alltså har organisationens namn som nyckelord på varenda undersida. Det liksom förtar meningen med att ens ange det nyckelordet, eller hur? Samma sak gäller för sidtitlar. De ska vara unika för att bli användbara på sökmotorer, i favoriter, i webbläsarnas flikar med mera.

Tänk på att även dina beskrivningstexter som hamnar i meta-description behöver vara unika inom webbplatsen.

Den överlägset vanligaste varianten på detta lär dock vara jättestora organisationer och hur de sköter sina PDF-dokument på externa webbplatser. När jag jobbade som webbansvarig för många år sedan var det med skräck jag fick siffror om hur många kopior av dokument som låg och skvalpade i vår uppladdningskatalog. Det värsta är ju att det inte är lätt att se till att alla blir uppdaterade när en ny version ska ut. Det är väl av denna anledning som man kan förstå att Google bör ranka ner en webbplats om man har massor med kopior av samma dokument, bilder eller annan typ av material.

Ta hjälp av Google för viss översikt

En googling på site:minsajt.se filetype:pdf kan i värsta fall vara den bästa översikt du kan få över dokument som publicerats på din webbplats. Då får du åtminstone en lista på det som Google känner till. När det gäller bilder och video kanske risken för dubbletter är mindre, men då kan du googla enbart på site:minsajt.se för att sedan växla över till bilder samt video för en översikt. Notera att det kan vara andra adresser som serverar mediafiler och dokument. Exempelvis kommer många av min arbetsgivares dokument från subdomänen alfresco.vgregion.se, med andra ord googlar man på site:alfresco.vgregion.se för att få koll.

Verktyg för att hitta kopior av material

Först och främst kan du vända dig till Google Search Console. Där finns vyer som varnar för identiska sidtitlar och beskrivningstexter. Som med så mycket annat har även Optimizr.com med detta i sina rapporter.

Lagom många huvudrubriker

Det finns rekommendationer från webbstandardorganisationen W3C att följa (de där som skriver dokumentation om hur webben borde fungera). Om din webbplats är i det borttynande gänget som följer kodstandarden XHTML får den inte lov att ha mer än en huvudrubrik. En huvudrubrik är samma sak som det som ibland kallas H1, detta på grund av att det är dess HTML-tagg, <h1> alltså, den första bland rubriker.

Om du däremot följer HTML5 får du enligt rekommendationen från W3C ha flera huvudrubriker, men det är rekommenderat att ha beskrivande kod runtomkring, exempelvis sektioner. I HTML5 kan alltså en huvudrubrik gälla inom en delmängd av innehållet.

Om man istället utgår ifrån användarens behov så är det mest logiska att inte ha flera huvudrubriker. Visst, det kan ses som logiskt att ha några stycken om tydlig och korrekt kod förklarar att huvudrubriken är för en delmängd av det som visas på skärmen. Men samtidigt är det ganska centrerat kring den seende användarens behov.

Ok, hur gör jag då?

Ha en eller ytterst få huvudrubriker. Följer du XHTML får du endast ha en huvudrubrik, annars bryter du mot rekommendation för XHTML. Den ursprungliga tanken bakom XHTML var att den skulle vara processbar av maskiner genom att vara kompatibel med XML-standarden. Inom XML är struktur väldigt viktigt då den är mer maskinläsbar än HTML.

Om din webbplats istället följer HTML5-standarden är det fortfarande rekommenderat att du har ett fåtal huvudrubriker, kanske helst endast en enda. Varför? Jo, i och med att sidan troligtvis har en intern struktur med en rubrik som är viktigare än de andra så bör den rankningssignalen framgå för sökmotorer och andra botar. Rubrikstorlek har inte endast med typografi och textens storlek att göra, det är även ditt sätt att vikta rubrikens relevans för sidan.

Bygger du en startsida eller landningssida? Ha för all del en huvudrubrik för respektive del med egen call-to-action men då ska du också kapsla in dem i egna sektioner. Detta är inte ett frikort från att följa praxis, eller att ha en semantisk ordning på din kod. Maskiner kan inte läsa och förstå innehållet, vilket också gäller de av dina besökare som råkar ha en funktionsnedsättning. Det gäller även mig när jag är trött, irriterad, ljusskygg, kognitivt nedsatt och bakis dagen efter midsommar.

Men glöm inte att ha en huvudrubrik, åtminstone en ska du ha!

Förutom att du kan granska koden manuellt kan du installera tillägg i webbläsaren. Webbläsartillägget SEO Doctor till Firefox klagar om du saknar en huvudrubrik. Dessutom klagas SEO Doctor om webbsidan saknar en underrubrik, vilket inte heller det skadar att ha om du bryr dig om SEO.

Ha en (lagom lång) beskrivningstext

Beskrivningstexten kallas ibland för meta-description. Det beror på att den är placerad bland en webbsidas alla andra övergripande metadata i kodens huvud, det som ligger i om du väljer att visa källkoden bakom en webbsida.

Beskrivningstexten ska väldigt kortfattat beskriva sidans syfte och innehåll. Detta med ett naturligt språk. Varje viktig sida på din webbplats bör ha denna typ av dold information. Eller ja, så dold är den faktiskt inte. Ibland visas den upp under sidans titel i sökmotorernas resultatsida. Den finns där för att användas vid behov.

Längd och utformning av beskrivningstexter

Beskrivningstexten ska vara unik. Det beror på att man ska kunna skilja på beskrivningstexter på en och samma webbplats.

Längdmässigt ska du hålla den under 160 tecken (räkna även mellanslag) om du vill ha med allt, men som alltid med text så ska du ha det viktigaste först i denna text. Samtidigt bör du hålla den över 80 tecken om den ska bli användbar. Någon undre gräns för när sökmotorer struntar i beskrivningstexten är jag inte medveten om. Det kan vara värt att bevaka dessa siffror löpande med tanke på den ökande flora av prylar vi använder för att ta del av webben.

Angående hur man formulerar texten kan man följa kommunikativa principer som AIDA (Attention-Interest-Desire-Action) eller KISS (Keep it simple, stupid). Det går förstås inte att skriva hur galet som helst. Är du inte van att uttrycka dig i skrift är det bra att leta upp en formel som funkar för dig.

När det gäller verktyg är nog Google Search Console klart bäst. Där finns en vy för att utvärdera beskrivningstexter, bland annat om det finns dubbletter på en webbplats.

Media ska ha alternativtexter

Du har säkert hört att man ska ha alternativtexter till bilder på webben? Annars gör man livet svårt för de som inte kan se. Nu är det inte bara synskadade som inte kan se, även sökmotorer lider av detta bekymmer. Trots att mjukvaror börjar kunna ”se” vad bilder föreställer är det långt kvar innan de förstår innehållet på ett sätt som människor gör.

Du har nog listat ut att detta inte bara gäller bilder. Även ljud och video har samma problem. Då dyker en annan funktionsnedsättning upp, nämligen obefintlig eller nedsatt hörsel. Även här kompletteras ambitionen att inte utestänga någon med vad som ger god sökmotoroptimering. Om innehåll i en video är textat för döva och blinda kan texten översättas och visas upp för ännu fler att ta del av.

Vi har alla en funktionsnedsättning någon gång. Tänk dig själv sittandes i en tyst avdelning på tåget och du har glömt hörlurarna hemma. Då blir du glad för att någon textat åt dig.

Praxis för textning av mediafiler

Första regeln är att inte texta sånt som är ovidkommande eller trivialt i sammanhanget, det kommer bara störa. Då ska man hellre välja en tom alternativtext vilket inte ska förväxlas med att inte alls ange alt-textens attribut. Genom att sätta exempelvis alt=”” på en bilds HTML-tagg talar man om för mottagaren att inget av värde finns att beskriva.

Laddar du upp video på Youtube finns ett inbyggt textningsverktyg. Kör du med eget verktyg för att strömma ljud eller video är detta något du behöver fundera på.

När det gäller informationsgrafik blir det svårare. Då kan man behöva lämna ut din data som ett alternativ för de som inte kan se. Datan behöver vara strukturerad så den kan bearbetas av maskiner. Det är precis vad man har tabeller till på webben. Samtidigt gäller det att vara medveten om att man inte i alla lägen kan uppfatta innehållet om datan är för komplex. Då kan man istället välja att texta slutsatsen av dessa data.

Många väljer att istället för att göra bilder av diagram publicera en tabell, där tabellen genom progressive enhancement-teknik ersätts med en illustrativ bild. Det finns en stor mängd Javascript-ramverk för dessa behov.

Vill du manuellt säkerställa att du gör rätt kan du använda tillägg i webbläsaren, exempelvis för bilder har jag SEO Doctor i Firefox. Stickprov när det gäller diagram eller andra visualiseringar är främst att högerklicka på dem och se om de är en bild. För att hitta många sidor som saknar alternativtexter på bilder så kan du använda Optimizrs rapporter.

Lagom många länkar på sida

Hur många länkar är lagom för enskild sida på din webbplats? Ja, det är svårt att sätta en exakt siffra på det och det handlar inte om en absolut gräns. Först kanske vi behöver resonera lite kring varför vi ska bry oss över huvud taget.

Alla länkar man har på en sida ska vara absolut nödvändiga. Varför? Jo, det belastar din besökares uppmärksamhet att välja bland de alternativ du ger. Vilken som är viktigast i sammanhanget blir inte helt självklart om det finns massor att välja bland.

Ett sätt är att sätta en gräns över vad som är ok oavsett vilken typ av sida det är. I några verktyg jag använt har det varnats om man har över 200 länkar på en undersida, då oavsett om de pekat på sidor inom webbplatsen eller externt.

Länkjuice = allt kan inte vara viktigast, alltid

Tänk på varje sida som att den har 10 förtroendepoäng att dela ut till andra sidor genom vad den länkar till. Länkar du till 5 sidor får de 2 poäng vardera, länkar du till 100 får de en tiondels poäng var.

Något som de intresserade av SEO jobbar med är att försöka balansera andelen utlänkar, alltså länkar som leder bort från en webbplats. Det är både en signal till sökmotorn och användaren i vilken utsträckning man hänvisar bort från den egna webbplatsen. Att ha en bra balans kring intern och extern fördelning av länkjuice är värt att bevaka och kolla hur marknadsledarna i din nisch gör. Kortfattat: Är poängen med en viss undersida att skicka iväg folk, eller finns internt material att erbjuda? Följ upp vad användarna väljer att göra.

Att ha många interna länkar tyder på rörig struktur. Genom att ha mängder med interna länkar försvagar man även den interna länkstrukturen. Kör man Wordpress är det inte sällan ett självframkallat magplask du säkert sett. Många spammar sina egna bloggposter med massor av taggar. Ju fler taggar, desto fler länkar och associationer. Det är vad man har de bredare kategorierna till. Håll igen, helt enkelt.

Använda rel=”nofollow” på externa länkar

Just för externa länkar kan man sätta attributet nofollow. Det talar om att man inte rekommenderar en sökmotor att följa länken och är ett sätt att berätta att man inte har förtroende för den länken. Man kan samtidigt fråga sig varför man har en länk man inte vill ansvara för. Detta är en pragmatisk standard som växt fram exempelvis för länkar som tillkommer på grund av användares bidrag på webbplatser. Det är ett sätt att inte belöna spammare och ett försök att vara selektiv med var man lämnar sin länkjuice.

För att få lite koll på detta är Optimizr.com bra, men antagligen vet du om vilka sidor på din webbplats som har ovanligt många länkar.

Webbsidor behöver inlänkar

Det är lite misstänkt att man dolt tipsar om en sida som är svår att upptäcka som vanlig användare. Du kanske inte vet hur detta kan hända även på din webbplats? De sidor som du har med i din sitemap, en fil som primärt används av sökmotorer, kan vara skräpsidor.

Ofta förekommande hittar jag exempel i hierarkiskt skapade webbplatser, något exempelvis webbpubliceringssystem som Episerver CMS ger per automatik. Där kan man hitta sidor som heter ”högerkolumn” och saknar innehåll. Eller ”huvudmeny” som används som en mapp i verktyget för webbredaktörens skull. Om varken din egen eller någon annans webbplats länkar till en viss webbsida är det definitivt en signal om att den webbsidan fullständigt saknar värde. Ibland stämmer det ju, men om sidan är meningslös så borde den inte heller finnas där och förvirra varken sökmotorer eller användare.

Om sidan nu inte är oviktig är det dags att länka till den, åtminstone själv, eller så får du försöka ragga några inlänkar från någon annan.

När det gäller verktyg för att få koll är det ambitiösa alternativet att ha koll på alla sina adresser. De adresser som haft besökare kan du exportera ut från ditt webbstatistikverktyg. Annars finns kanske intern sökteknik du kan dra nytta av, som vet om vilket innehåll som existerar oavsett om det får besökare eller ej. Har du listan sorterad efter popularitet kanske det är värt att börja med de som har få besökare, där finns kanske det du inte väntat dig ska besökas.

Akta sig för interna hänvisningskedjor

Du som läst boken Webbstrategi för alla har nog förstått hur viktigt jag tycker det är att ta hand om sina gamla eller tidigare inarbetade adresser på webben. Problemet kan dock över tid uppstå att du hänvisar till ytterligare en hänvisning. Då slösar du med webbserverns kraft och användarens tålamod.

Dina användare är otåliga, åtminstone gäller detta den absoluta majoriteten av webbplatser. Om dina webbsidor inte laddar in på under 0,1 sekunder så tillhör du den kategorin som kan få bättre flyt i upplevd interaktion. Det tar tid att hänvisa en användare från en adress till en annan. Egentligen helt i onödan, eller åtminstone är det inget en besökare har nytta av.

Ett scenario som inte är allt för ovanligt är att man hänvisas från http://adress.se till det säkrare protokollet som stödjer TLS/SSL. Det vill säga https://adress.se och om det inte vore illa nog så kan då webbplatsen börja ha preferenser som att lägga till det helt onödiga www-prefixet. Alltså skickas man vidare till https://www.adress.se och sedan krydda det hela med att vara noggrann med språkversion, därmed skickas man till https://www.adress.se/sv/

Nej, detta är inget absurt scenario. Våren 2015 hade min egen arbetsgivare en nylanserad webbplats som hade endast en färre hänvisning än detta för de som skulle besöka startsidan. Efter tillräckligt många hänvisningar så börjar det straffa sig även inom SEO. Enligt uppgift är just hänvisningen från HTTP till HTTPS inte något som Google straffar oss för, för just den hänvisningen tycks vi ha ett frikort⁸³.

Varje hänvisning tar ofta minst en tiondels sekund, men det är inte ovanligt med upp till en sekund beroende på den fördröjning i svarstid (latens) som finns mellan besökaren och servern. I extremfall har jag själv haft svarstider på flera sekunder. Då skulle antalet hänvisningar behöva multipliceras med flera sekunder. Tid som är helt bortkastad för alla parter.

Hur gör man då?

Se till att ha koll på vilka hänvisningar som finns. Har du åtkomst till loggar är det HTTP:s statuskod 301 och 302 du letar efter, det vill säga mer eller mindre permanenta hänvisningar. Tänk också på att 301 säger att det är en permanent hänvisning. Det talar om för sökmotorer och andra maskiner att de kan glömma bort den äldre adressen och hänge sig till den nya. 302 säger att det är en tillfällig hänvisning, använd den skillnaden med förstånd.

Du bör undvika att ha fler än en hänvisning. Man ska aldrig hamna på en hänvisningssida som skickar dig vidare. Vi ska omgående hänvisa till den slutgiltiga adressen. Med rätt statuskod enligt HTTP-specifikationen.

Den ambitiöse börjar leta efter loggfiler på servern eller nätverket, men rimligast är nog ändå att göra manuella stickprov och att vara väldigt uppmärksam när man själv agerar användare. Skriv om adresserna du har på din webbplats och kolla vad som händer. Vill du spåra allt kring HTTP kan du testa via Firefox att ha tillägget Tamper Data installerat, men många funktioner finns också i webbläsarnas utvecklarverktyg.

Genom ditt webbstatistik-verktyg kan du kolla upp vilka externa webbplatser som länkar till dig och vilka adresser de pekar ut. Exempelvis om de använder www-prefixet eller inte, kör med HTTPS eller inte. Någon som driver mycket eller viktig trafik till dig kan vara värd att prata med för att ange ”rätt” adress.

Inte ange nyckelord – i onödan

Denna fråga är ganska kontroversiell i vissa sammanhang. Men man kan i alla fall fråga sig för vems skull du anger nyckelord, eller meta-keywords som de ibland också kallas. Om Google någonsin brytt sig om dessa ord är det i alla fall länge sedan de slutade med det. Idag teoretiseras det snarare som att förekomsten av nyckelord är ett klantigt försök att spamma sökmotorer.

Ibland står det i organisationens redaktörsmanual att man ska skriva in nyckelord. Ja, det gör det även där jag jobbar. Det finns eventuellt två anledningar till det, det kan vara så att man har en egen sökmotor som drar nytta av dessa ord. Den andra något mindre smickrande anledningen är att kunskapen är från nittiotalets glada dagar när det nästan var praxis att lura sökmotorer med helt irrelevanta nyckelord.

Er egen sökmotor kan faktiskt ha nytta av dessa nyckelord. Anledningen till att detta kan fungera internt är för att man har större anledning att lita på sina egna redaktörer, ens egen sökmotor letar endast i material man själv har publicerat.

Ok, men vår egen sökmotor täcker ju in vår externa webb…

Här uppstår bekymret på riktigt. Om ni har nytta av att ange nyckelord för er egen sökmotors skull så gör för all del det, men tro inte att det gynnar Google eller de andra sökmotorerna. Om du anger nyckelord för din egen sökmotors skull, se för jösse namn till att orden är unika och relevanta så du inte spammar dig själv.

Tumregeln för vad inom extern sökmotoroptimering som är lönt att lägga tid på är att det ska vara komplicerat att fuska, samt att originellt material ska belönas. Det är oerhört enkelt att fuska i massiv skala med nyckelord. Det är därför det inte används av utomståendes sökmotorer.

För att få koll kan du läsa HTML-källkoden på sidorna du vill inspektera. Leta efter kod som ser ut ungefär så här i <head>:

<meta name=”keywords” content=”nyckelord, nyckelord2, nyckelord3”>

Det enda egentliga verktyg jag hittat för detta är Optimizr.com och av de sidor som de kollat på får man en lista med vilka sidor som innehåller nyckelord.

Lagom djup i webbplatsen

En högst ovetenskaplig tumregel du kan hålla dig efter är att inte alla användare orkar leta sig mer än tre nivåer ner i din webbplats för att hitta vad de söker. Detta dels för att många inte känner att de har den tiden att lägga på en svårnavigerad webbplats men också för att man inte vet om det är värt ansträngningen. Vi kan inte räkna med att särskilt många av våra användare är motiverade nog att anstränga sig. Om vi däremot designar navigeringen med en användare i åtanke finns det faktiskt bevis på att fyra nivåer är bättre än tre, bland annat i Jakob Nielsens bok Prioritizing Web Usability⁸⁴.

Att navigationen inte alltid är omsorgsfullt utformad för användarnas skull får jag signaler om mest hela tiden. Om man nu tror på ödet; samma dag som jag redigerade denna del av boken så damp det ner ett mejl som förklarade att ”webbredaktörerna hittar sina sidor enkelt i denna platta struktur”. Frågan är väl om webbplatsens navigation är till för webbredaktörernas skull?

Om din webbplats har hierarkiska adresser, sådana som anger snedstreck lite här och var, så kan du enkelt räkna dem. I vissa webbstatistikverktyg, exempelvis Matomo, kan man bläddra sig ner i denna mappstruktur och se den ibland bistra verkligheten av hur många nivåer som faktiskt finns att förflytta sig mellan.

Varför detta är ett problem?

Ofta går användbarhet, tillgänglighet och sökmotorers behov hand i hand. Sökmotorerna måste prioritera hur många undersidor på din webbplats de ska lägga tid på att försöka indexera. Du tilldelas helt enkelt en indexeringsbudget från sökmotorn, ett begränsat antal sidor på din webbplats kan alltså bli indexerade. Antalet sidor din webbplats tilldelats hänger ihop med sökmotorns bedömning av webbplatsens värde. Anledningen till det är att sökmotorn måste försöka skydda sina egna intressen och resurser då din webbplats faktiskt kan vara trasig eller spammig.

Det kan vara så att din webbplats har ett systematiskt fel som ger den oändligt många undersidor, sidor som knappt ens länkas från din egen webbplats. Därför behöver sökmotorer och andra maskiner försöka lista ut vilket antal sidor och exakt vilka av dem som är värt att kravla och försöka indexera. Det är ditt jobb att hjälpa dem på traven, och på köpet blir det ofta bättre för mänskliga besökare.

Undvik mer än tre nivåers djup

Du ska givetvis sträva efter den mest logiska navigationsstruktur som finns för din egen webbplats och det innehåll den har. Men kom ihåg att det inte är en reflekterande människa som sitter och bedömer detta hos sökmotorerna. Sånt görs helt automatiskt.

Om du har mer än tre nivåers djup för att nå en viss undersida är det rimligt att anta att den inte är särskilt viktig, inte viktig nog att indexera. Om den vore viktig hade den nog länkats direkt från startsidan eller direkt från en sida under startsidan. Eller hur?

Du har ett begränsat innehåll på dig att övertyga

Allt prat om Google-sniping (sidor skapade för specifika sökbegrepp) du möjligen snappat upp kan du med andra ord börja ifrågasätta. Du ska ha under 200 länkar per undersida, du ska inte ha fler än tre nivåer. Fram med miniräknaren och räkna på det. Det gamla snacket om att man når ut på sökmotorer via ”den långa svansen” och Google-sniping är inte lika gångbara utifrån detta synsätt.

Verktyg för att kolla navigationsstruktur

De som gör innehållsrevisioner i stil med det Kristina Halvorson rekommenderar i sin utmärkta bok Content Strategy for the Web⁸⁵ har denna struktur redan i sin innehållsdokumentation.

Har du Matomo, snarare än Google Analytics, finns webbplatsens djup som en trädstruktur att utforska. Det kan ta en stund att utforska strukturen och kom ihåg att det är adressernas struktur du ser snarare än om något är länkat direkt från en hög nivå i strukturen. Kör du Google Analytics kan du filtrera fram motsvarande information under Behavior -> Site Content -> Content Drilldown. Där ser du en webbplats gruppering, om URLerna har mappningar i sig.

För den manuellt stickprovsintresserade personen kan man upprätta en lista över de sidor som faktiskt är viktiga. Har de inte en direktlänk från startsidan och relevanta landningssidor är det dags att lösa det problemet.

Tydliga länktexter

Länktexten är texten som är klickbar och leder till en annan del av webben. Rent allmänt bör de vara blå och understrukna om du inte har goda skäl att designa dem annorlunda. Blå färg och understruken text är den historiska de facto-standarden för webben och då många fortfarande kör med detta underlättar det för dina användare om vi följer den konventionen.

Skriv inte ”Läs mer här” eller ”Klicka här” som länktext! Grundregeln för länkar är att deras text ska kunna stå för sig själva. Det vill säga, man ska som seende kunna skumma igenom sidan och bara läsa länktexter och ändå få en rätt god uppfattning om vad de länkar till.

För en person med obefintlig eller nedsatt syn är det högst avgörande att du skriver bra länktexter. Deras sätt att navigera längre textmassor är att hoppa mellan rubriker, länkar och andra designelement för att försöka få en uppfattning om en sidas innehåll. Det är inte direkt hjälpsamt om de får höra ”läs mer” tio gånger på raken när de försöker navigera, eller hur?

Praxis med tunga filer

Om det du länkar till är en ovanlig sorts fil bör du skriva ut det i länken, gärna inom parentes i slutet. Är filen tyngre än en megabyte är även det en bra sak att skriva ut i länktexten inom parentes. Allt för att inte överraska användaren. Exempelvis ”Ladda ner årsredovisningen för 2016 (PDF, 7 Mb)”.

Du har säkert också sett länktexter som ”Bla bla (öppnas i nytt fönster)”, eller de med en liten symbol efter. Det är i sig bra att tala om när man tänker öppna en länk i nytt fönster, men huvudregeln är att man inte ska öppna länkar i nya fönster. Det finns tusen dåliga ursäkter till varför man tycker det är motiverat att öppna en länk i ett nytt fönster, men låt bara bli. Det mest effektiva sättet att finta en användare är att öppna nya fönster till höger och vänster. Eller öppna i samma nya fönster flera gånger, eller knycker klicket via Javascript för oss som Ctrl-klickar på länkar. Följ webbstandard, låt bli att bestämma åt användaren, låt användaren ha kontroll över sin upplevelse!

Sökmotoroptimering och länktexter

De ord som utgör länktexten är en signal till sökmotorer om vad man anser att den länkade sidan handlar om. Det var detta några lustigkurrar utnyttjade för en massa år sedan när de gjorde en så kallad Google-bombning av den amerikanske presidenten George W Bush. Genom att i länktexten skriva ’miserable failure’ och länka till Vita husets profilsida för presidenten gjorde Google associationen att George W Bush och sökbegreppet ’miserable failure’ hörde ihop.

Med andra ord, du vill ha relevanta ord i länktexterna, ord som återspeglar vad innehållet handlar om. Det behöver inte vara exakt vad sidan har i huvudrubrik. Men ingen ska ingen känna sig förvånad över var man hamnade baserat på en knepigt formulerad länktext. Sökmotorer blir också allt bättre på att avgöra när man sysslar med keyword-stuffing, alltså när man proppar in en oläsbar mängd med sökord man hoppas få med. Skriv länktexterna med omtanke för en mänsklig läsare, i andra hand kan du experimentera med SEO.

Om du fullständigt dominerar på sökmotorerna på ett visst nyckelord kan du kanske kosta på dig att i länktexter använda synonymer eller andra begrepp. Exempel på detta kan vara att om du länkar till en produkt som har ett namn helt utom konkurrens på sökmotorerna så fundera på om inte ”Lazyboy Armchair 3000 Deluxe” kan få länkar som innehåller ord som fåtölj eller vad nu sökordet är som du vill försöka tränga dig fram på. Det är samma sak med egna varumärken. Det är nog ganska sällan man har konkurrens om dem och frågan är om man med ett utifrånperspektiv ska använda dem så ofta som man gör?

Google Search Console har vyer för vilka ord som används för att länka till webbplatsen. På vissa externa webbplatser har man inflytande över vilka ord som används, men tänk på att det är mer slitsamt att ändra dessa än på din egen webbplats. För att kolla vilka som länkar till din webbplats kan du kolla Search Consoles vy Söktrafik -> Länkar till din webbplats, det är vad Google känner till vid sin indexering. Men du kan också i ditt webbstatistikverktyg kolla vilka hänvisningswebbplatser som finns, alltså externa sidor där besökare kommit från. Då får du troligen en indikation på respektive sidas relativa viktighet.

Optimizr.com har med detta i sina rapporter. Även fast dessa rapporter inte kommer omgående är de bra för passiv eller periodisk webbanalys.

Bra fördelning av länkjuice

Det här med länkjuice, alltså en länks kraft eller värde, är ett luddigt begrepp som hör till sökmotoroptimering. Man kan se det som ett problem om för många av webbplatsens länkar hänvisar till andra webbplatser. Det kan ge sken av att webbplatsen inte har ett egenvärde, att det inte finns relaterad information inom webbplatsen.

Det finns många bud om hur många externa länkar en enskild sida bör ha, eller hur stor andel, men se inte detta som någon exakt vetenskap. Ibland är det så att en undersidas hela syfte går ut på att vägleda din användare till rätt webbplats – någon annans webbplats. Exempelvis har vi som jobbar med landstingens webbplatser extremt goda skäl att hänvisa de som söker vård till 1177.se, Ungdomsmottagningen Online, umo.se, då det är på de platserna vi samlar den gemensamma ansträngningen att göra bra webbplatser. Men såklart finns det användare vi har anledning att behålla. Som om man vill komma i kontakt med de som styr organisationen, eller något av allt annat som inte nationaliserats.

I normala fall ska du inte skicka iväg dina besökare till andra webbplatser. Sen om du sätter upp regler som att endast i undantagsfall ha fler än en externlänk är upp till dig.

Verktyg för att hitta spilld länkjuice

Du kan ju givetvis gå igenom dina viktigaste sidor manuellt och kolla hur det står till. Annars har Optimizr.com med detta i sina rapporter. Deras sätt att definiera detta är i skrivande stund att en sida har färre än tio interna länkar – det anses ge en svag innehållsstruktur.

Strukturell CSS inkluderas i HTML-koden

Målet med denna typ av CSS är att sidan kan presentera sig snabbare och låta användaren påbörja sin användning redan innan allt laddats ner. Om du googlar efter detta så kan du kolla efter Critical Path CSS.

Det hela går till på det för många webbutvecklare något underliga sättet att man inkluderar lite av CSS-koden in i HTML-koden. Direkt via en style-tagg i kodens sidhuvud. Det här är något vi som kodat för webben kämpat för att bli av med och fortfarande anses det delvis att CSS-kod i webbsidor är slarvig kod. Räkna inte med att alla utvecklare håller med dig om att detta är en bra idé.

Anekdot från mars 2015 – utvecklare trodde inte sina ögon

När jag höll en föreläsning om webbprestanda inför 40-talet utvecklare och tekniker satt flera med ett förvånat uttryck i ansiktet när de fick syn på en bild med koden bakom min privata webbplats. Bilden var tänkt att illustrera att man tar bort onödiga mellanslag, tabbar med mera ur HTML-koden. Jag hade tyvärr inte förvarnat om att all denna extra CSS-kod lagts dit med flit (note to self: ska nog ta upp detta tidigt under nästa föreläsning, så ingen behöver ställa frågan och känna sig uppläxad).

Jag hade givetvis inlett med att jag välkomnar frågor, så en av utvecklarna tog mod till sig: ”Men Marcus, är det inte väldigt dålig praxis att ha CSS i HTML-koden?!” Jag är ju beredd att hålla med. Det känns fortfarande skumt att se det i koden, men det är bara att vika ner sig och inse att den upplevda prestandan får gå före. Det handlar ändå om användarna till syvende och sist.

Det är rena rama magin, men det finns nackdelar. I och med att man lägger in kod som på inget sätt är unik per sida gör man alla sidors HTML-kod något tyngre. Tanken är att man lägger in bara det som gör att sidan kan visa upp sig snabbare. Det vill säga det som sätter de yttre ramarna för en sida. Det här är ett exempel på när upplevd prestanda och teoretisk prestanda krockar. Egentligen blir sidvisningen några kilobyte tyngre, men användaren får syn på webbplatsen snabbare och kan därmed börja använda den. Användaren får en upplevelse av bättre flyt.

Samtidigt måste man vara försiktig så inte sidans designelement ser ut att vara färdiga innan de faktiskt kan användas.

Verktyg för critical path css

Det finns en Critical Path CSS Generator⁸⁶ på webben som kan hjälpa dig sålla fram vilken CSS du ska inkludera i sidhuvudet. Eller om man själv eller någon man känner har svart bälte i CSS så kan man göra detta själv. Sedan placerar man detta i head-taggen i en style-tagg. Validerar sidan enligt W3C är det dags att testa om det fungerar som det är tänkt. Simulera gärna en långsam uppkoppling via Google Chrome och testa om något är visuellt färdigt men inte funktionellt, exempelvis hamburgermenyer m.m.

Är du osäker så sätt upp ett A/B-test och utvärdera om versionen med critical path CSS verkligen fungerade bättre på just din webbplats.

Inte öppna länkar i nytt fönster

Att automatiskt öppna länkar i ett nytt fönster är ett effektivt sätt att finta sina användare. De kommer nämligen inte kunna använda bakåt-knappen för att komma tillbaka. Därmed inför man ett onödigt krav på att användaren ska vara uppmärksam just när det nya fönstret öppnas samt att hen ska komma ihåg detta senare.

Alla argument jag hört om varför man gärna vill öppna länkar i nytt fönster är en förklädd välvilja om besökaren. Man har det oemotsagda antagandet att detta är vad användaren vill. Vissa är mer öppna med sin baktanke, som att man till varje pris vill behålla användaren på sin webbplats. Om ens webbplats ligger kvar bakom det nya fönstret finns ändå chansen att användaren fortsätter klicka runt senare.

Jag skulle vilja påstå att användare känner till bakåt-knappen, samt att de nog använder den om de vill komma tillbaka. Dessutom att det inte är förenligt med användbarhetsprinciper att tvinga användare att komma ihåg att sidan man hamnade på är i en ny flik eller ett nytt fönster (vilket gör att bakåt inte fungerar).

Men min absolut största favorit av alla dumheter kring att öppna nya fönster är när de öppnas i ett nytt namngivet fönster. Detta görs, om man nu kollar HTML-kod, genom att sätta attributet target till något, exempelvis target=”dokumentfonster”. Det som händer då är att första gången användaren klickar på en sådan länk så öppnas ett nytt fönster. Sedan kommer varje följande länk (med samma attribut) att ersätta innehållet i detta namngivna fönster/flik. Har man då en lista med länkar där alla hänvisar till samma target kommer flera klick leda till att endast den senaste klickade länken är inladdad, när man troligen ville ha alla de man klickade på.

Att öppna nya fönster för användarens skull, åt användaren, är bara förvirrande för alla inblandade. Denna ofta återkommande fråga tas upp av Webbriktlinjer.ses riktlinje 97 - att låta bakåtknappen fungera. Det gör den inte om man öppnar i nya fönster.

Nytt fönster är i strid med tillgänglighetsriktlinjen WCAG:s framgångsfaktorer

Även fast de allra flesta inte strävar efter att till punkt och pricka leva upp till WCAG:s mest strikta nivå, är det otvetydigt vad som är rätt sätt. Så här skriver de i sina rekommendationer (min fetning):

”Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

• Opening new windows by providing normal hyperlinks without the target attribute (future link), because many user agents allow users to open links in another window or tab.
• G200: Opening new windows and tabs from a link only when necessary”

W3C konstaterar alltså att man ska undvika att överraska användare, samt att användare själva kan öppna länkar i länkar i nytt fönster om de nu vill det⁸⁷. Dessutom, i G200⁸⁸, finns följande rekommendation:

The objective of this technique is to limit the use of links or buttons that open new windows or tabs within Web content. In general, it is better not to open new windows and tabs since they can be disorienting for people, especially people who have difficulty perceiving visual content.

Där ges också exempel på när det kan vara befogat med nya fönster, nämligen när:

1. Opening a page containing context-sensitive information, such as help instructions, or an alternate means of completing a form, such as a calendar-based date picker, will significantly disrupt a multi-step workflow, such as filling in and submitting a form, if the page is opened in the same window or tab.
2. The user is logged into a secured area of a site, and following a link to a page outside of the secured area would terminate the user’s logon. In this case opening external links in an external window allows the user to access such references while keeping their login active in the original window.

Det dessa två exempel indikerar är att ett desktop first-perspektiv finns, frågan är om W3C skulle resonera på samma sätt mobilt. Dessutom förutsätter de lite att man varken tänker eller kan designa om användarens flöde i webbapplikationen.

För de som vill leva efter god praxis oavsett vald ambitionsnivå kring tillgänglighet är frågan om länkar i nya fönster egentligen väldigt enkel – ge tusan i det :)

Nytt fönster är en säkerhetsrisk

Om nu inte användbarhet eller tillgänglighet är argument nog så är det också en säkerhetsrisk att öppna länkar i nytt fönster. I alla fall genom target="_blank" på länken. Det går nämligen att på en extern webbplats ta del av innehållet på ursprungssidan med hjälp av lite Javascript-kod⁸⁹. Med andra ord skall man aldrig öppna externa länkar i nytt fönster. Du har ingen kontroll över ifall de externa webbplatserna du länkar till har säkerhetsproblem och vad värre är så lär de knappast komma på att varna dig under tiden de lagar sitt säkerhetshål. Om de nu någonsin kommer laga säkerhetshålet, det kanske aldrig upptäcks.

Mig veterligen finns inget verktyg som kan hjälpa oss med detta i större skala. Om du har en egen sökmotor eller annan teknik som har en lokal kopia av alla sidors HTML kan du söka efter target= för att hitta dessa övertramp.

Ofta är dessa lösningar systematiska och följer webbplatsens publiceringssystem. Kolla därför in hur länkar i diverse listor hanteras. Därefter kan du fundera på om möjligheten till att öppna nya fönster borde tas bort från publiceringssystemet.

Publicera inte PDF-filer

Det är rena plågan att läsa PDF:er på en mobil skärm. Och nog är det väl dags att överge det där tänket om fasta format som uppfanns på 1400-talet genom tryckpressen? Om du nu inte testat själv att läsa en PDF på en mobiltelefon kan jag förklara det för dig. Det handlar om att antingen ha översikt där texten är för liten, eller så har du zoomat in så du kan läsa delar av en mening. När du zoomar kommer du tappa bort dig vid varje rad när du läst klart och ska gå in på nästa.

PDF är inte bara dåligt, formatet har sina förtjänster. Bland annat är det ett vettigt format för arkivering, specifikt varianten PDF/a, men också ett utmärkt format om man vill skicka något för utskrift till någon annan. PDF gör att man kan referera till sista raden på sida två och alla tittar på samma sak. Man vet att innehållet kommer skrivas ut likadant.

Responsiv webb är inte förenligt med PDF-filer

Men PDF:er är inte ett format för webben. Samma utmaning som vi adresserade genom att bygga responsiva webbplatser är det som gör PDF-filer mindre bra. Ortodox responsiv teori kräver att man tänker bort kanvas, storlek på skärm eller förutsätta en viss typ av användare. En PDF är urtypen av kanvas. Det hela går ut på att ha ett innehåll som har fixerad position inom en given måttbestämd yta. Ett kanvas helt enkelt.

Det är väldigt synd om man har en responsiv webbplats och användarna likt förbaskat hamnar på PDF-filer eller andra dokument som är olämpliga annat än möjligtvis för att ladda ner till en dator. Detta gäller förstås även Word-dokument och allt annat som inte är riktig webb.

Om din webbplats är på publika webben (alltså inte ett intranät) kan du pröva att formulera en sökfråga på Google liknande den nedan:

site:minsajt.se filetype:pdf

Tänk dock på att det på vissa organisationers webbplatser inte är huvuddomänen som serverar dokument och PDF-filer. På min arbetsplats skulle det varit alfresco.vgregion.se som varit domänen.

Erbjuda en sitemap

En sitemap är en teknisk motsvarighet till webbplatskartan. Alltså en lista med alla sidor som finns på en webbplats. Sitemaps är en industristandard⁹⁰ som togs fram av sökmotorföretag som Google, Bing med flera, men du kan mycket väl använda din sitemap till andra grejer än att skicka till sökmotorerna.

Bland annat kan din egen sökmotor ha nytta av den. Eller de som du samarbetar med kanske vill kunna bevaka när det kommer nytt material på din webbplats. Sitemapens innehåll är en kronologisk lista över vilka adresser som finns på webbplatsen. Nyast överst och dessutom kan man lägga in en viktning om adressens relativa värde inom webbplatsen.

Sitemapen ska gärna heta något förutsägbart, som sitemap.xml, och placeras i webbplatsens hemkatalog. Alternativt talar du om i din robots.txt var man kan hitta sitemapen. Har du flera sitemaps behöver du en så kallad siteindex, det är en lista över vilka sitemaps du har. Detta kan behövas om man har oerhört många poster i sina sitemaps, man får nämligen inte har en oändligt stor sitemap.

Kör du Wordpress kan du använda Wordpress SEO för att få med vad de kallar för XML Sajtkartor. I annat fall får du i värsta fall utveckla funktionen själv, eller om innehållet nästan aldrig ändras och du har en mindre webbplats kanske du orkar skriva den för hand.

Du kan påtala för Google att du har en sitemap via deras Search Console, detsamma gäller Bing med deras Webmaster Tools. Där kommer du få reda på om det är några fel relaterat till din sitemap.

Ha en robots.txt och en humans.txt

Bild 66: Robots.txt på min bokblogg.

En robots.txt är en textfil som ligger i roten, alltså huvudkatalogen, på en webbplats. Den finns där för att lämna instruktioner till botar som ansluter till webbplatsen. Bland annat instruerar man sökmotorerna den vägen om vilka delar av webbplatsen de inte ska indexera. Det är förstås praxis att följa det som står i en robots.txt men för illasinnade kan de den vägen också få tips, så det gäller att inte vara naiv.

Förutom att berätta vilka delar av webbplatsen man inte vill ha besök på (så kallad disallow) är det praxis att berätta var man placerat sin sitemap. Om du inte är helt Google-centrisk så kan andra sökmotorer få hjälp att indexera din webbplats om du listar din sitemap på detta vis. Det är trots allt en väldigt liten insats.

För att dubbelkolla att din robots.txt är korrekt utformad kan du via Googles verktyg Search Console anropa filen och få den analyserad.

En humans.txt också - för dina mänskliga läsare

En del webbplatser har börjat ha en humans.txt bredvid sin robots.txt, detta för att skriva dokumentation till mänskliga läsare. Det är webbens motsvarighet till att man ofta hittar en readme/läsmig.txt när man kollar in andra sorters mjukvaror.

Har du något att säga en mänsklig läsare så gör det i humans.txt-filen. Det kan vara kontaktuppgifter, instruktioner till tekniker eller utvecklare som kollar in webbplatsen.

Avrundning

Jag hoppas du hittat något matnyttigt i denna bok. Känn också att det står dig fritt att ställa uppföljande frågor, exempelvis via Twitter.

Fortsätt läs – Outro