Del 4: Aktivitetsplan

For å jobbe strategisk med din webanalyse bør du eller noen innen webteamet sette opp en aktivitetsplan som tydelig tar deg fra nåsituasjon til et ønsket resultat. Denne delen av boken tar opp en mengde eksempler på aktiviteter og måleverdier du kan velge å putte inn i din egen aktivitetsplan.

Det er hygienefaktorene på nettstedet som skaper forutsetninger for et verdifullt nettsted. Å begynne med alle på en gang er dumt, de tar tid. Se gjennom dem og velg ut fem til ti stykker å utføre (og beherske) i løpet av det kommende året. Det er bedre at du setter et mål du kan oppnå.

Hygienefaktorer

Poenget med å forsøke å leve opp til denne delens hygienefaktorer er å ha noe målbart å forholde seg til når det gjelder de teknikalitetene som påvirker besøkernes opplevelse. Dessuten er de en måte å forsøke å sikre at nettstedet ikke forverres over tid, men snarere kontinuerlig forbedres for hver oppdatering.

Listen med de aktivitetene du har valgt ut kan supplere de testprotokollene som systemutviklerne har. De fleste som bygger større nettsteder har allerede en systematisk måte å verifisere at et webprosjekt holder riktig kvalitet. Ganske mange har lenge brukt såkalte byggeservere for å ha kontroll over kodekvalitet for et større team utviklere. Flere av de verktøyene har muligheten til tilleggsmoduler som kan gjøre noen kontroller automatisk for deg. Så gjør gjerne en inventering av utviklingsarkitekturen. Snubler du over noe for Continuous Integration⁶³ er det verdt å lete etter tilleggsmoduler. Det er mulig å automatisk stoppe produksjonssetting av nye funksjoner om det ikke lever opp til kvalitetskravene man har satt opp.

Om du driver et større nettsted er det en god idé å interessere deg litt for hvilke tester utviklerne har for å forsikre seg om at riktig kvalitet oppnås. Disse testene kan være alt fra helt manuelle til fullstendig automatiserte. Men vær forberedt på at det kan være minert mark. Reaksjonen kan virkelig være alt fra at de blir glade for at man er interessert til at enhver bør ta hånd om sine egne problemer.

Ettersom verktøy og triks for å sjekke disse faktorene ikke alltid lever for alltid, kan du vende deg til en side på nettstedet mitt der jeg har en aktuell liste⁶⁴ med verktøy jeg selv bruker for øyeblikket.

Startpakke for din aktivitetsplan

Listen som følger er slikt du selv kan kontrollere for å sikre at nettstedet fungerer som du vil. Selvfølgelig kan du bytte ut verdier om du vil sikte høyere eller lavere. Velg ut hvilke punkter du synes det er rimelig at hver underside på nettstedet skal leve opp til, og diskuter dem med din webutvikler (iblant trenger man nemlig å resonnere annerledes).

Som du innser når du leser listen finnes ting man trenger å legge til avhengig av hvordan ens nettsted er tenkt å brukes. For eksempel de som har valgt å kjøre mobile first bør en aktivitet inn på listen for at man ikke bruker eller lenker til PDF-filer på nettstedet (de er som oftest uvennlige mot de med små skjermer).

Men nå er det på tide med en rekke forslag til aktiviteter.

Innføre HTTP/2 og HTTPS

Før jeg eller noen du møter fullstendig frelse deg rundt gledesmeldingen om at HTTP/2 er det beste siden Jesus H. Kristus gikk i kortbukser, tenk kritisk rundt hvilke brukere du etterlater deg. De som ikke har utstyr som støtter den nye webprotokollen. I skrivende stund er det primært de på eldre versjoner av Internet Explorer som tilhører denne gruppen. Før du tar steget bør du vite hvor stor andel av dine brukere og tiltenkte målgruppe som tjener på det.

I Microsofts verden er det først Internet Explorer 11 som støtter HTTP/2, mens alle andre moderne nettlesere har hatt det lenge (og som i motsetning til Internet Explorer ikke pleier å leve på overtid). At webserverne du bruker støtter protokollen er ikke selvfølgelig, men mange hadde støtte allerede i 2016. Om både brukerens enhet og alle involverte webservere støtter HTTP/2 vil det automatisk brukes. Dessuten husker nettleseren at webserveren tilbød HTTP/2, så neste besøk kommer til å gå enda raskere da nettleseren allerede ved sin forespørsel til webserveren sier at den vil snakke HTTP/2.

Å våge å ta steget

I mange tilfeller kommer det ikke å bli noen merkostnad eller manuell anstrengelse å aktivere HTTP/2 på sitt nettsted. Bruker man allerede et eksternt CDN (altså innholdsnettverk) er det rent av sannsynlig at filene der allerede drar nytte av HTTP/2. Derimot trenger man kanskje å gjøre visse ytelsesoptimaliseringer om igjen for å dra nytte av den nye protokollen. En utfordring her blir hvordan man optimaliserer nettstedet både for de på HTTP 1.1 og HTTP/2 ettersom god ytelsespraksis skiller seg, dette kommer vi mer inn på senere.

I mange år kommer HTTP 1.1 å leve parallelt med HTTP/2, i noen grad. Det er en aktivitet vi som jobber med webanalyse trenger å komme tilbake til. Hvilke systemer vi bruker kan begynne å jobbe med versjon 2, og hva innebærer det i praksis?

For deg med et lite Wordpress-nettsted er dette en liten sak sammenlignet med store organisasjoner der massevis med nye, gamle og iblant forhistoriske systemer samarbeider for å servere innhold til nettet.

Grunnen til at HTTP/2 i noen grad snur opp ned på de kvalitetskravene man stiller til et websystem som kjører versjon 1.1 er at man har tenkt grundig gjennom hvordan nettet av i dag ser ut. Blant annet er den nye versjonen bedre på flere samtidige filer og å holde en åpen kanal for å sende filer litt etter behov. At det automatisk inngår sikkerhet tilsvarende HTTPS kan vi se som en bonus.

De systemene du ser på først er de som sender mer enn én fil til den besøkende per sidevisning. Selvfølgelig selve webserveren, men også om du har et innholdsnettverk (CDN), separat bildesystem, etc.

Ha dette i bakhodet når du leser resten av denne delen i boken – å dele opp innhold i noen filer er god praksis med HTTP/2, men dårlig praksis i HTTP 1.1. Det gjør at om du optimaliserer ytelsen etter HTTP/2s vilkår, kommer det å straffe de som kjører eldre teknologi, så fundér på når det er verdt å ta steget.

Denne punkten handler mer om å følge med på hva som forventes av et moderne nettsted. I skrivende stund er HTTPS noe sånn noenlunde praksis for å få et ekstra dytt innen søkemotoroptimalisering, og før eller siden er det versjon 2 av HTTP, det vil si HTTP/2, som kommer til å være noe som oppmuntres innen SEO.

Om HTTP/2

Du som ikke har en anelse om hva HTTP er for noe, kan jeg kort forklare at det står for HyperText Transfer Protocol, noe som antyder at det er protokollen for hypertekst – det vil si HTML. Man kan si at HTTP er det hemmelige språket datamaskinen din snakker med den webtjenesten du kobler til. Du har sikkert sett det i adressefeltet når du har surfet på nettet. Når det i stedet står HTTPS betyr det at det ligger et lag med sikkerhet oppå HTTP, dette i form av noe som kalles for TLS (står for Transport Layer Security).

Den versjonen av HTTP vi har nå ble standardisert på 1990-tallet og krever en del lapping og laging for at det skal fungere slik nettet ser ut i dag. Derfor startet Google arbeidet med SPDY, som ble startskuddet for den nå standardiserte HTTP/2 (navnet på versjon 2).

Det HTTP/2 tilbyr er å gjøre våre nettbaserte tjenester raskere, enklere og mer robuste. Dette gjøres på teknikerspråk gjennom å støtte full multiplexing, noe som reduserer ventetiden. Målet er å omtrent halvere tiden det tar å laste inn en nettside. Dessuten innføres komprimering på HTTP-hodet, noe som betyr at innholdet i omfattende cookies ikke kommer til å senke ytelsen fullt så mye.

Du som har lest på om HTTP kan imidlertid være rolig. Egentlig er det ingenting av det du har lært deg som endres, det er samme navn på felt og samme metoder som tidligere. På grunn av dette er en overgang til HTTP/2 ganske udramatisk.

Det er en god idé å proaktivt undersøke om man kan støtte HTTP/2 med sitt nettsted, til å begynne med uten at det forstyrrer i de tilfellene en stor andel består av mindre sofistikerte besøkende med HTTP 1.1.

Nå kan nettsteder pushe varsler

En helt ny ting med HTTP/2 er at webserveren selv kan ta initiativet til en kontakt med en klient/nettleser. Tidligere har nettet gitt inntrykk av å kunne ha toveis-kommunikasjon. Men på et teknisk nivå utsettes webserveren for et hukommelsestap mellom hver tilkobling, og klienten var nødt til å med jevne mellomrom minne om sin eksistens. Det vil si, klienten gjorde konstant forespørsler om serveren hadde noe nytt å si.

At webserveren nå kan ta initiativet til denne kontakten bør også spare på bortkastet trafikk, redusere belastningen på datamaskiner noe som gjør at de bruker litt mindre strøm. Dette har man frem til nå forsøkt å løse gjennom en teknikk kalt websocket, men der kan det skje utvikling fremover.

Webhotell eller egen server?

Ligger nettstedet ditt på et webhotell får du nok pent vente til de bestemmer seg for å tilby dette. Men om det ligger på en egen server kan det være verdt å sjekke hva som lar seg gjøre. Det er på ingen måte hastverk å gjøre en overgang til HTTP/2, men ved neste gjennomgang av nettstedet er det definitivt aktuelt. Om nettstedet ennå ikke kjører HTTPS bør også det evalueres. Det HTTPS viser for din besøkende er at dennes integritet er verdifull, at skjemaer som postes ikke kan snoopes opp på veien mellom nettleseren og nettstedet. Samt at innholdet på respektive side er hemmelig for de som administrerer alle nettverk på veien mellom den besøkende og nettstedet.

Samtlige nettleserprodusenter har lovet å implementere HTTP/2, så da gjenstår bare at din webserver får støtte for at du og dine brukere skal kunne dra nytte av denne nye versjonen av HTTP.

Sørg for at sporing av nettstedssøk, outbound links, feilsider og nedlastinger fungerer

Overraskende ofte når jeg har hjulpet til med kollegaers og kunders nettstedstatistikkverktøy har man ikke sporet hvilke søkeord som brukes på nettstedets egen søkefunksjon. De fleste har i dag en søkefunksjon, og som du kan lese i denne bokens fordypning i emnet søkeanalyse er det en verdifull ressurs.

For den som tenker at man kan nøye seg med å ha kontroll på søkeord folk bruker på eksterne søkemotorer som Google, har man gått glipp av en helt avgjørende forskjell. De som søker på Google er åpne for forslag om hvem av alle som kan hjelpe dem videre, mens de som søker vel inne på deres nettsted søker etter hva de tror finnes på deres nettsted. På den måten kan man i klartekst få vite brukernes forventning og håp. Dessuten er det interessant å sjekke hva som ettersøkes da det tyder på at brukerne kan ha vanskelig for å finne nettopp det innholdet. Kanskje trenger det å løftes frem?

Ikke bare sporing av søk er slikt du skal konfigurere i ditt verktøy, det finnes sikkert mye mer. Problemet med å ikke gjøre disse innstillingene proaktivt er at det ikke alltid lar seg gjenskape i etterkant når du innser at de er bra. Kanskje begynner du på rute ett.

Se også til at sporingen av utgående lenker gjøres korrekt, du vil kunne vite til hvem du driver trafikk. Selvfølgelig er du interessert i å vite når brukerne havner på feilsider, og er det mulig å spore enda mer alvorlige feil kan det vise seg nyttig. Tilbyr du nedlastinger på nettstedet, eller har en masse innhold opplastet, sørg for at du vet hvordan det brukes. Utenforstående kan kanskje direktelenke til deres innhold uten at dere forstår hva som skjer.

Iblant kan man gruppere ulike typer innhold i sin nettstedstatistikk. La oss si at man har artikler for inspirasjon, produktsider og supportsider, da kan det være interessant å se hvordan de bidrar til helheten.

Ikke lekke person- eller kundeopplysninger til webanalyseverktøy eller andre tredjepartssystemer

Uten at man tenker over det kan mer eller mindre sensitive opplysninger havne i systemer der de ikke hører hjemme. Mest bemerkelsesverdig er vel om man lekker sensitive personopplysninger til tredjepart, men selv om det havner personopplysninger i feil verktøy kan det innebære en risiko for misbruk.

Så fort man samler inn personopplysninger er man også ansvarlig for hvordan disse håndteres, hvem som kommer til dem, etc. I de fleste land finnes lover som regulerer integritet og databeskyttelse. Det kan være verdt å gjøre litt research rundt dette for det markedet man opererer på, slik at det ikke kommer som en ubehagelig overraskelse senere.

Vil man snakke med utviklerne på utviklerspråk, eller kravstille det i sitt ytelsesbudsjett, kodningsstandard eller hva man vil kalle det, er det at man forventer at innhold og skjemaer bruker POST-metoden i HTTP. Som pensjonert utvikler kan jeg vel innrømme at mange utviklere ikke er så jævlig gode på HTTP. Om man eksemplifiserer det med at man ikke skal bruke GET, klarner det kanskje. Om det trengs mer utdypning, nevn noe med at det ikke er meningen at et postet skjemas felt skal vises i klartekst i adressefeltet.

Faktum er at denne typen håndtering dessuten gjør det litt mer tungvint å få oversikt, ettersom man får flere unike adresser til en og samme visning i nettstedet. Om det omstendelige ikke var argument nok, eller at det er dårlig praksis, er det også et brudd på blant annet Google Analytics' avtale å sende dem personopplysninger. Det er vel best å la være før man får sin konto helt brutalt stengt for avtalebrudd.

Tre eller færre stilmaler

Stilmaler er norsk for CSS (Cascading Style Sheet) som er en løsning, tro det eller ei, fra 90-tallet, skapt av Microsoft. Tanken er å skille formgivning fra innholdet og strukturen på en nettside.

Det er vanskelig å argumentere for at en besøkende på et nettsted har nytte av at stilmalen er oppdelt i mange ulike filer. For utvikleren som skapte nettstedet derimot kan det være veldig smidig å ha flere stilmaler.

Hvor mange CSS-filer trenger vi?

En stilmal som nullstiller alle avstander til nettleserens ytterkanter er ikke uvanlig (såkalt reset.css), en til for grunnleggende design, og en til for felles farger slik at man følger den grafiske profilen. En ytterligere CSS-fil for at nettstedet skal følge responsiv webdesign (som ofte er et tillegg til eksisterende nettsted), og en til for å sette farger på den lokale versjonen av nettstedet.

Deretter tilkommer det ikke sjelden noen stykker avhengig av dine tillegg i Wordpress (eller fulhackende webkonsulenter). Men la oss nøye oss med 5 CSS-filer å laste ned, så vi er på den sikre siden i et lite matematisk eksempel.

Hvorfor minimere antallet stilmaler?

Grunnen til at du vil ha få stilmaler, CSS-filer altså, er at hver fil som skal lastes ned har en ventetid før den begynner å sendes til den besøkende. Dette skyldes det kidsa av i dag kaller for lagg. Nøyaktig hvor lang denne ventetiden er avhenger av i det minste tre faktorer:

1. Den webserveren som sender filen.
2. Nettverket mellom serveren og den besøkende.
3. Den besøkendes egen tilkobling til nettet.

På grunn av denne ventetiden vil man normalt sett ha så få filer som mulig å sende til en besøkende. Jo flere filer desto mer tid som går til spille på venting.

Ta eksempelet ovenfor med fem CSS-filer. I best tenkelige scenario kommer det ikke å merkes i det hele tatt, da regner vi kaldt med at de besøkende sitter på en kablet tilkobling, solen skinner, alle bortsett fra dine besøkende er ute i en bypark og griller pølser og drikker rosévin. Akkurat din tiltenkte målgruppe er de eneste som bruker Internett og serveren din har det bra.

I et mer rimelig scenario kommer i det minste noen i din tiltenkte målgruppe å være i den situasjonen at de har en tvilsom mobil 3G-tilkobling med svartider på 0,1 sekunder. Det innebærer at det går med et halvt sekund bare for å vente på å få vite hvordan innholdet skal se ut, hvilke farger og skrifttyper som brukes og hvordan høyrekolonnen skal falle inn i bunnen på siden for mobile besøkende. Da har vi ikke regnet inn tiden det tar å overføre CSS-filenes faktiske innhold – bare den tiden det tar å vente på at filene skal begynne å sendes.

Hvorfor har man mer enn en eneste stilmal?

Ja, det kan man faktisk undre seg over. Om jeg spekulerer, og trekker veksler på mine erfaringer som webutvikler, ville jeg påstå at det skyldes latskap i kombinasjon med upresise krav fra bestilleren. Man skylder fra seg og mener at kunden burde kunne webutvikling bedre enn de webutviklerne man i anskaffelsen solgte inn som landets fremste eksperter.

Det er alltid litt for enkelt å skylde på bestilleren. Akkurat i dette tilfellet kan det tilkomme flere CSS-filer for brukeren å laste ned for hver «hurtigfiks» som gjøres på et nettsted. Eller om du nå kjører Wordpress, får du passe deg for hvilke ekstrafiler et plugin trenger.

Fulhack, hurtigfiks, latmasker, uvitenhet eller ingen yrkesære?

Jeg har dessverre vært med om at kollegaer har lagt inn en ekstra CSS-fil på en side. Da jeg spurte hvorfor de valgte å tilføre enda en fil som forsinker innlastingen av et nettsted, fikk jeg ofte til svar at det var den raskeste løsningen. Er man ikke enige om en form for minimumsnivå av kvalitet, er det dessverre bare å si seg enig, det er absolutt enklest og raskest å gjøre fulhack – det er derfor det heter fulhack…

3 eller færre Javascript-filer

Ikke sjelden lastes det ned en masse Javascript man som bruker aldri kommer til å ha bruk for. Ofte er de oppdelt i flere filer, noe som bidrar til ekstra ventetid. Som vi nettopp konstaterte er det normalt sett en fordel jo færre filer som trenger å sendes til en besøkende.

Du lurer kanskje på hvorfor man gjør det på denne åpenbart sløsete måten og deler opp innholdet i flere filer? Ja, det enkle svaret er at det er enklere å beregne kostnaden for at en utvikler skal bli ferdig raskt enn all den tiden man sløser på brukernes bekostning.

Selvfølgelig trenger det å skje en avveining av interesser her. Derfor trenger man å ha en form for målestokk over hva som er ok når det gjelder bruk av Javascript. Akkurat dette punktet handler om antallet Javascript-filer, at man skal slå dem sammen, men det finnes selvfølgelig en grense for hvor stor filen får lov å være for at man skal vinne noe.

Vanlig forekommende oppdeling av Javascript

Ikke sjelden har man noen ulike kategorier av Javascript-materiale, for eksempel Javascript som:

• Omgjør menyen på små skjermer, setter dit en slik hamburgermeny som sparer massevis med plass.
• Støtter interaksjon i skjemafelt, for eksempel gjennom å fortelle hvilke obligatoriske felt brukeren glemte å fylle ut ved posting.
• Følger med designrammeverk, for eksempel Bootstrap, som hjelper til med designkomponenter som dialogbokser, hvordan feilmeldinger skal vises (og en masse ytterligere designmagi man har valgt å ikke bruke på akkurat sitt eget nettsted).
• Jquery-biblioteket slynges ofte med av vane, men ganske ofte kreves det som komponent av andre komponenter.

Foruten disse har man ofte fått et eller flere Jquery-baserte tillegg for bildegallerier, karaktersetting av sider og annet.

Om man ikke passer seg får man disse Javascriptene i hver sin Javascript-fil. For den som velger å forsøke å gjøre en god jobb stilles man overfor hvilke Javascript man skal kombinere til en eneste fil (om nå ikke alle). Problemet er at du må gjøre en avveining mellom å sende Javascript-kode som ikke kommer til å brukes av enhver besøkende og å dele opp det hele i flere logiske grupperinger. Alle dine besøkende kommer ikke til å se bildegalleriet, for eksempel, så alle trenger ikke de Javascript-filene.

En ting er imidlertid klart, latmaskerversjonen altfor mange kjører med er at all Javascript lastes ned fra hver sin fil uansett om de i det hele tatt trengs på den siden som ber om dem.

Si for eksempel at man har valgt å ha massevis med enkelte Javascript-filer, da bør bare de som trengs for en bestemt underside lastes ned. Altså lastes ikke Javascript for skjemavalidering ned på en side som mangler skjema.

Alternativ metode er lazy loading

Lazy loading er et designmønster som går ut på at det som trengs for en sidevisning lastes ned litt senere, eller kun ved behov. Akkurat som at bilder i bunnteksten ikke trenger å lastes ned for majoriteten om bare et fåtall scroller seg ned dit, på samme måte kan Javascript-filer lastes ned når de kommer til bruk.

Motivasjonen for dette er selvfølgelig å ikke tynge ned mer enn nødvendig. Kritikken mot å slå sammen alle Javascript-filer er at da får brukeren ta imot massevis med data som er unødvendig for akkurat deres besøk.

Det lazy loading forutsetter er at svartiden trenger å være veldig lav, det vil si at det går ekstremt raskt å fra den besøkendes nettleser få noe overført fra webserveren. Det er definitivt ikke tilfellet om den besøkende har en trådløs tilkobling via 3G- eller Edge-nettet. Derimot er det utmerket for 4G-nettet og selvfølgelig alle moderne kablede tilkoblinger. Så spørsmålet er hvilken type besøkende ditt nettsted har, og hvor stor andel av dine besøkende er forsømmelige for det designmønsteret du velger.

Det finnes som du forstår grunn til å ha et visst slingringsmonn, og i min verden er tre Javascript-filer det slingringsmonnet, særlig da det uten særlig stor anstrengelse ved nybygg av et nettsted kan være en eneste Javascript-fil.

Utover antallet Javascript vil man helst ikke at de lastes inn før siden kan vise seg, dette kan du sjekke i Google Pagespeed nå for tiden, tror det står at man skal prioritere synlig innhold om de mener at man har feilet («above the fold»).

3 eller færre bilder for utseendet

Utviklere bør bruke CSS i stedet for bilder i så stor utstrekning som mulig. I fordums tid, da man lagde layout med tabeller, brukte man bilder, som blank.gif, for å dytte bokstaver inn fra venstremarginalen. Dessuten kunne man ikke regne med at CSS fungerte i eldre nettlesere.

I dag finnes det løsninger på de fleste av disse problemene. De kalles for polyfills, shims og en del annet, men poenget er at de lapper og lager på gamle elendige nettlesere. Det gjør at frontend-utvikleren (den som skriver CSS, HTML og Javascript) kan bruke moderne webstandardisert kode.

Grunnen til at vi vil holde nede antallet filer er den samme som jeg har skrevet tidligere, ekstra filer bidrar med ekstra ventetid – noe som særlig rammer de med ustabil internettilkobling. Best er som alltid å sende så lite som mulig og bare det man absolutt må.

«Men da slenger jeg inn en webfont, en SVG-fil, og en CSS sprite!»

Javisst, men disse tre løsningene er jo i mange tilfeller løsning på samme behov. Men da har man holdt seg til maks tre, noe som er min anbefaling, selv om det kan kjennes litt sløsete.

Webfonter kan foruten å beskrive utseendet på tekst inneholde ikoner man bruker på sin nettside. Kanskje et hus for hjem, et konvolutt for kontakt m.m. Webfonter er dessuten skalerbare og passer derfor godt på nettet i dag når man ikke vet hvilken størrelse på skjerm den besøkende kan tenkes å ha eller om den er høyoppløst.

Et responsivt nettsted kan også bruke SVG (Scalable Vector Graphics). Med SVG kan du til og med vise ulik grad av detaljer i illustrasjoner fra SVG-filen avhengig av hvilken flate som er tilgjengelig – responsiv ikonhåndtering med andre ord.

Bilde 62: Glyphicons som brukes i rammeverket Bootstrap

Den mer innarbeidede løsningen er CSS sprites. Det går ut på at man har massevis av bilder sammensatt til ett eneste bilde. Deretter bruker man CSS for å ha et lite «tittehull» mot det bildekartet. Man posisjonerer altså bildekartet bak et tittehull og da synes bare ønsket bilde.

Last bare inn det som trengs, når det trengs

Denne aktiviteten bør ikke tolkes bokstavelig, men ses som et veiledende prinsipp. Et vanlig eksempel er at først når brukeren vil legge igjen en kommentar begynner man å laste inn de filene som trengs for akkurat den delen. Si at du bruker en tredjepartstjeneste, som Disqus for kommentarer, så lastes de filene inn ved behov i stedet for ved hver eneste sidevisning.

Også når det gjelder filer som skal sendes fra ens egen webserver kan man jobbe på denne måten. Dette er særlig interessant om man har oppgradert til HTTP/2 da det ikke er like kostbart, ytelsesmessig, å sende en ny fil. Men glem som sagt ikke å ha kontroll på opplevelsen for de brukerne som ennå ikke støtter HTTP/2 med det utstyret de bruker. Her skal du tenke nøyaktig som med designprinsippet om progressive forbedringer – alle skal ha en god opplevelse, men de med veldig moderne utstyr kan få en enda bedre opplevelse.

Et første steg i denne retningen er å pakke ulike typer innhold i ulike grupper. At filer på et nettsted kan ha interne avhengigheter av hverandre kalles for AMD (Asynchronous Module Definition)⁶⁵ og det finnes koderammeverk, som Require.js, som hjelper til. Dette er mer noe å se på når man bygger om eller bygger nytt.

Sørg for at du har tilgang til gode data for webanalyse

I det minste i større organisasjoner har man ganske kompliserte IT-miljøer. Ting jeg har snublet over ikke bare der jeg har jobbet men også på det offentlige nettet er at man får feilmeldinger, sendes til en innloggingsside eller stoppes av en annen grunn. For å ha full kontroll på brukerens opplevelse trenger du å sørge for å ha data om disse avvikene, du kan ikke regne med at alt slikt samles inn i ditt webstatistikksystem.

Som aller lavest bør ditt verktøy for webanalyse samle inn data når brukere lander på din Error 404-side, men det finnes massevis av andre feilmeldinger. For eksempel at man ikke har tilgang til siden og trenger å logge inn, eller at siden har krasjet av en annen grunn.

Iblant er det kanskje ikke engang teknisk mulig å samle inn disse hendelsene til ditt verktøy for webanalyse. Men ikke engang da skal du gi opp! Om det er noe man kan slå fast er at teknikere som lager utstyr har hatt en form for logging for deres egen del. Forsøk å komme over den loggen. Innholdet er kanskje ikke særlig pent eller forståelig, men det er viktig å nå kunnskap om brukerens opplevelse. Det finnes verktøy som kan hjelpe deg å stadig ha oversikt. Vil du stadig vite hvordan situasjonen er nå eller nylig, kan du sjekke logganalyseplattformer som ELK (Elasticsearch Logstash Kibana). Men vil man holde hardere i pengene kan man sjekke selvhjelpsverktøy for det voksende området rundt data science, for eksempel Tableau (som også finnes i en gratisversjon, kalt Public).

Validere i henhold til WCAG 2.0 nivå AA

Fra og med 1. januar 2015 ble det ulovlig å på sitt nettsted diskriminere de med funksjonsnedsettelser. Det pleier å ta en stund før lover er prøvd i domstolenes alle nivåer, derfor er det ikke glassklart hvor grensene går. Det finnes selvfølgelig ulike nivåer av hvor stort overtramp man gjør mot en funksjonshemmet persons rettigheter. Å bli helt utestengt på grunn av sin funksjonsnedsettelse er jo et tilfelle man forhåpentligvis får vanskelig for å sno seg unna, mens domstolene nok ikke kommer til å inngi gudsfrykt i de som glemte å skrive alternativ tekst til et bilde.

Ganske umiddelbart ble Göteborgs Universitet anmeldt til diskrimineringsombudsmannen (DO) for diskriminering av blinde personer. Den som anmeldte mener at hen ble utestengt gjennom at påmeldingsskjemaet for utdanningen ikke var tilgjengelig 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, synshemmet som sammen med DO anmeldte Göteborgs Universitet for diskriminering⁶⁶

Vel opptatt til utdanningen viser det seg at den læringsplattformen som tilbys elevene ikke lar seg bruke for blinde. Det går ikke å motta meldinger fra lærere eller ta del av eksamensresultater. Göteborgs Universitet er imidlertid klar over 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

Om ikke den svenske lovgivningen er motivasjon nok, kom EU i mai 2016 frem til at det blir et felles «Webdirektiv». Det kommer til å gjelde offentlig sektor, de private aktørene som driver service på oppdrag fra offentlig sektor, og det som menes er nettsteder, intranett og apper⁶⁷.

En måte å slippe å diskutere nøyaktig hvilke ting man vil leve opp til og deretter argumentere detaljer med sine leverandører av websystemer, eller webutviklere, gjør det klokt å velge en etablert standard. WCAG 2.0 (Web Content Accessibility Guidelines) er en slik standard. WCAG tilbys av webstandardorganisasjonen W3C.

Det finnes tre ulike nivåer, nemlig A, AA og AAA. Jo flere A desto strengere etterlevelse av funksjonshemmedes behov. Hvilket nivå du velger er opp til deg, men følger du nivå AA ville jeg tippe at du ikke risikerer å felles på grunn av verken diskrimineringslovgivningen eller EUs webdirektiv, men jeg er jo ikke jurist :)

Hmm, hva innebærer dette med WCAG?

Egentlig bør veldig lite av de kravene WCAG stiller være nyheter for noen som har jobbet en stund med publisering på nettet. Blant annet betyr dette at man skal tilby tekstalternativer, for eksempel at bilder skal ha en alternativ tekst. Lager du videoklipp får du da også tenke på å ha et tekstalternativ for det som sies.

Det stilles også krav til kontrastforholdet mellom tekst og dens bakgrunn. Hvor høy kontrasten skal være avgjøres av tekstens størrelse. Apropos tekst skal den kunne skaleres om, noe som skaper problemer for deg om du er vant til å legge tekst i bilder for eksempel ved opprettelsen av bildepromoer eller bannere.

Mer om tilgjengelighet og testverktøy

W3C har en liste med verktøy⁶⁸ for å teste tilgjengeligheten på en nettside. Ettersom det finnes ulike regelverk er det verdt å sjekke at du lever opp til minimumskravene der du har virksomhet. For eksempel 508 Checker for å ikke bryte mot den amerikanske lovgivningen.

Hvis du har varsler, så følg opp!

Det blir stadig vanligere at nettsteder har varsler. Enten på gammeldags vis at man inne i grensesnittet har tall eller andre markeringer om at det bak en knapp skjuler seg uleste eller nye ting. Men i senere tid kan nettsteder varsle også om nettleseren ikke er synlig på skjermen.

Du som har brukt jobbnettverket Linkedin.com kan ikke ha unngått at deres varslingssystem har vært ødelagt siden begynnelsen. Microsofts Yammer har også vist en liten indikasjon for å påkalle oppmerksomhet når det under ikke finnes noe nytt å se. De er sikkert ikke alene på lange veier. I og med at brukere kan være tilkoblet mot samme tjeneste via flere samtidige kanaler, som app, mobilweb og web på en datamaskin (for øyeblikket i hvilemodus i ryggsekken).

Har ditt nettsted varsler, sørg for å følge opp om det fungerer som det er tenkt. Enkleste løsningen er vel å spørre sine brukere eller selv bruke tjenesten sin flittig.

Et annet alternativ er å designe tjenesten slik at man kan følge opp det. Det går an å bygge inn logging av brukergrensesnittet. For eksempel om en knapp har hatt statusen «nye meldinger» og om det likevel bare var leste meldinger etter et klikk.

I dag kan jo også datamaskiner motta denne typen varsler, så vi risikerer å fremstå som mer enn lovlig inkompetente om det pinger litt overalt men ingenting nytt finnes å se.

Viktige utgående lenker skal lede til tilgjengelige nettsteder

Dels hjelper du de av dine egne besøkende som har en funksjonsnedsettelse, samtidig styrer du med hjelp av dine utgående lenker ditt nettsteds tillit og kraft mot sider som har de samme verdiene som du har.

Eksempler på verktøy for å sjekke nettsteders generelle tilgjengelighet gjøres med verktøy som WAVE⁶⁹, eller om du vil automatisere kontrollen kan du sjekke ut Tenon.io⁷⁰ – du kan kanskje ikke regne med at webredaktører tar seg tiden.

Sidevisninger skal være på under ett sekund?

En vinkel på hvorfor det er viktig for deg er søkemotoroptimalisering (såkalt onpage-optimalisering). Google gir deg en viss tid for deres indeksering. Da er det jo bra om de rekker mange sider, eller hva?

For å løpende holde oversikt over søkegigantens resonnement rundt webytelse er det deres ytelsesguru Ilya Grigorik du skal følge. Vil du lese deg inn på teknikaliteter har han lagt ut sin bok gratis på nettet – High Performance Browser Networking⁷¹.

Bedre brukervennlighet på nettstedet som fører til høyere konvertering

En annen grunn til at et nettsted trenger å være raskt er for brukernes skyld. De mister følelsen av flyt og opplever at de venter omtrent når det har gått ett sekund. Da risikerer man å miste sin bruker før de oppnådde det du eller hen ville med besøket.

Anbefalingen er å servere en side på omtrent 0,1 sekund. Da oppleves det som at interaksjonen er umiddelbar. Tar det mellom 1–10 sekunder begynner brukeren å oppleve at de venter. Selv om studier viser at de fleste klarer å holde konsentrasjonen på det de driver med, begynner teknikken å irritere brukeren.

Sløser ikke med webserverens ressurser

En uvanlig vinkel på hvorfor et nettsted skal laste raskt er at webserveren som sender siden ikke kan håndtere et ubegrenset antall samtidige overføringer. Det faktiske antallet varierer selvfølgelig med hvor kostbar løsning man har, men det finnes potensial til å senke sine serverkostnader, klare seg lenger på eksisterende servere eller kanskje å være mer klar for en trafikktopp ved en krise eller en vellykket kampanje.

Gratis verktøy for å måle en sides lastetid

Vil du gjøre det enkelt for deg, sjekk ut Googles verktøy Pagespeed Insights, den advarer om serverens svartid er for lang. Samtidig, Pingdom har flere tjenester for dette, men mest interessant er den som måler nettstedets svartid flere ganger i timen. Da får du et diagram over ytelsen over tid og kan også motta advarsler via en mobilapp.

Google Pagespeed mobilt skal være minst 80 av 100

Google Pagespeed er et konkret mål på hvor god ytelse et nettsted har, noe som både Google og ekte brukere bryr seg om. En grunn til at du kanskje nøyer deg med Googles synspunkt er at vi uansett er i deres vold når det gjelder SEO.

Nå er det kanskje ikke 80 av 100 akkurat du skal velge. Du trenger imidlertid å velge et nivå, noe som stemmer overens med din ambisjon rundt nettstedets ytelse. Du bør kanskje heve nivået og velge 90? Om mobile kunder er de viktigste for deg. Eller så velger du 50 om nettstedet ditt har en lang vei å gå for å bli bra i mobilen.

Google selv har imidlertid en mening om hva de synes er et godt nivå (min utheving):

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 dokumentasjon om Pagespeed Insights⁷²

Lag en testside for å evaluere endringer i webdesign

For at det skal være en rettferdig sammenligning fra en måling til en annen trenger man å teste under de samme forutsetningene. Med andre ord må man sette opp en representativ testside på nettstedet sitt. Akkurat den siden er den man gjør tester mot for å vite at resultatet er sammenlignbart over tid. Det som kan variere er webserverens svartid, ellers skal sidens innhold i redaksjonell forstand i stor grad være det samme fra en gang til en annen.

Gjør du det på denne måten vet du om endringer i webdesign har gjort situasjonen bedre eller dårligere. Det kan være at du prøver å bytte tema om du kjører Wordpress, at webkonsulentene dine har oppgradert noe eller muligens gjort en nyutvikling.

Hvordan man utformer sin testside

For at testsiden din skal være meningsfull gjelder det at den i redaksjonell utforming er praktisk talt den samme over en lengre tid. Om du skal kunne sammenligne resultatet før en oppgradering av publiseringssystemet med etter, gjelder det at innholdet er tilnærmet likt.

Mitt forslag er at du oppretter en underside utelukkende beregnet for test. Den siden skal inneholde tekst, bilder og slikt som er normalkomplekst for en vanlig side på nettstedet. Det er ikke her du bygger inn en masse merkelige eksterne tjenester, widgets, videoklipp eller slikt som verken du eller dine utviklere har kontroll over.

Gjør en nullmåling

Når du har testsiden din gjør du en første måling hos Google Pagespeed, deretter avstemmer du resultatet med alle involverte og dokumenterer det et sted (slik at folk forstår at dette må de leve med fremover). På en passende høytidelig måte burde man sikkert forklare at det ikke er akseptabelt at resultatet blir dårligere.

Eventuelt er du jo din egen motpart, da er en jurist noe overflødig og du får si til deg selv å skjerpe deg :)

Bilder skal bearbeides for nettet

Det finnes mye å tenke på når man utsmykker sitt nettsted, men også når man fyller det med redaksjonelt innhold. De som utsmykker er som oftest proffer på bildebehandling, men ikke alltid like profesjonelle på hva som gjelder for nettet og hvilke vilkår nettet stiller.

Så finnes det redaktører og alle brukere som laster opp materiale til nettsteder. Det er ikke alltid vi får det til, heller ikke sikkert at vi får hjelp av de verktøyene vi tilbys.

Iblant har man bilder via en mediebank, der mediebanken gjør jobben for en, iblant laster man dem opp manuelt. I dag, når alle til slutt har kjøpt inn på at nettsteder må være responsive ned til en mindre skjerm, oppstår enda et problem. Nemlig at de små skjermene ofte har høyere oppløsning enn de store, og derfor kan dra nytte av mer detaljrike bilder (samtidig er ikke skarphet avgjørende).

Men de små skjermene, mobiltelefoner i de fleste tilfeller, er også beheftet med den store ulempen av å ha en trådløs og iblant ustabil tilkobling. Det innebærer at selv normaloppløste bilder kan oppleves som kjempetrege å laste ned.

Bildebehandling for nettet er med andre ord vanskeligere enn noen gang.

Bilder bør være i den oppløsningen de skal vises

Et ytterligere krux er at de fleste responsive nettsteder har flytende kolonnebredde. Slik nesten alle har designet det finnes bilder som fyller hele kolonnens bredde, noe som fører til at vi ikke på forhånd vet nøyaktig i hvilken størrelse bildet kommer til å vises.

Ta da som et tankeeksempel at midtkolonnen kan være fra 300 til 500 piksler bred. Bildet som vises øverst i den kolonnen trenger å være like bredt som kolonnen for at det skal se «harmonisk» ut.

Velger du da å laste opp bilder som er 500 eller 300 piksler brede?

La oss regne på forskjellen. Si at bildet har et 2:1-forhold i sin størrelse. Da blir den større varianten 125 000 piksler (500 x 250). Er den i stedet 300 bred blir det totalt 45 000 piksler (300 x 150). Det er en kjempestor forskjell på bildeflate og valget ditt kommer definitivt å påvirke ytelsen.

Som løk på laksen har vi utfordringen med høyoppløste skjermer. Hva Apple-brukere kaller for retina. Det innebærer ofte dobbelt så høy oppløsning, det vil si at hver piksel blir fire for å nå maksimal skarphet – slik at det ikke ser uskarpt ut for de som har vent seg til skarpheten.

Ovennevnte bilde ville altså være 500 000 piksler for å være skikkelig skarpt (1000 x 500). Det er ti ganger så mye data sammenlignet med om du velger å sende bildet i 300 x 150.

Tør du å sende et slikt høyoppløst bilde til en mobiltelefon som innimellom er tilkoblet på et tvilsomt mobilnett? Her får du gjøre en avveining, men som jeg håper du har forstått er dette ingenting man kan gjøre uten omtanke. Grunnregelen er forrædersk enkel: bilder skal være i den oppløsningen de vises, samt at man ikke skal skalere dem ned med HTML eller CSS.

Er du bekymret for dette, les gjerne på om responsive bilder på nettet, dessuten har jeg litt mer om det i min bok Webbstrategi för alla.

Bilder skal lagres i egnet format

Grunnregelen er at bilder skal være lagret i det formatet som muliggjør minst filstørrelse i relasjon til en bevart bildekvalitet.

De fleste kjenner til formatene GIF (uttales tydeligvis «jiff» ifølge meningsytrere), JPG og PNG som noe man støter på på nettet. Disse formatene har sine styrker og svakheter, ekstremt kortfattet:

• GIF støtter animasjoner og transparens, men kun 256 farger. Effektivt nettopp for animasjoner og iblant enkle illustrasjoner, som logotyper.
• JPG er et format for fotografier. Veldig bra på alle bilder som mangler flater med én og samme farge – om slikt inntreffer pleier de å «blø» og vise rosa og grønne flekker om det er komprimert.
• PNG har to varianter, en på 8 bit og en på 24 bit. Den på 8 bit har likheter med GIF da man kan ha maksimalt 256 farger. Ved 24 bit får man også transparens samt at den da støtter millioner av farger. PNG er mest effektiv som 8 bit og for illustrasjoner, informasjonsgrafikk, logotyper med mer.

Deretter tilkommer initiativ som WebP, skapt i 2010. Noe som Google, Ebay og Facebook har drevet kampanje for. De viser jo veldig mange bilder så det ligger absolutt i deres interesse å få bred støtte blant nettleserne. WebP-bilder er ifølge tester jeg har lest opptil 25 % mindre i størrelse sammenlignet med den av de tre andre som presterer best. Så det er noe å holde øynene åpne for.

Bilder trenger å lagres for nettet

Når du har valgt riktig format trenger et bilde å lagres optimalisert for nettet. Dette finnes i alle bildebehandlingsprogrammer jeg har støtt på. Det kan være slik at om du nøler på at du har valgt riktig format, sjekker du de andre formatene når du lagrer for nettet. I det minste Photoshop støtter dette gjennom at man øverst til høyre i dialogboksen kan velge format.

Om du velger PNG, sjekk gjerne om filen blir mindre og fortsatt ser ok ut som 8-bit, gjerne med så få farger som mulig. Etter en stund får man ganske god følelse for hvilke bilder som kanskje fungerer som annet bildeformat.

Med JPG-filer kan du dels litt grovhugget velge nivå av komprimering, men det finnes også en glider der du kan velge mellom 0–100 hvor mye kvalitet du vil bevare. Vær oppmerksom på flater med samme farge eller nyanse, og særlig oppmerksom skal man være rundt flater med hud på mennesker der vi ser ut til å være ekstra følsomme. Personen på bilde kan oppleves som syk om bildet er optimalisert for hardt.

Det du kommer til å se ved for hard optimalisering er at detaljrikdommen ser ut til å forsvinne, at det oppstår misfargende ruter av oftest grønt og rosa. Klipp inn en bit hvitt i et foto og komprimer steinhardt, da ser du hva jeg mener.

Med en GIF-fil resonnerer du som en 8-bit PNG.

Kjør bilder gjennom ikke-ødeleggende optimalisering

Nå har du allerede tatt tre steg for at et bilde skal gå raskt å laste ned. Når blir vi ferdige egentlig? Ja, dette er det siste steget i den prosessen jeg selv tar.

Det vi nå gjør er å fjerne helt unødvendige data fra bildet – såkalt ikke-ødeleggende optimalisering. Poenget er at optimaliseringen ikke skal gå å oppdage med det blotte øye, men iblant kan filene bli veldig mye mindre. Regn med at minst 5 % lar seg høvle bort på absolutt hvilket som helst bilde.

Bilde 63: Imageoptim skreller bort opptil tre fjerdedeler av bilders filstørrelse.

Jeg som kjører Mac bruker det fantastiske programmet Imageoptim. Det fungerer så utmerket at jeg drar en masse bilder (kanskje hele nettstedets bildemappe) til programmets vindu og så optimaliseres alle bilder og overskrives på sin nåværende plass. Etter det laster man opp bildene igjen.

For deg som ikke kjører eller har tilgang til en Mac finnes webtjenester som gjør det samme, men litt mer omstendelig. Det finnes også tillegg til ens nettsted slik at dette kan gjøres automatisk (slik at man ikke trenger å huske det). Til mine Wordpress-nettsteder har jeg kjørt med et plugin som heter Ewww Image Optimizer⁷³.

Ikke bruke skrifttyper som må lastes ned

Mange ganger har en papirfokusert kommunikasjons- eller markedsavdeling valgt en spesiell skrifttype man vil bruke i all sin kommunikasjon. Kanskje tvinges man gjennom sin grafiske profil. Der skal ikke nettet stikke ut som et unntak, og da har man sørget for å sende skrifttyper (du vet det der som bestemmer hvordan bokstavene skal se ut) også til besøkende på nettet.

Så finnes det tilfeller når et designrammeverk webutviklerne har brukt for å spare tid gjør at den besøkende må laste ned skrifttyper for å vise nettsiden. Disse skrifttypene er ikke alltid avstemt med identitetsansvarlig innen organisasjonen.

Som vi tidligere har konstatert er det klokt å forsøke å ha så få filer å laste ned som mulig. Dette særlig om man har en stor andel brukere som ikke har en kjempegod internettilkobling.

Apropos dårligere internettilkoblinger skal man også være klar over at det kanskje ikke blir nøyaktig som man tenkte seg med den der fine skrifttypen. Det finnes et ganske selvforklarende begrep, Flash of Unstyled Text (FOUT)⁷⁴, som belyser problemet med at tekst kan rekke å vises med en standardskrifttype og deretter blinker det til når skrifttypen man nettopp sendte benyttes. Det finnes flere varianter på dette problemet, Flash of Invisible Text som på bildet her ved siden av.

Bilde 64: Vi har nok alle ventet på usynlig tekst. Som disse sosiale knappene uten tekst. (Kilde: SimonW på Twitter).

Webtypografi

Selv om man ikke har valgt en spesiell skrifttype er det ikke sikkert at den skrifttypen man har valgt er den som vises for de besøkende. Hvordan dine skrifttyper fungerer kan du sjekke på Font Family Reunion⁷⁵. Jeg har selv funnet halvekstreme typografiske avvik der en skrifttype uten seriffer (såkalt sans-serif) er erstattet med en annen skrifttype som har seriffer (såkalt serif).

Laste inn skrifttyper via Google Fonts?

Bruk gjerne Google Fonts som tjeneste for å laste ned skrifttyper (om du nå må). Fordelen er at om skrifttypen er vanlig blant andre nettsteder som bruker Google Fonts, finnes sjansen for at skrifttypen allerede finnes i nettleserens hurtigminne hos dine besøkende og dermed ikke trenger å lastes ned på nytt.

Ulempen er at det i mange tilfeller ikke allerede er nedlastet, men sannsynligvis er Googles servere raskere enn dine. En annen ulempe er at du har litt av samme integritetsproblematikken som med webanalyseverktøyet Google Analytics om du lar Google hjelpe deg med å servere innhold til dine brukere.

Som du forstår er det her med webtypografi heller ikke noe man skal overlate til tilfeldighetene. Vil man ta den enkle veien ut er tipset å ikke ha noen ekstra skrifttyper, men velge en vanlig forekommende skrifttype som har en høy leseverdi – en skrifttype som ikke trenger å lastes ned.

Følge W3Cs anbefalinger for HTML, CSS og Javascript

Praktisk talt alle nettsteder består av HTML for sitt innhold og struktur, CSS for hvordan det skal se ut visuelt og Javascript for å støtte interaksjon. Det finnes flere måter å skrive kode i disse språkene, men det finnes også anbefalinger. Å sørge for at ens kode fungerer i mange nettlesere, for så mange som mulig, uten å stille en masse krav er det som kalles for at man følger webstandard. Webstandard er en god praksis å følge om man ikke har eksepsjonelt gode grunner til å la være.

Hvordan vet jeg at vi følger webstandard?

Det finnes ingen sertifiseringsorganisasjon (så vidt jeg vet) som deler ut Ok-stempler til de som følger webstandard. Dessuten er det nok, i det minste i juridisk forstand, et altfor ullent begrep for å oppsummere alt som skal stå i en avtale mellom bestiller og utfører.

I stedet får man koke det ned til å følge de anbefalingene standardorganisasjonen W3C (World Wide Web Consortium) har satt opp for den grensesnittkoden som sendes til de besøkende.

Følger man anbefalingene øker sannsynligheten for at det ser ut som det skal og fungerer uansett hvilken nettleser eller type enhet brukeren velger.

Men alle de kule nymodighetene jeg vil bruke da?

En nyttig motvekt til vår naturlige nysgjerrighet på å teste nye heftige muligheter er den stadig strengere lovgivningen innen tilgjengelighet. At det er diskriminering å begrense folks muligheter til å bruke nettet.

En måte å forsøke å samkjøre flere interessenters behov er å ta utgangspunkt i designstrategien kalt progressive enhancement. Den går ut på at standardinnstillingen er at alle skal være velkomne, men at man uten å forverre funksjonshemmedes opplevelse kan tilby finesser til de hvis tekniske forutsetninger tillater slikt.

Et ytterst enkelt eksempel på dette er hvordan CSS 3 fungerer i nettlesere, støttes det ikke vises ikke runde hjørner på bokser. Det forverrer ikke den grunnleggende opplevelsen for noen, muligens beriker den opplevelsen for enkelte.

En annen designstrategi er graceful degradation. Den begynner til forskjell fra progressive enhancement fra andre enden – at finesser skaleres bort uten å skape trøbbel.

Min personlige anbefaling er å kjøre progressive enhancement men at tankegangen fra graceful degradation brukes i feilhåndtering og de feilmeldingene man gir ut til brukere.

W3C har en tjeneste, Markup Validation Service, som hjelper deg å sjekke om en nettside følger kodestandarden den utgir seg for å følge.

Minifisere frontend-kode

Leser du koden bak nettsider? Det vil si HTML, CSS og Javascript? De fleste gjør ikke det, og det er jo selvfølgelig ikke derfor man har en nettside. Man kan spørre seg hvorfor det er så vanlig at webutviklere prioriterer sin egen yrkesgruppes interesse av lesbar kode fremfor de besøkendes behov for en rask opplevelse.

For en webutvikler er det kjempesmidig med lesevennlig kode når noe trenger å sjekkes på et nettsted som ligger ute skarpt på nettet. Webutviklere sysselsetter seg mer enn gjerne med nesten religiøst fundamentalistiske stillingtakinger rundt hvordan man bør bruke mellomrom i stedet for tabber, eller omvendt, når man skal radbryte kode etc.

Derimot du som forsøker å betale regningene på nettbanken bryr deg jo fullstendig blankt i hvor lettlest koden er for den ekstremt lille gruppen som produserer nettsteder, det eneste du bryr deg om er at det fungerer bra og raskt.

Minifisering i praksis

All grensesnittkode (også kalt frontend-kode på svorsk) bør minifiseres om det kan redusere filstørrelsen nevneverdig. Det gjør filen lettere å laste ned. Det gjelder selvfølgelig bare tekstfiler, men med tanke på hvor mye Javascript og CSS mange nettsteder bruker kan det gjøre ganske stor forskjell. Jeg har sett alt mellom 5 og 90 % mindre størrelse på filer som er minifisert, det påvirker som du forstår hastigheten en del.

Hvordan man begynner å minifisere (som utvikler eller på Wordpress)

Det finnes flere måter å innføre minifisering på et nettsted. Da jeg bygget på Microsofts ASP.NET-plattform har jeg valgt å kjøre med byggeskript (såkalte MSBuild) som gjør at når kode pakkes for publisering vaskes alt fra å gjøre utvikleren glad til i stedet å møte brukernes behov. I mitt tilfelle kjørte jeg med Yahoos YUI Compressor. Mange som kjører med utviklerverktøyet Visual Studios prosjektmaler for ASP.NET MVC velger å kjøre med automatisk bundling (sammenslåing av filer) og minifisering. Automatikken er i det minste bedre enn å la være.

Byggeskript fungerer fint for små team, men er ikke perfekt om man jobber med kontinuerlig integrasjon/oppdatering. Da trenger man å bygge inn dette i sin byggeserver eller hvor i arbeidsflyten det nå kan tenkes å passe inn.

Bilde 65: Minifisering inngår i Cloudflares gratisabonnement.

For den som kjører Wordpress kan man evaluere diverse tillegg, eller det kan finnes som et tilvalg for den som har CDN/innholdsnettverk som fronter ens nettsted. Trenger man manuelt å minifisere filer kan du gå til webtjenester som Minify Code.

Det eneste helt gyldige motargumentet jeg har hørt så langt er at om ens nettsted sender alle tekstfiler komprimert, er akkurat innsatsen med minifisering ikke like avgjørende. Komprimering går, veldig forenklet, ut på å finne mønstre som teknisk kan beskrives. Et slikt mønster er 20 tomme rader i HTML-koden, eller at hver rad innledes med massevis av mellomrom for innrykk. I de tilfellene kommer komprimeringen å gjøre en del nytte. Om du bare vil velge én innsats med hvordan du bearbeider tekstfiler, synes jeg at du prioriterer komprimeringen høyere.

Og nei, det er ikke synd på utviklere om man gjør koden mindre lesevennlig. Utviklere løser gjerne sine egne problemer først og det finnes en rekke tjenester for å gjøre kode lesevennlig igjen. Blant annet under navn som «HTML Formatter», «Online Javascript beautifier» for Javascript-kode og «Format CSS Online» for CSS-kode.

Nå burde alle kunne være fornøyde – samtidig :)

Sende tekstfiler komprimert

Veldig stor andel av nettet består av tekstfiler. Det kan være HTML for innhold som skal vises i nettlesere. Formgivningen på nettsteder støttes av CSS (også kjent som stilmaler) som også er «vanlig» tekst. Det samme gjelder Javascript som hjelper til med blant annet interaksjon. Så finnes det massevis med andre filer i tekstformat. Man kan argumentere for at alle filer består av tekst, men det ignorerer vi akkurat nå.

Hvorfor komprimere?

Praktisk talt alle tekstfiler har overflødig informasjon. For webkode kan det være at webutvikleren har beholdt en pen formatering (full av mellomrom m.m.) for at den skal være lettlest, men selv i løpende tekst finnes ofte gjentagelser eller slikt som kan pakkes sammen av en smart komprimeringsalgoritme.

Poenget med komprimering er å gjøre ting mindre. På nettet komprimeres tekst før den sendes til en besøkende ved hjelp av Gzip nettopp for at filen skal være så liten som mulig og ta så kort tid som mulig å overføre. Man forsøker å tilby en så rask opplevelse som man kan.

Hvordan komprimerer jeg i Wordpress, eller i .NET?

Vil du eksperimentere kan du sjekke etter tillegg som gjør komprimeringen for deg. For Wordpress finnes det en fil i nettstedets hjemmekatalog, den har det underlige navnet .htaccess og håndterer blant annet innstillinger for komprimering.

På .NET-plattformen kan man stille inn dette i sin web.config-fil for nettstedet.

Følge webbriktlinjer.se

Svenske myndigheter har utarbeidet Vägledning för webbutveckling, ofte kalt webbriktlinjer.se, for å etablere en standard for webutvikling innen offentlig sektor. For deg som har vært med en stund er dette den nye utgaven av det som tidligere ble kalt for 24-timmarsvägledningen, den gangen mange av oss måtte mase om at det ikke var ok at myndigheter stengte av nettstedet sitt etter kontortid.

Gjesp, hvem bryr seg?

Selv den som ikke har med offentlig sektor å gjøre kan ha nytte av de hjelpsomme tipsene som finnes i veiledningen. Særlig med tanke på at de fleste punktene er drøftet av landets fremste innen alle tenkelige retninger av webutvikling. Om du ikke i dag har valgt en standard for hvordan nettstedet skal fungere, er dette en utmerket begynnelse.

Veiledningen finnes der av en grunn. Det er en måte å ikke internt sitte fast i diskusjoner som «men slik har vi alltid gjort» eller å ved usikkerhet kjøpe noens argument med hud og hår.

Der jeg jobber har vi en masse dårlige vaner og organisatoriske egenheter. Blant annet er jeg lei av å stadig forklare hvorfor man ikke skal åpne lenker i nytt vindu. I stedet for å argumentere pleier jeg nå å henvise til veiledningen, i dette tilfellet retningslinje nr 97 om at tilbakeknappen 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, riktlinje 97⁷⁶

Om man åpner lenker i nytt vindu kan man ikke gå tilbake i nettleseren. Brukerne merker ikke alltid at et nytt vindu er åpnet, noe som bidrar med brukervennlighetsproblemer helt unødvendig.

Nå trenger man kanskje ikke å følge alle retningslinjene så nøye at man stopper all utvikling og memorerer alle retningslinjer. Dog er det en god idé å velge ut noen man alltid følger, og om diskusjon oppstår om hva som er «best practice» synes jeg at man følger veiledningens anbefaling om man ikke har ekstremt gode grunner til å la være.

For din bekvemmelighet er retningslinjene dessuten prioritert, slik at du vet hva som er viktigst. Den første retningslinjen, som er prio 1, er faktisk å følge tilgjengelighetsstandarden WCAG 2.0 nivå AA, noe vi allerede har tatt opp i aktivitetslisten.

Filers levetid standard til 30 dager

Før man begynner å jage hundredeler av et sekund på å overføre materiale til en bruker, bør man først lene seg tilbake og ta en klype frisk luft. Hva kan være bedre enn en rask overføring? Jeg ville nominere en overføring som ikke trengs. Noe som ikke inntreffer burde være enormt mye raskere enn det som skjer.

Mitt forslag er at filer man ikke regner med skal endre seg på lenge automatisk skal ha minst 30 dagers forventet levetid. Hvorfor akkurat 30 dager? Det er ikke meningsfullt å sette 20 år ettersom nettleserne automatisk tømmer sine hurtigminner med jevne mellomrom – 30 dager duger godt.

Det man håper på er at en tilbakevendende besøkende allerede har en stor del av nettstedets filer i nettleserens midlertidige minne (dens cache). Ved et gjentatt besøk vil ikke uendrede filer sendes til den besøkende, kun de som er endret eller som ikke ble lastet ned ved forrige besøk (kan jo være en annen underside enn ved foregående besøk).

Dette er en del av den skjulte informasjonen som webserveren leverer som instruksjon til nettleseren ved et besøk.

Hvilke filer kan leve lenge i nettleserens cache?

Dette er selvfølgelig ikke magi, det er heller ingen sølvkule. Man må bruke hodet, alternativt begynne i den forsiktige enden av disse mulighetene. Det finnes filer som ikke oppdateres nesten aldri. Logotyper for eksempel, eller favorittikoner.

Inkluderer du Javascript-rammeverket Jquery versjon 2.1.3 kommer den filen trolig aldri til å oppdateres, derimot erstattes av en nyere versjon. Med andre ord kan du trygt sette 30 dagers levetid på filer hvis filnavn indikerer dens versjon.

Ulempen er imidlertid at dette trenger å gjøres med omtanke, ellers kan det oppstå litt uønskede bieffekter i webdesignen. Mange filer på et nettsted har interne avhengigheter, for eksempel får man som oftest utseendet på nettstedet i en pakke. Da gjelder det at hele pakken oppdateres og alle inngående filer får nye adresser.

Akkurat som med Jquery burde du eller dine utviklere jobbe med versjonsnummerering på filer som er en del av webdesignen.

En annen ting å være oppmerksom på er hvordan en bildebank leverer bilder direkte ut på ditt nettsted. Om bildene oppdateres i verktøyet men filnavnet er identisk før og etter oppdateringen, kan du ikke regne med at endringen slår igjennom. Derfor er det ikke bare å fulhacke inn lang levetid på et system som ikke er klart. Dette kan du rede ut med din webutvikler (eller deg selv).

Okay, men om jeg nå panisk må få ut en ny logo?

Bytt navn på filen og sørg for at den omdøpte filen brukes på nettstedet. Vanskeligere enn det er det ikke. Psst! Om din omdøpte fil utelukkende brukes via en uendret CSS- eller Javascript-fil, kan også de trenge å døpes om. Betrakt det som en pakke av avhengigheter.

Sette levetid i Wordpress (Apache) og i .NET

Som så mange andre tekniske innstillinger for Wordpress gjøres dette i filen .htaccess som ligger i nettstedets hjemmekatalog. Det kan være slik at den er skjult for det programmet du bruker når du leter etter den, den der innledende punkten er UNIX sin måte å si at en fil skal skjules.

Kjører du derimot med Microsofts .NET-plattform kan du velge om du stiller inn det via din web.config-fil i nettstedets hjemmekatalog eller om du gjør innstillingen i webserveren Internet Information Server.

Fornuftige adresser

Det finnes massevis å tenke på når man utformer en fornuftig URL-struktur (URL – Uniform Resource Locator, URL og nettadresse er det samme). Til å begynne med skal den være lesbar slik at man forstår hvem som er avsenderen og hva innholdet er.

Hva en URL ikke skal inneholde…

Men det er kanskje enklere å forklare hva man skal la være? En ting vi ser stadig sjeldnere på det offentlige nettet er sesjonsunnik informasjon i adressefeltet. Det er et brukervennlighetsproblem om adressen du har i adressefeltet ikke kan sendes til noen andre for å se nøyaktig det samme som du så på den adressen. Her får man virkelig tenke gjennom når det gjelder innloggede tjenester på nettet, slik at adressen lar seg bruke for å gi support, ikke byr inn til sikkerhetshull, med mer.

Et annet problem med sesjons-ID i URL-er er at søkemotorer vil få nye adresser ved hver indeksering, og det likes ikke å ha mengder med adresser til ett og samme innhold. En måte å håndtere adresser som er varianter på en hovedadresse er det som kalles kanonisk adresse. Da angis det i metadata i sidens kildekode hvilken adresse som er originalet, altså den kanoniske adressen som er den man ber søkemotorer å indeksere i stedet.

For å ikke bråke med brukervennligheten skal man la være understreker og mellomrom. Dette gjelder i de fleste tilfeller også filnavn for filer som lastes opp og blir tilgjengelige på nettet, som dokumenter og bilder. Grunnen til dette er at en utskrevet adresse som blir klikkbar på nettet ofte er understreket, da er det vanskelig for den som leser adressen å være sikker på om det er understrek eller mellomrom. I stedet skal man konsekvent bruke bindestrek for mellomrom og lesbarhet.

Store eller små bokstaver i en URL?

Man bør gjerne la være å bruke store bokstaver. En av grunnene er at man utsetter sin bruker for den kognitive belastningen å gjøre forskjell på små og store bokstaver – som oftest unødvendig. Man bør konsekvent kjøre med små bokstaver.

Hvor dynamisk adresse holder man ut med?

Du har sikkert sett adresser som har et spørsmålstegn i seg, fulgt av en masse ord og likhetstegn? Dette er det som pleier å kalles for en dynamisk adresse, der motsetningen er en friendly-URL som i stedet har skråstreker og en intern mappestruktur – ofte med foreldre og barn.

En veldig dynamisk adresse – med tre eller flere spørreparametere – kan forvirre søkemotorer, foruten at de som oftest er vanskeligere å forstå for mennesker. Helst bør du unngå dynamiske adresser.

Kvalitetsindikatorer for en URL

Nedenstående ti punkter er hentet fra boken Webbstrategi för alla, der finnes en mer grundig gjennomgang enn hva som er meningsfullt i denne boken.

1. Være utformet for å kunne bestå over veldig lang tid.
2. Angi hvem som er avsenderen.
3. Beskrive hva som finnes på adressen.
4. Være så kort som mulig, ikke inneholde uvesentligheter og være enkel å memorere eller lese opp over telefon.
5. Følge navngivningsstandard, det vil si ikke inneholde spesialtegn, ingen store bokstaver etc.
6. Ha eksistert en stund, det er et tegn på seriøsitet for en søkemotor.
7. Inneholde noe unikt, med andre ord skal det ikke finnes flere måter å nå nøyaktig samme innhold.
8. Være funksjonell. Om adressen er hierarkisk skal det gå an å slette deler av adressen for å nå et høyere nivå i strukturen.
9. Gi korrekt statuskode ifølge HTTP. Mangler siden er det 404 som gjelder, er den flyttet skal man videresende med status 301.
10. Ha en form for rettestavingsfunksjon slik at den klarer feilaktigheter som www som prefiks, med eller uten avsluttende skråstrek etc.

Mange av disse potensielle problemene fanger du opp automatisk med verktøyet Optimizr.com, men jeg anbefaler alltid å gjøre manuelle kontroller når tid for refleksjon prioriteres – gjerne kvartalsvis.

Responsiv typografi

Har du sjekket gjennom alle dine undersider på en mobil eller annen liten skjerm? Antagelig ikke. Om man gjør det kommer det sikkert til å dukke opp en og annen overskrift som forårsaker at man må scrolle sidelengs for å kunne lese hele ordet, da det svenske/norske språket er bygget opp av sammensetninger av ord.

Dette problemet gjelder primært overskrifter da de er av større størrelse enn brødtekst, derfor tar hver bokstav mer bredde i beslag og lange ord får ikke alltid plass. Men tenk gjerne på tilgjengelighetsaspektet, at visse av dine brukere antagelig kjører med forstørret tekst, så det som gjelder på din skjerm gjenspeiler ikke nødvendigvis alle andres situasjon.

Myke bindestreker for orddeling ved behov

Løsningen på problemet er å sette inn myke bindestreker, som til forskjell fra vanlige bindestreker kun deler et ord om plassen krever det. Mest åpenbare eksempelet er vel hovedoverskriften sett på en mobils skjerm, men dette kan like gjerne opptre som «heislesning» – altså ett ord per rad – om man har smale kolonner i sin design når den ikke vises i fullskjerm på en dataskjerm.

En myk bindestrek kan skrives inn manuelt i ordet der du vil gjøre en eventuell orddeling, skriv bare inn ­ som står for soft hyphen. For eksempel:

<h1>Stortings&shy;representant</h1>

Har du uflaks fungerer det ikke i ditt websystems vanlige tekstfelt, da får en utvikler sørge for at man får skrive HTML også i disse tekstfeltene. Ofte er problemet at systemet forsøker å konvertere bort &-tegnet, noe som havarerer din myke bindestrek.

Verktøy for dette er noe mer omstendelig enn ellers (inntil videre). Du kan sjekke siders karakter på textalyser.net som fungerer best med engelsk tekst, men du får også en oversikt over hvor lange ord du har i en tekst.

En annen løsning for deg med en funksjonsrik egen søkemotor er å tvinge den til å rapportere på hvilke sider på ditt nettsted den finner lange ord. Nøyaktig hvor lange ord som fungerer er vanskelig å svare på, men du vil nok gjerne ha dem ordnet etter hvilken lengde som finnes (og glem nå ikke å ha margin slik at de som kjører med forstørret tekst ikke glemmes bort).

Google Pagespeed Insights fanger problemet i sin brukervennlighetskontroll under «Tilpass størrelsen på innholdet etter visningsområdet» når tekst ikke får plass innen synlig flate. I skrivende stund – i versjon 2 – ser den ikke ut til å kunne advare om dette også når det gjelder scenarioet at brukeren har forstørret teksten ett eller flere trinn.

Innhold publiseres som strukturerte data

Praktisk talt hvert nettsted har informasjon som er av en strukturert type, men det er ikke alltid det publiseres på en strukturert måte. Jeg snakker her om innhold som vi som mennesker helt enkelt kan identifisere som en kalenderhendelse – som en sommerfest – eller et geografisk sted, at «Stockholm» trolig mener den svenske hovedstaden snarere enn den lille avkroken i USA.

Denne egenskapen å forstå hva innholdet er eller dreier seg om har ikke datamaskiner. Du som er interessert i søkemotoroptimalisering har nok ikke gått glipp av alt snakk om RDFa. Det er en av teknikkene for å merke opp innhold slik at en søkemotor forstår. Slik at til og med en maskin forstår innholdet.

Microdata, Schema.org og Microformats.org

Google ble lei av at Microformats.org var så trege med oppdateringer og lanserte da Schema.org sammen med Microsoft, Yahoo, med flere.

Tar du en titt på nettstedet innser du at nesten all form for innhold du publiserer kan slippes i et strukturert format. En av fordelene er at man kan få mer plass i Googles trefflister, for eksempel har du sikkert sett anmeldelser og små kalendere i trefflisten hos Google. Nøyaktig på hvilken måte det vises er noe som i det minste Google stadig eksperimenterer med. Å merke opp hvem som har forfattet en artikkel eller bloggpost var noe de bare viste i et år før de fjernet det.

Søkemotoroptimalisering, men ikke nødvendigvis høyere rangering

Egentlig anses det ikke blant søkemotoroptimerere at ens nettsted klatrer høyere i Googles treffliste om man har strukturerte data. Derimot får man i flertallet av tilfeller mer plass i trefflisten, noe som definitivt er på bekostning av de som ligger under ens side i listen.

Hva som er anbefalt mengde strukturerte data avhenger litt av hva ditt nettsted har for type virksomhet, men selvfølgelig skal din kjernevirksomhet beskrives strukturert om det lar seg gjøre. For eksempel om du lister mottak for kunder, angi deres geografiske posisjon, kontaktopplysninger m.m.

For å verifisere at dine strukturerte data er korrekte kan du teste med Google Structured Data Testing Tool⁷⁷.

Henvises til filer som ikke finnes eller ikke fungerer

Bare fordi en nettside lastes inn uten å gi en feilmelding betyr det ikke at alt er vel. Bak kulissene gjemmer det seg iblant feil i noen av alle de filene som trengs for at nettsiden skal bli komplett, slik den er tenkt.

Det finnes flere årsaker til disse feilene. Vanligst når jeg har sett dem er at webutviklerne har lyktes med å rote bort en fil når man har løftet over endringer fra utviklingsmiljøet til produksjonsmiljøet. Da forårsaker man en 404-feil på en eller et fåtall filer.

Det kan også være en serverfeil som inntreffer, det vil si noe i 500-serien. På visse nettsteder opprettes stilmaler, Javascript og til og med bilder av webserveren. De er altså ikke statiske filer på en harddisk. Om en feil i denne opprettelsen inntreffer – mer eller mindre midlertidig – kommer serveren dels ikke å sende filen, men også skape en feil.

Men hvorfor er dette et problem?

Grunnen til at dette er et problem henger sammen med hvilken fil som mangler eller ikke fungerer. Si at det er stilmalen for utskrift, da er det få som kommer til å oppdage det, men det gjør utskrifter dårligere enn det er tenkt.

Dessuten risikerer alle typer feil å gi dårlige signaler til søkemotorer når de skal rangere ditt nettsted. Å konstant ha problemer med nettstedet inngir ikke tillit hos brukerne.

Hvordan finner jeg disse feilene?

De avanserte måtene er ofte bare tilgjengelige for større organisasjoner, men vi begynner her. Om du har tilgang til webserverens loggfiler kan du ofte få detaljert innsikt i serverens syn på sin velbefinnende. Disse loggfilene vil du helst slippe å lese som tekst, så sjekk gjerne hvilke analyseverktøy som er tilgjengelige, kanskje har du Event Viewer i Windows Server, noe logganalyse som Kibana eller Splunk. Kanskje kan du få loggfilene og kjøre dem inn i et verktøy for preparering av data, som Tableau.

Å inspisere loggfiler og å overvåke feil bør interessere alle som ikke er teknofobe. Det er en indikator på hvordan et nettsted har det, om det er utviklet på en kompetent måte og om driften fungerer.

Du med nettsted på webhotell

Har man et mindre nettsted er man ofte noe mer begrenset i hvilke valg man har av analyse. Men det er ingenting å henge leppen over. Dine utgifter for å holde i gang nettstedet er forsømmelige sammenlignet med hva ovennevnte verktøy koster :)

Foruten det åpenbare å være oppmerksom på underligheter når man selv opptrer som bruker på sitt eget nettsted, finnes det verktøy som sjekker dette for deg. Enklest er nettverksverktøyene som finnes i alle moderne nettlesere. Dem finner du under respektive nettlesers utviklermeny. Der ser man alle filer som lastes inn for en sidevisning, om de genererer feil eller ikke. Det er primært HTTP-seriene 400 og 500 du trenger å fundere på, har du god tid er det verdt å fundere på 300-serien også da det ikke er effektivt å kalle filer som videresender.

Svakheten med den metoden er at man gjør stikkprøver, en side om gangen og man må gjøre det manuelt. Et annet verktøy som gjør dette litt mer automatisert og på massevis av sider på ditt nettsted er gratisverktøyet Optimizr.com – med ulempen at du må vente inn rapportene de sender ut innimellom. Optimizr.com fungerer for ganske passiv webanalyse og kan være et godt innsteg for de fleste.

Feil statuskoder sendes – nettstedet lyver

Det hører til god oppførsel å svare ærlig og konkret på spørsmål. Dessverre er det ikke alltid dette prioriteres når vi lar datamaskiner kommunisere med hverandre.

Praksis for HTTP (protokollen som transporterer nettsider over internett) er at man snakker åpent om det gikk bra (200 Ok), om materialet er flyttet (301 redirect), forsvunnet (410 Gone) eller lignende. For den mer useriøse finnes til og med statuskoden 418: I'm a teapot om din smarte tekanne trenger å kunne kommunisere over internett :)

HTTP statuskoder for at maskiner skal forstå hverandre

For at nettet skal fungere optimalt og maskiner forstå hverandre trenger man å følge disse oppsatte reglene for kommunikasjon. For ikke-menneskelige brukeres skyld, som Googles crawlere og andre boter, skal man følge HTTPs statuskoder, punktum. Ellers kan de ikke vite om en adresse eller side har opphørt å eksistere, aldri eksistert eller ikke kan finnes. Hvordan skal ellers en maskin finne ut hva som har skjedd, de kan jo ikke lese og forstå tekst, noe som ikke engang trengs om man nå bare sender riktig tall, riktig statuskode.

Sender du for eksempel statuskode 301 eller 302 instrueres boter om at adressen permanent eller midlertidig er flyttet til en annen adresse. Ikke vanskelig i det hele tatt, egentlig.

Største avvikelsene på dette området er hvordan man velger å fortelle at noe gikk galt. I 2015 gjorde jeg en sjekk av Sveriges kommuners måte å håndtere 404-feilmeldinger. Testen gikk ut på å evaluere om de sendte 404 som melding på en åpenbart feilaktig adresse. 6,2 prosent av de 290 kommunene sendte «200 Ok» i stedet for «404 Not found». De later altså som om ingen feil har inntruffet.

Dette blir et problem litt avhengig av hvilket innhold man viser i forbindelse med sin 200 Ok-side. Å presentere startsiden sin i stedet for en feilmelding er en naiv form for velvilje men fortsatt ganske vanlig. Da får man tilfeldigvis veldig mange alternative adresser til sin startside, noe som i SEO-sammenheng kan straffe seg avhengig av om man tror på straff for duplisert innhold (og har glemt å sette kanonisk URL i sidens kildekode).

Hvordan man finner feilaktig feilhåndtering

En ting du kan gjøre er å manuelt skrive inn en feilaktig adresse og se hva som presenteres. For å sjekke hvilken statuskode serveren gir kan du for eksempel sjekke i nettverkspanelet som ofte følger med moderne nettlesere for datamaskiner. Om du vil ha full kontroll på HTTP finnes Firefox-tillegget Tamper Data⁷⁸.

Tenk også på om det er andre systemer som bidrar til nettstedet. For eksempel har ofte større organisasjoner spesialiserte systemer for dokumenthåndtering, mediehåndtering, med flere og da trenger også disse å testes.

For en mer passiv webanalyse kan du melde inn ditt offentlig tilgjengelige nettsted til Optimizr.com og avvente de rapportene som sendes når de føler at de har sjekket nettstedet ditt ferdig.

Lar seg crawle og indeksere nettstedet

At ens nettsted ikke er teknisk tilgjengelig kan være nøyaktig det man er ute etter, men det gjelder sjelden for et offentlig nettsted. Der er i stedet poenget at alle bør være velkomne, både mennesker og maskiner, på majoriteten av innholdet.

Hindre som finnes kan være av ulik art. Dels den myke varianten der man ber om å bli latt i fred, alternativt forsøker å instruere boter om å ikke ta med siden i indeks. Så finnes det der kjempehøye hinderet at tilgang mangler.

Lavere hindre som kan være problematiske

Det finnes flere mindre dramatiske måter å forsøke å fortelle maskiner hvordan man ønsker å få sitt nettsted behandlet. En klassiker som styrer hele nettstedets innstillinger er å ha en fil kalt robots.txt som plasseres i nettstedets hjemmekatalog. I robots.txt pleier man å angi hvilke mapper søkemotorer og andre maskiner skal la være, hvor nettstedets sitemap er plassert, med mer.

Hvorvidt en side skal tas med i en søkemotors indeks kan også detaljstyres gjennom sidens egen metadata i HEAD-taggen. Der kan man også plassere metadata som forteller om sidens kanoniske forhold innen nettstedet, det vil si om siden er en variant av en annen. I så fall angis den andre, viktigere, sidens URL som canonical-URL. Det er en måte å kunne ha flere adresser til potensielt samme innhold, men at man forteller hvilken hovedadressen er.

Det går også å på lenker ha instruksjoner om hvordan maskiner skal oppføre seg, som at lenker ikke trenger å følges. Dette gjøres gjennom attributtet rel="nofollow" på respektive lenke.

For mange år siden, i 2008 nærmere bestemt, ble nettstedet jeg bygde for Västra Götalandsregionen utsatt for å bli ekskludert fra Google sakte men sikkert under ferien min. Etter en masse frustrasjon og feilsøking viste det seg at en oppdatering til programvaren bak nettstedet automatisk hadde satt opp et ønske om å ikke bli indeksert. Google gjorde dessverre som programvaren fra Microsoft ba om. Det er selvfølgelig bra jo tidligere man oppdager slike problemer.

Høyere hindre for webtilgang

Så finnes de mer strikte måtene å stenge ute maskiner, og det er å blokkere dem eller kreve innlogging for å få tilgang. Du har sikkert opplevd å få opp en innloggingsdialog når du har surfet på nettet, men man kan ikke alltid regne med å i det hele tatt få sjansen til å forsøke å logge inn. Iblant blir man blokkert fordi man ikke sitter innen det godkjente nettverket, ikke har riktig IP-adresse eller hva noen nå har satt opp for krav.

Verktøy for å oppdage dette problemet

Et smidig verktøy er SEO Doctor⁷⁹ som tillegg for Firefox. Om ikke siden kan indekseres vises et rødt advarselssymbol der du har plassert tillegget i din nettleser. En annen måte å gjøre stikkprøver er Pingdoms Full page test⁸⁰.

Skal du lete etter tilgangsproblemer er det blant annet HTTPs statuskoder 401 Unauthorized og 403 Forbidden du er ute etter. Det er ikke umulig at dette logges på din webserver, men har du nettstedet ditt på et webhotell kommer du kanskje ikke til denne loggen.

Optimizr.com har med også dette i sine rapporter, men da forutsatt at de har indeksert hele ditt nettsted, ellers får du lete etter andre alternativer.

Lenker til sider som ikke finnes

Det er ikke bare når sider mangler på ditt nettsted du skal bry deg. Om du lenker til en side på noen andres nettsted og de kaster den, går det ut over dine brukere som følger den lenken.

Å ikke ha kontroll på de sidene man lenker til har blitt en stadig hetere potet innen søkemotoroptimalisering, og løsningen er ikke å slutte å lenke eksternt. Snarere skal du begynne å følge opp at de lenkene du har faktisk fungerer. Har du ikke kontroll på dine utgående lenker gir det et tydelig signal til søkemotorer om at du ikke jobber aktivt med nettstedets allerede etablerte materiale og at man bør betrakte ditt nettsted med mistro. Regn med dårligere rangering.

Begynn å sjekke utgående lenker

Om du har lyst til å sjekke dette manuelt, noe vi alle bør gjøre innimellom, begynn med de sidene som brukes mest på ditt nettsted eller de du synes er viktigst. Sjekk gjennom alle utgående lenker slik at de peker på fungerende sider og med forventet innhold. Ikke sjelden har de vi lenker til flyttet på det materialet lenken dreide seg om eller rent av fjernet det. Se din lenkevern som å stelle i hagen. Du blir skitten på hendene og får kroket rygg, men det lønner seg på sikt.

Vil du i stedet sjekke utgående lenker etter hvor populære de er å klikke på, kan det være noe din nettstedstatistikk allerede sporer. Outgoing links logges i alle fall automatisk i mine kontoer på Google Analytics.

Den ambisiøse og automatiserte sjekken

Vil du gjøre dette i massiv skala kan du ha nytte av å ha egen søketeknikk. Har du en organisasjonsintern søkemotor har den sikkert mulighet til å indeksere også nettstedseksterne lenker og kan da samle på seg 404-feil med mer. Som du nok forstår kommer søkemotoren ikke til å begripe om det er «feil» innhold lenken peker på, så du trenger uansett å gjøre manuelle innsatser innimellom.

Finnes det stor interesse for webanalyse og oversikt kan du sikkert beregne kostnaden for at noen utvikler en semi-automatisk kontroll. Ta utgangspunkt i nettstedets sitemap, hent ned alle sider og sil frem alle organisasjonseksterne lenker – deretter sjekker du om lenkene gir annet enn HTTP statuskode 200 Ok.

Optimizr.com har med dette i sine rapporter, men det forutsetter at de har tatt seg bryet med å sjekke hele ditt nettsted.

Serveren gir feilmelding i 500-serien

Feilmeldinger i 500-serien pleier ofte utviklerne å være skyldige i, eller så er det en teknisk driftsforstyrrelse. Uansett hva er det verdt å stoppe opp og umiddelbart ta tak i disse problemene. Jeg kan ikke forestille meg noe møte jeg ville blitt igjen i om jeg fikk vite at vi hadde HTTP-status 500 på nettstedet vårt.

Foruten det åpenbare problemet at det rammer dine brukere gir det et dårlig signal til søkemotorer. Ditt nettsted ser ikke ut til å være robust eller pålitelig nok til å sende besøkende til. Med andre ord bør du ha kontroll på disse feilene også om de aldri inntreffer når det er høyt trykk på ditt nettsted.

Det trenger ikke å være hele sider som er rammet av serverfeil, deler av det som kreves for en sidevisning kan hver for seg gi serverfeil. For eksempel om din stilmal genereres på webserveren eller kanskje om du har en hjemmesnekret statistikkløsning som skaper skjulte bilder.

Når kan man forvente seg HTTP-status 500?

Det kan være en driftssetting av ny kode som har gått skeis. Så om du vet at det er driftsettingsdag kan du kanskje roe deg en stund før du begynner å jage de som forhåpentligvis allerede jobber på en løsning.

Det kan også være en overbelastning av nettstedet. Et slikt tilfelle jeg selv har gjennomlidd var da en treg ekstern tjeneste gjorde at hele nettstedet gikk ned. Du vet det der om at ingen kjede er sterkere enn sitt svakeste ledd. I det tilfellet måtte webserveren vente på svar fra en altfor treg ekstern tjeneste. Ettersom en webserver ikke kan håndtere uendelig mange samtidige brukere, begynner den å avvise nye besøkende ved å svare med Error 500 mest hele tiden. Grensen for akkurat det nettstedet gikk ved omtrent 140 000 sidevisninger per dag.

Overbelastningsangrep?

Om det nå er et angrep man utsettes for eller annen ikke legitim trafikk, kan dette være et forvarsel om å ta kontakt med de som håndterer nettstedets infrastruktur. I beste fall finnes et filter å sette inn for å beskytte nettstedet, men likevel slippe gjennom vanlige brukere.

For mange år siden ble det utført et «strek» mot Polisen.se fra massevis av nettsteder. De ville gi igjen med anledning av aksjonen mot serverhallen der The Pirate Bay hadde sine servere. Angrepet gikk ut på at man lastet inn en tung PDF-fil fra polisen.se ved hver sidevisning på de egne nettstedene. På den måten ble alle besøkende på disse nettstedene også besøkende (uvitende) på politiets nettsted – som tidvis gikk ned for telling.

Løsningen var ikke nødvendigvis å fjerne PDF-filen, da ville kanskje alle 404-feilene i stedet senke nettstedet, derimot kunne man sikkert ha sjekket i nettverket hvor brorparten av trafikken kom fra. Om man foran webserveren hadde filtrert bort trafikk fra webforum, som hamsterpaj.net med flere, ville webserveren fått litt pusterom. Nøyaktig hvordan denne episoden endte husker jeg ikke, men disse kampanjene har en tendens til å ikke være så langvarige.

Verktøy for å holde kontroll på 500 Internal Server Error

Google Search Console har en aldeles utmerket visning for feil i både 500- og 400-seriene. Du kan til og med få e-post om det inntreffer uventet mange feil. Enda en grunn til at alle webansvarlige må registrere seg på Google Search Console (og Bings motpart selvfølgelig).

Om du kan få statistikk over serverfeil for en lengre tidsperiode er det interessant å overvåke eventuelle trender av feil. Det er litt surt å innse at nettstedet en dag sank til bunns på grunn av økt kompleksitet bak kulissene og at det hadde ropt om hjelp via error 500-meldinger i flere måneder.

Vil du gjøre manuelle stikkprøver fungerer Pingdoms Full Page test bra.

God og passende lang sidetittel

Sidetittelen er det der som synes øverst i nettleservinduet, på datamaskiner i det minste. Det er ikke nødvendigvis det samme som hovedoverskriften, men det pleier å finnes ganske store likheter. Det er også det som blir den klikkbare teksten på søkemotorens resultatside og kommer til å være navnet i nettleserfaner, bokmerker etc.

Hvorfor sidetittelen er så viktig

Sidetittelen er en av de viktigste delene å jobbe med for at du skal kunne nå ut på en søkemotor og overbevise folk om å gå inn på akkurat ditt nettsted. Dessuten bør de ordene folk søker etter gjerne inngå i din sidetittel da det er en av de sterkeste rangeringssignalene du har å spille med.

Med tanke på antallet faner folk har i sine nettlesere på datamaskiner innser du snart at du har 1-2 ord på deg til å navngi siden i akkurat det brukstilfellet. Google viser imidlertid betydelig flere tegn. Nøyaktig hvor mange er noe de har en tendens til å justere. Uansett Googles syn på saken skal du skrive fornuftige sidetitler som er tilpasset mennesker. Med andre ord kan du ha følgende tommelfingerregler:

• Tenkte nøkkelord skal inngå tidlig i sidetittelen, slik at man ikke må lese langt for å få vite at det er en relevant side.
• Sidetittelen trenger å være ganske kort, i skrivende stund er det 50–60 tegn som anbefales, men da har man nok ikke tenkt på andre typer interaksjon. På skikkelig små skjermer man har på litt avstand – smartklokker blant annet. Om det i det hele tatt er visuelle grensesnitt det handler om i fremtiden.
• Den trenger å være unik innen ditt nettsted, hvordan skal ellers en besøkende kunne gjøre forskjell på to sider om de har identisk sidetittel?
• Ikke automatisk ta med nettstedets navn i sidetittelen, i det minste ikke om det er for at det skal være lett å finne til nettstedet ved søk på dets navn (der har du nok ingen konkurranse å snakke om).

For å følge opp dette kan du bruke Google Search Console. Der finnes en visning der du kan se hvilke sidetitler som forekommer mer enn én gang på nettstedet (av det Google kjenner til om ditt nettsted, altså).

Rimelige størrelser på filene dine

Ordet «rimelig» er akkurat så herlig vagt som det svenske «lagom». Hva en rimelig filstørrelse er lar seg vel ikke sette et tall på, egentlig. Men jo større filstørrelse desto lengre tid tar de å laste ned både for dine besøkende og også søkemotorer når de velger hva de skal inkludere i sine indekser.

Størrelsen på innholdet, HTML-filen altså, trenger du kanskje ikke å være så restriktiv med. Dels fordi det lar seg komprimere ned til en tiendels størrelse ved overføring, men kanskje primært fordi det er en dråpe i havet sammenlignet med andre filer vi har på våre nettsteder. Bilder, video og lyd derimot tar så enormt mye mer plass – særlig det som er lagt dit redaksjonelt.

Det er nå du trenger et ytelsesbudsjett

For å forsøke å bøte på problemet med overfylte nettsider eller i det minste sette opp en form for målbar ambisjon kan man dokumentere kravene i et ytelsesbudsjett. Det går kort sagt ut på å etablere og følge en retningslinje om hvor tung og hvor treg alt som hører til en sidevisning får lov å være. Å sette opp krav på en sides vekt er ganske rett frem. Sett en fornuftig verdi der man har god margin til hva folk holder ut med på det markedet nettstedet henvender seg til. Si for eksempel at ingen side får veie inn på mer enn 399 Kb. Det finnes rikelig med mer eller mindre fornuftige triks som gjør at man kanskje vil ha unntak fra denne regelen. Men begynn med en regel og la de som har lyst til å avvike fra regelen argumentere for smarte teknikker, som lazy-loading, overfor de kravene som stilles til nettstedets alle undersider.

En utfordring å spesifisere akseptabel hastighet i sitt ytelsesbudsjett

Sammenlignet med en sides vekt er hastigheten litt mer kinkig å definere. Det som teller her er den opplevde hastigheten da det er den individuelle opplevelsen som styrer om brukeren mangler flyt. Dessuten har ikke alle de samme forutsetningene for hastighet. Blant annet varierer kvaliteten på tilkobling, noe jeg merket som altfor sent fikk 4G. Jeg har ventet evigheter på «responsive» bildekaruseller med enorme høyoppløste bilder (til min lille skjerm). Den opplevde hastigheten påvirkes også av hvor mye kraft som finnes i enheten brukeren har. Det påvirker hvor mange designelementer nettleseren orker å jonglere med for å vise siden.

Akkurat som med sidens vekt synes jeg at man kan begynne med å gjøre det enkelt for seg i sitt ytelsesbudsjett, men at man får være forberedt på ovennevnte problematikk. For et nettsted som kun henvender seg til brukere i Sverige kan ytelsesbudsjettets krav være at ingen side får ta lengre tid enn 10 sekunder å laste ned komplett. Da målt fra en 3G-tilkobling innen Sveriges grenser. Som en ytterste grense.

Beregn innvirkningen av ditt ytelsesbudsjett uten å flytte deg

Vil du relativisere dette og gjøre teoretiske målinger fra skrivebordet kan du sjekke med Bredbandskollen hvilke hastigheter folk har rundt om i landet. Da kan du raskt få et bilde av hva ditt ytelsesbudsjett innebærer i praksis i Ekshärad midt ute i de värmlandske skogene, eller for den som venter på et forsinket tog i Bastuträsk – 10 mil fra nærmeste hamburgerbar i Västerbotten.

Krisekommunikasjon stiller litt andre krav til ytelse. Om du er en samfunnsaktør bør du for alles vår skyld også ta høyde for at det ved en krise kan være ytterst viktig å ikke være sløsaktig. Ved kriser kan kommunikasjon via mobilnettet være det eneste logiske alternativet for flertallet av de rammede og de som hjelper til. Mobilnettet er faktisk en endelig ressurs. Din kriseweb bør ikke sende med en masse skrifttyper, høyoppløste versjoner av logoen eller 2 Mb med Javascript for å kunne tegne opp avanserte kolonnesystemer på ulikt store skjermer. Hold det enkelt!

Filstørrelser i designen

Jo mer man sløser med tunge filer for designen av sitt nettsted, med stilmaler, Javascript, skrifttyper og designbilder, desto mindre plass finnes for redaksjonelt innhold. Altså det innholdet som den besøkende kom dit for å ta del av!

Det som rammer din besøkende takket være dine utviklere og designere kan oppsummeres i to kategorier; tekstfiler, eller mediefiler.

Når det gjelder bilder finnes massevis med triks. Blant annet å velge riktig format, å optimalisere dem og deretter kjøre ekstra ikke-ødeleggende komprimering. Samme fremgangsmåte finnes for video og lyd. Vær oppmerksom på nye formater! Det lanseres stadig nye ideer og triks du kan dra nytte av. I 2015 merket man det humoristisk navngitte prosjektet Piper Pied⁸¹, de komprimerer menneskers ansikter mindre hardt, noe som gjør at resten av bildet kan komprimeres hardere uten at det ser fullt så ille ut.

For deg med tilgang til en Windows Server kan du installere Search Engine Optimization Toolkit⁸². Den programvaren kan gå gjennom hele ditt nettsted og lister deretter filstørrelser, blant mye annet. Men det finnes også med i Optimizrs alle rapporter.

Ingen kopier av innhold

Det skal kun finnes én adresse til et unikt innhold. Vanskeligere enn det er det egentlig ikke. Men om du nå har duplikater av innhold, i alle fall når det gjelder nettsider, bør du oppgi dens «kanoniske adresse». Det innebærer at man med metadata peker ut den siden som er opprinnelsen eller originalet, den av alle varianter du vil at søkemotorer skal indeksere. Det er det som kalles for dens canonical-URL og fungerer i alle fall for HTML-filer.

At innholdet skal være unikt på en adresse gjelder mer enn selve sidene, noe som kan være lett å gå glipp av om man ikke graver teknisk. Iblant snubler man over nettsider som henter inn samme Javascript-rammeverk to ganger – men fra to ulike adresser. Foruten at det er klønete gjort av utviklerne er det sløseri med de besøkendes tilkobling og et signal om ganske lavt ambisjonsnivå til søkemotorer når de skal velge hvilket nettsted som skal rangeres høyest.

Alt skal være så unikt som mulig

Noe mange nok ikke tenker på er at alt skal være så unikt som mulig. Jeg kan humre litt over de nettstedene som fortsatt har et ovenfra-og-ned-syn på nøkkelord på sitt nettsted, at de altså har organisasjonens navn som nøkkelord på hver eneste underside. Det liksom ødelegger meningen med å i det hele tatt angi det nøkkelordet, ikke sant? Det samme gjelder for sidetitler. De skal være unike for å bli brukbare på søkemotorer, i favoritter, i nettlesernes faner med mer.

Tenk på at også dine beskrivelsestekster som havner i meta-description trenger å være unike innen nettstedet.

Den suverent vanligste varianten på dette er nok kjempestore organisasjoner og hvordan de håndterer sine PDF-dokumenter på eksterne nettsteder. Da jeg jobbet som webansvarlig for mange år siden var det med skrekk jeg fikk tall om hvor mange kopier av dokumenter som lå og skvulpet i vår opplastningskatalog. Det verste er jo at det ikke er lett å sørge for at alle blir oppdatert når en ny versjon skal ut. Det er vel av denne grunnen man kan forstå at Google bør rangere ned et nettsted om man har massevis med kopier av samme dokument, bilder eller annen type materiale.

Ta hjelp av Google for viss oversikt

En googling på site:mittsted.no filetype:pdf kan i verste fall være den beste oversikten du kan få over dokumenter som er publisert på ditt nettsted. Da får du i det minste en liste over det Google kjenner til. Når det gjelder bilder og video er kanskje risikoen for duplikater mindre, men da kan du google kun på site:mittsted.no for deretter å bytte over til bilder samt video for en oversikt. Merk at det kan være andre adresser som serverer mediefiler og dokumenter. For eksempel kommer mange av min arbeidsgivers dokumenter fra subdomenet alfresco.vgregion.se, med andre ord googler man på site:alfresco.vgregion.se for å få oversikt.

Verktøy for å finne kopier av materiale

Først og fremst kan du vende deg til Google Search Console. Der finnes visninger som advarer om identiske sidetitler og beskrivelsestekster. Som med så mye annet har også Optimizr.com med dette i sine rapporter.

Passende mange hovedoverskrifter

Det finnes anbefalinger fra webstandardorganisasjonen W3C å følge (de der som skriver dokumentasjon om hvordan nettet burde fungere). Om ditt nettsted er i den utdøende gjengen som følger kodestandarden XHTML, får den ikke lov til å ha mer enn én hovedoverskrift. En hovedoverskrift er det samme som det som iblant kalles H1, dette fordi det er dens HTML-tagg, <h1> altså, den første blant overskrifter.

Om du derimot følger HTML5 får du ifølge anbefalingen fra W3C ha flere hovedoverskrifter, men det er anbefalt å ha beskrivende kode rundt, for eksempel seksjoner. I HTML5 kan altså en hovedoverskrift gjelde innen en delmengde av innholdet.

Om man i stedet tar utgangspunkt i brukerens behov er det mest logiske å ikke ha flere hovedoverskrifter. Visst, det kan ses som logisk å ha noen stykker om tydelig og korrekt kode forklarer at hovedoverskriften er for en delmengde av det som vises på skjermen. Men samtidig er det ganske sentrert rundt den seende brukerens behov.

Ok, hvordan gjør jeg da?

Ha én eller ytterst få hovedoverskrifter. Følger du XHTML får du kun ha én hovedoverskrift, ellers bryter du mot anbefalingen for XHTML. Den opprinnelige tanken bak XHTML var at den skulle være prosesserbar av maskiner gjennom å være kompatibel med XML-standarden. Innen XML er struktur veldig viktig da den er mer maskinlesbar enn HTML.

Om ditt nettsted i stedet følger HTML5-standarden er det fortsatt anbefalt at du har et fåtall hovedoverskrifter, kanskje helst kun én. Hvorfor? Jo, i og med at siden trolig har en intern struktur med en overskrift som er viktigere enn de andre, bør den rangeringssignalen fremgå for søkemotorer og andre boter. Overskriftstørrelse har ikke kun med typografi og tekstens størrelse å gjøre, det er også din måte å vekte overskriftens relevans for siden.

Bygger du en startside eller landingsside? Ha for all del en hovedoverskrift for respektive del med egen call-to-action, men da skal du også kapsle dem inn i egne seksjoner. Dette er ikke et frikort fra å følge praksis, eller å ha en semantisk rekkefølge på din kode. Maskiner kan ikke lese og forstå innholdet, noe som også gjelder de av dine besøkende som tilfeldigvis har en funksjonsnedsettelse. Det gjelder også meg når jeg er trøtt, irritert, lysskygg, kognitivt nedsatt og bakfull dagen etter midtsommer.

Men glem ikke å ha en hovedoverskrift, i det minste én skal du ha!

Foruten at du kan granske koden manuelt kan du installere tillegg i nettleseren. Nettlesertillegget SEO Doctor til Firefox klager om du mangler en hovedoverskrift. Dessuten klager SEO Doctor om nettsiden mangler en underoverskrift, noe som heller ikke skader å ha om du bryr deg om SEO.

Ha en (passende lang) beskrivelsestekst

Beskrivelsesteksten kalles iblant for meta-description. Det skyldes at den er plassert blant en nettsides alle andre overordnede metadata i kodens hode, det som ligger i om du velger å vise kildekoden bak en nettside.

Beskrivelsesteksten skal veldig kortfattet beskrive sidens formål og innhold. Dette med et naturlig språk. Hver viktige side på ditt nettsted bør ha denne typen skjult informasjon. Eller ja, så skjult er den faktisk ikke. Iblant vises den under sidens tittel i søkemotorenes resultatside. Den finnes der for å brukes ved behov.

Lengde og utforming av beskrivelsestekster

Beskrivelsesteksten skal være unik. Det skyldes at man skal kunne skille på beskrivelsestekster på ett og samme nettsted.

Lengdemessig bør du holde den under 160 tegn (tell også mellomrom) om du vil ha med alt, men som alltid med tekst skal du ha det viktigste først i denne teksten. Samtidig bør du holde den over 80 tegn om den skal bli brukbar. Noen nedre grense for når søkemotorer strunter i beskrivelsesteksten er jeg ikke kjent med. Det kan være verdt å overvåke disse tallene løpende med tanke på den økende floraen av enheter vi bruker for å ta del av nettet.

Angående hvordan man formulerer teksten kan man følge kommunikative prinsipper som AIDA (Attention-Interest-Desire-Action) eller KISS (Keep it simple, stupid). Det lar seg selvfølgelig ikke gjøre å skrive helt vilt. Er du ikke vant til å uttrykke deg skriftlig er det bra å lete opp en formel som fungerer for deg.

Når det gjelder verktøy er nok Google Search Console klart best. Der finnes en visning for å evaluere beskrivelsestekster, blant annet om det finnes duplikater på et nettsted.

Media skal ha alternative tekster

Du har sikkert hørt at man skal ha alternative tekster til bilder på nettet? Ellers gjør man livet vanskelig for de som ikke kan se. Nå er det ikke bare synshemmede som ikke kan se, også søkemotorer lider av dette problemet. Til tross for at programvarer begynner å kunne «se» hva bilder forestiller, er det langt igjen før de forstår innholdet på den måten mennesker gjør.

Du har nok skjønt at dette ikke bare gjelder bilder. Også lyd og video har samme problem. Da dukker en annen funksjonsnedsettelse opp, nemlig manglende eller nedsatt hørsel. Også her suppleres ambisjonen om å ikke utestenge noen med hva som gir god søkemotoroptimalisering. Om innhold i en video er tekstet for døve og blinde kan teksten oversettes og vises for enda flere å ta del av.

Vi har alle en funksjonsnedsettelse en gang. Tenk deg selv sittende i en stille avdeling på toget og du har glemt hodetelefonene hjemme. Da blir du glad for at noen har tekstet for deg.

Praksis for tekstning av mediefiler

Første regelen er å ikke tekste slikt som er irrelevant eller trivielt i sammenhengen, det kommer bare å forstyrre. Da bør man heller velge en tom alternativ tekst, noe som ikke skal forveksles med å ikke i det hele tatt angi alt-tekstens attributt. Gjennom å sette for eksempel alt="" på en bildes HTML-tagg forteller man mottakeren at ingenting av verdi finnes å beskrive.

Laster du opp video på Youtube finnes et innebygd tekstverktøy. Kjører du med eget verktøy for å strømme lyd eller video er dette noe du trenger å fundere på.

Når det gjelder informasjonsgrafikk blir det vanskeligere. Da kan man trenge å gjøre dataene sine tilgjengelige som et alternativ for de som ikke kan se. Dataene trenger å være strukturert slik at de kan bearbeides av maskiner. Det er akkurat hva man har tabeller til på nettet. Samtidig gjelder det å være klar over at man ikke i alle situasjoner kan oppfatte innholdet om dataene er for komplekse. Da kan man i stedet velge å tekste konklusjonen av disse dataene.

Mange velger å i stedet for å lage bilder av diagrammer publisere en tabell, der tabellen gjennom progressive enhancement-teknikk erstattes med et illustrativt bilde. Det finnes en stor mengde Javascript-rammeverk for disse behovene.

Vil du manuelt sikre at du gjør riktig kan du bruke tillegg i nettleseren, for eksempel for bilder har jeg SEO Doctor i Firefox. Stikkprøver når det gjelder diagrammer eller andre visualiseringer er primært å høyreklikke på dem og se om de er et bilde. For å finne mange sider som mangler alternative tekster på bilder kan du bruke Optimizrs rapporter.

Passende mange lenker på en side

Hvor mange lenker er passende for en enkelt side på ditt nettsted? Ja, det er vanskelig å sette et eksakt tall på det og det handler ikke om en absolutt grense. Først trenger vi kanskje å resonnere litt rundt hvorfor vi skal bry oss i det hele tatt.

Alle lenker man har på en side skal være absolutt nødvendige. Hvorfor? Jo, det belaster din besøkendes oppmerksomhet å velge blant de alternativene du gir. Hvilken som er viktigst i sammenhengen blir ikke helt selvfølgelig om det finnes massevis å velge blant.

En måte er å sette en grense for hva som er ok uansett hvilken type side det er. I noen verktøy jeg har brukt har det blitt advart om man har over 200 lenker på en underside, da uansett om de pekte på sider innen nettstedet eller eksternt.

Lenkejuice = alt kan ikke være viktigst, alltid

Tenk på hver side som at den har 10 tillitspoeng å dele ut til andre sider gjennom hva den lenker til. Lenker du til 5 sider får de 2 poeng hver, lenker du til 100 får de en tiendedels poeng hver.

Noe som de som er interessert i SEO jobber med er å forsøke å balansere andelen utgående lenker, altså lenker som fører bort fra et nettsted. Det er både et signal til søkemotoren og brukeren i hvilken grad man henviser bort fra det egne nettstedet. Å ha en god balanse rundt intern og ekstern fordeling av lenkejuice er verdt å overvåke og sjekke hvordan markedslederne i din nisje gjør. Kortfattet: Er poenget med en bestemt underside å sende av gårde folk, eller finnes internt materiale å tilby? Følg opp hva brukerne velger å gjøre.

Å ha mange interne lenker tyder på rotete struktur. Gjennom å ha mengder med interne lenker svekker man også den interne lenkestrukturen. Kjører man Wordpress er det ikke sjelden et selvpåført mageplask du sikkert har sett. Mange spammer sine egne bloggposter med massevis av tagger. Jo flere tagger, desto flere lenker og assosiasjoner. Det er hva man har de bredere kategoriene til. Hold igjen, rett og slett.

Bruke rel="nofollow" på eksterne lenker

Akkurat for eksterne lenker kan man sette attributtet nofollow. Det forteller at man ikke anbefaler en søkemotor å følge lenken og er en måte å fortelle at man ikke har tillit til den lenken. Man kan samtidig spørre seg hvorfor man har en lenke man ikke vil ta ansvar for. Dette er en pragmatisk standard som har vokst frem for eksempel for lenker som tilkommer på grunn av brukeres bidrag på nettsteder. Det er en måte å ikke belønne spammere og et forsøk på å være selektiv med hvor man legger igjen sin lenkejuice.

For å få litt oversikt over dette er Optimizr.com bra, men du vet antagelig om hvilke sider på ditt nettsted som har uvanlig mange lenker.

Nettsider trenger innlenker

Det er litt mistenkelig at man i det skjulte tipser om en side som er vanskelig å oppdage som vanlig bruker. Du vet kanskje ikke hvordan dette kan skje også på ditt nettsted? De sidene du har med i din sitemap, en fil som primært brukes av søkemotorer, kan være søppelsider.

Ofte forekommende finner jeg eksempler i hierarkisk oppbygde nettsteder, noe for eksempel webpubliseringssystemet Episerver CMS gir automatisk. Der kan man finne sider som heter «høyrekolonne» og mangler innhold. Eller «hovedmeny» som brukes som en mappe i verktøyet for webredaktørens skyld. Om verken ditt eget eller noen andres nettsted lenker til en bestemt nettside er det definitivt et signal om at den nettsiden fullstendig mangler verdi. Iblant stemmer det jo, men om siden er meningsløs bør den heller ikke finnes der og forvirre verken søkemotorer eller brukere.

Om siden nå ikke er uviktig er det på tide å lenke til den, i det minste selv, eller så får du forsøke å skaffe noen innlenker fra noen andre.

Når det gjelder verktøy for å få oversikt er det ambisiøse alternativet å ha kontroll på alle sine adresser. De adressene som har hatt besøkende kan du eksportere ut fra ditt webstatistikkverktøy. Ellers finnes kanskje intern søketeknikk du kan dra nytte av, som vet om hvilket innhold som eksisterer uansett om det får besøkende eller ikke. Har du listen sortert etter popularitet er det kanskje verdt å begynne med de som har få besøkende, der finnes kanskje det du ikke ventet deg skulle besøkes.

Passe seg for interne viderekoblingskjeder

Du som har lest boken Webbstrategi för alla har nok forstått hvor viktig jeg synes det er å ta vare på sine gamle eller tidligere innarbeidede adresser på nettet. Problemet kan imidlertid over tid oppstå at du videresender til enda en videresending. Da sløser du med webserverens kraft og brukerens tålmodighet.

Dine brukere er utålmodige, i det minste gjelder dette det absolutte flertallet av nettsteder. Om dine nettsider ikke laster inn på under 0,1 sekunder tilhører du den kategorien som kan få bedre flyt i opplevd interaksjon. Det tar tid å videresende en bruker fra en adresse til en annen. Egentlig helt unødvendig, eller i det minste er det ingenting en besøkende har nytte av.

Et scenario som ikke er altfor uvanlig er at man videresendes fra http://adresse.no til den sikrere protokollen som støtter TLS/SSL. Det vil si https://adresse.no og om det ikke var ille nok kan nettstedet begynne å ha preferanser som å legge til det helt unødvendige www-prefikset. Altså sendes man videre til https://www.adresse.no og deretter krydre det hele med å være nøyaktig med språkversjon, dermed sendes man til https://www.adresse.no/nb/

Nei, dette er ikke noe absurd scenario. Våren 2015 hadde min egen arbeidsgiver et nylansert nettsted som hadde kun én færre videresending enn dette for de som skulle besøke startsiden. Etter tilstrekkelig mange videresendinger begynner det å straffe seg også innen SEO. Ifølge opplysninger er akkurat videresendingen fra HTTP til HTTPS ikke noe som Google straffer oss for, for akkurat den videresendingen ser vi ut til å ha et frikort⁸³.

Hver videresending tar ofte minst en tiendedels sekund, men det er ikke uvanlig med opptil ett sekund avhengig av den forsinkelsen i svartid (latens) som finnes mellom den besøkende og serveren. I ekstremtilfeller har jeg selv hatt svartider på flere sekunder. Da ville antallet videresendinger måtte multipliseres med flere sekunder. Tid som er fullstendig bortkastet for alle parter.

Hvordan gjør man da?

Sørg for å ha kontroll på hvilke videresendinger som finnes. Har du tilgang til logger er det HTTPs statuskode 301 og 302 du leter etter, det vil si mer eller mindre permanente videresendinger. Tenk også på at 301 sier at det er en permanent videresending. Det forteller søkemotorer og andre maskiner at de kan glemme den eldre adressen og holde seg til den nye. 302 sier at det er en midlertidig videresending, bruk den forskjellen med forstand.

Du bør unngå å ha flere enn én videresending. Man skal aldri havne på en videresendingsside som sender deg videre. Vi skal umiddelbart videresende til den endelige adressen. Med riktig statuskode ifølge HTTP-spesifikasjonen.

Den ambisiøse begynner å lete etter loggfiler på serveren eller nettverket, men rimeligst er nok likevel å gjøre manuelle stikkprøver og å være veldig oppmerksom når man selv opptrer som bruker. Skriv om adressene du har på ditt nettsted og sjekk hva som skjer. Vil du spore alt rundt HTTP kan du teste via Firefox å ha tillegget Tamper Data installert, men mange funksjoner finnes også i nettlesernes utviklerverktøy.

Gjennom ditt webstatistikkverktøy kan du sjekke opp hvilke eksterne nettsteder som lenker til deg og hvilke adresser de peker ut. For eksempel om de bruker www-prefikset eller ikke, kjører med HTTPS eller ikke. Noen som driver mye eller viktig trafikk til deg kan være verdt å snakke med for å angi «riktig» adresse.

Ikke angi nøkkelord – unødvendig

Denne problemstillingen er ganske kontroversiell i visse sammenhenger. Men man kan i alle fall spørre seg for hvems skyld du angir nøkkelord, eller meta-keywords som de iblant også kalles. Om Google noen gang har brydd seg om disse ordene er det i alle fall lenge siden de sluttet med det. I dag teoretiseres det snarere som at forekomsten av nøkkelord er et klønete forsøk på å spamme søkemotorer.

Iblant står det i organisasjonens redaktørhåndbok at man skal skrive inn nøkkelord. Ja, det gjør det også der jeg jobber. Det finnes eventuelt to grunner til det, det kan være slik at man har en egen søkemotor som drar nytte av disse ordene. Den andre noe mindre smigrende grunnen er at kunnskapen stammer fra nittitallets glade dager da det nesten var praksis å lure søkemotorer med helt irrelevante nøkkelord.

Deres egen søkemotor kan faktisk ha nytte av disse nøkkelordene. Grunnen til at dette kan fungere internt er at man har større grunn til å stole på sine egne redaktører, ens egen søkemotor leter kun i materiale man selv har publisert.

Ok, men vår egen søkemotor dekker jo inn vår eksterne web…

Her oppstår problemet på ordentlig. Om dere har nytte av å angi nøkkelord for deres egen søkemotors skyld, gjør for all del det, men tro ikke at det gagner Google eller de andre søkemotorene. Om du angir nøkkelord for din egen søkemotors skyld, sørg for jøsse navn for at ordene er unike og relevante slik at du ikke spammer deg selv.

Tommelfingerregelen for hva innen ekstern søkemotoroptimalisering som er lønnsomt å legge tid på er at det skal være komplisert å jukse, samt at originalt materiale skal belønnes. Det er enormt enkelt å jukse i massiv skala med nøkkelord. Det er derfor det ikke brukes av utenforståendes søkemotorer.

For å få oversikt kan du lese HTML-kildekoden på sidene du vil inspisere. Let etter kode som ser ut omtrent slik i <head>:

<meta name="keywords" content="nøkkelord, nøkkelord2, nøkkelord3">

Det eneste egentlige verktøyet jeg har funnet for dette er Optimizr.com, og av de sidene de har sjekket får man en liste med hvilke sider som inneholder nøkkelord.

Passende dybde i nettstedet

En høyst uvitenskapelig tommelfingerregel du kan holde deg etter er at ikke alle brukere orker å lete seg mer enn tre nivåer ned i ditt nettsted for å finne det de søker. Dette dels fordi mange ikke føler at de har den tiden å legge på et vanskelig navigerbart nettsted, men også fordi man ikke vet om det er verdt anstrengelsen. Vi kan ikke regne med at særlig mange av våre brukere er motiverte nok til å anstrenge seg. Om vi derimot designer navigasjonen med en bruker i tankene, finnes det faktisk bevis for at fire nivåer er bedre enn tre, blant annet i Jakob Nielsens bok Prioritizing Web Usability⁸⁴.

At navigasjonen ikke alltid er omsorgsfullt utformet for brukernes skyld får jeg signaler om nesten hele tiden. Om man nå tror på skjebnen; samme dag som jeg redigerte denne delen av boken, dumpet det ned en e-post som forklarte at «webredaktørene finner sine sider enkelt i denne flate strukturen». Spørsmålet er vel om nettstedets navigasjon er til for webredaktørenes skyld?

Om ditt nettsted har hierarkiske adresser, slike som angir skråstrek litt her og der, kan du enkelt telle dem. I visse webstatistikkverktøy, for eksempel Matomo, kan man bla seg ned i denne mappestrukturen og se den iblant bitre virkeligheten av hvor mange nivåer som faktisk finnes å forflytte seg mellom.

Hvorfor dette er et problem?

Ofte går brukervennlighet, tilgjengelighet og søkemotorers behov hånd i hånd. Søkemotorene må prioritere hvor mange undersider på ditt nettsted de skal legge tid på å forsøke å indeksere. Du tildeles rett og slett et indekseringsbudsjett fra søkemotoren, et begrenset antall sider på ditt nettsted kan altså bli indeksert. Antallet sider ditt nettsted er tildelt henger sammen med søkemotorens vurdering av nettstedets verdi. Grunnen til det er at søkemotoren må forsøke å beskytte sine egne interesser og ressurser da ditt nettsted faktisk kan være ødelagt eller spammete.

Det kan være slik at ditt nettsted har en systematisk feil som gir det uendelig mange undersider, sider som knapt engang lenkes fra ditt eget nettsted. Derfor trenger søkemotorer og andre maskiner å forsøke å finne ut hvilket antall sider og nøyaktig hvilke av dem som er verdt å crawle og forsøke å indeksere. Det er din jobb å hjelpe dem på vei, og på kjøpet blir det ofte bedre for menneskelige besøkende.

Unngå mer enn tre nivåers dybde

Du bør selvfølgelig strebe etter den mest logiske navigasjonsstrukturen som finnes for ditt eget nettsted og det innholdet det har. Men husk at det ikke er et reflekterende menneske som sitter og vurderer dette hos søkemotorene. Slikt gjøres helt automatisk.

Om du har mer enn tre nivåers dybde for å nå en bestemt underside er det rimelig å anta at den ikke er særlig viktig, ikke viktig nok til å indeksere. Om den var viktig hadde den nok blitt lenket direkte fra startsiden eller direkte fra en side under startsiden. Eller hva?

Du har et begrenset innhold på deg til å overbevise

Alt snakk om Google-sniping (sider skapt for spesifikke søkebegreper) du muligens har snappet opp kan du med andre ord begynne å stille spørsmål ved. Du skal ha under 200 lenker per underside, du skal ikke ha flere enn tre nivåer. Frem med kalkulatoren og regn på det. Det gamle snakket om at man når ut på søkemotorer via «den lange halen» og Google-sniping er ikke like gangbare ut fra dette synspunktet.

Verktøy for å sjekke navigasjonsstruktur

De som gjør innholdsrevisjoner i stil med det Kristina Halvorson anbefaler i sin utmerkede bok Content Strategy for the Web⁸⁵ har denne strukturen allerede i sin innholdsdokumentasjon.

Har du Matomo, snarere enn Google Analytics, finnes nettstedets dybde som en trestruktur å utforske. Det kan ta en stund å utforske strukturen og husk at det er adressenes struktur du ser snarere enn om noe er lenket direkte fra et høyt nivå i strukturen. Kjører du Google Analytics kan du filtrere frem tilsvarende informasjon under Behavior -> Site Content -> Content Drilldown. Der ser du et nettsteds gruppering, om URL-ene har mappinger i seg.

For den manuelt stikkprøveinteresserte personen kan man opprette en liste over de sidene som faktisk er viktige. Har de ikke en direktelenke fra startsiden og relevante landingssider, er det på tide å løse det problemet.

Tydelige lenketekster

Lenketeksten er teksten som er klikkbar og leder til en annen del av nettet. Rent allment bør de være blå og understreket om du ikke har gode grunner til å designe dem annerledes. Blå farge og understreket tekst er den historiske de facto-standarden for nettet, og da mange fortsatt kjører med dette letter det for dine brukere om vi følger den konvensjonen.

Skriv ikke «Les mer her» eller «Klikk her» som lenketekst! Grunnregelen for lenker er at deres tekst skal kunne stå for seg selv. Det vil si, man skal som seende kunne skumme gjennom siden og bare lese lenketekster og likevel få en ganske god oppfatning av hva de lenker til.

For en person med manglende eller nedsatt syn er det høyst avgjørende at du skriver gode lenketekster. Deres måte å navigere lengre tekstmasser er å hoppe mellom overskrifter, lenker og andre designelementer for å forsøke å få en oppfatning av en sides innhold. Det er ikke direkte hjelpsomt om de får høre «les mer» ti ganger på rad når de forsøker å navigere, eller hva?

Praksis med tunge filer

Om det du lenker til er en uvanlig type fil bør du skrive det ut i lenken, gjerne i parentes til slutt. Er filen tyngre enn en megabyte er også det en bra ting å skrive ut i lenketeksten i parentes. Alt for å ikke overraske brukeren. For eksempel «Last ned årsrapporten for 2016 (PDF, 7 Mb)».

Du har sikkert også sett lenketekster som «Bla bla (åpnes i nytt vindu)», eller de med et lite symbol etter. Det er i seg selv bra å fortelle når man tenker å åpne en lenke i nytt vindu, men hovedregelen er at man ikke skal åpne lenker i nye vinduer. Det finnes tusen dårlige unnskyldninger til hvorfor man synes det er motivert å åpne en lenke i et nytt vindu, men bare la være. Den mest effektive måten å lure en bruker er å åpne nye vinduer til høyre og venstre. Eller åpne i samme nye vindu flere ganger, eller kaprer klikket via Javascript for oss som Ctrl-klikker på lenker. Følg webstandard, la være å bestemme for brukeren, la brukeren ha kontroll over sin opplevelse!

Søkemotoroptimalisering og lenketekster

De ordene som utgjør lenketeksten er et signal til søkemotorer om hva man anser at den lenkede siden handler om. Det var dette noen lurebukar utnyttet for en masse år siden da de gjorde en såkalt Google-bombing av den amerikanske presidenten George W Bush. Gjennom å i lenketeksten skrive «miserable failure» og lenke til Det hvite hus' profilside for presidenten, gjorde Google assosiasjonen at George W Bush og søkebegrepet «miserable failure» hørte sammen.

Med andre ord, du vil ha relevante ord i lenketekstene, ord som gjenspeiler hva innholdet handler om. Det trenger ikke å være nøyaktig hva siden har i hovedoverskrift. Men ingen skal føle seg overrasket over hvor man havnet basert på en knepig formulert lenketekst. Søkemotorer blir også stadig bedre på å avgjøre når man driver med keyword-stuffing, altså når man propper inn en ulesbar mengde med søkeord man håper å fange opp. Skriv lenketekstene med omtanke for en menneskelig leser, i andre rekke kan du eksperimentere med SEO.

Om du fullstendig dominerer på søkemotorene på et bestemt nøkkelord kan du kanskje unne deg å i lenketekster bruke synonymer eller andre begreper. Eksempel på dette kan være at om du lenker til et produkt som har et navn helt uten konkurranse på søkemotorene, funderr på om ikke «Lazyboy Armchair 3000 Deluxe» kan få lenker som inneholder ord som lenestol eller hva nå søkeordet er som du vil forsøke å trenge deg frem på. Det er det samme med egne varemerker. Det er nok ganske sjelden man har konkurranse om dem, og spørsmålet er om man med et utenfraperspektiv bør bruke dem så ofte som man gjør?

Google Search Console har visninger for hvilke ord som brukes for å lenke til nettstedet. På visse eksterne nettsteder har man innflytelse over hvilke ord som brukes, men tenk på at det er mer slitsomt å endre disse enn på ditt eget nettsted. For å sjekke hvem som lenker til ditt nettsted kan du sjekke Search Consoles visning Søketrafikk -> Lenker til nettstedet ditt, det er hva Google kjenner til ved sin indeksering. Men du kan også i ditt webstatistikkverktøy sjekke hvilke henvisningsnettsteder som finnes, altså eksterne sider der besøkende har kommet fra. Da får du trolig en indikasjon på respektive sides relative viktighet.

Optimizr.com har med dette i sine rapporter. Selv om disse rapportene ikke kommer umiddelbart er de bra for passiv eller periodisk webanalyse.

God fordeling av lenkejuice

Det her med lenkejuice, altså en lenkes kraft eller verdi, er et ullent begrep som hører til søkemotoroptimalisering. Man kan se det som et problem om for mange av nettstedets lenker henviser til andre nettsteder. Det kan gi inntrykk av at nettstedet ikke har en egenverdi, at det ikke finnes relatert informasjon innen nettstedet.

Det finnes mange bud om hvor mange eksterne lenker en enkelt side bør ha, eller hvor stor andel, men se ikke dette som noen eksakt vitenskap. Iblant er det slik at en undersides hele formål går ut på å veilede din bruker til riktig nettsted – noen andres nettsted. For eksempel har vi som jobber med landstingenes nettsteder ekstremt gode grunner til å henvise de som søker helse til 1177.se, Ungdomsmottagningen Online, umo.se, da det er på de stedene vi samler den felles anstrengelsen å lage gode nettsteder. Men selvfølgelig finnes det brukere vi har grunn til å beholde. Som om man vil komme i kontakt med de som styrer organisasjonen, eller noe av alt annet som ikke er nasjonalisert.

I normale tilfeller skal du ikke sende av gårde dine besøkende til andre nettsteder. Om du så setter opp regler om at kun unntaksvis ha mer enn én eksternlenke er opp til deg.

Verktøy for å finne sølt lenkejuice

Du kan jo selvfølgelig gå gjennom dine viktigste sider manuelt og sjekke hvordan det står til. Ellers har Optimizr.com med dette i sine rapporter. Deres måte å definere dette er i skrivende stund at en side har færre enn ti interne lenker – det anses å gi en svak innholdsstruktur.

Strukturell CSS inkluderes i HTML-koden

Målet med denne typen CSS er at siden kan presentere seg raskere og la brukeren begynne sin bruk allerede før alt er lastet ned. Om du googler etter dette kan du lete etter Critical Path CSS.

Det hele foregår på den for mange webutviklere noe underlige måten at man inkluderer litt av CSS-koden inn i HTML-koden. Direkte via en style-tagg i kodens topptekst. Dette er noe vi som har kodet for nettet har kjempet for å bli kvitt, og fortsatt anses det delvis at CSS-kode i nettsider er slurvete kode. Regn ikke med at alle utviklere er enige med deg om at dette er en god idé.

Anekdote fra mars 2015 – utviklere trodde ikke sine øyne

Da jeg holdt et foredrag om webytelse foran 40-talls utviklere og teknikere satt flere med et overrasket uttrykk i ansiktet da de fikk øye på et bilde med koden bak mitt private nettsted. Bildet var ment å illustrere at man fjerner unødvendige mellomrom, tabber med mer fra HTML-koden. Jeg hadde dessverre ikke forvarsl om at all denne ekstra CSS-koden var lagt dit med vilje (note to self: bør nok ta dette opp tidlig under neste foredrag, slik at ingen trenger å stille spørsmålet og føle seg belært).

Jeg hadde selvfølgelig innledet med at jeg ønsker spørsmål velkommen, så en av utviklerne tok mot til seg: «Men Marcus, er det ikke veldig dårlig praksis å ha CSS i HTML-koden?!» Jeg er jo villig til å si meg enig. Det føles fortsatt rart å se det i koden, men det er bare å bøye seg og innse at den opplevde ytelsen får gå foran. Det handler tross alt om brukerne til syvende og sist.

Det er ren magi, men det finnes ulemper. I og med at man legger inn kode som på ingen måte er unik per side, gjør man alle siders HTML-kode noe tyngre. Tanken er at man legger inn bare det som gjør at siden kan vise seg raskere. Det vil si det som setter de ytre rammene for en side. Dette er et eksempel på når opplevd ytelse og teoretisk ytelse kolliderer. Egentlig blir sidevisningen noen kilobyte tyngre, men brukeren får øye på nettstedet raskere og kan dermed begynne å bruke det. Brukeren får en opplevelse av bedre flyt.

Samtidig må man være forsiktig slik at ikke sidens designelementer ser ut til å være ferdige før de faktisk kan brukes.

Verktøy for critical path css

Det finnes en Critical Path CSS Generator⁸⁶ på nettet som kan hjelpe deg å sile frem hvilken CSS du skal inkludere i toppteksten. Eller om man selv eller noen man kjenner har svart belte i CSS, kan man gjøre dette selv. Deretter plasserer man dette i head-taggen i en style-tagg. Validerer siden ifølge W3C er det på tide å teste om det fungerer som det er tenkt. Simuler gjerne en treg tilkobling via Google Chrome og test om noe er visuelt ferdig men ikke funksjonelt, for eksempel hamburgermenyer m.m.

Er du usikker, sett opp en A/B-test og evaluer om versjonen med critical path CSS virkelig fungerte bedre på akkurat ditt nettsted.

Ikke åpne lenker i nytt vindu

Å automatisk åpne lenker i et nytt vindu er en effektiv måte å lure sine brukere. De kommer nemlig ikke til å kunne bruke tilbake-knappen for å komme tilbake. Dermed innfører man et unødvendig krav om at brukeren skal være oppmerksom akkurat da det nye vinduet åpnes samt at hen skal huske dette senere.

Alle argumenter jeg har hørt om hvorfor man gjerne vil åpne lenker i nytt vindu er en forkledd velvilje overfor den besøkende. Man har den uimotsagte antakelsen om at dette er hva brukeren vil. Enkelte er mer åpne med sin baktanke, som at man for enhver pris vil beholde brukeren på sitt nettsted. Om ens nettsted ligger igjen bak det nye vinduet finnes likevel sjansen for at brukeren fortsetter å klikke rundt senere.

Jeg vil påstå at brukere kjenner til tilbake-knappen, samt at de nok bruker den om de vil komme tilbake. Dessuten at det ikke er forenlig med brukervennlighetsprinsipper å tvinge brukere til å huske at siden man havnet på er i en ny fane eller et nytt vindu (noe som gjør at tilbake ikke fungerer).

Men min absolutt største favoritt av alle dumheter rundt å åpne nye vinduer er når de åpnes i et nytt navngitt vindu. Dette gjøres, om man nå sjekker HTML-kode, gjennom å sette attributtet target til noe, for eksempel target="dokumentvindu". Det som da skjer er at første gang brukeren klikker på en slik lenke åpnes et nytt vindu. Deretter vil hver påfølgende lenke (med samme attributt) erstatte innholdet i dette navngitte vinduet/fanen. Har man da en liste med lenker der alle henviser til samme target vil flere klikk føre til at kun den sist klikkede lenken er innlastet, når man trolig ville ha alle de man klikket på.

Å åpne nye vinduer for brukerens skyld, til brukeren, er bare forvirrende for alle involverte. Denne ofte tilbakevendende problemstillingen tas opp av Webbriktlinjer.ses retningslinje 97 – å la tilbakeknappen fungere. Det gjør den ikke om man åpner i nye vinduer.

Nytt vindu er i strid med tilgjengelighetsretningslinjen WCAGs suksessfaktorer

Selv om de aller fleste ikke streber etter å til punkt og prikke leve opp til WCAGs mest strikte nivå, er det utvetydig hva som er riktig måte. Slik skriver de i sine anbefalinger (min utheving):

"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 unngå å overraske brukere, samt at brukere selv kan åpne lenker i nytt vindu om de nå vil det⁸⁷. Dessuten, i G200⁸⁸, finnes 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 gis også eksempler på nå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 eksemplene indikerer er at et desktop first-perspektiv finnes, spørsmålet er om W3C ville resonnere på samme måte mobilt. Dessuten forutsetter de litt at man verken tenker eller kan redesigne brukerens flyt i webapplikasjonen.

For de som vil leve etter god praksis uansett valgt ambisjonsnivå rundt tilgjengelighet er spørsmålet om lenker i nye vinduer egentlig veldig enkelt – gi blaffen i det :)

Nytt vindu er en sikkerhetsrisiko

Om nå ikke brukervennlighet eller tilgjengelighet er argument nok, er det også en sikkerhetsrisiko å åpne lenker i nytt vindu. I alle fall gjennom target="_blank" på lenken. Det lar seg nemlig gjøre å på et eksternt nettsted ta del av innholdet på opprinnelsessiden ved hjelp av litt Javascript-kode⁸⁹. Med andre ord skal man aldri åpne eksterne lenker i nytt vindu. Du har ingen kontroll over om de eksterne nettstedene du lenker til har sikkerhetsproblemer, og hva verre er vil de neppe komme på å varsle deg mens de fikser sitt sikkerhetshull. Om de noen gang kommer til å fikse sikkerhetshullet, det blir kanskje aldri oppdaget.

Meg bekjent finnes det ikke noe verktøy som kan hjelpe oss med dette i større skala. Om du har en egen søkemotor eller annen teknikk som har en lokal kopi av alle siders HTML kan du søke etter target= for å finne disse overtredelsene.

Ofte er disse løsningene systematiske og følger nettstedets publiseringssystem. Sjekk derfor inn hvordan lenker i diverse lister håndteres. Deretter kan du fundere på om muligheten til å åpne nye vinduer burde fjernes fra publiseringssystemet.

Ikke publiser PDF-filer

Det er ren plage å lese PDF-er på en mobil skjerm. Og er det ikke vel på tide å forlate den der tankegangen om faste formater som ble oppfunnet på 1400-tallet gjennom trykkpressen? Om du nå ikke har testet selv å lese en PDF på en mobiltelefon kan jeg forklare det for deg. Det handler om å enten ha oversikt der teksten er for liten, eller så har du zoomet inn slik at du kan lese deler av en setning. Når du zoomer kommer du til å miste oversikten ved hver rad når du har lest ferdig og skal inn på neste.

PDF er ikke bare dårlig, formatet har sine fortjenester. Blant annet er det et fornuftig format for arkivering, spesifikt varianten PDF/a, men også et utmerket format om man vil sende noe for utskrift til noen andre. PDF gjør at man kan referere til siste linjen på side to og alle ser på det samme. Man vet at innholdet vil skrives ut likt.

Responsiv web er ikke forenlig med PDF-filer

Men PDF-er er ikke et format for nettet. Samme utfordring som vi adresserte gjennom å bygge responsive nettsteder er det som gjør PDF-filer mindre bra. Ortodoks responsiv teori krever at man tenker bort lerret, størrelse på skjerm eller forutsetter en bestemt type bruker. En PDF er urtypen av lerret. Det hele går ut på å ha et innhold som har fiksert posisjon innen en gitt mål-bestemt flate. Et lerret rett og slett.

Det er veldig synd om man har et responsivt nettsted og brukerne like fullt havner på PDF-filer eller andre dokumenter som er uegnede til annet enn muligens å laste ned til en datamaskin. Dette gjelder selvfølgelig også Word-dokumenter og alt annet som ikke er ekte web.

Om ditt nettsted er på det offentlige nettet (altså ikke et intranett) kan du prøve å formulere en søkeforespørsel på Google lignende den nedenfor:

site:mittsted.no filetype:pdf

Tenk imidlertid på at det på visse organisasjoners nettsteder ikke er hoveddomenet som serverer dokumenter og PDF-filer. På min arbeidsplass ville det vært alfresco.vgregion.se som var domenet.

Tilby et sitemap

Et sitemap er en teknisk motstykke til nettstedskartet. Altså en liste med alle sider som finnes på et nettsted. Sitemaps er en industristandard⁹⁰ som ble utarbeidet av søkemotorselskaper som Google, Bing med flere, men du kan utmerket godt bruke ditt sitemap til andre ting enn å sende til søkemotorene.

Blant annet kan din egen søkemotor ha nytte av det. Eller de du samarbeider med ønsker kanskje å kunne overvåke når det kommer nytt materiale på ditt nettsted. Sitemapens innhold er en kronologisk liste over hvilke adresser som finnes på nettstedet. Nyest øverst og dessuten kan man legge inn en vekting om adressens relative verdi innen nettstedet.

Sitemapen bør gjerne hete noe forutsigbart, som sitemap.xml, og plasseres i nettstedets hjemmekatalog. Alternativt forteller du i din robots.txt hvor man kan finne sitemapen. Har du flere sitemaps trenger du en såkalt siteindex, det er en liste over hvilke sitemaps du har. Dette kan trenges om man har enormt mange poster i sine sitemaps, man får nemlig ikke ha et uendelig stort sitemap.

Kjører du Wordpress kan du bruke Wordpress SEO for å få med det de kaller for XML-nettstedskart. I annet fall får du i verste fall utvikle funksjonen selv, eller om innholdet nesten aldri endres og du har et mindre nettsted, orker du kanskje å skrive det for hånd.

Du kan påpeke for Google at du har et sitemap via deres Search Console, det samme gjelder Bing med deres Webmaster Tools. Der vil du få vite om det er noen feil relatert til ditt sitemap.

Ha en robots.txt og en humans.txt

Bilde 66: Robots.txt på min bokblogg.

En robots.txt er en tekstfil som ligger i roten, altså hovedkatalogen, på et nettsted. Den finnes der for å gi instruksjoner til boter som kobler til nettstedet. Blant annet instruerer man søkemotorene den veien om hvilke deler av nettstedet de ikke skal indeksere. Det er selvfølgelig praksis å følge det som står i en robots.txt, men for ondsinnet kan de den veien også få tips, så det gjelder å ikke være naiv.

Foruten å fortelle hvilke deler av nettstedet man ikke vil ha besøk på (såkalt disallow) er det praksis å fortelle hvor man har plassert sitt sitemap. Om du ikke er helt Google-sentrisk kan andre søkemotorer få hjelp med å indeksere ditt nettsted om du lister ditt sitemap på denne måten. Det er tross alt en veldig liten innsats.

For å dobbeltsjekke at din robots.txt er korrekt utformet kan du via Googles verktøy Search Console lese inn filen og få den analysert.

En humans.txt også – for dine menneskelige lesere

En del nettsteder har begynt å ha en humans.txt ved siden av sin robots.txt, dette for å skrive dokumentasjon til menneskelige lesere. Det er nettets motstykke til at man ofte finner en readme/lesmeg.txt når man sjekker inn andre typer programvarer.

Har du noe å si en menneskelig leser, gjør det i humans.txt-filen. Det kan være kontaktopplysninger, instruksjoner til teknikere eller utviklere som sjekker inn nettstedet.

Avrunding

Jeg håper du har funnet noe matnyttig i denne boken. Føl også at det står deg fritt å stille oppfølgende spørsmål, for eksempel via Twitter.

Fortsett å lese – Outro