Vad är webbutveckling?

Innan teknikvalen diskuteras finns ett antal fundamentala beslut. De skiljer ett webb-projekt från ett annat mer än vilken stack som väljs:

1. 01Bygga eller köpa. Bygga sajten själva, anlita byrå, eller köra på SaaS-plattform. Avvägningarna handlar om ägande, flexibilitet, tid till lansering och totalkostnad över livstid.
2. 02CMS eller skräddarsytt. WordPress eller Webflow ger snabb start och låg ingångströskel. Skräddarsytt bygge ger flexibilitet och äganderätt men kräver mer kompetens i drift och underhåll.
3. 03Ägande vs bekvämlighet. Open-source-CMS ger maximal äganderätt men kräver eget drift-arbete. Proprietär SaaS ger kortare tid till lansering men låser fast i leverantören.
4. 04Driftsmodell. Egen drift, hanterad drift, eller serverlös. Kostnad, kontroll och skalbarhet är avvägningar.
5. 05Tid till lansering vs framtida flexibilitet. Snabba mallar löser nuet men begränsar morgondagen. Skräddarsytt bygge tar längre tid men sätter inga gränser senare.

Beslutsunderlag, inte status. Det vi ser i nätverket är att de flesta webb-projekt som havererar inte havererar på teknikvalet. De havererar på att grundbesluten togs underförstått, utan att alla intressenter förstod vad de innebar.

När grundbesluten är gjorda kommer teknikval-valet som konsekvens. Det finns inga universal-rätta val. Här är avvägningarna för de vanliga alternativen:

• WordPress: snabb start, stort ekosystem, lätt att hitta utvecklare. Bäst för innehållstunga sajter med måttlig anpassning. Avvägning: säkerhetsunderhåll och växande plugin-mängd över tid.
• Webflow: visuell byggare med professionellt resultat. Bäst för marknadssajter där design-flexibilitet betyder mer än innehållsskala. Avvägning: SaaS-låsning, mindre kontroll på serversidan.
• Shopify: e-handelsplattform med snabb start. Bäst för standard-e-handelsflöden. Avvägning: transaktionsavgifter, mindre flexibilitet utanför Shopify-ekosystemet.
• Next.js↗ eller liknande JavaScript-framework: maximal flexibilitet och prestanda. Bäst för komplexa applikationer, headless-arkitektur, eller hög-trafik-sajter. Avvägning: kräver utvecklingsteam för drift.
• Sanity, Strapi eller annan headless-CMS: separerar innehållshantering från presentation. Bäst när innehåll används i flera kanaler eller när presentationen ska kunna bytas utan att röra innehållet. Avvägning: två-system-komplexitet.

Teknikvalet ska bekräfta affärsbeslutet, inte styra det. En CMS-driven sajt med begränsad anpassning kan vara helt rätt för ett SaaS-bolag som behöver fokusera på produkten. En skräddarsydd Next.js-plattform kan vara fel för ett mindre bolag som ska iterera innehåll snabbt. Strategin leder, specialisterna levererar. Teknikvalet följer.

Prestanda är inte en teknisk fråga. Det är en affärs-KPI. Googles guide för Core Web Vitals och affärseffekt↗ visar att laddningstid direkt påverkar avvisningsfrekvens och konvertering. Varje extra sekund laddningstid kan kosta avhopp och förlorad intäkt. Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift) är Googles formaliserade mätpunkter för upplevd prestanda. De påverkar både ranking och konvertering.

• LCP (Largest Contentful Paint): hur snabbt sidans huvudinnehåll syns. Bör vara under 2,5 sekunder.
• INP (Interaction to Next Paint): hur snabbt sidan svarar på användarinput. Bör vara under 200 millisekunder.
• CLS (Cumulative Layout Shift): hur stabilt layouten är när sidan laddas. Bör vara under 0,1.

Prestanda-arbete är affärsarbete. Det handlar inte om att klara Lighthouse-tester för Googles skull, utan om att besökarna stannar, scrollar och konverterar. En sajt som tar 4 sekunder att ladda förlorar besökare innan de sett vad ni säljer. Prestanda-budget måste vara med från sajtens grundbeslut, inte adderas som optimering i sluttampen.

Tillgänglighet (a11y) är inte valfri. EU:s European Accessibility Act gjorde tillgänglighet till lag-krav från juni 2025 för många digitala tjänster. WCAG-riktlinjerna↗ är det internationella referens-ramverket. A11y är också affärsbeslut: en otillgänglig sajt utesluter en del av befolkningen från att handla, läsa eller konvertera.

• Tangentbordsnavigering: hela sajten ska fungera utan mus
• Skärmläsar-stöd: semantiskt korrekt HTML, alt-text på bilder, ARIA-attribut där det behövs
• Färgkontrast: minst 4,5 till 1 för normal text mot bakgrund
• Fokus-indikering: synliga fokusmarkeringar vid tangentbordsnavigering
• Strukturerade rubriker: H1 till H6-hierarki som matchar dokumentets logik

A11y-arbetet är ofta enklare att bygga in från start än att lägga till i efterhand. Det vi ser i nätverket (samlad senior expertis erfarenhet av att bygga och granska sajter) är att otillgängliga sajter typiskt byggts av byråer som inte hade a11y som standard-krav. En a11y-granskning på en färdig sajt avslöjar ofta 50 till 100 brister. Bygger man från grunden med a11y som krav är det inte mer arbete. Det är samma arbete, gjort rätt från början.

Inte alla webb-relaterade problem är webbutvecklings-problem. En sajt som konverterar dåligt kan ha en webbutvecklings-rot eller inte. Innan ni ringer en webbyrå, fråga var problemet egentligen sitter:

• Det är webb-jobb om: sajten är teknisk-svag (laddningstid, mobilanpassning, fundamental UX-fel), strukturen blockerar konvertering, eller om plattformen begränsar vad ni behöver göra framåt.
• Det är CRO-jobb om: trafiken konverterar dåligt och problemet ligger i copy, hypoteser eller trattflöde snarare än i sajtens grundstruktur.
• Det är SEO-jobb om: rätt målgrupp inte hittar er. Webbutveckling kan vara förutsättning för SEO (teknisk grund) men är inte SEO.
• Det är copy-jobb om: budskapet inte träffar målgruppens situation. En vacker sajt med fel ord konverterar inte.

Skiljelinjen är inte exakt. I praktiken är webb-projekt ofta blandade. En omlansering kan kräva webbutveckling, SEO-migrering, copy-iteration och CRO-arbete parallellt. Att förstå vilken disciplin som löser vilket problem skiljer ett lyckat projekt från ett spretigt. Om det här pekar på er situation, se hur Memorise arbetar med webb.