Tech Platform: centrum-csr.com

#centrum-csr.com, ditt kunnskapssenter om bedriftens samfunnsansvar

Nesten ingen kommer til et fagnettsted via forsiden. De kommer fra et søkeresultat eller en lenke i et nyhetsbrev, lander midt inne i arkivet og bestemmer seg i løpet av den første skjermen. centrum-csr.com er et nettsted om bedriftens samfunnsansvar og bærekraftig utvikling, laget for bedrifter, frivillige organisasjoner og alle som innfører slik praksis i egen virksomhet. Det gikk i drift i 2012, kjører på WordPress med Redis som objektcache og et REST API-lag, frontend er bygget i HTML5, CSS3 og SASS, og mediefilene leveres gjennom CDN. Utviklingen tok omtrent seks uker, og kunden leverte layout og plassering av elementer.

At leseren lander dypt inne i strukturen har flere følger enn det kan se ut som. Hver enkelt side må stå på egne bein, navigasjonen må fungere innenfra og ut, og publiseringsdatoen må være synlig, for på dette fagfeltet er et dokument uten dato et dokument ingen kan vise til.

#Kunnskapsbase og nyheter eldes i ulikt tempo

Den viktigste redaksjonelle avgjørelsen var å skille kunnskapsbasen fra nyhetsstrømmen. De ser like ut, begge er tekst med tittel og dato, men de oppfører seg ulikt på alle punkter som betyr noe.

En nyhet holder en uke, hører hjemme på forsiden og trenger ikke komme tilbake. En veiledning i kunnskapsbasen er verdt nøyaktig så mye som riktigheten to år senere. Den trenger gjennomgang, en synlig dato for siste kontroll og en plass i strukturen som ikke avhenger av når den ble publisert. I praksis betyr det at det varige stoffet får egne temakategorier, som økologi og forretningsetikk, og egne maler, mens nyhetene forblir en strøm.

Prisen er redaksjonell disiplin. Noen må avgjøre hvilken skuff en tekst hører hjemme i, og den avgjørelsen lar seg ikke automatisere, for det samme materialet kan skrives som en notis om et arrangement eller som en innføring i et tema. Gevinsten kommer først etter år, når en gjennomgang gjelder tjue veiledninger og ikke to hundre innlegg der de fleste uansett er historie.

Samme logikk ligger bak den egne seksjonen med eksempler på gjennomførte tiltak. Det er ikke pynt, men en samling saker det vises til fra fagtekstene. For at den skal la seg vedlikeholde, må hver sak ha egne felter i stedet for å være enda et avsnitt med et bilde limt inn.

#Asynkron lasting og grensen som er verdt å kjenne

Nettstedet henter innhold asynkront, altså laster lister og seksjoner inn flere oppføringer uten at hele siden lastes på nytt. Med en stor base av artikler og rapporter er det en reell lettelse: leseren blar, snevrer inn og betaler ikke full pris for å bygge en side hver gang.

Det finnes én grense, og den bør kjennes før utviklingen, ikke etter. Innhold som først finnes etter at et skript har kjørt, finnes ikke for deler av publikum: i det milde tilfellet ikke for en søkerobot, i det alvorlige ikke for en skjermleser. Derfor har hver artikkel og hver rapport sin egen adresse og sin fullstendige tekst i et vanlig HTML-dokument, og det asynkrone laget gjør bare navigasjonen i listene raskere.

REST-grensesnittet gjør her det samme som et godt avgrenset endepunkt gjør i ethvert annet prosjekt: det leverer akkurat de dataene som trengs for å tegne én del av grensesnittet. Hvis artikkellisten hadde bedt om hele innlegg, ville hver etterlasting dratt med seg all brødtekst for å vise tittel, kategori og to linjer ingress. Det mindre svaret er ikke bare raskere, det oppfører seg også bedre i cache, fordi den ressursen endres sjeldnere enn artikkelteksten.

#Ytelse og hvem cachen egentlig hjelper

Redis tar objektcachen. En WordPress-side settes sammen av mange små lesninger: innstillinger, metadata, taksonomirelasjoner. I en listevisning med kategorier, stikkord og ingresser vokser antallet slike lesninger raskere enn antallet synlige elementer skulle tilsi.

Det interessante spørsmålet er hvem cachen hjelper. En full sidecache betjener den anonyme leseren og løser saken sett fra den kanten. Den gjør ingenting for en innlogget redaktør, for visninger med parametre eller for API-svar, og det er nettopp der redaksjonen arbeider. Et nettsted som er raskt for lesere og tregt i administrasjonsgrensesnittet demper publiseringslysten, og det koster mer enn noen hundre millisekunder på forsiden.

Mediefilene, altså bilder, infografikk og videomateriale om tiltakene, leveres gjennom CDN. Grunnen er nøktern: det er de største filene på nettstedet, og å levere dem fra applikasjonsserveren binder kapasitet som heller bør gå til å bygge sider.

Målingene ble gjort mot en kopi av produksjon, ikke mot en tom installasjon. En tom WordPress svarer alltid raskt, for det finnes ingenting å lete i. Først en database med hele bestanden av artikler, rapporter, kategorirelasjoner og kommentarhistorikk viser hvilken spørring som skanner halve tabellen.

#Skjemaer er stedet der nettstedet møter mennesker

Et kontaktskjema på et fagnettsted gjør en annen jobb enn et i en nettbutikk. Det tar ikke imot bestillinger, men forespørsler om rådgivning, ønsker om materiale og henvendelser fra organisasjoner som vil vise fram egen praksis. Meldingene er lange, og avsenderen venter et svar, ikke en kvittering.

Tre ting må avklares teknisk. Leveringsevne først: e-post som nettstedets egen server sender med besøkendes adresse i avsenderfeltet havner i søppelpost langt oftere enn man tror, så avsenderadressen må tilhøre nettstedets domene og adressen fra skjemaet hører hjemme i svarfeltet. Søppelpost dernest: ethvert offentlig tilgjengelig skjema blir funnet av automatisert trafikk i løpet av uker, så filtrering og fartsgrense er en forutsetning for at innboksen fortsatt skal være lesbar. Feltlengde til slutt: å kutte meldingsteksten ved en tegngrense er en feil som først viser seg når noen har beskrevet saken sin i tre avsnitt og to av dem kom fram.

#Frontend er der gjelden samler seg

Presentasjonslaget ble skrevet i HTML5, CSS3 og SASS. SASS var et vedlikeholdsvalg og ikke et estetisk et: det holder farger, avstander og bruddpunkter samlet ett sted i stedet for spredt utover stilarkene, noe som på et nettsted som utvides i årevis er forskjellen mellom en endring på et kvarter og en ettermiddag med lesing av CSS.

Det bør sies rett ut at dette laget eldes raskere enn noe annet i prosjektet. Responsiv praksis fra 2012 og rammeverkene man bygde oppsett på den gangen er i dag nettopp den delen en større ombygging bytter ut i sin helhet. Innholdsmodellen og måten data leveres på gjennom grensesnittet har holdt seg vesentlig bedre. Den observasjonen er verdt å ta med videre: penger brukt på datastruktur arbeider lenger enn penger brukt på presentasjon.

På søkesiden besto arbeidet av semantisk oppmerking, ryddige metadata, lesbare adresser, strukturerte data etter schema.org og et XML-sitemap. Hensikten er avgrenset: å beskrive for en maskin det et menneske leser ut av oppsettet. Strukturerte data løfter ikke en svak tekst over en god, de hindrer at en god tekst blir oversett fordi roboten ikke forsto hva slags side den så på. Jeg har ingen målinger av effekten som kunne oppgis med god samvittighet, så jeg oppgir ingen.

#Støtte og vedlikehold av nettstedet

Den løpende oppfølgingen omfatter oppdateringer av kjerne, tema og utvidelser, gjennomgang av logger, sikkerhetskopier og mindre funksjonelle og visuelle endringer. Oppdateringer testes på en kopi, for et prosjekt med egne maler, API-integrasjon og offentlige skjemaer har flere steder der en endring i en utvidelse flytter oppførselen uten å melde feil: et filter en visning bygde på forsvinner, en spørring settes sammen annerledes, utsending fra skjemaet stopper stille.

En sikkerhetskopi er en gjenopprettingsprosedyre, ikke en fil på en disk. Verdi har den kopien noen allerede har satt opp en fungerende versjon av nettstedet fra, med notat om hvor lang tid det tok.

#Oppsummering

På centrum-csr.com er det faglige innholdet produktet, og teknikken har som oppgave å holde det lesbart i årevis. Det som avgjorde formen er usynlig utenfra: kunnskapsbasen skilt fra nyhetsstrømmen, asynkron lasting som en akselerasjon og ikke som eneste vei til teksten, en objektcache innstilt etter redaksjonens arbeid, og en datastruktur holdt atskilt fra et presentasjonslag som uansett kom til å eldes først.

Videre til neste prosjekt følger det tekniske laget og metoden: WordPress, Redis, REST API, CDN og måling mot en kopi av produksjon. Det som ikke følger med er innholdsmodellen og integrasjonene til dette nettstedet, skrevet for ett materiale og én redaksjonell rutine. En ny leveranse begynner med en gjennomgang av omfanget, og prisen kommer etter den.