Gå til primært indhold

Det nye Shift website

Vi har glædet os rigtig meget til at lancere vores nye website, som vi har gået og arbejdet på imellem opgaver for vores kunder og samarbejdspartnere, og vi har også glædet os til at fortælle lidt om tankerne og teknologien bag. Men lad os starte med at gå lidt tilbage i tiden, inden vi kommer så langt.

http://shiftcph.dk, version 1

Da vi startede Shift for lidt over syv år siden brugte vi forholdsvis kort tid på at designe og udvikle vores eget website, bl.a. fordi vi fokuserede på at skabe noget forretning og hjælpe andre med deres websites, men også fordi vi havde en idé om at vores første website var en midlertidig løsning. Det viste sig at være en korrekt antagelse, men vi havde nok ikke forudset at den midlertidige løsning holdt i mere end syv år. Oh well, det er vel i virkeligheden en klassisk historie: det er altid skomagerens søn, der render rundt med huller i sålerne.

Det er nu ikke fordi vi ikke har taget tilløb til at ændre vores website undervejs, det har vi skam. Vi er bare aldrig kommet særlig langt med projektet, og da vi for næsten tre år siden var lige ved at være klar med en struktur og et design, ændrede vi fuldstændig strategi og form, og dermed blev det nye website slået tilbage til nul.

Men nu! Nu er det endelig klart — bemærk at jeg ikke skriver færdigt, for det er en af de ting, vi konstant fortæller vores kunder: et website er aldrig færdigt, men befinder sig derimod i en tilstand af konstant udvikling, og heldigvis for det. 

Noget at leve op til

Det oprindelige Shift-site stod lidt som et fyrtårn, som vi skulle sigte efter, idet det lever op til to ud af de tre ting, som vi lever af at sælge: sitet overholder tilgængeligheds-standarden (WCAG 2.1 AA) og det loader utrolig hurtigt (100/100 ifølge Googles målinger). 

Screenshot fra Lighthouse, der viser at det første Shift site scorede 100 i alle fire kategorier: performance, accessibility, best practices og SEO.
Det første Shift website scorede ganske pænt i Google Lighthouse testen: 100 ud af 100 i alle fire kategorier.

Når vi engang imellem talte om glæden ved at vores hjemmeside levede op til vores egne krav, så var det også altid med et lille aber dabei i baghovedet: hvor svært var det lige at gøre med en enkelt side, der ikke havde noget reelt content. Derfor var det også et af målene for det nye Shift website, at det skulle performe mindst lige så godt som det gamle.

Teknologivalg

Valget af Content Management System var en af de sjove snakke, som optog os undervejs. Vi er alle bekendte med WordPress, som har et fantastisk redaktør-interface, men det kan godt byde på udfordringer kodemæssigt og ikke mindst performance-mæssigt, når man skal foretage database-opslag undervejs. En mulighed var at bruge WordPress som CMS, men ikke benytte sig af deres frontend-lag (også kendt som theming-delen), men derimod af deres API, som praktisk talt betyder at man benytter WordPress som et såkaldt headless CMS. Men når man har sagt A, så kan man lige så godt sige B, og hvis vi skulle gå med et headless CMS, så kunne det lige så godt være et ægte et af slagsen. Og når man taler om det, så ender valget ofte mellem to muligheder: Prismic og Contentful. Efter meget kortvarig research, der viste at begge dele understøttede vores behov, så valgte vi at gå videre med Prismic — ganske enkelt fordi Contentful er markant dyrere. 

For at have et lynende hurtigt website, kan man sige at vi har skruet tiden tilbage til internettets spæde start, hvor mulighederne var begrænsede og de fleste sites derfor bestod af statiske HTML-sider. Dengang var det en besværlig proces at ændre på tværs af 50 statiske sider: hvis man havde en ændring til f.eks. navigationen eller footeren, krævede det som oftest at man åbnede alle 50 filer, lavede ændringen i dem alle og uploadede til sin server igen via FTP.  Sådan er det heldigvis ikke længere, og pt. er der ved at opstå en trend der omtales som Static Sites. Et Static Site er ikke spor statisk ift. indhold, men er derimod en samling pre-byggede HTML-filer, der ligger klar på en server, så når brugeren efterspørger en side, skal serveren ikke lave noget arbejde udover at sende filen tilbage til brugeren. Væk er databasekald, fil-generering og andre ting, der giver brugeren en dårlig oplevelse og istedet er de erstattet med en hjemmeside der loader med lynets hast. En lille, og for os ubetydelig, ulempe ved Static Sites, er at man som udvikler og redaktør, skal vente lidt før ens ændringer træder i kraft, da alle siderne skal bygges før de bliver publiceret — man kan sige at ventetiden er flyttet fra brugeren og over til udviklerne og redaktørerne, og det synes vi giver fin mening, for alle valg vi foretager os i Shift er med brugeren i centrum.

Gatsby

For at bygge vores Static Site, valgte vi at bruge et framework, der hedder Gatsby. Der var kortvarigt andre muligheder på bordet, bl.a. 11ty, men Gatsby giver os nogle muligheder og udfordringer, som vi synes kunne være interessante at give os i kast med: først og fremmest er det godt dokumenteret og meget udbredt, og dernæst bruger man React til at generere sit site — nu skulle man måske tro at vi valgte React-vejen fordi vi er superskarpe til det, men faktisk forholdt det sig en smule omvendt: vi kunne godt tænke os at blive bedre til det, end vi var i forvejen, og hvad kunne være en bedre læring end at prøve det på egen krop? React har sine fordele og ulemper, men én af fordelene er helt klart at det er komponent/modul-baseret, og dermed kommer den tredje af vores “produkter”, nemlig skalérbarhed, også i spil på vores eget website.

Micro-services

Ved at splitte vores site op i et rent kodelag og et headless CMS, har vi samtidig ikke bundet os fast til én løsning, som vi ville have gjort, hvis vi f.eks. havde valgt et traditionelt CMS (WordPress, Drupal, Umbraco etc.). En af fordelene ved den fremgangsmåde er, at vi kan udskifte en eller flere dele seamlessly, dvs. at hvis vores behov på et tidspunkt vokser sig større end Prismic kan leve op til, så kan vi udskifte det med et andet CMS, der kan levere data i struktureret form (hint: det kan de stort set allesammen nu), og dermed vil ændringerne, der skal laves til vores React-kode være minimale.

Hosting

Indtil nu har vi kun omtalt to dele af vores teknologiske stack, nemlig Gatsby og Prismic. En tredje og u-undværlig del af teknik-stakken er hosting provideren. Indtil nu har vi selv håndteret en server med alt hvad det indebærer: håndtering af SSL-certifikater, installering af sikkerhedsupdates og opdatering af serveren. Endelig har vi brugt god, gammeldags FTP til at flytte filer mellem vores lokale udviklingsmiljøer og live-serveren — det har virket, men sidstnævnte kan gøres smartere. Vi har bare ikke prioriteret at bruge tiden på det, da den tid højst sandsynligvis vil overstige den tid, vi har brugt på at flytte filerne.

For at sige det ærligt, så gider vi ikke rode med den slags mere. For det første er det ikke et område, hvor vi kalder os eksperter, og for det andet så er det lidt … kedeligt. Vi undskylder på forhånd til dem, der synes at den slags er sjovt og spændende, men det er bare ikke noget vi finder den store glæde ved. Heldigvis for os er der kommet flere services, der specialiserer sig i at hoste Static Sites og fjerne alt det besværlige ved hosting, og en af disse services er Netlify, som udgør hosting-delen af af vores nye website. Netlifys bruger-interface er nemt, intuitivt og giver alle de muligheder, vi har brug for, så der bliver automatisk bygget en ny version af websitet, når vi publicerer nyt indhold i Prismic eller når vi opdaterer koden i vores GIT release-branch.

Fortsættes...

Følg med her på sitet for at læse anden del af historien om tilblivelsen af vores nye website. Næste gang skriver vi om indholds-strategi.