React & Next.js — Høytytende webapplikasjoner
Vi bruker React 18 og Next.js 15 (App Router) i alle frontend-prosjekter: fra presentasjonsnettsteder til komplekse SaaS-løsninger med titusenvis av brukere. Koden er strengt TypeScript, og både testene og utrullingen er automatiserte.
Hvorfor Next.js i prosjektene våre
Next.js 15 med App Router gir en unik hybridmodell: statiske sider (SSG) leveres ferdig fra CDN, dynamiske sider kjører Server Components som ikke sender unødvendig JavaScript til nettleseren, og sider med sanntidsdata bruker isolerte Client Components. Hver side får dermed den renderingsmodellen som passer innholdet.
Bildefiler optimaliseres automatisk gjennom `<Image>`-komponenten (WebP/AVIF, responsiv srcSet, lazy loading), fontene ligger inline i den kritiske CSS-en via `next/font`, og tredjepartsskript lastes med prioriteringsstrategier. Effekten måles med Core Web Vitals (LCP, CLS og INP).
- Server Components for markedsføringssider — ingen komponent-JS hos klienten, ferdig HTML for crawlere
- Streaming SSR med Suspense for dashbord med live data
- Incremental Static Regeneration (ISR) for halvdynamisk innhold
- Route Groups og Parallel Routes for komplekse layouter uten ny rendering
Streng TypeScript — ingen stille feil
Alle prosjektene våre bruker TypeScript med `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` og `noUncheckedIndexedAccess`. Disse innstillingene stopper hele kategorier av kjøretidsfeil ved kompilering: tilgang til undefined, ufullstendige typer på API-svar og feilaktige sammenligninger. Et typisk prosjekt har 0 TypeScript-feil i CI før noen test kjøres.
For tilstandshåndtering bruker vi Zustand (lett, uten boilerplate) eller React Context for lokal tilstand. Datahenting håndteres med TanStack Query (automatisk cache, smart ugyldiggjøring, stale-while-revalidate). Skjemaer bygges med React Hook Form + Zod-skjemavalidering — synkron og asynkron validering uten duplisert kode.
- ESLint med egne regler for forbudte mønstre (any, console.log, magic strings)
- Prettier med ensartet konfigurasjon — ingen PR avvises på grunn av formatering
- Zod for validering av data fra eksterne API-er ved kjøretid
- Path aliases (`@/components/...`) — tydelige importer uten `../../..`
Automatisert testing og CI/CD
Enhetstester med Vitest (raskt, kompatibelt med Jest-API-et), komponenttester med React Testing Library og E2E med Playwright i 3 nettlesere (Chromium, Firefox, WebKit). GitHub Actions-pipelinen kjører alle testene for hver PR, og sammenslåing blokkeres hvis én av dem feiler. Minimum 80 % dekning på forretningslogikk.
- Lighthouse CI — en score under 90 blokkerer utrulling til staging
- Automatisk bundle-analyse — varsel hvis bundelen vokser med mer enn 5 % i forhold til main
- Storybook for UI-komponenter — levende visuell dokumentasjon
Fordeler og begrensninger
Fordeler
- Innebygd bilde- og fontoptimalisering (next/image, next/font) uten manuelt oppsett.
- Innebygd SSR og SSG — ferdig HTML for Google og AI-søkemotorer.
- Streng TypeScript fanger feil ved kompilering, ikke i produksjon.
- Modent økosystem: Vercel, tusenvis av pakker, et enormt fellesskap.
Begrensninger
- Læringskurven for App Router og Server Components er bratt.
- Hyppige endringer mellom hovedversjoner — krever vedlikehold.
- For et enkelt statisk nettsted kan Next.js være overkill sammenlignet med ren HTML.
- Store bygg øker kompileringstiden og CI-kostnadene.
Kort vurdering
Velg React & Next.js for nettsteder og webapplikasjoner som må være raske, indekserbare og skalerbare. For en enkelt statisk landingsside uten interaktivitet er en enklere løsning nok.
Spesifikasjonstabell
| Egenskap | Grense / terskel | Typisk bruk | |
|---|---|---|---|
| Rendering | SSR, SSG, ISR, CSR | Server Components begrenser nettleser-API-ene | Statisk markedsføring + dynamisk dashbord |
| Ytelse | Core Web Vitals (LCP, CLS, INP) måles, Lighthouse CI i pipelinen | JS-hydrering øker med interaktiviteten | Nettsteder med mye trafikk og kritisk SEO |
| Skalering | Titusenvis av brukere, edge-CDN | Krever Node-hosting eller serverless | SaaS, portaler, nettbutikker |
| Typisk kostnad | Åpen kildekode, hosting fra ~0€ | Serverless-funksjoner belastes etter bruk | Fra små prosjekter til enterprise |
Next.js mot alternativer
| Kriterium | Next.js | Nuxt / Astro / Vite |
|---|---|---|
| SSR + SSG i ett rammeverk | Ja, innebygd | Delvis (Nuxt ja, Vite nei) |
| React-økosystem | Fullt | Vue (Nuxt) eller flere rammeverk (Astro) |
| Optimalt for rent statisk nettsted | Bra | Astro er lettere |
Ofte stilte spørsmål
Hvorfor Next.js og ikke bare React (Vite)?
React med Vite rendrer bare hos klienten, så den første HTML-en er tom — dårlig for SEO og GEO. Next.js legger til SSR og SSG og leverer komplett HTML som Google og AI-søkemotorer kan lese uten å kjøre JavaScript.
Er Next.js bra for SEO?
Ja. SSR/SSG leverer indekserbar HTML, metadata og JSON-LD genereres på serveren, og bilder og fonter optimaliseres med next/image og next/font — tekniske forutsetninger for god indeksering.
Kan jeg migrere et eksisterende nettsted til Next.js?
Ja, trinnvis: sidene flyttes én etter én, og URL-ene og 301-omdirigeringene beholdes slik at du ikke mister plasseringer i Google.
Hva slags hosting trenger Next.js?
Statiske sider fungerer på hvilken som helst CDN. Dynamiske funksjoner (SSR, API routes) trenger Node.js eller en serverless-runtime som Vercel, Netlify eller en Docker-container.