Del 4: Aktivitetsplan

For at arbejde strategisk med din webanalyse bør du eller nogen i webteamet opsætte en aktivitetsplan, der tydeligt tager dig fra nutidssituation til en ønsket situation. Denne del af bogen tager en mængde eksempler op på aktiviteter og måleværdier, du kan vælge at putte ind i din egen aktivitetsplan.

Det er hygiejnefaktorerne på webstedet, der skaber forudsætningerne for et værdifuldt websted. At begynde med alle på en gang er dumt, de tager tid. Kig dem igennem, og vælg fem til ti stykker at udføre (og mestre) i det kommende år. Det er bedre, at du sætter et mål, du kan opnå.

Hygiejnefaktorer

Pointen med at forsøge at leve op til denne dels hygiejnefaktorer er at have en målbar måde at forholde sig til de teknikaliteter, der påvirker besøgendes oplevelse. Desuden er de en måde at forsøge at sikre, at webstedet ikke forringes over tid, men snarere løbende forbedres for hver opdatering.

Listen med de aktiviteter, du har valgt ud, kan supplere de testprotokoller, som systemudviklerne har. De fleste, der bygger større websteder, har allerede en systematisk måde at verificere, at et webprojekt holder den rette kvalitet. Ret mange har længe brugt såkaldte byggeservere til at have kontrol over kodekvalitet for et større team udviklere. Flere af de værktøjer har mulighed for plugins, der kan lave nogle kontroller automatisk for dig. Så lav gerne en inventering af udviklingsarkitekturen. Snubler du over noget til Continuous Integration⁶³, er det værd at lede efter plugins. Det er muligt automatisk at stoppe produktionssætning af nye funktioner, hvis det ikke lever op til de kvalitetskrav, man har sat op.

Hvis du driver et større websted, er det en god idé at interessere dig lidt for, hvilke test udviklerne har for at forsikre sig om, at den rette kvalitet opnås. Disse test kan være alt fra helt manuelle til fuldstændigt automatiserede. Men vær forberedt på, at det kan være mineret mark. Reaktionen kan virkelig være alt fra, at de bliver glade for, at man er interesseret, til at enhver bør klare sine egne problemer.

Eftersom værktøjer og tricks til at tjekke disse faktorer ikke altid lever for evigt, kan du henvende dig til en side på mit websted, hvor jeg har en aktuel liste⁶⁴ med værktøjer, jeg selv bruger for øjeblikket.

Startpakke til din aktivitetsplan

Listen, der følger, er ting, du selv kan kontrollere for at sikre, at webstedet fungerer, som du vil. Selvfølgelig kan du udskifte værdier, hvis du vil sigte højere eller lavere. Vælg hvilke punkter, du synes det er rimeligt, at hver underside på webstedet skal leve op til, og diskuter dem med din webudvikler (nogle gange er det nemlig nødvendigt at ræsonnere anderledes).

Som du indser, når du læser listen, er der ting, man skal tilføje afhængigt af, hvordan ens websted er tænkt at bruges. For eksempel dem, der har valgt at køre mobile first, bør have en aktivitet på listen om, at man ikke bruger eller linker til PDF-filer på webstedet (de er oftest uvenlige mod dem med små skærme).

Men nu er det tid til en bunke forslag til aktiviteter.

Indføre HTTP/2 og HTTPS

Inden jeg eller nogen, du møder, fuldstændigt omvender dig med glædesbudskabet om, at HTTP/2 er det bedste siden Vor Herre gik i korte bukser, så tænk kritisk over, hvilke brugere du efterlader. Dem, der ikke har udstyr, der understøtter den nye webprotokol. I skrivende stund er det primært dem på ældre versioner af Internet Explorer, der tilhører denne gruppe. Inden du tager skridtet, bør du vide, hvor stor en andel af dine brugere og tiltænkte målgruppe der drager fordel.

I Microsofts verden er det først Internet Explorer 11, der understøtter HTTP/2, mens alle andre moderne webbrowsere har haft det længe (og som i modsætning til Internet Explorer ikke plejer at leve på overtid). At de webservere, du bruger, understøtter protokollen, er ikke selvfølgeligt, men mange havde understøttelse allerede i 2016. Hvis både brugerens enhed og alle involverede webservere understøtter HTTP/2, vil det automatisk blive brugt. Desuden husker webbrowseren, at webserveren tilbød HTTP/2, så næste besøg vil gå endnu hurtigere, da webbrowseren allerede i sin forespørgsel til webserveren siger, at den vil tale HTTP/2.

At turde tage skridtet

I mange tilfælde vil der ikke være nogen meromkostning eller manuel anstrengelse i at aktivere HTTP/2 på sit websted. Bruger man allerede et eksternt CDN (altså indholdsleveringsnetværk), er det ligefrem sandsynligt, at filerne der allerede drager nytte af HTTP/2. Derimod kan man have behov for at gøre visse præstationsoptimeringer om for at drage nytte af den nye protokol. En udfordring her bliver, hvordan man optimerer webstedet både for dem på HTTP 1.1 og HTTP/2, da god præstationspraksis adskiller sig, dette kommer vi mere ind på senere.

I mange år vil HTTP 1.1 leve parallelt med HTTP/2, i et eller andet omfang. Det er en aktivitet, vi som arbejder med webanalyse, skal vende tilbage til. Hvilke systemer vi bruger, kan begynde at arbejde med version 2, og hvad indebærer det i praksis?

For dig med et lille Wordpress-websted er dette en lille foranstaltning sammenlignet med store organisationer, hvor masser af nye, gamle og undertiden forhistoriske systemer samarbejder om at servere indhold til webben.

Grunden til, at HTTP/2 en smule vender op og ned på de kvalitetskrav, man stiller til et websystem, der kører version 1.1, er, at man har tænkt ordentligt igennem, hvordan webben af i dag ser ud. Blandt andet er den nye version bedre til flere samtidige filer og til at holde en åben kanal til at sende filer lidt, når de behøves. At der automatisk medfølger sikkerhed svarende til HTTPS, kan vi se som en bonus.

De systemer, du kigger på først, er dem, der sender mere end én fil til den besøgende per sidevisning. Naturligvis selve webserveren, men også om du har et indholdsleveringsnetværk (CDN), separat billedsystem osv.

Hav dette i tankerne, når du læser resten af denne del af bogen – at dele indhold op i nogle stykker filer er god praksis med HTTP/2, men dårlig praksis i HTTP 1.1. Det gør, at hvis du optimerer præstationen efter HTTP/2's vilkår, vil det straffe dem, der kører ældre teknik, så overvej, hvornår det er værd at tage skridtet.

Denne punkt handler mere om at overvåge, hvad der forventes af et moderne websted. I skrivende stund er HTTPS nogenlunde praksis for at få et ekstra skub inden for søgemaskineoptimering, og før eller siden er det version 2 af HTTP, det vil sige HTTP/2, der vil være noget, der opmuntres inden for SEO.

Om HTTP/2

Du, der ikke aner, hvad HTTP er for noget, kan jeg kort forklare, at det står for HyperText Transfer Protocol, hvilket antyder, at det er protokollen for Hypertext – det vil sige HTML. Man kan sige, at HTTP er det hemmelige sprog, din computer taler med den webtjeneste, du forbinder til. Du har sikkert set det i adressefeltet, når du har surfet på nettet. Når der i stedet står HTTPS, betyder det, at der ligger et lag af sikkerhed oven på HTTP, dette i form af noget, der hedder TLS (står for Transport Layer Security).

Den version af HTTP, vi har nu, blev standardiseret i 1990'erne og kræver en del lapning og reparation, for at det skal fungere, som webben ser ud i dag. Derfor startede Google arbejdet med SPDY, hvilket blev startskuddet til den nu standardiserede HTTP/2 (navnet på version 2).

Det, HTTP/2 tilbyder, er at gøre vores webbaserede tjenester hurtigere, enklere og mere robuste. Det gøres på teknikersprog ved at understøtte full multiplexing, hvilket mindsker ventetiden. Målet er omtrent at halvere den tid, det tager at indlæse en webside. Desuden indføres komprimering på HTTP-headeren, hvilket betyder, at indholdet i omfangsrige cookies ikke vil sænke præstationen helt så meget.

Du, der har læst op om HTTP, kan dog være rolig. Egentlig er det intet af det, du har lært, der ændrer sig, det er de samme navne på felter og de samme metoder som tidligere. På grund af dette er en overgang til HTTP/2 ret udramatisk.

Det er en god idé proaktivt at undersøge, om man kan understøtte HTTP/2 med sit websted, til en begyndelse uden at det forstyrrer i de tilfælde, en stor andel består af mindre sofistikerede besøgende med HTTP 1.1.

Nu kan websteder pushe notifikationer

En helt ny ting med HTTP/2 er, at webserveren selv kan tage initiativet til en kontakt med en klient/webbrowser. Tidligere har webben givet udseende af at kunne have tovejskommunikation. Men på et teknisk niveau rammes webserveren af en hukommelsestab mellem hver forbindelse, og klienten var nødt til med jævne mellemrum at minde om sin eksistens. Det vil sige, klienten lavede konstant forespørgsler, om serveren havde noget nyt at sige.

At webserveren nu kan tage initiativet til denne kontakt, bør også spare på spildt trafik, mindske belastningen på computere, hvilket gør, at de trækker lidt mindre strøm. Det har man indtil nu forsøgt at løse med en teknik kaldet websocket, men der kan der ske udvikling fremover.

Webhotel eller egen server?

Ligger dit websted på et webhotel, må du nok pænt vente, til de beslutter sig for at tilbyde dette. Men hvis det ligger på en egen server, kan det være værd at tjekke, hvad der kan gøres. Det er på ingen måde hastende at lave en overgang til HTTP/2, men ved næste gennemsyn af webstedet er det absolut på sin plads. Hvis webstedet endnu ikke kører HTTPS, bør det også evalueres. Det, HTTPS viser for din besøgende, er, at dennes integritet er værdifuld, at formularer, der postes, ikke kan snages op på vejen mellem webbrowseren og webstedet. Samt at indholdet på den respektive side er hemmeligt for dem, der administrerer alle netværk på vejen mellem den besøgende og webstedet.

Samtlige webbrowserproducenter har lovet at implementere HTTP/2, så da mangler kun, at din webserver får understøttelse, for at du og dine brugere kan drage nytte af denne nye version af HTTP.

Sørg for, at sporing af webstedssøgning, outbound links, fejlsider og downloads fungerer

Overraskende ofte, når jeg har hjulpet kolleger og kunders webstedsstatistikværktøjer, har man ikke sporet, hvilke søgeord der bruges på webstedets egen søgefunktion. De fleste har i dag en søgefunktion, og som du kan læse i denne bogs dybdedyk i emnet søgeanalyse, er det en værdifuld ressource.

For den, der tænker, at man kan nøjes med at have styr på søgeord, folk bruger på eksterne søgemaskiner som Google, har man overset en helt afgørende forskel. Dem, der søger på Google, er åbne for forslag om, hvem af alle der kan hjælpe dem videre, mens dem, der søger inde på jeres websted, søger efter, hvad de tror findes på jeres websted. På den måde kan man i klartekst få at vide, hvad brugernes forventning og forhåbning er. Desuden er det interessant at tjekke, hvad der efterspørges, da det tyder på, at brugerne kan have svært ved at finde netop det indhold. Måske skal det fremhæves?

Ikke kun sporing af søgninger er noget, du skal konfigurere i dit værktøj, der er sikkert meget mere. Problemet med ikke at lave disse indstillinger proaktivt er, at det ikke altid kan genskabes bagefter, når du indser, at de er gode. Måske begynder du på felt et.

Sørg også for, at sporingen af udgående links gøres korrekt, du vil kunne vide, til hvem du driver trafik. Naturligvis er du interesseret i at vide, hvornår brugerne havner på fejlsider, og er det muligt at spore endnu mere alvorlige fejl, kan det vise sig nyttigt. Tilbyder du downloads på webstedet, eller har en masse indhold uploadet, så sikr dig, at du ved, hvordan det bruges. Udenforstående linker måske direkte til jeres indhold, uden at I forstår, hvad der sker.

Nogle gange kan man gruppere forskellige typer indhold i sin webstedsstatistik. Lad os sige, at man har artikler til inspiration, produktsider og supportsider, så kan det være interessant at se, hvordan de bidrager til helheden.

Ikke komme til at lække person- eller kundeoplysninger til webanalyseværktøjer eller andre tredjepartssystemer

Uden at man tænker over det, kan mere eller mindre følsomme oplysninger havne i systemer, hvor de ikke hører hjemme. Mest bemærkelsesværdigt er vel, hvis man lækker følsomme personoplysninger til tredjepart, men selv hvis der havner personoplysninger i det forkerte værktøj, kan det indebære en risiko for misbrug.

Så snart man indsamler personoplysninger, er man også ansvarlig for, hvordan disse håndteres, hvem der får adgang til dem osv. I de fleste lande er der love, der regulerer integritet og databeskyttelse. Det kan være værd at lave lidt research omkring dette for det marked, man opererer på, så det ikke kommer som en ubehagelig overraskelse senere.

Vil man tale med udviklerne på udviklersprog, eller stille krav i sin præstationsbudget, kodningsstandard eller hvad man vil kalde det, er det, at man forventer, at indhold og formularer bruger POST-metoden i HTTP. Som afgået udvikler kan jeg vel indrømme, at mange udviklere ikke er så pokkers gode til HTTP. Hvis man eksemplificerer det med, at man ikke skal bruge GET, klarer det sig måske. Hvis der er brug for yderligere tydeliggørelse, så nævn noget med, at det ikke er meningen, at et postet formulars felter skal vises i klartekst i adressefeltet.

Faktum er, at denne type håndtering desuden gør det lidt mere besværligt at få overblik, da man får flere unikke adresser til en og samme visning af webstedet. Hvis det besværlige ikke var argument nok, eller at det er dårlig praksis, er det også et brud på blandt andet Google Analytics' aftale at sende dem personoplysninger. Det er vel bedst at lade være, inden man får sin konto lukket brutalt ned for aftaleovertrædelse.

Tre eller færre stilark

Stilark er dansk for CSS (Cascading Style Sheet), som er en løsning, tro det eller ej, fra 90'erne, skabt af Microsoft. Tanken er at adskille formgivning fra indholdet og strukturen på en webside.

Det er svært at argumentere for, at en besøgende på et websted har nytte af, at stilarket er opdelt i mange forskellige filer. For udvikleren, der skabte webstedet, kan det derimod være meget smart at have flere stilark.

Hvor mange CSS-filer har vi brug for?

Et stilark, der nulstiller alle afstande til webbrowserens yderkanter, er ikke usædvanligt (såkaldt reset.css), et til grundlæggende design, og et til fælles farver, så man følger den grafiske profil. Et yderligere CSS-fil til, at webstedet skal følge responsivt webdesign (som ofte er et tillæg til eksisterende web), derefter et til for at sætte farver på den lokale version af webstedet.

Dertil tilkommer der ikke sjældent nogle stykker afhængigt af dine tilføjelser i Wordpress (eller sjuskende webkonsulenter). Men lad os nøjes med 5 CSS-filer at downloade, så vi er på den sikre side i et lille matematisk eksempel.

Hvorfor minimere antallet af stilark?

Grunden til, at du vil have få stilark, CSS-filer altså, er, at hver fil, der skal downloades, har en ventetid, inden den begynder at sendes til den besøgende. Det skyldes, hvad ungerne i dag kalder for lag. Præcis hvor lang denne ventetid er, afhænger af mindst tre faktorer:

1. Den webserver, der sender filen.
2. Netværket mellem serveren og den besøgende.
3. Den besøgendes egen opkobling til nettet.

På grund af denne ventetid vil man normalt have så få filer som muligt at sende til en besøgende. Jo flere filer, desto mere tid, der spildes på ventetid.

Tag eksemplet ovenfor med fem CSS-filer. I det bedst tænkelige scenarie vil det slet ikke mærkes, da regner vi koldt med, at de besøgende sidder på en kablet forbindelse, solen skinner, alle undtagen dine besøgende er ude i en bypark og griller pølser og drikker rosévin. Netop din tiltænkte målgruppe er de eneste, der bruger internettet, og din server har det godt.

I et mere realistisk scenarie vil i det mindste nogen i din tiltænkte målgruppe være i den situation, at de har en tvivlsom mobil 3G-forbindelse med svartider på 0,1 sekunder. Det indebærer, at der går et halvt sekund til at vente på at få at vide, hvordan indholdet skal se ud, hvilke farver og skrifttyper der bruges, og hvordan højrekolonnen skal falde ind i bunden af siden for mobile besøgende. Da har vi ikke regnet med den tid, det tager at overføre CSS-filernes faktiske indhold – kun den tid, det tager at vente på, at filerne begynder at sendes.

Hvorfor har man mere end et eneste stilark?

Ja, det kan man faktisk undre sig over. Hvis jeg spekulerer og drager veksler på mine erfaringer som webudvikler, ville jeg påstå, at det skyldes dovenskab i kombination med upræcise krav fra bestilleren. Man skyder fra sig og mener, at kunden burde kunne webudvikling bedre end de webudviklere, man i udbuddet solgte ind som landets fremmeste eksperter.

Det er altid lidt for let at give bestilleren skylden. Netop i dette tilfælde kan der tilkomme flere CSS-filer for brugeren at downloade for hvert "quick fix", der laves på et websted. Eller, hvis du nu kører Wordpress, skal du passe på, hvilke ekstrafiler et plugin kræver.

Dirty hack, quick fix, dovne, uvidenhed eller ingen faglig ære?

Jeg har desværre oplevet, at kolleger har lagt en ekstra CSS-fil ind på en side. Da jeg spurgte, hvorfor de valgte at tilføje yderligere en fil, der forsinker indlæsningen af et websted, fik jeg ofte til svar, at det var den hurtigste løsning. Er man ikke enige om en form for minimumsniveau af kvalitet, er det desværre bare at give dem ret, det er absolut nemmest og hurtigst at lave dirty hacks – det er derfor, det hedder dirty hacks…

3 eller færre Javascript-filer

Ikke sjældent downloades der en masse Javascript, man som bruger aldrig vil få brug for. Ofte er de opdelt i flere filer, hvilket bidrager med ekstra ventetid. Som vi netop har konstateret, er det normalt en fordel med så få filer som muligt, der skal sendes til en besøgende.

Du spørger måske, hvorfor man gør på denne åbenlyst ødselende måde og deler indholdet op i flere filer? Ja, det enkle svar er, at det er lettere at regne på omkostningen ved, at en udvikler bliver hurtigt færdig, end al den tid, man spilder på brugernes bekostning.

Naturligvis skal der ske en afvejning af interesser her. Derfor har man brug for en form for målestok over, hvad der er ok, når det gælder brug af Javascript. Netop denne punkt handler om antallet af Javascript-filer, at man skal slå dem sammen, men der er naturligvis en grænse for, hvor stor filen må være, for at man vinder noget.

Almindeligt forekommende opdeling af Javascript

Ikke sjældent har man nogle forskellige kategorier af Javascript-materiale, for eksempel Javascript som:

• Omformer menuen på små skærme, sætter en sådan hamburgermenu på, hvilket sparer masser af plads.
• Understøtter interaktion i formularfelter, for eksempel ved at fortælle, hvilke obligatoriske felter brugeren har glemt at udfylde ved postning.
• Følger med designrammeværk, for eksempel Bootstrap, som hjælper med designkomponenter som dialogbokse, hvordan fejlmeddelelser skal vises (og en masse yderligere designmagi, man har valgt ikke at bruge på netop sit eget websted).
• Jquery-biblioteket smides ofte med af vane, men ret ofte kræves det som komponent af andre komponenter.

Ud over disse har man ofte fået et eller flere Jquery-baserede tilføjelser til billedgallerier, bedømmelse af sider og andet.

Hvis man ikke passer sig, får man disse Javascript i hver sin Javascript-fil. For den, der vælger at forsøge at gøre et godt arbejde, stilles man over for, hvilke Javascript man skal kombinere til en enkelt fil (hvis ikke alle). Problemet er, at du skal lave en afvejning mellem at sende Javascript-kode, der ikke vil bruges af enhver besøgende, og at dele det op i flere logiske grupperinger. Alle dine besøgende vil ikke se billedgalleriet, for eksempel, så alle har ikke brug for de Javascript-filer.

En ting er dog klar, dovenmandversionen, alt for mange kører med, er, at al Javascript downloades fra hver sin fil, uanset om de overhovedet behøves på den side, der ankalder dem.

Sig for eksempel, at man har valgt at have masser af enkelte Javascript-filer, så bør kun dem, der behøves til en bestemt underside, downloades. Altså downloades ikke Javascript til formularvalidering på en side, der mangler formular.

Alternativ metode er lazy loading

Lazy loading er et designmønster, der går ud på, at det, der behøves til en sidevisning, downloades lidt senere, eller kun ved behov. Præcis som at billeder i sidefoden ikke behøver downloades for flertallet, hvis kun et fåtal scroller sig derned, på samme måde kan Javascript-filer downloades, når de kommer i brug.

Motivationen for dette er naturligvis ikke at tynge ned mere end nødvendigt. Kritikken mod at slå alle Javascript-filer sammen er, at brugeren da skal modtage masser af data, der er unødvendige for netop deres besøg.

Det, lazy loading forudsætter, er, at svartiden skal være meget lav, det vil sige, at det går uhyre hurtigt fra den besøgendes webbrowser at få noget overført fra webserveren. Det er absolut ikke tilfældet, hvis den besøgende har en trådløs forbindelse via 3G- eller Edge-nettet. Derimod er det fremragende til 4G-nettet og naturligvis alle modernere kablede forbindelser. Så spørgsmålet er, hvilken type besøgende dit websted har, og hvor stor en andel af dine besøgende, der er ubetydelig for det designmønster, du vælger.

Der er som du forstår grund til at have en vis prutningsmarginal, og i min verden er tre Javascript-filer den prutningsmarginal, især da det uden særlig stor anstrengelse ved nybygning af et websted kan være en enkelt Javascript-fil.

Ud over antallet af Javascript vil man helst ikke have, at de indlæses, inden siden kan vise sig, dette kan du tjekke i Google Pagespeed i dag, tror det står, at man skal prioritere synligt indhold, hvis de synes, man har fejlet ("above the fold").

3 eller færre billeder til udseendet

Udviklere bør bruge CSS i stedet for billeder i så stor udstrækning som muligt. I fortiden, dengang man lavede layout med tabeller, brugte man billeder, som blank.gif, til at skubbe bogstaver ind fra venstremargen. Desuden kunne man ikke regne med, at CSS fungerede i ældre webbrowsere.

I dag er der løsninger på de fleste af disse problemer. De hedder polyfills, shims og en del andet, men pointen er, at de lapper og reparerer gamle elendige webbrowsere. Det gør, at frontend-udvikleren (den der skriver CSS, HTML og Javascript) kan bruge moderne webstandardiseret kode.

Grunden til, at vi vil holde antallet af filer nede, er den samme som jeg har skrevet tidligere, ekstra filer bidrager med ekstra ventetid – hvilket især rammer dem med ustabil internetforbindelse. Bedst er som altid at sende så lidt som muligt og kun det, man absolut er nødt til.

"Men så smider jeg en webfont, en SVG-fil og en CSS sprite ind!"

Jada, men disse tre løsninger er jo i mange tilfælde løsning på det samme behov. Men så har man holdt sig til maks tre, som er min anbefaling, selvom det kan føles lidt ødselagtigt.

Webfonts kan ud over at beskrive udseendet på tekst indeholde ikoner, man bruger på sin webside. Måske et hus for hjem, en konvolut for kontakt m.m. Webfonts er desuden skalerbare og passer derfor godt på webben i dag, når man ikke ved, hvilken skærmstørrelse den besøgende kan tænkes at have, eller om den er højopløst.

Et responsivt websted kan også bruge SVG (Scalable Vector Graphics). Med SVG kan du sågar vise forskellige mængder detaljer i illustrationer fra SVG-filen afhængigt af, hvilken plads der er tilgængelig – responsiv ikonhåndtering med andre ord.

Billede 62: Glyphicons, der bruges i rammeværket Bootstrap

Den mere indarbejdede løsning er CSS sprites. Det går ud på, at man har masser af billeder sammensat til et enkelt billede. Derefter bruger man CSS til at have et lille "kighul" mod det billedkort. Man positionerer altså billedkortet bag et kighul, og så synes kun det ønskede billede.

Indlæs kun det, der behøves, når det behøves

Denne aktivitet bør ikke tolkes bogstaveligt, men ses som et vejledende princip. Et almindeligt eksempel er, at først når brugeren vil skrive en kommentar, begynder man at indlæse de filer, der behøves til netop den del. Sig at du bruger en tredjepartstjeneste som Disqus til kommentarer, så indlæses de filer ved behov i stedet for ved enhver sidevisning.

Også når det gælder filer, der skal sendes fra ens egen webserver, kan man arbejde på denne måde. Det er især interessant, hvis man har opgraderet til HTTP/2, da det ikke er lige så dyrt, præstationsmæssigt, at sende en ny fil. Men glem som sagt ikke at have styr på oplevelsen for de brugere, der endnu ikke understøtter HTTP/2 med det udstyr, de bruger. Her skal du tænke præcis som med designprincippet om progressive forbedringer – alle skal have en god oplevelse, men dem med meget moderne udstyr kan få en endnu bedre oplevelse.

Et første skridt i denne retning er at pakke forskellige typer indhold i forskellige grupper. At filer på et websted kan have interne afhængigheder af hinanden, kaldes for AMD (Asynchronous Module Definition)⁶⁵, og der er koderammeværk som Require.js, der hjælper til. Det her er mere noget at kigge på, når man bygger om eller bygger nyt.

Sørg for, at du har adgang til gode data til webanalyse

I hvert fald i større organisationer har man ret komplicerede IT-miljøer. Ting, jeg er snublet over ikke kun der, hvor jeg har arbejdet, men også på det offentlige web, er, at man får fejlmeddelelser, sendes til en indlogningsside eller stoppes af en anden grund. For at have fuld kontrol over brugerens oplevelse skal du sørge for at have data om disse afvigelser, du kan ikke regne med, at alt sådant indsamles i dit webstatistiksystem.

Som absolut minimum bør dit værktøj til webanalyse indsamle data, når brugere lander på din Error 404-side, men der er en drejefuld af fejlmeddelelser derudover. For eksempel at man ikke har adgang til siden og skal logge ind, eller at siden er gået ned af en anden årsag.

Nogle gange er det måske ikke engang teknisk muligt at indsamle disse begivenheder til dit webanalyseværktøj. Men ikke engang da skal du give op! Hvis der er noget, man kan bande på, er det, at teknikere, der fremstiller udstyr, har haft en form for logning til eget brug. Forsøg at få fat i den log. Indholdet er måske ikke særlig pænt eller forståeligt, dog er det vigtigt at opnå viden om brugerens oplevelse. Der er værktøjer, der kan hjælpe dig med konstant at have styr på tingene. Vil du konstant vide, hvordan situationen er nu eller lige var, kan du kigge på loganalysplatforme som ELK (Elasticsearch Logstash Kibana). Men vil man holde hårdere i pengene, kan man kigge på selvhjælpsværktøjer for det voksende område inden for data science, for eksempel Tableau (som også findes i en gratisversion, kaldet Public).

Validér ifølge WCAG 2.0 niveau AA

Fra og med den første januar 2015 blev det ulovligt på sit websted at diskriminere dem med funktionsnedsættelser. Det plejer at vare et stykke tid, inden love er prøvet i domstolenes alle niveauer, derfor er det ikke glasklart, hvor grænserne går. Der er naturligvis forskellige niveauer af, hvor stor en overtrædelse man begår mod en funktionsnedsat persons rettigheder. At blive helt udelukket på grund af sin funktionsnedsættelse er jo et tilfælde, der forhåbentlig bliver svært at sno sig fra, mens domstolene nok ikke vil indgyde gudfrygtighed i dem, der har glemt at skrive alternativtekst til et billede.

Ret hurtigt blev Göteborgs Universitet anmeldt til diskrimineringsombudsmanden (DO) for diskrimination af blinde personer. Den, der anmeldte, mener, at vedkommende er blevet udelukket, fordi tilmeldingsformularen til uddannelsen ikke var tilgængelig for blinde.

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, synshandicappet der sammen med DO anmeldte Göteborgs Universitet for diskrimination⁶⁶

Vel optaget på uddannelsen viser det sig, at den læringsplatform, der tilbydes eleverne, ikke kan bruges af blinde. Det er ikke muligt at modtage beskeder fra lærere eller tage del af eksamensresultater. Göteborgs Universitet er dog bevidste om dette og svarer 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

Hvis ikke den svenske lovgivning er motivation nok, nåede EU i maj 2016 frem til, at det bliver et fælles "Webdirektiv". Det vil gælde offentlig sektor, de private aktører, der udfører service på opdrag af offentlig sektor, og det, der menes, er websteder, intranet og apps⁶⁷.

En måde at slippe for at diskutere præcis, hvilke ting man vil leve op til, og derefter argumentere detaljer med sine leverandører af websystemer eller webudviklere, er at vælge en etableret standard. WCAG 2.0 (Web Content Accessibility Guidelines) er en sådan standard. WCAG tilbydes af webstandardorganisationen W3C.

Der er tre forskellige niveauer, nemlig A, AA og AAA. Jo flere A'er, desto strengere overholdelse af funktionsnedsattes behov. Hvilket niveau du vælger, er op til dig, men følger du niveau AA, vil jeg gætte på, at du ikke risikerer at dømmes på grund af hverken diskrimineringsloven eller EU's webdirektiv, men jeg er jo ikke jurist :)

Hmm, hvad indebærer dette med WCAG?

Egentlig bør meget lidt af de krav, WCAG stiller, være nyheder for nogen, der har arbejdet et stykke tid med publicering på webben. Blandt andet betyder det, at man skal tilbyde tekstalternativer, for eksempel at billeder skal have en alternativtekst. Laver du videoklip, skal du da også tænke på at have et tekstalternativ til det, der tales.

Der stilles også krav til kontrastforholdet mellem tekst og dens baggrund. Hvor høj kontrasten skal være, afgøres af tekstens størrelse. Apropos tekst skal den kunne skaleres om, noget der skaber problemer for dig, hvis du er vant til at lægge tekst i billeder, for eksempel ved skabelse af billedpuffer eller bannere.

Mere om tilgængelighed og testværktøjer

W3C har en liste med værktøjer⁶⁸ til at teste tilgængeligheden på en webside. Da der er forskellige regelsæt, er det værd at tjekke, at du lever op til minimumskravene der, hvor du har virksomhed. For eksempel 508 Checker for ikke at bryde den amerikanske lovgivning.

Eksempler på værktøjer til at tjekke websteders generelle tilgængelighed er WAVE⁶⁹, eller hvis du vil automatisere kontrollen, kan du kigge på Tenon.io⁷⁰ – du kan måske ikke regne med, at webredaktører tager sig tiden.

Sidevisninger skal være på under et sekund?

En vinkel på, hvorfor det er vigtigt for dig, er søgemaskineoptimering (såkaldt onpage-optimering). Google giver dig en vis tid til deres indeksering. Så er det vel godt, hvis de når mange sider, ikke?

For løbende at holde styr på søgegigantens ræsonnementer omkring webpræstation er det deres præstationsguru Ilya Grigorik, du skal følge. Vil du læse op på teknikaliteter, har han lagt sin bog gratis ud på nettet – High Performance Browser Networking⁷¹.

Bedre brugervenlighed på webstedet, hvilket fører til højere konvertering

En anden grund til, at et websted skal være hurtigt, er for brugernes skyld. De mister følelsen af flow og oplever, at de venter omtrent, når der er gået et sekund. Så risikerer man at miste sin bruger, inden de har opnået det, du eller vedkommende ville med besøget.

Anbefalingen er at servere en side på ca. 0,1 sekund. Så opleves det, som om interaktionen er øjeblikkelig. Tager det mellem 1-10 sekunder, begynder brugeren at opleve, at de venter. Selvom studier viser, at de fleste klarer at holde koncentrationen om, hvad de er i gang med, begynder teknikken at irritere brugeren.

Spilder ikke webserverens ressourcer

En usædvanlig vinkel på, hvorfor et websted skal indlæses hurtigt, er, at webserveren, der sender siden, ikke kan håndtere et ubegrænset antal samtidige overførsler. Det faktiske antal varierer naturligvis med, hvor dyr en løsning man har, men der er potentiale til at sænke sine serveromkostninger, klare sig længere på eksisterende servere eller måske at være mere klar til en trafiktop ved en krise eller en vellykket kampagne.

Gratis værktøjer til at måle en sides indlæsningstid

Vil du gøre det enkelt for dig, så tjek Googles værktøj Pagespeed Insights, det advarer, hvis serverens svartid er for lang. Samtidig har Pingdom en række tjenester til dette, men mest interessant er den, der måler webstedets svartid flere gange i timen. Så får du et diagram over præstationen over tid og kan også modtage advarsler via en mobilapp.

Google Pagespeed mobilt skal være mindst 80 af 100

Google Pagespeed er et konkret mål for, hvor god præstation et websted har, noget som både Google og rigtige brugere bekymrer sig om. En grund til, at du måske nøjes med Googles synspunkt, er, at vi alligevel er i deres vold, når det gælder SEO.

Nu er det måske ikke 80 af 100, netop du skal vælge. Dog har du brug for at vælge et niveau, noget der stemmer overens med din ambition omkring webstedets præstation. Du skal måske hæve niveauet og vælge 90? Hvis mobile kunder er de vigtigste for dig. Eller du vælger 50, hvis dit websted har en lang vej at gå for at blive godt i mobilen.

Google selv har dog en holdning til, hvad de synes er et godt niveau (min fremhævning):

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⁷²

Opret en testside til at evaluere ændringer i webdesign

For at det skal være en retfærdig sammenligning fra en måling til en anden, er det nødvendigt at teste under de samme forudsætninger. Med andre ord skal man opsætte en repræsentativ testside på sit websted. Netop den side er den, man laver test mod for at vide, at resultatet er sammenligneligt over tid. Det, der kan variere, er webserverens svartid, ellers skal sidens indhold i redaktionel forstand i vid udstrækning være det samme fra gang til gang.

Gør du det på denne måde, ved du, om ændringer i webdesign har gjort situationen bedre eller værre. Det kan være, at du prøver at skifte tema, hvis du kører Wordpress, at dine webkonsulenter har opgraderet noget, eller muligvis lavet en nyudvikling.

Hvordan man udformer sin testside

For at din testside skal være meningsfuld, gælder det, at den fra en redaktionel udformning er praktisk taget den samme over en længere tid. Hvis du skal kunne sammenligne resultatet før en opgradering af publiceringssystemet med efter, gælder det, at indholdet er næsten identisk.

Mit forslag er, at du opretter en underside udelukkende beregnet til test. Den side skal indeholde tekst, billeder og sådant, der er normalkomplekst for en almindelig side på webstedet. Det er ikke her, du indlejrer en masse mærkelige eksterne tjenester, widgets, videoklip eller sådant, hverken du eller dine udviklere har kontrol over.

Lav en nulmåling

Når du har din testside, laver du en første måling hos Google Pagespeed, derefter afstemmer du resultatet med alle involverede og dokumenterer det et sted (så folk forstår, at dette må de finde sig i fremover). På en passende højtidelig måde burde man sikkert erklære, at det ikke er acceptabelt, at resultatet bliver dårligere.

Eventuelt er du jo din egen modpart, så er en jurist noget overflødigt, og du må sige til dig selv, at du skal skærpe dig :)

Billeder skal bearbejdes til webben

Der er meget at tænke på, når man udsmykker sit websted, men også når man fylder det med redaktionelt indhold. Dem, der udsmykker, er oftest professionelle til billedbehandling, men ikke altid lige så professionelle med hensyn til, hvad der gælder for webben, og hvilke vilkår webben stiller.

Dertil er der redaktører og alle brugere, der uploader materiale til websteder. Det er ikke altid, vi får det rigtige resultat, heller ikke sikkert, at vi får hjælp af de værktøjer, vi tilbydes.

Nogle gange har man billeder via en mediebank, hvor mediebanken gør arbejdet for en, nogle gange uploader man dem manuelt. I dag, hvor alle endelig har accepteret, at websteder skal være responsive ned til en mindre skærm, opstår endnu et problem. Nemlig at de små skærme ofte har højere opløsning end de store og derfor kan drage nytte af mere detaljrige billeder (samtidig er skarphed ikke altafgørende).

Men de små skærme, mobiltelefoner i de fleste tilfælde, er også behæftet med den store ulempe at have en trådløs og undertiden ustabil forbindelse. Det indebærer, at selv normalopløste billeder kan opleves som meget sløve at downloade.

Billedbehandling til webben er med andre ord sværere end nogensinde.

Billeder bør være i den opløsning, de skal vises

Et yderligere krux er, at de fleste responsive websteder har flydende kolonnebredde. Som næsten alle har designet det, er der billeder, der fylder hele kolonnens bredde, hvilket fører til, at vi ikke på forhånd ved, i præcis hvilken størrelse billedet vil blive vist.

Tag så som et tankeeksperiment, at midterkolonnen kan være fra 300 til 500 pixels bred. Billedet, der vises i toppen af den kolonne, skal være lige så bredt som kolonnen, for at det skal se "harmonisk" ud.

Vælger du da at uploade billeder, der er 500 eller 300 pixels brede?

Lad os regne på forskellen. Sig at billedet har et 2:1-forhold i sin størrelse. Så bliver den større variant 125.000 pixels (500 x 250). Er det i stedet 300 bredt, bliver det totalt 45.000 pixels (300 x 150). Det er en kæmpe forskel på billedareal, og dit valg vil absolut påvirke præstationen.

Som lus i skindpelsen har vi udfordringen med højopløste skærme. Det, Apple-brugere kalder for retina. Det indebærer ofte dobbelt så høj opløsning, det vil sige, at hver pixel bliver fire for at nå maksimal skarphed – så det ikke ser sløret ud for dem, der har vænnet sig til skarpheden.

Ovennævnte billede ville altså være 500.000 pixels for at være virkelig skarpt (1000 x 500). Det er ti gange så meget data sammenlignet med, hvis du vælger at sende billedet i 300 x 150.

Tør du sende et sådant højopløst billede til en mobiltelefon, der af og til er forbundet på et tvivlsomt mobilnet? Her må du lave en afvejning, men som jeg håber, du har forstået, er dette intet, man kan gøre uden eftertanke. Grundreglen er forræderisk enkel: billeder skal være i den opløsning, de vises, og man skal ikke skalere dem ned med HTML eller CSS.

Er du bekymret over dette, så læs gerne op om responsive billeder på nettet, desuden har jeg lidt mere om det i min bog Webbstrategi för alla.

Billeder skal gemmes i passende format

Grundreglen er, at billeder skal være gemt i det format, der muliggør mindst filstørrelse i relation til en bibeholdt billedkvalitet.

De fleste kender formaterne GIF (udtales tilsyneladende "jiff" ifølge folk med stærke meninger), JPG og PNG som noget, man støder på på webben. Disse formater har deres styrker og svagheder, ekstremt kortfattet:

• GIF understøtter animationer og gennemsigtighed, men kun 256 farver. Effektivt netop til animationer og undertiden enkle illustrationer som logoer.
• JPG er et format til fotografier. Meget godt til alle billeder, der mangler flader med en og samme farve – hvis sådant forekommer, plejer de at "bløde" og vise lyserøde og grønne pletter, hvis det er komprimeret.
• PNG har to varianter, en på 8 bit og en på 24 bit. Den på 8 bit har ligheder med GIF, da man kan have maksimalt 256 farver. Ved 24 bit får man også gennemsigtighed, samt at den da understøtter millioner af farver. PNG er mest effektiv som 8 bit og til illustrationer, informationsgrafik, logoer med mere.

Dertil tilkommer initiativer som WebP, skabt i 2010. Noget Google, Ebay og Facebook har ført kampagne for. De viser jo utrolig mange billeder, så det ligger absolut i deres interesse at få bred understøttelse blandt webbrowserne. WebP-billeder er ifølge test, jeg har læst, op til 25 % mindre i størrelse sammenlignet med den af de tre andre, der præsterer bedst. Så det er noget at holde øje med.

Billeder skal gemmes til webben

Når du har valgt det rette format, skal et billede gemmes optimeret til webben. Det findes i alle billedbehandlingsprogrammer, jeg har stødt på. Det kan være, at hvis du er i tvivl om, at du har valgt det rette format, tjekker du de andre formater, når du gemmer til webben. I det mindste Photoshop understøtter dette ved, at man øverst i højre hjørne af dialogboksen kan vælge format.

Hvis du vælger PNG, så tjek gerne, om filen bliver mindre og stadig ser ok ud som 8-bit, gerne med så få farver som muligt. Efter et stykke tid får man ret god fornemmelse for, hvilke billeder der måske fungerer som et andet billedformat.

Med JPG-filer kan du dels lidt grovhugget vælge niveau af komprimering, men der er også en skyder, hvor du kan vælge mellem 0-100, hvor meget kvalitet du vil bevare. Vær opmærksom på flader med samme farve eller nuance, og særlig opmærksom skal man være på hudflader på mennesker, hvor vi synes at være ekstra følsomme. Personen på billedet kan opleves som syg, hvis billedet er optimeret for hårdt.

Det, du vil se ved for hård optimering, er, at detaljerigdommen synes at forsvinde, at der opstår misfarvede firkanter af oftest grønt og lyserødt. Klip et stykke hvidt ind i et foto, og komprimér stenhardt, så ser du, hvad jeg mener.

Med en GIF-fil ræsonnerer du som en 8-bit PNG.

Kør billeder gennem ikke-destruktiv optimering

Nu har du allerede taget tre skridt for, at et billede skal gå hurtigt at downloade. Hvornår bliver vi færdige egentlig? Ja, dette er det sidste trin i den proces, jeg selv tager.

Det, vi nu gør, er at fjerne helt unødvendig data fra billedet – såkaldt ikke-destruktiv optimering. Pointen er, at optimeringen ikke skal kunne opdages med det blotte øje, men undertiden kan filerne blive meget mindre. Regn med, at mindst 5 % kan høvles af på præcis ethvert billede.

Billede 63: Imageoptim skærer op til tre fjerdedele af billeders filstørrelse.

Jeg, der kører Mac, bruger det fantastiske program Imageoptim. Det fungerer så fortræffeligt, at jeg trækker en masse billeder (måske hele webbens billedmappe) til programmets vindue, og derefter optimeres alle billeder og overskrives på deres nuværende placering. Herefter uploader man billederne igen.

For dig, der ikke kører eller har adgang til en Mac, er der webtjenester, der gør det samme, men lidt mere omstændeligt. Der er også tilføjelser til ens websted, så dette kan gøres automatisk (så man ikke behøver at huske det). Til mine Wordpress-websteder har jeg kørt med et plugin, der hedder Ewww Image Optimizer⁷³.

Ikke bruge skrifttyper, der skal downloades

Mange gange har en papirfokuseret kommunikations- eller marketingafdeling valgt en særlig skrifttype, man vil bruge i al sin kommunikation. Måske tvinges man gennem sin grafiske profil. Der skal webben ikke stikke ud som en undtagelse, og så har man sørget for at sende skrifttyper (du ved det, der bestemmer, hvordan bogstaverne skal se ud) også til besøgende på webben.

Dertil er der tilfælde, hvor et designrammeværk, webudviklerne har brugt for at spare tid, gør, at den besøgende skal downloade skrifttyper for at vise websiden. Disse skrifttyper er ikke altid afstemt med den identitetsansvarlige i organisationen.

Som vi tidligere har konstateret, er det klogt at forsøge at have så få filer at downloade som muligt. Det gælder især, hvis man har en stor andel brugere, der ikke har en supergod internetforbindelse.

Apropos dårligere internetforbindelser skal man også være bevidst om, at det måske ikke bliver præcis, som man har tænkt sig med den fine skrifttype. Der er et ret selvforklarende begreb, Flash of Unstyled Text (FOUT)⁷⁴, der belyser problemet med, at tekst kan nå at vises med en standardskrifttype, og så blinker det til, når den skrifttype, man netop har sendt, appliceres. Der er flere varianter af dette problem, Flash of Invisible Text som på billedet her ved siden af.

Billede 64: Vi har nok alle ventet på usynlig tekst. Som disse sociale knapper uden tekst. (Kilde: SimonW på Twitter).

Webtypografi

Selvom man ikke har valgt en underlig skrifttype, er det ikke sikkert, at den skrifttype, man har valgt, er den, der vises for de besøgende. Hvordan dine skrifttyper fungerer, kan du tjekke på Font Family Reunion⁷⁵. Jeg har selv fundet halvekstreme typografiske afvigelser, hvor en skrifttype uden haker (såkaldt sans-serif) er erstattet med en anden skrifttype, der har haker (såkaldt serif).

Indlæse skrifttyper via Google Fonts?

Brug gerne Google Fonts som tjeneste til at downloade skrifttyper (hvis du nu er nødt til det). Fordelen er, at hvis skrifttypen er almindelig blandt andre websteder, der bruger Google Fonts, er der en chance for, at skrifttypen allerede er i webbrowserens cache hos dine besøgende og dermed ikke behøver at downloades på ny.

Ulempen er, at det i mange tilfælde ikke allerede er downloadet, men sandsynligvis er Googles servere hurtigere end dine. En anden ulempe er, at du har lidt af den samme integritetsproblematik som med webanalyseværktøjet Google Analytics, hvis du lader Google hjælpe dig med at servere indhold til dine brugere.

Som du forstår, er det her med webtypografi heller ikke noget, man skal overlade til tilfældighederne. Vil man tage den nemme vej ud, er tippet ikke at have nogen ekstra skrifttyper, men vælge en almindeligt forekommende skrifttype, der har en høj læseværdi – en skrifttype, der ikke behøver downloades.

Følge W3C's anbefalinger for HTML, CSS og Javascript

Praktisk talt alle websteder består af HTML for sit indhold og struktur, CSS for hvordan det skal se ud visuelt og Javascript for at understøtte interaktion. Der er flere måder at skrive kode i disse sprog, men der er også anbefalinger. At sørge for, at ens kode fungerer i mange webbrowsere, for så mange som muligt, uden at stille en masse krav, er det, der kaldes at følge webstandard. Webstandard er en god praksis at følge, hvis man ikke har exceptionelt gode grunde til at lade være.

Hvordan ved jeg, at vi følger webstandard?

Der er ingen certificeringsorganisation (så vidt jeg ved), der uddeler ok-stempler til dem, der følger webstandard. Desuden er det nok, i hvert fald i juridisk forstand, et alt for vagt begreb til at opsummere alt, der skal stå i en aftale mellem bestiller og udfører.

I stedet må man koge det ned til at følge de anbefalinger, standardorganisationen W3C (World Wide Web Consortium) har sat op for den grænsefladekode, der sendes til de besøgende.

Følger man anbefalingerne, øges sandsynligheden for, at det ser ud, som det skal, og fungerer, uanset hvilken webbrowser eller type enhed brugeren vælger.

Men alle de fede nymodens ting, jeg vil bruge da?

En nyttig modvægt til vores naturlige nysgerrighed på at teste nye smarte muligheder er den stadig strengere lovgivning inden for tilgængelighed. At det er diskrimination at begrænse folks muligheder for at bruge webben.

En måde at forsøge at forene flere interessenters behov er at tage udgangspunkt i designstrategien kaldet progressive enhancement. Den går ud på, at standardindstillingen er, at alle skal være velkomne, men at man uden at forringe funktionsnedsattes oplevelse kan tilbyde finesser til dem, hvis tekniske forudsætninger tillader sådant.

Et yderst simpelt eksempel på dette er, hvordan CSS 3 fungerer i webbrowsere, understøttes det ikke, vises ikke runde hjørner på bokse. Det forringer ikke den grundlæggende oplevelse for nogen, muligvis beriger det oplevelsen for visse.

En anden designstrategi er graceful degradation. Den starter til forskel fra progressive enhancement fra den anden ende – at finesser skaleres bort, uden at det skaber problemer.

Min personlige anbefaling er at køre progressive enhancement, men at tænkningen fra graceful degradation bruges i fejlhåndtering og de fejlmeddelelser, man giver brugere.

W3C har en tjeneste, Markup Validation Service, der hjælper dig med at tjekke, om en webside følger den kodestandard, den udgiver sig for at følge.

Minificér frontend-kode

Læser du koden bag websider? Det vil sige HTML, CSS og Javascript? De fleste gør det ikke, og det er jo naturligvis ikke derfor, man har en webside. Man kan spørge sig, hvorfor det er så almindeligt, at webudviklere prioriterer deres egen faggruppes interesse i læsbar kode frem for de besøgendes behov for en hurtig oplevelse.

For en webudvikler er det fantastisk smart med læsevenlig kode, når noget skal tjekkes på et websted, der ligger skarpt ude på webben. Webudviklere beskæftiger sig mere end gerne med nærmest religiøst fundamentalistiske stillingtagen om, hvordan man bør bruge mellemrum i stedet for tabulatorer, eller omvendt, hvornår man skal lave linjeskift i kode osv.

Derimod du, der forsøger at betale regningerne i netbanken, er fuldstændig ligeglad med, hvor letlæselig koden er for den ekstremt lille gruppe, der producerer websteder, det eneste du bekymrer dig om, er, at det fungerer godt og hurtigt.

Minificering i praksis

Al grænsefladekode (også kaldet frontend-kode) bør minificeres, hvis det kan reducere filstørrelsen mærkbart. Det gør filen lettere at downloade. Det gælder naturligvis kun tekstfiler, men med tanke på, hvor meget Javascript og CSS mange websteder bruger, kan det gøre ret stor forskel. Jeg har set alt mellem 5 og 90 % mindre størrelse på filer, der er minificeret, det påvirker som du forstår hastigheden en del.

Hvordan man begynder at minificere (som udvikler eller på Wordpress)

Der er flere måder at indføre minificering på et websted. Da jeg byggede på Microsofts ASP.NET-platform, valgte jeg at køre med byggescripts (såkaldte MSBuild), hvilket gør, at når kode pakkes til publicering, vaskes alt fra at gøre udvikleren glad til i stedet at møde brugernes behov. I mit tilfælde kørte jeg med Yahoos YUI Compressor. Mange, der kører med udviklerværktøjet Visual Studios projektskabeloner til ASP.NET MVC, vælger at køre med automatisk bundling (sammenlægning af filer) og minificering. Automatikken er i det mindste bedre end at lade være.

Byggescripts fungerer fint til små teams, men er ikke perfekt, hvis man arbejder med kontinuerlig integration/opdatering. Så er det nødvendigt at bygge det ind i sin byggeserver, eller hvor i arbejdsflowet det nu kan tænkes at passe ind.

Billede 65: Minificering indgår i Cloudflares gratisabonnement.

For den, der kører Wordpress, kan man evaluere diverse tilføjelser, eller det kan være et tilvalg for den, der har CDN/indholdsleveringsnetværk, der fronter ens websted. Har man brug for manuelt at minificere filer, kan du gå til webtjenester som Minify Code.

Det eneste højst gyldige modargument, jeg har hørt indtil videre, er, at hvis ens websted sender alle tekstfiler komprimeret, er netop indsatsen med minificering ikke lige så afgørende. Komprimering går, højst forenklet, ud på at finde mønstre, der teknisk kan beskrives. Et sådant mønster er 20 tomme linjer i HTML-koden, eller at hver linje indledes med masser af mellemrum til indryk. I de tilfælde vil komprimeringen gøre en del nytte. Hvis du kun vil vælge én indsats med, hvordan du bearbejder tekstfiler, synes jeg, at du prioriterer komprimeringen højere.

Og nej, det er ikke synd for udviklere, hvis man gør koden mindre læsevenlig. Udviklere løser gerne deres egne problemer først, og der er et flertal tjenester til at gøre kode læsevenlig igen. Blandt andet under navne som "HTML Formatter", "Online Javascript beautifier" til Javascript-kode og "Format CSS Online" til CSS-kode.

Nu burde alle kunne være tilfredse – samtidigt :)

Send tekstfiler komprimeret

En meget stor andel af webben består af tekstfiler. Det kan være HTML til indhold, der skal vises i webbrowsere. Formgivningen på websteder understøttes af CSS (også kendt som stilark), som også er "almindelig" tekst. Det samme gælder Javascript, der hjælper med blandt andet interaktion. Dertil er der masser af andre filer i tekstformat. Man kan argumentere for, at alle filer består af tekst, men det ignorerer vi lige nu.

Hvorfor komprimere?

Praktisk talt alle tekstfiler har overflødig information. For webkode kan det være, at webudvikleren har beholdt en pæn formatering (fuld af mellemrum m.m.) for at den skal være letlæselig, men selv i løbende tekst er der ofte gentagelser eller sådant, der kan pakkes sammen af en smart komprimeringsalgoritme.

Pointen med komprimering er at gøre ting mindre. På webben komprimeres tekst, inden den sendes til en besøgende, med hjælp af Gzip, netop for at filen skal være så lille som mulig og tage så kort tid som muligt at overføre. Man forsøger at tilbyde en så hurtig oplevelse, som man kan.

Hvordan komprimerer jeg i Wordpress, eller i .NET?

Vil du eksperimentere, kan du tjekke efter tilføjelser, der gør komprimeringen for dig. Til Wordpress er der en fil i webstedets hjemmemappe, den har det underlige navn .htaccess og håndterer blandt andet indstillinger for komprimering.

På .NET-platformen kan man indstille dette i sin web.config-fil for webstedet.

Følge webbriktlinjer.se

Svenske myndigheder har udarbejdet Vägledning för webbutveckling, ofte kaldet webbriktlinjer.se, for at etablere en standard for webudvikling inden for den offentlige sektor. For dig, der har været med et stykke tid, er dette den nye udgave af det, der tidligere hed 24-timmarsvägledningen, dengang mange af os fik mase om, at det ikke var ok, at myndigheder slukkede for sit websted efter kontortid.

Gab, hvem bekymrer sig?

Selv den, der ikke har med offentlig sektor at gøre, kan have nytte af de hjælpsomme tips, der er i vejledningen. Især i betragtning af, at de fleste punkter er blevet drøftet af landets fremmeste inden for alle tænkelige retninger af webudvikling. Hvis du ikke i dag har valgt en standard for, hvordan webstedet skal fungere, er dette en fremragende begyndelse.

Vejledningen er der af en grund. Det er en måde ikke internt at gå i stå i diskussioner som "men sådan har vi jo altid gjort", eller at man ved usikkerhed køber nogens argument med hud og hår.

Der, hvor jeg arbejder, har vi en masse dårlige vaner og organisatoriske egenarter. Blandt andet er jeg træt af konstant at forklare, hvorfor man ikke skal åbne links i nyt vindue. I stedet for at argumentere plejer jeg nu at henvise til vejledningen, i dette tilfælde retningslinje nr. 97 om, at tilbageknappen skal fungere:

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, retningslinje 97⁷⁶

Hvis man åbner links i nyt vindue, kan man ikke gå tilbage i webbrowseren. Brugerne bemærker ikke altid, at et nyt vindue er åbnet, hvilket bidrager med brugervenlighedsproblemer helt unødvendigt.

Nu behøver man måske ikke følge alle retningslinjerne så nidkært, at man stopper al udvikling og memorerer alle retningslinjer. Dog er det en god idé at vælge nogle, man altid følger, og hvis diskussion opstår om, hvad der er "best practice", synes jeg, man følger vejledningens anbefaling, hvis man ikke har ekstremt gode grunde til at lade være.

For din bekvemmelighed er retningslinjerne desuden prioriterede, så du ved, hvad der er vigtigst. Den første retningslinje, som er prio 1, er faktisk at følge tilgængelighedsstandarden WCAG 2.0 niveau AA, hvilket vi allerede har taget op i aktivitetslisten.

Filers levetid default til 30 dage

Inden man begynder at jage hundrededele af et sekund på at overføre materiale til en bruger, bør man først læne sig tilbage og tage en mundfuld frisk luft. Hvad kan være bedre end en hurtig overførsel? Jeg ville nominere en overførsel, der ikke behøves. Noget, der ikke finder sted, burde være uhyre meget hurtigere end det, der sker.

Mit forslag er, at filer, man ikke regner med skal ændres i lang tid, automatisk skal have mindst 30 dages forventet levetid. Hvorfor netop 30 dage? Det er ikke meningsfuldt at sætte 20 år, da webbrowserne automatisk tømmer deres cacheminder med jævne mellemrum – 30 dage duer fint.

Det, man håber på, er, at en tilbagevendende besøgende allerede har en stor del af webstedets filer i webbrowserens midlertidige hukommelse (dens cache). Ved et genbesøg vil uændrede filer ikke sendes til den besøgende, men kun dem, der er ændrede, eller som ikke blev downloadet ved forrige besøg (kan jo være en anden underside end ved foregående besøg).

Det er en del af den skjulte information, som webserveren overleverer som instruktion til webbrowseren ved et besøg.

Hvilke filer kan leve længe i webbrowserens cache?

Det her er naturligvis ikke magi, det er heller ikke en sølvkugle. Man skal bruge hovedet, alternativt begynde i den forsigtige ende af disse muligheder. Der er filer, der næsten aldrig opdateres. Logoer for eksempel, eller favoritikoner.

Inkluderer du Javascript-rammeværket Jquery version 2.1.3, vil den fil sandsynligvis aldrig blive opdateret, derimod erstattet af en nyere version. Med andre ord kan du roligt sætte 30 dages levetid på filer, hvis filnavn indikerer deres version.

Ulempen er dog, at dette skal gøres med eftertanke, ellers kan der opstå lidt uønskede bieffekter i webdesignet. Mange filer på et websted har interne afhængigheder, for eksempel får man oftest udseendet på webstedet i en pakke. Så gælder det, at hele pakken opdateres, og alle indgående filer får nye adresser.

Præcis som med Jquery bør du eller dine udviklere arbejde med versionsnummerering på filer, der er en del af webdesignet.

En anden ting at være opmærksom på er, hvordan en billedbank leverer billeder direkte ud på dit websted. Hvis billederne opdateres i værktøjet, men filnavnet er identisk før og efter opdateringen, kan du ikke regne med, at ændringen slår igennem. Derfor er det ikke bare at hacke lang levetid ind på et system, der ikke er klart. Det kan du afklare med din webudvikler (eller dig selv).

Okay, men hvis jeg nu panisk skal have et nyt logo ud?

Skift navn på filen, og sørg for, at den omdøbte fil bruges på webstedet. Sværere end det er det ikke. Psst! Hvis din omdøbte fil udelukkende bruges via en uændret CSS- eller Javascript-fil, kan de også have behov for at omdøbes. Betragt det som en pakke af afhængigheder.

Sætte levetid i Wordpress (Apache) og i .NET

Som så mange andre tekniske indstillinger for Wordpress gøres dette i filen .htaccess, der ligger i webstedets hjemmemappe. Det kan være, at den er skjult for det program, du bruger, når du leder efter den, det indledende punktum er UNIX' måde at sige, at en fil skal skjules.

Kører du derimod med Microsofts .NET-platform, kan du vælge, om du indstiller det via din web.config-fil i webstedets hjemmemappe, eller om du laver indstillingen i webserveren Internet Information Server.

Fornuftige adresser

Der er masser at tænke på, når man udformer en fornuftig URL-struktur (URL – Uniform Resource Locator, URL og webadresse er det samme). Til at begynde med skal den være læsbar, så man forstår, hvem der er afsender, og hvad indholdet er.

Hvad en URL ikke skal indeholde…

Men det er måske enklere at forklare, hvad man skal lade være med? En ting, vi ser stadig sjældnere på det offentlige web, er sessionsunike informationer i adressefeltet. Det er et brugervenlighedsproblem, hvis den adresse, du har i adressefeltet, ikke kan sendes til en anden for at se præcis det samme, som du så på den adresse. Her skal man virkelig tænke sig om, når det gælder indloggede tjenester på webben, så adressen kan bruges til at give support, ikke byder ind til sikkerhedshuller, med mere.

Et andet problem med sessions-ID i URL'er er, at søgemaskiner vil få nye adresser ved hver indeksering, og det kan de ikke lide, at der er masser af adresser til et og samme indhold. En måde at håndtere adresser, der er varianter af en hovedadresse, er det, der hedder kanonisk adresse. Så angives det i metadata i sidens kildekode, hvilken adresse der er originalet, altså den kanoniske adresse, som er den, man beder søgemaskiner om at indeksere i stedet.

For ikke at skabe problemer med brugervenligheden skal man lade være med understregninger og mellemrum. Det gælder i de fleste tilfælde også filnavne til filer, der uploades og bliver tilgængelige på webben, som dokumenter og billeder. Grunden til dette er, at en udskrevet adresse, der bliver klikbar på webben, ofte er understreget, da er det svært for den, der læser adressen, at være sikker på, om det er understregning eller mellemrum. I stedet skal man konsekvent bruge bindestreg til mellemrum og læsbarhed.

Store eller små bogstaver i en URL?

Man skal gerne lade være med at bruge store bogstaver. En af grundene er, at man udsætter sin bruger for den kognitive byrde at skelne mellem små og store bogstaver – oftest unødvendigt. Man bør konsekvent køre med små bogstaver.

Hvor dynamisk en adresse finder man sig i?

Du har sikkert set adresser, der har et spørgsmålstegn i sig, fulgt af en masse ord og lighedstegn? Det er, hvad der plejer at hedde en dynamisk adresse, hvor modsætningen er en friendly-URL, der i stedet har skråstreger og en intern mappestruktur – ofte med forældre og børn.

En meget dynamisk adresse – med tre eller flere forespørgselsparametre – kan forvirre søgemaskiner, ud over at de oftest er mere svært forståelige for mennesker. Helst skal du undgå dynamiske adresser.

Kvalitetsindikatorer for en URL

Nedenstående ti punkter er hentet fra bogen Webbstrategi för alla, der er en mere grundig gennemgang, end hvad der er meningsfuldt i denne bog.

1. Være udformet til at kunne bestå over meget lang tid.
2. Angive, hvem der er afsender.
3. Beskrive, hvad der er på adressen.
4. Være så kort som mulig, ikke indeholde uvæsentligheder og være enkel at memorere eller læse op over telefon.
5. Følge navnegivningsstandard, det vil sige ikke indeholde specialtegn, ingen store bogstaver osv.
6. Have eksisteret et stykke tid, det er et tegn på seriøsitet for en søgemaskine.
7. Indeholde noget unikt, med andre ord skal der ikke være flere måder at nå præcis det samme indhold.
8. Være funktionel. Hvis adressen er hierarkisk, skal det gå at slette dele af adressen for at nå et højere niveau i strukturen.
9. Give korrekt statuskode ifølge HTTP. Mangler siden, er det 404, der gælder, er den flyttet, skal man videresende med status 301.
10. Have en form for stavekontrolfunktion, så den klarer fejl som www som præfiks, med eller uden afsluttende skråstreg osv.

Mange af disse potentielle problemer fanger du automatisk med værktøjet Optimizr.com, men jeg anbefaler altid at lave manuelle kontroller, når tid til refleksion prioriteres – gerne kvartalsvis.

Responsiv typografi

Har du tjekket alle dine undersider igennem på en mobil eller anden lille skærm? Sandsynligvis ikke. Gør man det, vil der sikkert dukke en og anden overskrift op, der forårsager, at man skal scrolle til siden for at kunne læse hele ordet, da det svenske (og danske) sprog er opbygget af sammensætninger af ord.

Det her problem gælder primært overskrifter, da de er af større størrelse end brødtekst, derfor tager hvert bogstav mere bredde i beslag, og lange ord får ikke altid plads. Men tænk gerne på tilgængelighedsaspektet, at visse af dine brugere sandsynligvis kører med forstørret tekst, så det, der gælder på din skærm, afspejler ikke nødvendigvis alle andres situation.

Bløde bindestreger til orddeling ved behov

Løsningen på problemet er at indsætte bløde bindestreger, som til forskel fra almindelige bindestreger kun deler et ord, hvis pladsen kræver det. Det mest oplagte eksempel er vel hovedoverskriften set på en mobils skærm, men det her kan lige så godt optræde som "elevatortekst" – altså et ord per linje – hvis man har smalle kolonner i sit design, når det ikke vises i fuldskærm på en computerskærm.

En blød bindestreg kan skrives manuelt ind i ordet, hvor du vil lave en eventuel orddeling, skriv bare ­, som står for soft hyphen. For eksempel:

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

Har du uheld, virker det ikke i dit websystems almindelige tekstfelter, så må en udvikler sørge for, at man kan skrive HTML også i disse tekstfelter. Ofte er problemet, at systemet forsøger at konvertere &-tegnet bort, hvilket ødelægger din bløde bindestreg.

Værktøjer til dette er noget mere omstændige end ellers (indtil videre). Du kan tjekke siders vurdering på textalyser.net, som fungerer bedst med engelsk tekst, men du får også et overblik over, hvor lange ord du har i en tekst.

En anden løsning for dig med en funktionsrig egen søgemaskine er at tvinge den til at rapportere, på hvilke sider på dit websted den finder lange ord. Præcis hvor lange ord der fungerer, er svært at svare på, men du vil nok gerne have dem ordnet efter, hvilken længde der er (og glem nu ikke at have marginal, så dem, der kører med forstørret tekst, ikke glemmes).

Google Pagespeed Insights fanger problemet i sin brugervenlighedskontrol under "Tilpas størrelsen på indholdet til visningsområdet", når tekst ikke får plads inden for synlig flade. I skrivende stund – i version 2 – synes den ikke at kunne advare om dette også, når det gælder scenariet, at brugeren har forstørret teksten et eller flere trin.

Indhold publiceres som strukturerede data

Praktisk talt ethvert websted har information, der er af en struktureret type, men det er ikke altid, det publiceres på en struktureret måde. Jeg taler her om indhold, som vi som mennesker nemt kan identificere som en kalenderbegivenhed – som en sommerfest – eller en geografisk placering, at "Stockholm" sandsynligvis refererer til den svenske hovedstad snarere end det lille hul i USA.

Denne egenskab til at forstå, hvad indholdet er eller refererer til, har computere ikke. Du, der er interesseret i søgemaskineoptimering, har nok ikke overset alt snakken om RDFa. Det er en af teknikkerne til at opmærke indhold, så en søgemaskine forstår. Så selv en maskine forstår indholdet.

Microdata, Schema.org og Microformats.org

Google blev træt af, at Microformats.org var så langsomme med opdateringer, og lancerede da Schema.org sammen med Microsoft, Yahoo med flere.

Tager du et kig på webstedet, indser du, at næsten al form for indhold, du publicerer, kan udgives i et struktureret format. En af fordelene er, at man kan få mere plads i Googles træflister, for eksempel har du sikkert set anmeldelser og små kalendere i træflisten hos Google. Præcis på hvilken måde det vises, er noget, i hvert fald Google konstant eksperimenterer med. At opmærke, hvem der har forfattet en artikel eller blogindlæg, var noget, de kun viste i et år, inden de fjernede det.

Søgemaskineoptimering, men ikke nødvendigvis højere ranking

Egentlig anses det ikke blandt søgemaskineoptimører, at ens websted klatrer højere i Googles træfliste, hvis man har strukturerede data. Derimod får man i flere tilfælde mere plads i træflisten, hvilket absolut er på bekostning af dem, der ligger under ens side i listen.

Hvad der er anbefalet mængde strukturerede data, afhænger lidt af, hvad dit websted har for type virksomhed, men naturligvis skal din kernevirksomhed beskrives struktureret, hvis det er muligt. For eksempel, hvis du lister modtagelser for kunder, angiv deres geografiske position, kontaktoplysninger m.m.

For at verificere, at dine strukturerede data er korrekte, kan du teste med Google Structured Data Testing Tool⁷⁷.

Henvises til filer, der ikke findes eller ikke fungerer

Bare fordi en webside indlæses uden at give en fejlmeddelelse, betyder det ikke, at alt er fryd og gammen. Bag kulisserne gemmer der sig undertiden fejl i nogen af alle de filer, der behøves, for at websiden skal blive komplet, som den er tænkt.

Der er flere årsager til disse fejl. Mest almindeligt, når jeg har set dem, er, at webudviklerne har fumlet en fil bort, når man har løftet ændringer fra udviklingsmiljøet til produktionsmiljøet. Så forårsager man en 404-fejl på en eller et fåtal filer.

Det kan også være et serverfejl, der indtræffer, det vil sige noget i 500-serien. På visse websteder skabes stilark, Javascript og endda billeder af webserveren. De er altså ikke statiske filer på en harddisk. Hvis en fejl i denne skabelse indtræffer – mere eller mindre midlertidigt – vil serveren dels ikke sende filen, men også skabe en fejl.

Men hvorfor er dette et problem?

Grunden til, at dette er et problem, hænger sammen med, hvilken fil der mangler eller ikke fungerer. Sig at det er stilarket til udskrift, så er det få, der vil opdage det, men det gør udskrifter dårligere, end det er tænkt.

Dertil risikerer alle typer fejl at give dårlige signaler til søgemaskiner, når de skal ranke dit websted. Konstant at have problemer med webstedet indgyder ikke tillid hos brugerne.

Hvordan finder jeg disse fejl?

De avancerede måder er ofte kun tilgængelige for større organisationer, men vi begynder her. Hvis du har adgang til webserverens logfiler, kan du ofte få detaljeret indsigt i serverens syn på sit velbefindende. Disse logfiler vil du helst slippe for at læse som tekst, så tjek gerne, hvilke analyseværktøjer der er tilgængelige, måske har du Event Viewer i Windows Server, en loganalyse som Kibana eller Splunk. Måske kan du få logfilerne og køre dem ind i et værktøj til preparering af data som Tableau.

At inspicere logfiler og overvåge fejl bør interessere alle, der ikke er teknofober. Det er en indikator for, hvordan et websted har det, om det er udviklet på en kompetent måde, og om dets drift fungerer.

Dig med websted på webhotel

Har man et mindre websted, er man ofte noget mere begrænset i, hvilke valg man har af analyse. Men det er ikke noget at hænge med læben over. Dine udgifter til at holde webstedet kørende er ubetydelige sammenlignet med, hvad ovennævnte værktøjer koster :)

Ud over det oplagte i at være opmærksom på mærkværdigheder, når man selv agerer bruger på sit eget websted, er der værktøjer, der tjekker dette for dig. Enklest er de netværksværktøjer, der er i alle moderne webbrowsere. Dem finder du under den respektive webbrowsers udviklermenu. Der ser man alle filer, der indlæses til en sidevisning, om de genererer fejl eller ej. Det er primært HTTP-serierne 400 og 500, du skal tænke over, har du god tid, er det værd at overveje 300-serien også, da det ikke er effektivt at anrope filer, der videresender.

Svagheden ved den metode er, at man laver stikprøver, en side ad gangen, og man skal gøre det manuelt. Et andet værktøj, der gør dette lidt mere automatiseret og på masser af sider på dit websted, er gratisværktøjet Optimizr.com – med ulempen, at du skal vente på de rapporter, de sender ud af og til. Optimizr.com fungerer til ret passiv webanalyse og kan være en god indgang for de fleste.

Forkerte statuskoder sendes – webstedet lyver

Det hører til god opførsel at svare ærligt og konkret på spørgsmål. Desværre er det ikke altid, dette prioriteres, når vi lader computere kommunikere med hinanden.

Praksis for HTTP (protokollen, der transporterer websider over internettet) er, at man taler åbent om, hvorvidt noget gik godt (200 Ok), om materialet er flyttet (301 redirect), forsvundet (410 Gone) eller lignende. For den mere useriøse er der endda statuskoden 418: I'm a teapot, hvis din smarte tekande har behov for at kommunikere over internettet :)

HTTP-statuskoder for at maskiner skal forstå hinanden

For at webben skal fungere optimalt, og maskiner forstå hinanden, er det nødvendigt at følge disse opsatte regler for kommunikation. For ikke-menneskelige brugeres skyld, som Googles crawlere og andre botter, skal man følge HTTP's statuskoder, punktum. Ellers kan de ikke vide, om en adresse eller side er ophørt med at eksistere, aldrig har eksisteret eller ikke kan findes. Hvordan skal ellers en maskine finde ud af, hvad der er sket, de kan jo ikke læse og forstå tekst, noget der ikke engang er nødvendigt, hvis man blot sender den rigtige kode, den rigtige statuskode.

Sender du for eksempel statuskode 301 eller 302, instrueres botter om, at adressen permanent eller midlertidigt er flyttet til en anden adresse. Slet ikke svært, egentlig.

De største afvigelser på dette område er, hvordan man vælger at fortælle, at noget gik galt. I 2015 lavede jeg et tjek af Sveriges kommuners måde at håndtere 404-fejlmeddelelser. Testen gik ud på at evaluere, om de sendte 404 som meddelelse på en åbenlyst forkert adresse. 6,2 procent af de 290 kommuner sendte "200 Ok" i stedet for "404 Not found". De lader altså som om, at ingen fejl er sket.

Det bliver et problem lidt afhængigt af, hvilket indhold man viser i forbindelse med sin 200 Ok-side. At præsentere sin startside i stedet for en fejlmeddelelse er en naiv form for velvilje, men stadig ret almindeligt. Så ender man med at få meget mange alternative adresser til sin startside, hvilket i SEO-sammenhæng kan straffe sig, afhængigt af om man tror på straf for duplikeret indhold (og har glemt at sætte kanonisk URL i sidens kildekode).

Hvordan man finder fejlagtig fejlhåndtering

En ting, du kan gøre, er manuelt at skrive en forkert adresse ind og se, hvad der præsenteres. For at tjekke, hvilken statuskode serveren giver, kan du for eksempel tjekke i netværkspanelen, der ofte følger med moderne webbrowsere til computere. Vil du have fuld kontrol over HTTP, er der Firefox-tilføjelsen Tamper Data⁷⁸.

Tænk også på, om der er andre systemer, der bidrager til webstedet. For eksempel har ofte større organisationer specialiserede systemer til dokumenthåndtering, mediefilhåndtering med flere, og så skal disse også testes.

Til en mere passiv webanalyse kan du tilmelde dit offentligt tilgængelige websted til Optimizr.com og afvente de rapporter, der sendes, når de føler, de har tjekket dit websted færdigt.

Kan webstedet crawles og indekseres

At ens websted ikke er teknisk tilgængeligt, kan være præcis, hvad man er ude efter, men det gælder sjældent for et offentligt websted. Der er pointen i stedet, at alle bør være velkomne, både mennesker og maskiner, til størstedelen af indholdet.

Forhindringer, der er, kan være af forskellig art. Dels den bløde variant, hvor man beder om at blive ladt i fred, alternativt forsøger at instruere botter om ikke at tage siden med i indeks. Dertil er der den kæmpehøje forhindring om, at adgang mangler.

Lavere forhindringer, der kan være problematiske

Der er et flertal mindre dramatiske måder at forsøge at fortælle maskiner, hvordan man ønsker sit websted behandlet. En klassiker, der styrer hele webstedets indstillinger, er at have en fil kaldet robots.txt, der placeres i webstedets hjemmemappe. I robots.txt plejer man at angive, hvilke mapper søgemaskiner og andre maskiner skal lade være med, hvor webstedets sitemap er placeret, med mere.

Hvorvidt en side skal tages med i en søgemaskines indeks, kan også detailstyres gennem sidens egne metadata i HEAD-taggen. Der kan man også placere metadata, der fortæller om sidens kanoniske forhold inden for webstedet, det vil sige om siden er en variant af en anden. I så fald angives den anden, vigtigere, sides URL som canonical-URL. Det er en måde at kunne have flere adresser til potentielt det samme indhold, men at man fortæller, hvilken hovedadressen er.

Man kan også på links have instruktioner om, hvordan maskiner skal opføre sig, som at links ikke behøver følges. Det gøres gennem attributtet rel="nofollow" på det respektive link.

For mange år siden, i 2008 nærmere bestemt, kom det websted, jeg byggede på for Västra Götalandsregionen, ud for at blive ekskluderet fra Google så småt under min ferie. Efter en masse frustration og fejlsøgning viste det sig, at en opdatering til softwaren bag webstedet automatisk havde sat et ønske op om ikke at blive indekseret. Google gjorde desværre, som softwaren fra Microsoft bad om. Det er naturligvis godt, jo tidligere man opdager disse problemer.

Højere forhindringer for webadgang

Dertil er der de mere strenge måder at lukke maskiner ude på, og det er at blokere dem eller kræve indlogning for at få adgang. Du har sikkert oplevet at få en indlogningsdialog op, når du surfede på webben, men man kan ikke altid regne med overhovedet at få chancen for at forsøge at logge ind. Undertiden bliver man blokeret, fordi man ikke sidder inden for det godkendte netværk, ikke har den rette IP-adresse, eller hvad nogen nu har sat op af krav.

Værktøjer til at opdage dette problem

Et smart værktøj er SEO Doctor⁷⁹ som tilføjelse til Firefox. Hvis siden ikke kan indekseres, vises et rødt advarselssymbol, der hvor du har placeret tilføjelsen i din webbrowser. En anden måde at lave stikprøver er Pingdoms Full page test⁸⁰.

Skal du lede efter adgangsproblemer, er det blandt andet HTTP's statuskoder 401 Unauthorized og 403 Forbidden, du er ude efter. Det er ikke umuligt, at dette logges på din webserver, men har du dit websted på et webhotel, har du måske ikke adgang til denne log.

Optimizr.com har dette med i sine rapporter, men da forudsat, at de har indekseret hele dit websted, ellers må du lede efter andre alternativer.

Links til sider, der ikke findes

Det er ikke kun, når sider mangler på dit websted, du skal bekymre dig. Hvis du linker til en side på andres websted, og de kasserer den, går det ud over dine brugere, der følger det link.

Ikke at have styr på de sider, man linker til, er blevet en stadig mere hed kartoffel inden for søgemaskineoptimering, og løsningen er ikke at holde op med at linke eksternt. Snarere skal du begynde at følge op på, at de links, du har, faktisk fungerer. Har du ikke styr på dine eksterne links, giver det et tydeligt signal til søgemaskiner om, at du ikke arbejder aktivt med dit websteds allerede etablerede materiale, og at man bør betragte dit websted med mistro. Regn med dårligere ranking.

Begynd at tjekke eksterne links

Hvis du har lyst til at tjekke dette manuelt, hvilket vi alle bør gøre af og til, så begynd med de sider, der bruges mest på dit websted, eller dem du synes er vigtigst. Tjek alle udgående links igennem, at de peger på fungerende sider og med forventet indhold. Ikke sjældent har dem, vi linker til, flyttet det materiale, linket refererede til, eller ligefrem fjernet det. Se din linkpleje som at rode i haven. Du bliver beskidt om hænderne og får krum ryg, men det betaler sig på sigt.

Vil du i stedet tjekke de eksterne links efter, hvor populære de er at klikke på, kan det være noget, din webstedsstatistik allerede sporer. Outgoing links logges i hvert fald automatisk i mine konti på Google Analytics.

Den ambitiøse og automatiserede kontrol

Vil du gøre dette i massiv skala, kan du have nytte af at have egen søgeteknologi. Har du en organisationsintern søgemaskine, har den sikkert mulighed for at indeksere også webstedseksterne links og kan da samle på sig 404-fejl med mere. Som du nok forstår, vil søgemaskinen ikke kunne forstå, om det er "forkert" indhold, linket peger på, så lige meget hvad skal du lave manuelle indsatser af og til.

Er der stor interesse for webanalyse og overblik, kan du sikkert regne på omkostningen ved, at nogen udvikler en semi-automatisk kontrol. Tag udgangspunkt i webstedets sitemap, download alle sider, og filtrer alle organisationseksterne links frem – derpå tjekker du, om linkene giver andet end HTTP-statuskode 200 Ok.

Optimizr.com har dette med i sine rapporter, men det forudsætter, at de har bemøjet sig med at tjekke hele dit websted.

Serveren giver fejlmeddelelse i 500-serien

Fejlmeddelelser i 500-serien er udviklerne som regel skyldige i, eller også er det en teknisk driftsforstyrrelse. Uanset hvad er det værd at stoppe op og omgående tage fat i disse problemer. Jeg kan ikke forestille mig noget møde, jeg ville have været i, hvis jeg havde fået at vide, at vi havde HTTP-status 500 på vores websted.

Ud over det åbenlyse problem, at det rammer dine brugere, giver det et dårligt signal til søgemaskiner. Dit websted synes ikke at være robust eller pålideligt nok at sende besøgende til. Med andre ord bør du have styr på disse fejl, selv om de aldrig indtræffer, når der er højt tryk på dit websted.

Det behøver ikke at være hele sider, der er ramt af serverfejl, dele af det, der kræves til en sidevisning, kan hver for sig give serverfejl. For eksempel hvis dit stilark genereres på webserveren, eller måske hvis du har en hjemmelavet statistikløsning, der skaber skjulte billeder.

Hvornår kan man forvente sig HTTP-status 500?

Det kan være en idriftsætning af ny kode, der er gået skævt. Så hvis du ved med dig selv, at det er idriftsætningsdag, kan du måske falde lidt til ro, inden du begynder at jage dem, der forhåbentlig allerede arbejder på en løsning.

Det kan også være en overbelastning af webstedet. En sådan lejlighed, jeg selv har gennemlevet, var, da en langsom ekstern tjeneste gjorde, at hele webstedet gik ned. Du kender det med, at ingen kæde er stærkere end sit svageste led. I det tilfælde måtte webserveren vente på svar fra en alt for langsom ekstern tjeneste. Da en webserver ikke kan håndtere uendeligt mange samtidige brugere, begynder den at afvise nye besøgende ved at svare med Error 500 det meste af tiden. Grænsen for netop det websted gik ved ca. 140.000 sidevisninger per dag.

Overbelastningsangreb?

Hvis det nu er et angreb, man udsættes for, eller anden ikke-legitim trafik, kan det være en forvarning om at tage kontakt med dem, der håndterer webstedets infrastruktur. I bedste fald er der et filter at sætte ind for at beskytte webstedet, men alligevel slippe almindelige brugere igennem.

For mange år siden blev der udført et "bus" mod Polisen.se fra masser af websteder. De ville give igen i anledning af aktionen mod serverrummet, hvor The Pirate Bay havde sine servere. Angrebet gik ud på, at man indlæste en tung PDF-fil fra polisen.se ved hver sidevisning på de egne websteder. På den måde blev alle de besøgende på disse websteder også besøgende (uvidende) på politiets websted – som periodevis gik ned.

Løsningen var ikke nødvendigvis at fjerne PDF-filen, da alle 404-fejlene måske i stedet ville sænke webstedet, derimod kunne man sikkert have tjekket i netværket, hvor broderparten af trafikken kom fra. Hvis man inden webserveren havde filtreret trafik fra webfora som hamsterpaj.net med flere, ville webserveren have fået lidt pusterum. Præcis hvordan denne episode endte, husker jeg ikke, men disse kampagner har tendens til ikke at være så langvarige.

Værktøjer til at holde styr på 500 Internal Server Error

Google Search Console har en aldeles fremragende visning af fejl i både 500- og 400-serierne. Du kan endda få e-mail, hvis der opstår uventet mange fejl. Endnu en grund til, at alle webansvarlige skal registrere sig på Google Search Console (og Bings pendant naturligvis).

Hvis du kan få statistik over serverfejl for en længere tidsperiode, er det interessant at overvåge eventuelle tendenser af fejl. Det er lidt surt at indse, at webstedet en dag sank til bunden på grund af øget kompleksitet bag kulisserne, og at det havde råbt om hjælp via error 500-meddelelser i flere måneder.

Vil du lave manuelle stikprøver, fungerer Pingdoms Full Page test godt.

God og passende lang sidetitel

Sidetitlen er det, der synes øverst i webbrowservinduet, på computere i det mindste. Det er ikke nødvendigvis det samme som hovedoverskriften, men der plejer at være store ligheder. Det er også det, der bliver den klikbare tekst på søgemaskinens resultatside og vil være navnet i webbrowserfaner, bogmærker osv.

Hvorfor sidetitlen er så vigtig

Sidetitlen er en af de vigtigste dele at arbejde med, for at du kan nå ud på en søgemaskine og overbevise folk om at gå ind på netop dit websted. Desuden skal de ord, folk søger efter, gerne indgå i din sidetitel, da det er en af de stærkeste rankningssignaler, du har at spille med.

Med tanke på antallet af faner, folk har i deres webbrowsere på computere, indser du hurtigt, at du har 1-2 ord til at navngive siden i netop det brugsscenarie. Google viser dog betydeligt flere tegn. Præcis hvor mange er noget, de har tendens til at justere. Uanset Googles syn på sagen skal du skrive fornuftige sidetitler, der er tilpasset mennesker. Med andre ord kan du have følgende tommelfingerregler:

• Tiltænkte nøgleord skal indgå tidligt i sidetitlen, så man ikke skal læse langt for at finde ud af, at det er en relevant side.
• Sidetitlen skal være ret kort, i skrivende stund er det 50-60 tegn, der anbefales, men da har man nok ikke tænkt på andre typer interaktion. På virkelig små skærme, man har på lidt afstand – smarture blandt andet. Om det overhovedet er visuelle grænseflader, det handler om i fremtiden.
• Den skal være unik inden for dit websted, hvordan skal ellers en besøgende kunne skelne mellem to sider, hvis de har identisk sidetitel?
• Ikke automatisk tage webstedets navn med i sidetitlen, i hvert fald ikke hvis det er for at gøre det let at finde webstedet ved søgning på dets navn (der har du nok ingen konkurrence at tale om).

Til at følge op på dette kan du bruge Google Search Console. Der er en visning, hvor du kan se, hvilke sidetitler der forekommer mere end en gang på webstedet (af det, Google kender til om dit websted, altså).

Rimelige størrelser på dine filer

Ordet "rimelig" er præcis så vidunderligt vagt som det svenske "lagom". Hvad en rimelig filstørrelse er, kan man vel ikke sætte et tal på, egentlig. Men jo større filstørrelse, desto længere tid tager de at downloade, både for dine besøgende og også søgemaskiner, når de vælger, hvad de skal inkludere i deres indeks.

Størrelsen på indholdet, HTML-filen altså, behøver du måske ikke at være så restriktiv med. Dels fordi det kan komprimeres ned til en tiendedels størrelse ved overførsel, men måske primært fordi det er en dråbe i havet sammenlignet med andre filer, vi har på vores websteder. Billeder, video og lyd tager derimod uhyre meget mere plads – især det, der er lagt der redaktionelt.

Det er nu, du har brug for et præstationsbudget

For at forsøge at råde bod på problemet med overfyldte websider, eller i det mindste sætte en form for målbar ambition op, kan man dokumentere kravene i et præstationsbudget. Det går i korte træk ud på at etablere og følge en retningslinje for, hvor tung og hvor langsom alt, der hører til en sidevisning, må være. At sætte krav op for en sides vægt er ret ligetil. Sæt en fornuftig værdi, hvor man har god marginal til, hvad folk finder sig i på det marked, webstedet henvender sig til. Sig for eksempel, at ingen side må veje ind på mere end 399 Kb. Der er masser af mere eller mindre smarte tricks, der gør, at man måske vil have undtagelser fra denne regel. Men begynd med en regel, og derefter må dem, der har lyst til at afvige fra reglen, argumentere for smarte teknikker som lazy-loading over for de krav, der stilles til webstedets alle undersider.

En udfordring at specificere acceptabel hastighed i sit præstationsbudget

Sammenlignet med en sides vægt er hastigheden lidt mere vanskelig at definere. Det, der tæller her, er den oplevede hastighed, da det er den individuelle oplevelse, der styrer, om brugeren mangler flow. Desuden har ikke alle de samme forudsætninger for hastighed. Blandt andet varierer kvaliteten af forbindelsen, noget jeg mærkede, da jeg alt for sent fik 4G. Jeg har ventet evigheder på "responsive" billedkarruseller med enorme højopløste billeder (til min lille skærm). Den oplevede hastighed påvirkes også af, hvor meget kraft der er i den enhed, brugeren har. Det påvirker, hvor mange designelementer webbrowseren orker at jonglere med for at vise siden.

Præcis som med sidens vægt synes jeg, man kan begynde med at gøre det enkelt for sig i sit præstationsbudget, men at man skal være forberedt på den ovenfor beskrevne problematik. For et websted, der kun henvender sig til brugere i Sverige, kan præstationsbudgettets krav være, at ingen side må tage længere end 10 sekunder at downloade komplet. Da målt fra en 3G-forbindelse inden for Sveriges grænser. Som en yderste grænse.

Beregn virkningen af dit præstationsbudget uden at forlade dit skrivebord

Vil du relativere dette og lave teoretiske målinger fra skrivebordet, kan du tjekke med Bredbandskollen, hvilke hastigheder folk har rundt omkring i landet. Så kan du hurtigt få et billede af, hvad dit præstationsbudget indebærer i praksis i Ekshärad midt ude i de värmlandske skove, eller for den, der venter på et forsinket tog i Bastuträsk – 10 mil fra nærmeste hamburgerbar i Västerbotten.

Krisekommunikation stiller lidt andre krav til præstation. Hvis du er en samfundsaktør, bør du for alles skyld også tage højde for, at det ved en krise kan være yderst vigtigt ikke at være ødsel. Ved kriser kan kommunikation via mobilnettet være det eneste logiske alternativ for størstedelen af de ramte og dem, der hjælper til. Mobilnettet er faktisk en endelig ressource. Dit kriseweb bør ikke sende en masse skrifttyper, højopløste versioner af logoet eller 2 Mb Javascript til at kunne tegne avancerede kolonnesystemer på forskellige store skærme. Hold det enkelt!

Filstørrelser i designet

Jo mere man ødsler med tunge filer til webstedets design, med stilark, Javascript, skrifttyper og designbilleder, desto mindre plads er der til redaktionelt indhold. Altså det indhold, den besøgende kom for at tage del af!

Det, der rammer din besøgende takket være dine udviklere og designere, kan sammenfattes i to kategorier; tekstfiler eller mediefiler.

Når det gælder billeder, er der masser af tricks. Blandt andet at vælge det rigtige format, at optimere dem og derpå køre ekstra ikke-destruktiv komprimering. Samme fremgangsmåde er der til video og lyd. Vær opmærksom på nye formater! Der lanceres konstant nye idéer og tricks, du kan drage nytte af. I 2015 bemærkedes det spøgefuldt navngivne projekt Piper Pied⁸¹, de komprimerer menneskers ansigter mindre hårdt, hvilket gør, at resten af billedet kan komprimeres hårdere, uden at det ser helt så slemt ud.

For dig med adgang til en Windows Server kan du installere Search Engine Optimization Toolkit⁸². Den software kan gennemgå hele dit websted og lister derefter filstørrelser, blandt meget andet. Men det indgår også i Optimizrs alle rapporter.

Ingen kopier af indhold

Der skal kun være én adresse til et unikt indhold. Sværere end det er det egentlig ikke. Men hvis du nu har dubletter af indhold, i hvert fald når det gælder websider, bør du angive dens "kanoniske adresse". Det indebærer, at man med metadata peger den side ud, der er oprindelsen eller originalet, den af alle varianter du vil have, at søgemaskiner skal indeksere. Det er, hvad der hedder dens canonical-URL, og det fungerer i hvert fald for HTML-filer.

At indholdet skal være unikt på en adresse, gælder mere end selve siderne, hvilket kan være let at overse, hvis man ikke graver teknisk. Undertiden snubler man over websider, der henter det samme Javascript-rammeværk to gange – men fra to forskellige adresser. Ud over at det er klodsete gjort af udviklerne, er det spild af de besøgendes forbindelse og et signal om ret lavt ambitionsniveau til søgemaskiner, når de skal vælge, hvilket websted der skal rankes højest.

Alt skal være så unikt som muligt

Noget, mange nok ikke tænker over, er, at alt skal være så unikt som muligt. Jeg kan grine lidt ad de websteder, der stadig har et oppefra-og-ned-syn på nøgleord på sit websted, at de altså har organisationens navn som nøgleord på hver eneste underside. Det fjerner lidt meningen med overhovedet at angive det nøgleord, ikke? Samme ting gælder for sidetitler. De skal være unikke for at blive brugbare på søgemaskiner, i favoritter, i webbrowsernes faner med mere.

Tænk på, at også dine beskrivelsestekster, der havner i meta-description, skal være unikke inden for webstedet.

Den suverænt mest almindelige variant af dette er dog kæmpestore organisationer og, hvordan de håndterer deres PDF-dokumenter på eksterne websteder. Da jeg arbejdede som webansvarlig for mange år siden, var det med skræk, jeg fik tal om, hvor mange kopier af dokumenter der lå og skvulpede i vores uploadmappe. Det værste er jo, at det ikke er let at sørge for, at alle bliver opdateret, når en ny version skal ud. Det er vel af den grund, man kan forstå, at Google bør ranke et websted ned, hvis man har masser af kopier af det samme dokument, billeder eller anden type materiale.

Tag hjælp af Google til et vist overblik

En googling på site:minsajt.se filetype:pdf kan i værste fald være det bedste overblik, du kan få over dokumenter, der er publiceret på dit websted. Så får du i det mindste en liste over det, Google kender til. Når det gælder billeder og video, er risikoen for dubletter måske mindre, men da kan du google udelukkende på site:minsajt.se for derefter at skifte til billeder samt video for et overblik. Bemærk, at det kan være andre adresser, der serverer mediefiler og dokumenter. For eksempel kommer mange af min arbejdsgivers dokumenter fra subdomænet alfresco.vgregion.se, med andre ord googler man på site:alfresco.vgregion.se for at få styr på det.

Værktøjer til at finde kopier af materiale

Først og fremmest kan du henvende dig til Google Search Console. Der er visninger, der advarer om identiske sidetitler og beskrivelsestekster. Som med så meget andet har også Optimizr.com dette med i sine rapporter.

Passende antal hovedoverskrifter

Der er anbefalinger fra webstandardorganisationen W3C at følge (dem, der skriver dokumentation om, hvordan webben burde fungere). Hvis dit websted er i den svindende skare, der følger kodestandarden XHTML, må den ikke have mere end én hovedoverskrift. En hovedoverskrift er det samme som det, der undertiden hedder H1, det skyldes, at det er dens HTML-tag, <h1> altså, den første blandt overskrifter.

Hvis du derimod følger HTML5, må du ifølge anbefalingen fra W3C have flere hovedoverskrifter, men det er anbefalet at have beskrivende kode omkring, for eksempel sektioner. I HTML5 kan altså en hovedoverskrift gælde inden for en delmængde af indholdet.

Hvis man i stedet tager udgangspunkt i brugerens behov, er det mest logiske ikke at have flere hovedoverskrifter. Ganske vist kan det ses som logisk at have nogle stykker, hvis tydelig og korrekt kode forklarer, at hovedoverskriften er for en delmængde af det, der vises på skærmen. Men samtidig er det ret centreret om den seende brugers behov.

Ok, hvordan gør jeg så?

Hav en eller yderst få hovedoverskrifter. Følger du XHTML, må du kun have én hovedoverskrift, ellers bryder du mod anbefaling for XHTML. Den oprindelige tanke bag XHTML var, at den skulle kunne behandles af maskiner ved at være kompatibel med XML-standarden. Inden for XML er struktur meget vigtigt, da den er mere maskinlæsbar end HTML.

Hvis dit websted i stedet følger HTML5-standarden, er det stadig anbefalet, at du har et fåtal hovedoverskrifter, måske helst kun en eneste. Hvorfor? Jo, i og med at siden sandsynligvis har en intern struktur med en overskrift, der er vigtigere end de andre, bør det rankningssignal fremgå for søgemaskiner og andre botter. Overskriftsstørrelse har ikke kun med typografi og tekstens størrelse at gøre, det er også din måde at veje overskriftens relevans for siden.

Bygger du en startside eller landingsside? Hav for al del en hovedoverskrift for den respektive del med egen call-to-action, men så skal du også indkapsle dem i egne sektioner. Det er ikke et frikort fra at følge praksis, eller at have en semantisk orden på din kode. Maskiner kan ikke læse og forstå indholdet, hvilket også gælder dem af dine besøgende, der tilfældigvis har en funktionsnedsættelse. Det gælder også mig, når jeg er træt, irriteret, lysfølsom, kognitivt nedsat og tømmermændsplagt dagen efter midsommer.

Men glem ikke at have en hovedoverskrift, mindst en skal du have!

Ud over at du kan gennemgå koden manuelt, kan du installere tilføjelser i webbrowseren. Webbrowsertilføjelsen SEO Doctor til Firefox klager, hvis du mangler en hovedoverskrift. Desuden klager SEO Doctor, hvis websiden mangler en underoverskrift, hvilket heller ikke skader at have, hvis du bekymrer dig om SEO.

Ha en (passende lang) beskrivelsestekst

Beskrivelsesteksten hedder undertiden meta-description. Det skyldes, at den er placeret blandt en websides alle andre overordnede metadata i kodens hoved, det der ligger i , hvis du vælger at vise kildekoden bag en webside.

Beskrivelsesteksten skal meget kortfattet beskrive sidens formål og indhold. Det med et naturligt sprog. Hver vigtig side på dit websted bør have denne type skjult information. Eller ja, så skjult er den faktisk ikke. Undertiden vises den under sidens titel i søgemaskinernes resultatside. Den er der for at bruges ved behov.

Længde og udformning af beskrivelsestekster

Beskrivelsesteksten skal være unik. Det skyldes, at man skal kunne skelne mellem beskrivelsestekster på et og samme websted.

Længdemæssigt skal du holde den under 160 tegn (tæl også mellemrum), hvis du vil have alt med, men som altid med tekst skal du have det vigtigste først i denne tekst. Samtidig bør du holde den over 80 tegn, hvis den skal blive brugbar. Nogen nedre grænse for, hvornår søgemaskiner ignorerer beskrivelsesteksten, er jeg ikke bekendt med. Det kan være værd at overvåge disse tal løbende med tanke på den stigende flora af enheder, vi bruger til at tage del af webben.

Angående hvordan man formulerer teksten, kan man følge kommunikative principper som AIDA (Attention-Interest-Desire-Action) eller KISS (Keep it simple, stupid). Det er naturligvis ikke muligt at skrive, hvor galt det skal være. Er du ikke vant til at udtrykke dig skriftligt, er det godt at finde en formel, der fungerer for dig.

Når det gælder værktøjer, er Google Search Console klart bedst. Der er en visning til at evaluere beskrivelsestekster, blandt andet om der er dubletter på et websted.

Medier skal have alternative tekster

Du har sikkert hørt, at man skal have alternative tekster til billeder på webben? Ellers gør man livet svært for dem, der ikke kan se. Nu er det ikke kun synshandicappede, der ikke kan se, også søgemaskiner lider af dette problem. Selvom software begynder at kunne "se", hvad billeder forestiller, er der lang vej, inden de forstår indholdet, som mennesker gør.

Du har nok regnet ud, at dette ikke kun gælder billeder. Også lyd og video har det samme problem. Så dukker en anden funktionsnedsættelse op, nemlig fraværende eller nedsat hørelse. Også her suppleres ambitionen om ikke at udelukke nogen med, hvad der giver god søgemaskineoptimering. Hvis indhold i en video er tekstet for døve og blinde, kan teksten oversættes og vises for endnu flere at tage del af.

Vi har alle en funktionsnedsættelse en gang imellem. Tænk dig selv siddende i en stille afdeling på toget, og du har glemt høretelefonerne derhjemme. Så bliver du glad for, at nogen har tekstet for dig.

Praksis for tekstning af mediefiler

Første regel er ikke at tekste noget, der er irrelevant eller trivielt i sammenhængen, det vil bare forstyrre. Så skal man hellere vælge en tom alternativtekst, hvilket ikke skal forveksles med slet ikke at angive alt-tekstens attribut. Ved at sætte for eksempel alt="" på et billedes HTML-tag fortæller man modtageren, at intet af værdi er at beskrive.

Uploader du video på Youtube, er der et indbygget tekstningsværktøj. Kører du med eget værktøj til at streame lyd eller video, er dette noget, du skal tænke over.

Når det gælder informationsgrafik, bliver det sværere. Så kan man have behov for at udlevere sine data som et alternativ for dem, der ikke kan se. Dataen skal være struktureret, så den kan bearbejdes af maskiner. Det er præcis, hvad man har tabeller til på webben. Samtidig gælder det at være bevidst om, at man ikke i alle situationer kan opfatte indholdet, hvis dataen er for kompleks. Så kan man i stedet vælge at tekste konklusionen af disse data.

Mange vælger i stedet for at lave billeder af diagrammer at publicere en tabel, hvor tabellen gennem progressive enhancement-teknik erstattes med et illustrativt billede. Der er en stor mængde Javascript-rammeværk til disse behov.

Vil du manuelt sikre, at du gør rigtigt, kan du bruge tilføjelser i webbrowseren, for eksempel til billeder har jeg SEO Doctor i Firefox. Stikprøver, når det gælder diagrammer eller andre visualiseringer, er primært at højreklikke på dem og se, om de er et billede. Til at finde mange sider, der mangler alternative tekster på billeder, kan du bruge Optimizrs rapporter.

Passende mange links på en side

Hvor mange links er passende for en enkelt side på dit websted? Ja, det er svært at sætte et præcist tal på, og det handler ikke om en absolut grænse. Først har vi måske brug for at ræsonnere lidt om, hvorfor vi overhovedet skal bekymre os.

Alle links, man har på en side, skal være absolut nødvendige. Hvorfor? Jo, det belaster din besøgendes opmærksomhed at vælge mellem de alternativer, du giver. Hvilket der er vigtigst i sammenhængen, bliver ikke helt selvfølgeligt, hvis der er masser at vælge imellem.

En måde er at sætte en grænse for, hvad der er ok, uanset hvilken type side det er. I nogle værktøjer, jeg har brugt, er der advaret, hvis man har over 200 links på en underside, da uanset om de pegede på sider inden for webstedet eller eksternt.

Linkjuice = alt kan ikke være vigtigst, altid

Tænk på hver side som om den har 10 tillidspoint at dele ud til andre sider gennem det, den linker til. Linker du til 5 sider, får de 2 point hver, linker du til 100, får de en tiendedels point hver.

Noget, de SEO-interesserede arbejder med, er at forsøge at balancere andelen af eksterne links, altså links, der fører væk fra et websted. Det er både et signal til søgemaskinen og brugeren i, hvilken udstrækning man videresender fra det egne websted. At have en god balance omkring intern og ekstern fordeling af linkjuice er værd at overvåge og tjekke, hvordan markedslederne i din niche gør. Kortfattet: Er pointen med en bestemt underside at sende folk af sted, eller er der internt materiale at tilbyde? Følg op på, hvad brugerne vælger at gøre.

At have mange interne links tyder på rodet struktur. Ved at have masser af interne links svækker man også den interne linkstruktur. Kører man Wordpress, er det ikke sjældent et selvforskyldt maveplask, du sikkert har set. Mange spammer deres egne blogindlæg med masser af tags. Jo flere tags, desto flere links og associationer. Det er, hvad man har de bredere kategorier til. Hold igen, ganske enkelt.

Bruge rel="nofollow" på eksterne links

Netop for eksterne links kan man sætte attributtet nofollow. Det fortæller, at man ikke anbefaler en søgemaskine at følge linket, og det er en måde at sige, at man ikke har tillid til det link. Man kan samtidig spørge sig, hvorfor man har et link, man ikke vil stå inde for. Det er en pragmatisk standard, der er vokset frem, for eksempel for links, der tilkommer på grund af brugeres bidrag på websteder. Det er en måde ikke at belønne spammere og et forsøg på at være selektiv med, hvor man afgiver sin linkjuice.

Til at få lidt styr på dette er Optimizr.com godt, men sandsynligvis ved du, hvilke sider på dit websted der har usædvanligt mange links.

Websider har brug for indgående links

Det er lidt mistænkeligt, at man skjult tipser om en side, der er svær at opdage som almindelig bruger. Du ved måske ikke, hvordan det kan ske selv på dit websted? De sider, du har med i din sitemap, en fil der primært bruges af søgemaskiner, kan være skramlesider.

Ofte forekommende finder jeg eksempler i hierarkisk skabte websteder, noget for eksempel webpubliceringssystemet Episerver CMS giver automatisk. Der kan man finde sider, der hedder "højrekolonne" og mangler indhold. Eller "hovedmenu", der bruges som en mappe i værktøjet for webredaktørens skyld. Hvis hverken dit eget eller andres websted linker til en bestemt webside, er det absolut et signal om, at den webside fuldstændig mangler værdi. Undertiden passer det jo, men hvis siden er meningsløs, burde den heller ikke være der og forvirre hverken søgemaskiner eller brugere.

Hvis siden nu ikke er uvigtig, er det tid til at linke til den, i det mindste selv, eller også må du forsøge at skaffe nogle indgående links fra andre.

Når det gælder værktøjer til at få styr på det, er det ambitiøse alternativ at have styr på alle sine adresser. De adresser, der har haft besøgende, kan du eksportere ud fra dit webstatistikværktøj. Ellers er der måske intern søgeteknologi, du kan drage nytte af, som ved, hvilket indhold der eksisterer, uanset om det får besøgende eller ej. Har du listen sorteret efter popularitet, er det måske værd at begynde med dem, der har få besøgende, der er måske det, du ikke ventede skulle besøges.

Pas på interne videresendelseskæder

Du, der har læst bogen Webbstrategi för alla, har nok forstået, hvor vigtigt jeg synes det er at tage sig af sine gamle eller tidligere indarbejdede adresser på webben. Problemet kan dog over tid opstå, at du videresender til endnu en videresendelse. Så spilder du webserverens kraft og brugerens tålmodighed.

Dine brugere er utålmodige, i det mindste gælder det for det absolutte flertal af websteder. Hvis dine websider ikke indlæses på under 0,1 sekunder, tilhører du den kategori, der kan få bedre flow i oplevet interaktion. Det tager tid at videresende en bruger fra en adresse til en anden. Egentlig helt unødvendigt, eller i hvert fald er det intet, en besøgende har nytte af.

Et scenarie, der ikke er alt for usædvanligt, er, at man videresendes fra http://adresse.dk til den sikrere protokol, der understøtter TLS/SSL. Det vil sige https://adresse.dk, og hvis det ikke var slemt nok, kan webstedet begynde at have præferencer om at tilføje det helt unødvendige www-præfiks. Altså sendes man videre til https://www.adresse.dk, og derefter krydre det hele med at være omhyggelig med sprogversion, dermed sendes man til https://www.adresse.dk/da/

Nej, det er ikke noget absurd scenarie. I foråret 2015 havde min egen arbejdsgiver et nylanceret websted, der havde kun en færre videresendelse end dette for dem, der ville besøge startsiden. Efter tilstrækkeligt mange videresendelser begynder det at straffe sig også inden for SEO. Ifølge oplysninger er netop videresendelsen fra HTTP til HTTPS ikke noget, Google straffer os for, for netop den videresendelse synes vi at have et frikort⁸³.

Hver videresendelse tager ofte mindst en tiendedels sekund, men det er ikke usædvanligt med op til et sekund afhængigt af den forsinkelse i svartid (latens), der er mellem den besøgende og serveren. I ekstreme tilfælde har jeg selv haft svartider på flere sekunder. Så ville antallet af videresendelser skulle ganges med flere sekunder. Tid, der er helt spildt for alle parter.

Hvordan gør man så?

Sørg for at have styr på, hvilke videresendelser der er. Har du adgang til logfiler, er det HTTP's statuskode 301 og 302, du leder efter, det vil sige mere eller mindre permanente videresendelser. Tænk også på, at 301 siger, at det er en permanent videresendelse. Det fortæller søgemaskiner og andre maskiner, at de kan glemme den ældre adresse og holde sig til den nye. 302 siger, at det er en midlertidig videresendelse, brug den forskel med forstand.

Du bør undgå at have mere end én videresendelse. Man skal aldrig havne på en videresendelsesside, der sender dig videre. Vi skal omgående videresende til den endelige adresse. Med den rigtige statuskode ifølge HTTP-specifikationen.

Den ambitiøse begynder at lede efter logfiler på serveren eller netværket, men mest rimeligt er nok alligevel at lave manuelle stikprøver og at være meget opmærksom, når man selv agerer bruger. Skriv adresserne, du har på dit websted, om, og tjek, hvad der sker. Vil du spore alt vedrørende HTTP, kan du teste via Firefox at have tilføjelsen Tamper Data installeret, men mange funktioner er også i webbrowsernes udviklerværktøjer.

Gennem dit webstatistikværktøj kan du tjekke, hvilke eksterne websteder der linker til dig, og hvilke adresser de peger ud. For eksempel om de bruger www-præfikset eller ej, kører med HTTPS eller ej. Nogen, der driver meget eller vigtig trafik til dig, kan være værd at tale med for at angive den "rigtige" adresse.

Ikke angive nøgleord – unødigt

Dette spørgsmål er ret kontroversielt i visse sammenhænge. Men man kan i hvert fald spørge sig, for hvis skyld du angiver nøgleord, eller meta-keywords, som de undertiden også hedder. Om Google nogen sinde har bekymret sig om disse ord, er det i hvert fald længe siden, de holdt op med det. I dag teoretiseres det snarere, at forekomsten af nøgleord er et klodsete forsøg på at spamme søgemaskiner.

Undertiden står der i organisationens redaktørmanual, at man skal skrive nøgleord ind. Ja, det gør der også, der hvor jeg arbejder. Der er eventuelt to grunde til det, det kan være, at man har en egen søgemaskine, der drager nytte af disse ord. Den anden, noget mindre flatterende grund er, at viden stammer fra halvfemsernes glade dage, da det næsten var praksis at snyde søgemaskiner med helt irrelevante nøgleord.

Jeres egen søgemaskine kan faktisk have nytte af disse nøgleord. Grunden til, at det kan fungere internt, er, at man har større grund til at stole på sine egne redaktører, ens egen søgemaskine leder kun i materiale, man selv har publiceret.

Ok, men vores egen søgemaskine dækker jo også vores eksterne web…

Her opstår problemet for alvor. Hvis I har nytte af at angive nøgleord for jeres egen søgemaskines skyld, så gør for al del det, men tro ikke, at det gavner Google eller de andre søgemaskiner. Hvis du angiver nøgleord for din egen søgemaskines skyld, sørg for Guds skyld for, at ordene er unikke og relevante, så du ikke spammer dig selv.

Tommelfingerreglen for, hvad der inden for ekstern søgemaskineoptimering er lønsomt at bruge tid på, er, at det skal være kompliceret at snyde, samt at originalt materiale skal belønnes. Det er uhyre enkelt at snyde i massiv skala med nøgleord. Det er derfor, det ikke bruges af udenforståendes søgemaskiner.

Til at få styr på det kan du læse HTML-kildekoden på de sider, du vil inspicere. Led efter kode, der ser ud omtrent som dette i <head>:

<meta name="keywords" content="nøgleord, nøgleord2, nøgleord3">

Det eneste egentlige værktøj, jeg har fundet til dette, er Optimizr.com, og af de sider, de har tjekket, får man en liste med, hvilke sider der indeholder nøgleord.

Passende dybde i webstedet

En højst uvidenskabelig tommelfingerregel, du kan holde dig efter, er, at ikke alle brugere orker at lede sig mere end tre niveauer ned i dit websted for at finde, hvad de søger. Det dels fordi mange ikke føler, at de har den tid at lægge på et svært navigerbart websted, men også fordi man ikke ved, om det er anstrengelsen værd. Vi kan ikke regne med, at særlig mange af vores brugere er motiverede nok til at anstrenge sig. Hvis vi derimod designer navigationen med en bruger i tankerne, er der faktisk beviser for, at fire niveauer er bedre end tre, blandt andet i Jakob Nielsens bog Prioritizing Web Usability⁸⁴.

At navigationen ikke altid er omsorgsfuldt udformet for brugernes skyld, får jeg signaler om nærmest hele tiden. Hvis man nu tror på skæbnen; samme dag som jeg redigerede denne del af bogen, dumpede der en e-mail ind, der forklarede, at "webredaktørerne finder deres sider nemt i denne flade struktur". Spørgsmålet er vel, om webstedets navigation er til for webredaktørernes skyld?

Hvis dit websted har hierarkiske adresser, sådanne der angiver skråstreg her og der, kan du nemt tælle dem. I visse webstatistikværktøjer, for eksempel Matomo, kan man bladre sig ned i denne mappestruktur og se den undertiden barske virkelighed af, hvor mange niveauer der faktisk er at bevæge sig mellem.

Hvorfor dette er et problem?

Ofte går brugervenlighed, tilgængelighed og søgemaskines behov hånd i hånd. Søgemaskinerne skal prioritere, hvor mange undersider på dit websted de skal bruge tid på at forsøge at indeksere. Du tildeles ganske enkelt et indekseringsbudget fra søgemaskinen, et begrænset antal sider på dit websted kan altså blive indekseret. Antallet af sider, dit websted er tildelt, hænger sammen med søgemaskinens vurdering af webstedets værdi. Grunden til det er, at søgemaskinen skal forsøge at beskytte sine egne interesser og ressourcer, da dit websted faktisk kan være defekt eller spammy.

Det kan være, at dit websted har en systematisk fejl, der giver det uendeligt mange undersider, sider der knap linkes fra dit eget websted. Derfor skal søgemaskiner og andre maskiner forsøge at finde ud af, hvilket antal sider og præcis hvilke af dem der er værd at crawle og forsøge at indeksere. Det er dit job at hjælpe dem på vej, og på købet bliver det ofte bedre for menneskelige besøgende.

Undgå mere end tre niveauers dybde

Du skal naturligvis stræbe efter den mest logiske navigationsstruktur, der er for dit eget websted og det indhold, det har. Men husk, at det ikke er et reflekterende menneske, der sidder og bedømmer dette hos søgemaskinerne. Sådant gøres helt automatisk.

Hvis du har mere end tre niveauers dybde for at nå en bestemt underside, er det rimeligt at antage, at den ikke er særlig vigtig, ikke vigtig nok til at indeksere. Hvis den var vigtig, ville den nok være linket direkte fra startsiden eller direkte fra en side under startsiden. Eller hvad?

Du har et begrænset indhold til at overbevise

Al snak om Google-sniping (sider skabt til specifikke søgebegreber), du muligvis har snappet op, kan du med andre ord begynde at stille spørgsmålstegn ved. Du skal have under 200 links per underside, du skal ikke have mere end tre niveauer. Frem med lommeregneren, og regn på det. Det gamle snak om, at man når ud på søgemaskiner via "den lange hale" og Google-sniping, er ikke lige så gangbare ud fra dette synspunkt.

Værktøjer til at tjekke navigationsstruktur

Dem, der laver indholdsrevisioner i stil med det, Kristina Halvorson anbefaler i sin fremragende bog Content Strategy for the Web⁸⁵, har denne struktur allerede i sin indholdsdokumentation.

Har du Matomo, snarere end Google Analytics, er webstedets dybde tilgængelig som en træstruktur at udforske. Det kan tage et stykke tid at udforske strukturen, og husk, at det er adressernes struktur, du ser, snarere end om noget er linket direkte fra et højt niveau i strukturen. Kører du Google Analytics, kan du filtrere tilsvarende information frem under Behavior -> Site Content -> Content Drilldown. Der ser du et websteds gruppering, hvis URL'erne har mappinger i sig.

For den manuelt stikprøvsinteresserede person kan man oprette en liste over de sider, der faktisk er vigtige. Har de ikke et direkte link fra startsiden og relevante landingssider, er det tid til at løse det problem.

Tydelige linktekster

Linkteksten er teksten, der er klikbar og fører til en anden del af webben. Rent generelt bør de være blå og understregede, hvis du ikke har gode grunde til at designe dem anderledes. Blå farve og understreget tekst er den historiske de facto-standard for webben, og da mange stadig kører med dette, letter det for dine brugere, hvis vi følger den konvention.

Skriv ikke "Læs mere her" eller "Klik her" som linktekst! Grundreglen for links er, at deres tekst skal kunne stå for sig selv. Det vil sige, man skal som seende kunne skimme igennem siden og kun læse linktekster og alligevel få en ret god opfattelse af, hvad de linker til.

For en person med fraværende eller nedsat syn er det i høj grad afgørende, at du skriver gode linktekster. Deres måde at navigere længere tekstmasser er at hoppe mellem overskrifter, links og andre designelementer for at forsøge at få en opfattelse af en sides indhold. Det er ikke direkte hjælpsomt, hvis de får at høre "læs mere" ti gange i træk, når de forsøger at navigere, vel?

Praksis med tunge filer

Hvis det, du linker til, er en usædvanlig type fil, bør du skrive det i linket, gerne i parentes til sidst. Er filen tungere end en megabyte, er det også en god ting at skrive i linkteksten i parentes. Alt for ikke at overraske brugeren. For eksempel "Download årsrapporten for 2016 (PDF, 7 Mb)".

Du har sikkert også set linktekster som "Bla bla (åbner i nyt vindue)", eller dem med et lille symbol efter. Det er i sig selv godt at fortælle, hvornår man tænker at åbne et link i nyt vindue, men hovedreglen er, at man ikke skal åbne links i nye vinduer. Der er tusind dårlige undskyldninger for, hvorfor man synes, det er motiveret at åbne et link i et nyt vindue, men lad bare være. Den mest effektive måde at finte en bruger på er at åbne nye vinduer til højre og venstre. Eller åbne i det samme nye vindue flere gange, eller kapre klikket via Javascript for os, der Ctrl-klikker på links. Følg webstandard, lad være med at bestemme for brugeren, lad brugeren have kontrol over sin oplevelse!

Søgemaskineoptimering og linktekster

De ord, der udgør linkteksten, er et signal til søgemaskiner om, hvad man anser, at den linkede side handler om. Det var det, nogle sjove gutter udnyttede for en masse år siden, da de lavede en såkaldt Google-bombning af den amerikanske præsident George W Bush. Ved i linkteksten at skrive 'miserable failure' og linke til Det Hvide Hus' profilside for præsidenten lavede Google associationen, at George W Bush og søgebegrebet 'miserable failure' hørte sammen.

Med andre ord vil du have relevante ord i linkteksterne, ord der afspejler, hvad indholdet handler om. Det behøver ikke at være præcis, hvad siden har i hovedoverskrift. Men ingen skal føle sig overrasket over, hvor man er havnet baseret på en snedigt formuleret linktekst. Søgemaskiner bliver også stadigt bedre til at afgøre, når man sysler med keyword-stuffing, altså når man propper en ulæselig mængde søgeord ind, man håber at få med. Skriv linkteksterne med omtanke for en menneskelig læser, i anden række kan du eksperimentere med SEO.

Hvis du fuldstændigt dominerer på søgemaskinerne på et bestemt nøgleord, kan du måske koste på dig i linktekster at bruge synonymer eller andre begreber. Eksempler på dette kan være, at hvis du linker til et produkt, der har et navn helt uden konkurrence på søgemaskinerne, så overvej om ikke "Lazyboy Armchair 3000 Deluxe" kan få links, der indeholder ord som lænestol, eller hvad nu søgeordet er, du vil forsøge at trænge dig frem på. Det er det samme med egne varemærker. Det er nok ret sjældent, man har konkurrence om dem, og spørgsmålet er, om man med et udefraperspektiv skal bruge dem så ofte, som man gør?

Google Search Console har visninger for, hvilke ord der bruges til at linke til webstedet. På visse eksterne websteder har man indflydelse på, hvilke ord der bruges, men tænk på, at det er mere slidsommt at ændre disse end på dit eget websted. Til at tjekke, hvem der linker til dit websted, kan du tjekke Search Consoles visning Søgetrafik -> Links til dit websted, det er, hvad Google kender til ved sin indeksering. Men du kan også i dit webstatistikværktøj tjekke, hvilke henvisningswebsteder der er, altså eksterne sider, besøgende er kommet fra. Så får du sandsynligvis en indikation på den respektive sides relative vigtighed.

Optimizr.com har dette med i sine rapporter. Selvom disse rapporter ikke kommer omgående, er de gode til passiv eller periodisk webanalyse.

God fordeling af linkjuice

Det med linkjuice, altså et links kraft eller værdi, er et vagt begreb, der hører til søgemaskineoptimering. Man kan se det som et problem, hvis for mange af webstedets links henviser til andre websteder. Det kan give udseende af, at webstedet ikke har en egenværdi, at der ikke er relateret information inden for webstedet.

Der er mange bud på, hvor mange eksterne links en enkelt side bør have, eller hvor stor en andel, men betragt ikke dette som nogen eksakt videnskab. Undertiden er det sådan, at en undersides hele formål går ud på at guide din bruger til det rigtige websted – andres websted. For eksempel har vi, der arbejder med regionernes websteder, ekstremt gode grunde til at henvise dem, der søger pleje, til 1177.se, Ungdomsmottagningen Online, umo.se, da det er på de steder, vi samler den fælles anstrengelse for at lave gode websteder. Men naturligvis er der brugere, vi har grund til at beholde. Som hvis man vil i kontakt med dem, der styrer organisationen, eller noget af alt det andet, der ikke er nationaliseret.

I normale tilfælde skal du ikke sende dine besøgende til andre websteder. Derefter, om du sætter regler op om kun i undtagelsestilfælde at have mere end et eksternt link, er op til dig.

Værktøjer til at finde spildt linkjuice

Du kan jo naturligvis gennemgå dine vigtigste sider manuelt og tjekke, hvordan det står til. Ellers har Optimizr.com dette med i sine rapporter. Deres måde at definere det er i skrivende stund, at en side har færre end ti interne links – det anses at give en svag indholdsstruktur.

Strukturel CSS inkluderes i HTML-koden

Målet med denne type CSS er, at siden kan præsentere sig hurtigere og lade brugeren påbegynde sin brug, allerede inden alt er downloadet. Googler du efter dette, kan du kigge efter Critical Path CSS.

Det hele foregår på den for mange webudviklere noget underlige måde, at man inkluderer lidt af CSS-koden ind i HTML-koden. Direkte via en style-tag i kodens sidehoved. Det her er noget, vi der har kodet til webben har kæmpet for at blive fri for, og stadig anses det delvis, at CSS-kode i websider er sjusket kode. Regn ikke med, at alle udviklere er enige med dig i, at dette er en god idé.

Anekdote fra marts 2015 – udviklere troede ikke deres egne øjne

Da jeg holdt et foredrag om webpræstation for 40-tallet udviklere og teknikere, sad flere med et overrasket udtryk i ansigtet, da de fik øje på et billede med koden bag mit private websted. Billedet var tænkt at illustrere, at man fjerner unødvendige mellemrum, tabulatorer med mere fra HTML-koden. Jeg havde desværre ikke advaret om, at al denne ekstra CSS-kode var lagt der med vilje (note to self: bør nok tage det op tidligt under næste foredrag, så ingen behøver at stille spørgsmålet og føle sig irettesat).

Jeg havde naturligvis indledt med, at jeg byder spørgsmål velkomne, så en af udviklerne tog mod til sig: "Men Marcus, er det ikke meget dårlig praksis at have CSS i HTML-koden?!" Jeg er jo parat til at give ham ret. Det føles stadig mærkeligt at se det i koden, men man er bare nødt til at bøje sig og indse, at den oplevede præstation må gå forud. Det handler jo alligevel om brugerne i sidste ende.

Det er ren magi, men der er ulemper. I og med at man lægger kode ind, der på ingen måde er unik per side, gør man alle siders HTML-kode en smule tungere. Tanken er, at man kun lægger det ind, der gør, at siden kan vise sig hurtigere. Det vil sige det, der sætter de ydre rammer for en side. Det er et eksempel på, når oplevet præstation og teoretisk præstation støder sammen. Egentlig bliver sidevisningen nogle kilobyte tungere, men brugeren får øje på webstedet hurtigere og kan dermed begynde at bruge det. Brugeren får en oplevelse af bedre flow.

Samtidig skal man være forsigtig, så sidens designelementer ikke ser ud til at være færdige, inden de faktisk kan bruges.

Værktøjer til critical path css

Der er en Critical Path CSS Generator⁸⁶ på webben, der kan hjælpe dig med at filtrere frem, hvilken CSS du skal inkludere i sidehovedet. Eller, hvis man selv eller nogen, man kender, har sort bælte i CSS, kan man gøre dette selv. Derpå placerer man det i head-taggen i en style-tag. Validerer siden ifølge W3C, er det tid til at teste, om det fungerer, som det er tænkt. Simulér gerne en langsom forbindelse via Google Chrome, og test om noget er visuelt færdigt, men ikke funktionelt, for eksempel hamburgermenuer m.m.

Er du usikker, så sæt en A/B-test op, og evaluér om versionen med critical path CSS virkelig fungerede bedre på netop dit websted.

Ikke åbne links i nyt vindue

At automatisk åbne links i et nyt vindue er en effektiv måde at finte sine brugere på. De vil nemlig ikke kunne bruge tilbageknappen til at komme tilbage. Dermed indfører man et unødvendigt krav om, at brugeren skal være opmærksom, netop når det nye vindue åbnes, samt at vedkommende skal huske dette senere.

Alle argumenter, jeg har hørt om, hvorfor man gerne vil åbne links i nyt vindue, er en forklædt velvilje over for den besøgende. Man har den uimodsagte antagelse, at dette er, hvad brugeren vil. Visse er mere åbne med deres bagtanke, som at man for enhver pris vil beholde brugeren på sit websted. Hvis ens websted ligger bag det nye vindue, er der alligevel chancen for, at brugeren fortsætter med at klikke rundt senere.

Jeg vil påstå, at brugere kender til tilbageknappen, samt at de nok bruger den, hvis de vil komme tilbage. Desuden at det ikke er foreneligt med brugervenlighedsprincipper at tvinge brugere til at huske, at den side, man landede på, er i en ny fane eller et nyt vindue (hvilket gør, at tilbage ikke fungerer).

Men min absolut største favorit af alle dumheder omkring at åbne nye vinduer er, når de åbnes i et nyt navngivet vindue. Det gøres, hvis man nu tjekker HTML-kode, ved at sætte attributtet target til noget, for eksempel target="dokumentvindue". Det, der sker, er, at første gang brugeren klikker på et sådant link, åbnes et nyt vindue. Derefter vil hvert følgende link (med det samme attribut) erstatte indholdet i dette navngivne vindue/fane. Har man da en liste med links, hvor alle henviser til det samme target, vil flere klik føre til, at kun det senest klikkede link er indlæst, når man sandsynligvis ville have alle dem, man klikkede på.

At åbne nye vinduer for brugerens skyld, til brugeren, er bare forvirrende for alle involverede. Dette ofte tilbagevendende spørgsmål tages op af Webbriktlinjer.ses retningslinje 97 – at lade tilbageknappen fungere. Det gør den ikke, hvis man åbner i nye vinduer.

Nyt vindue er i strid med tilgængelighedsretningslinjen WCAG's succeskriterier

Selvom de allerfleste ikke stræber efter til punkt og prikke at leve op til WCAG's mest strenge niveau, er det utvetydigt, hvad der er den rigtige måde. Sådan skriver de i deres anbefalinger (min fremhævning):

"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 konstaterer altså, at man skal undgå at overraske brugere, samt at brugere selv kan åbne links i nyt vindue, hvis de nu ønsker det⁸⁷. Desuden, i G200⁸⁸, er der følgende anbefaling:

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.

Der gives også eksempler på, hvornår det kan være berettiget med nye vinduer, nemlig 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, disse to eksempler indikerer, er, at et desktop first-perspektiv er til stede, spørgsmålet er, om W3C ville ræsonnere på samme måde mobilt. Desuden forudsætter de lidt, at man hverken tænker eller kan redesigne brugerens flow i webapplikationen.

For dem, der vil leve efter god praksis uanset valgt ambitionsniveau omkring tilgængelighed, er spørgsmålet om links i nye vinduer egentlig meget enkelt – lad det pokker mig være :)

Nyt vindue er en sikkerhedsrisiko

Hvis nu hverken brugervenlighed eller tilgængelighed er argument nok, er det også en sikkerhedsrisiko at åbne links i nyt vindue. I hvert fald gennem target="_blank" på linket. Det er nemlig muligt på et eksternt websted at tage del af indholdet på den oprindelige side med lidt Javascript-kode⁸⁹. Med andre ord skal man aldrig åbne eksterne links i nyt vindue. Du har ingen kontrol over, om de eksterne websteder, du linker til, har sikkerhedsproblemer, og hvad værre er, de vil næppe fortælle dig, mens de reparerer deres sikkerhedshul. Om de nu nogen sinde reparerer sikkerhedshullet, det bliver måske aldrig opdaget.

Mig bekendt er der intet værktøj, der kan hjælpe os med dette i større skala. Hvis du har en egen søgemaskine eller anden teknologi, der har en lokal kopi af alle siders HTML, kan du søge efter target= for at finde disse overtrædelser.

Ofte er disse løsninger systematiske og følger webstedets publiceringssystem. Tjek derfor, hvordan links i diverse lister håndteres. Derefter kan du overveje, om muligheden for at åbne nye vinduer burde fjernes fra publiceringssystemet.

Publicér ikke PDF-filer

Det er en ren plage at læse PDF'er på en mobil skærm. Og er det ikke på tide at opgive den der tankegang om faste formater, der blev opfundet i 1400-tallet med bogtrykkerpressen? Hvis du nu ikke selv har prøvet at læse en PDF på en mobiltelefon, kan jeg forklare det for dig. Det handler om enten at have overblik, hvor teksten er for lille, eller at du har zoomet ind, så du kan læse dele af en sætning. Når du zoomer, vil du tabe dig selv ved hver linje, når du har læst færdig og skal gå ind på den næste.

PDF er ikke kun dårligt, formatet har sine fortjenester. Blandt andet er det et fornuftigt format til arkivering, specifikt varianten PDF/a, men også et fremragende format, hvis man vil sende noget til udskrift til en anden. PDF gør, at man kan referere til den sidste linje på side to, og alle kigger på det samme. Man ved, at indholdet vil blive skrevet ud ens.

Responsivt web er ikke foreneligt med PDF-filer

Men PDF'er er ikke et format til webben. Den samme udfordring, som vi adresserede ved at bygge responsive websteder, er det, der gør PDF-filer mindre gode. Ortodoks responsiv teori kræver, at man tænker kanvas bort, skærmstørrelse eller forudsætter en bestemt type bruger. En PDF er arketypen af kanvas. Det hele går ud på at have et indhold med fikseret position inden for en given størrelsesbestemt flade. Et kanvas ganske enkelt.

Det er meget ærgerligt, hvis man har et responsivt websted, og brugerne lige meget hvad lander på PDF-filer eller andre dokumenter, der er uegnede til andet end muligvis at downloade til en computer. Det gælder naturligvis også Word-dokumenter og alt andet, der ikke er rigtig web.

Hvis dit websted er på det offentlige web (altså ikke et intranet), kan du prøve at formulere en søgeforespørgsel på Google lignende den nedenfor:

site:minsajt.se filetype:pdf

Tænk dog på, at det på visse organisationers websteder ikke er hoveddomænet, der serverer dokumenter og PDF-filer. På min arbejdsplads ville det have været alfresco.vgregion.se, der var domænet.

Tilbyde en sitemap

En sitemap er en teknisk pendant til webstedskortet. Altså en liste med alle sider, der findes på et websted. Sitemaps er en industristandard⁹⁰, der blev udarbejdet af søgemaskinevirksomheder som Google, Bing med flere, men du kan sagtens bruge din sitemap til andre ting end at sende til søgemaskinerne.

Blandt andet kan din egen søgemaskine have nytte af den. Eller dem, du samarbejder med, vil måske gerne kunne overvåge, hvornår der kommer nyt materiale på dit websted. Sitemapens indhold er en kronologisk liste over, hvilke adresser der er på webstedet. Nyeste øverst, og desuden kan man lægge en vægtning ind om adressens relative værdi inden for webstedet.

Sitemapen skal gerne hedde noget forudsigeligt, som sitemap.xml, og placeres i webstedets hjemmemappe. Alternativt fortæller du i din robots.txt, hvor man kan finde sitemapen. Har du flere sitemaps, har du brug for et såkaldt siteindex, det er en liste over, hvilke sitemaps du har. Det kan være nødvendigt, hvis man har uhyre mange poster i sine sitemaps, man må nemlig ikke have en uendelig stor sitemap.

Kører du Wordpress, kan du bruge Wordpress SEO til at få XML-sitemaps med. I andet fald må du i værste fald udvikle funktionen selv, eller, hvis indholdet næsten aldrig ændres, og du har et mindre websted, orker du måske at skrive den i hånden.

Du kan påtale for Google, at du har en sitemap via deres Search Console, det samme gælder Bing med deres Webmaster Tools. Der vil du få at vide, om der er nogen fejl relateret til din sitemap.

Ha en robots.txt og en humans.txt

Billede 66: Robots.txt på min bogblog.

En robots.txt er en tekstfil, der ligger i roden, altså hjemmemappen, på et websted. Den er der for at levere instruktioner til botter, der forbinder til webstedet. Blandt andet instruerer man søgemaskinerne ad den vej om, hvilke dele af webstedet de ikke skal indeksere. Det er naturligvis praksis at følge det, der står i en robots.txt, men for ondsindede kan de ad den vej også få tips, så det gælder om ikke at være naiv.

Ud over at fortælle, hvilke dele af webstedet man ikke ønsker besøg på (såkaldt disallow), er det praksis at fortælle, hvor man har placeret sin sitemap. Hvis du ikke er helt Google-centrisk, kan andre søgemaskiner få hjælp til at indeksere dit websted, hvis du lister din sitemap på denne måde. Det er trods alt en meget lille indsats.

Til at dobbelttjekke, at din robots.txt er korrekt udformet, kan du via Googles værktøj Search Console anrope filen og få den analyseret.

En humans.txt også – for dine menneskelige læsere

En del websteder er begyndt at have en humans.txt ved siden af sin robots.txt, dette for at skrive dokumentation til menneskelige læsere. Det er webbens pendant til, at man ofte finder en readme/læsmig.txt, når man tjekker andre typer software.

Har du noget at sige en menneskelig læser, så gør det i humans.txt-filen. Det kan være kontaktoplysninger, instruktioner til teknikere eller udviklere, der tjekker webstedet.

Afrunding

Jeg håber, du har fundet noget nyttigt i denne bog. Føl dig også fri til at stille opfølgende spørgsmål, for eksempel via Twitter.

Fortsæt med at læse – Outro