Ekstern CTO - Sådan auditerer jeg en webshop på 2 timer

Når en webshop-ejer kontakter mig for en teknisk gennemgang er det typisk fordi noget føles forkert. Siden er langsom. Konverteringen er faldet. Ting der plejede at virke virker ikke længere. Men de ved ikke præcis hvad der er galt eller hvor de skal starte.

Det er her en audit kommer ind. På 2 timer kan jeg give et klart billede af din webshops tekniske tilstand. Ikke en overfladisk gennemgang men en struktureret analyse der identificerer de vigtigste problemer og muligheder.

Tidsfordeling og struktur

En effektiv audit kræver struktur. Jeg har udviklet en proces der giver mig mest muligt indblik på 2 timer fordelt på fire faser. Performance-analyse tager 30 minutter og fokuserer på hastighed, Core Web Vitals og mobile oplevelse. Kode og tema tager 30 minutter med fokus på tema-kvalitet, apps, scripts og teknisk gæld. Integrationer og flow tager 30 minutter med fokus på checkout, betalinger og tredjepartssystemer. Rapport og anbefalinger tager 30 minutter med sammenfatning, prioritering og handlingsplan.

Fase 1 med performance-analyse

Jeg starter altid med performance fordi det er det mest synlige problem og ofte det der påvirker bundlinjen mest direkte.

Mit primære værktøj er PageSpeed Insights fra Google der giver Core Web Vitals-scores baseret på rigtige brugerdata og lab-tests. Jeg kører det på forsiden, en kategoriside, en produktside og checkout hvis tilgængelig eksternt. GTmetrix supplerer PageSpeed med detaljeret vandfaldsdiagram der viser præcis hvilke ressourcer der loader, i hvilken rækkefølge og hvor lang tid de tager. WebPageTest viser rendering-progression og identificerer render-blocking ressourcer, og Chrome DevTools afslører tredjepartsscripts i Network-fanen mens Performance-fanen viser JavaScript-problemer.

For Core Web Vitals skal LCP (Largest Contentful Paint) være under 2.5 sekunder og over 4 sekunder er kritisk. INP (Interaction to Next Paint) skal være under 200ms og erstattede FID som officiel Core Web Vital i marts 2024 hvor den måler responsivitet på alle interaktioner. CLS (Cumulative Layout Shift) skal være under 0.1 og høj CLS betyder elementer der hopper rundt.

Typiske fund er billeder der ikke er optimeret hvilket ofte udgør over 50% af problemet, for mange tredjepartsscripts fra tracking, chat og reviews, render-blocking CSS og JavaScript, manglende lazy loading og for mange HTTP-requests hvor over 50 er et warning sign.

I en nylig audit fandt jeg en webshop med LCP på 8.2 sekunder på mobil. Årsagen var et hero-billede på 4.5 MB der ikke var optimeret. Komprimering og WebP-format bragte det ned på 180 KB og LCP faldt til 2.1 sekunder. Det er den slags lavthængende frugter jeg ofte finder i første fase.

Fase 2 med kode og tema

Nu går jeg dybere. Her handler det om at forstå det tekniske fundament.

For tema-kvalitet undersøger jeg om det er et moderne tema eller et ældre, hvornår det sidst blev opdateret, om der er custom kode og om den er velstruktureret, og om det bruger moderne practices som CSS Grid og lazy loading. For app-landskabet kigger jeg på hvor mange apps der er installeret, om der er overlap i funktionalitet, om der er apps der ikke bruges men stadig loader scripts, og om kritiske apps er opdaterede. For script-analyse undersøger jeg hvilke tredjepartsscripts der loader, om der er scripts fra afinstallerede apps, om scripts er placeret korrekt med defer/async og om der er konflikter mellem scripts.

Jeg bruger Wappalyzer eller BuiltWith til at identificere teknologier, frameworks og services der bruges. Chrome DevTools Sources-fanen giver gennemgang af loaded scripts og deres oprindelse. View Source er gammeldags men effektivt hvor jeg scanner HTML for red flags.

Red flags jeg kigger efter inkluderer scripts fra ukendte domæner som potentiel sikkerhedsrisiko, inline styles og scripts som tegn på quick fixes, jQuery plus andet framework som ofte unødvendig bloat, kommenteret kode i produktion som dårlig kodepraksis, console errors som JavaScript-fejl der påvirker funktionalitet og mixed content warnings med HTTP-ressourcer på HTTPS-side.

Fase 3 med integrationer og flow

Her tester jeg den faktiske brugeroplevelse og de kritiske flows.

Jeg laver en test-ordre uden at gennemføre betaling og observerer hastighed mellem trin, unødvendige felter eller friktion, betalingsmuligheder og deres integration, fejlhåndtering og hvad der sker ved fejl, samt mobile checkout-oplevelse.

For tredjepartsintegrationer tjekker jeg betalingsgateway med korrekt konfiguration og alle betalingsmetoder, fragt med korrekt loading af fragtpriser og eventuelle forsinkelser, marketing med korrekt implementering af tracking-scripts, og email med afsendelse af bekræftelser og SPF/DKIM-opsætning.

Jeg gennemgår typiske brugerflows fra forside til produktside, søgning og filtrering, tilføj til kurv, kurv til checkout og oprettelse af konto hvis relevant. Jeg kigger efter døde links med produkter eller kategorier der 404’er, langsom søgning med søgeresultater der tager for lang tid, broken images der ikke loader, form errors med formularer der ikke submitter korrekt, og mobile issues med touch-targets der er for små og tekst der er ulæselig.

Fase 4 med rapport og anbefalinger

Den sidste halve time bruger jeg på at sammenfatte fundene i en struktureret rapport.

Rapporten indeholder en executive summary på en halv side der opsummerer de vigtigste fund for en ikke-teknisk læser. Der er et performance-scorecard med Core Web Vitals for nøglesider sammenlignet med Googles anbefalinger og branchegennemsnit. Detaljerede fund dokumenteres med beskrivelse af problemet, screenshot eller data der viser problemet, anbefalet løsning, estimeret kompleksitet som lav, mellem eller høj, og prioritet som kritisk, vigtig eller nice-to-have. Der er en prioriteret handlingsplan med top 5-10 anbefalinger baseret på påvirkning på brugeroplevelse og konvertering, kompleksitet at implementere og risiko ved at ignorere. Quick wins er ting der kan fikses på under en time med stor effekt.

Et eksempel på rapportstruktur er problem nummer 1 med kritisk langsom LCP på mobil med score på 6.8 sekunder der bør være under 2.5 sekunder, årsag er hero-slider med 5 ukomprimerede billeder, løsning er komprimér billeder, implementer lazy loading og overvej statisk hero, kompleksitet er lav og prioritet er kritisk. Problem nummer 2 er 12 ubrugte apps der loader scripts med påvirkning på cirka 1.2 sekunder ekstra loadtid, løsning er afinstallér ubrugte apps og ryd op i tema-kode, kompleksitet er mellem da det kræver tema-oprydning og prioritet er høj.

Hvad en audit ikke dækker

Jeg går ikke dybt i komplet sikkerhedsaudit der kræver specialiserede værktøjer og mere tid, SEO-analyse der er en disciplin i sig selv, konverteringsoptimering der kræver data og A/B-testing, forretningsanalyse med omsætning, marginer og kundedata, eller juridisk compliance med GDPR og cookieregler. Jeg ser ikke backend-kode medmindre jeg får adgang, database-struktur og queries, server-konfiguration på selvhostede løsninger eller tredjeparters interne systemer.

En audit er et øjebliksbillede der viser status lige nu. Den fanger ikke intermitterende problemer eller ting der kun sker under høj belastning. Hvis du har brug for dybere analyse af specifikke områder kan vi aftale en udvidet gennemgang.

Typiske red flags der altid dukker op

Performance red flags inkluderer LCP over 4 sekunder på mobil, CLS over 0.25 med elementer der hopper, over 100 HTTP-requests per sidevisning, tredjepartsscripts der udgør over 50% af loadtid og manglende billedoptimering. Tekniske red flags inkluderer tema der ikke er opdateret i over et år, over 20 apps installeret, console errors på alle sider, mixed content warnings og broken structured data. Integrations red flags inkluderer checkout der tager over 10 sekunder at loade, betalingsfejl der ikke håndteres gracefully, fragtpriser der loader asynkront og skaber CLS og tracking der blokerer rendering. Arkitektoniske red flags inkluderer ingen caching-strategi, alle assets loaded synkront, fonts der blokerer rendering og ingen CDN på statiske assets.

Hvad det koster

Standard audit på 2 timer koster 3.500 kr ekskl. moms og inkluderer 2 timers grundig gennemgang, skriftlig rapport på 5-10 sider, prioriteret handlingsplan og 30 minutters opfølgende sparring hvis ønsket. Udvidet audit med pris efter aftale er for større webshops eller specifikke dybdegående analyser af sikkerhed, SEO eller performance under load hvor vi aftaler scope og pris individuelt.

Du får konkret, handlingsorienteret rådgivning og hvad du gør med den bagefter er helt op til dig.

Hvornår giver en audit mening

En audit er relevant når du føler noget er galt men ved ikke hvad, performance er faldet uden åbenlys årsag, du overvejer platformskifte og vil vide hvad der er galt nu, du skal vælge bureau og vil have uafhængig vurdering af nuværende setup, du har overtaget en webshop og vil kende dens tilstand, eller du forbereder investering eller salg og har brug for teknisk overblik.

En audit er ikke nødvendig hvis alt kører perfekt og vækster stabilt, du har nyligt fået grundig gennemgang fra et bureau du stoler på, eller din webshop er under 3 måneder gammel da der ikke er nået at akkumulere problemer.

Opsummering

En webshop-audit handler ikke om at finde fejl for fejlenes skyld. Det handler om at give dig et klart billede af din tekniske situation så du kan træffe informerede beslutninger.

På 2 timer kan jeg identificere de vigtigste problemer og muligheder. Ikke alt men nok til at du ved hvor du skal fokusere.

Hvis din webshop føles langsom, ustabil eller bare ikke helt rigtig er en audit et godt sted at starte. Du får konkrete svar i stedet for mavefornemmelser. Kontakt mig for at aftale en audit af din webshop.