Next.js-utvikler

Hva vi leverer

Next.js 15 med App Router og React 19 Server Components i frontenden. WordPress 6.7+ som redaksjonell backend, som kommuniserer over REST eller GraphQL. Cloudflare Workers og Pages som runtime og edge-cache. TypeScript gjennom hele stacken. Tailwind CSS som designsystem. Anthropic Claude og Model Context Protocol når AI-funksjoner faktisk lønner seg.

Dette er ikke en teknologiliste fra en stillingsannonse, men en stack vi vedlikeholder i egen produksjon. Hvert element har en begrunnelse: App Router gir rendering per rute, RSC kutter JavaScript som sendes til klienten, Workers fjerner kaldstarter og holder dataene innenfor rekkevidden av europeisk regelverk. Når et element slutter å forsvare plassen sin i praksis, ryker det ut av stacken, noe vi dokumenterer kvartalsvis i Tech Radar.

Når Next.js er riktig valg

Personaliserte sider, sesjonsdrevne flyter, A/B-testede opplevelser, transaksjonell checkout, sanntidsdashbord og autentiserte arbeidsområder drar alle nytte av streaming SSR- og RSC-modellen. Tankemodellen er: "rendre tett på dataene, strøm det som er klart, hydrer det som er interaktivt". For sider som passer, leverer Next.js et UX som klassisk SSR eller statisk ikke kan matche.

For sider som ikke passer, sier vi det rett ut. Innholdstunge markedssider, blogger og dokumentasjon vinner som regel på Astro med statisk + ISR til lavere kostnad. Rammeverkvalget er en del av scoping, ikke en standardinnstilling. Viser discovery at nettstedet ditt ikke trenger Next.js, får du høre det, sammen med en rimeligere anbefaling.

Arkitektur: WordPress som backend, Next.js som frontend

I et headless-oppsett slutter WordPress å rendre sider og blir det systemet faktisk er godt på: redaksjonelt arbeid. Innholdsteamet jobber i det kjente panelet, med de samme rollene, arbeidsflytene og redaksjonelle utvidelsene. Next.js henter innholdet over REST eller WPGraphQL og rendrer det etter en strategi valgt per rute: forsiden og landingssider som statiske med revalidering, produktkatalogen som ISR med webhook-drevet invalidering, checkout og kundepanel som SSR med full sesjon.

Tre elementer avgjør om en slik arkitektur fungerer i praksis, og alle tre er en del av leveransen. Redaksjonell forhåndsvisning: redaktøren må kunne se utkastet før publisering, så vi setter opp draft mode koblet til WordPress i stedet for å forklare teamet at "sånn går det ikke lenger". Cache-invalidering: en publisering i WordPress sender en webhook som revaliderer nøyaktig de rutene endringen gjelder, i stedet for å tømme hele cachen. Mediehåndtering: bilder går gjennom Next.js-pipelinen med automatisk AVIF og responsive størrelser, uansett hva redaktøren lastet opp.

Ytelse og Core Web Vitals

Ytelse i Next.js kommer ikke fra rammeverket, men fra arkitekturbeslutningene rammeverket gjør mulige. Streaming SSR sender første byte før serveren er ferdig med å rendre helheten, noe som direkte senker TTFB og LCP. Server Components holder datahentingslogikken på serveren, så klienten får mindre JavaScript, og INP slutter å lide av at alt hydreres på en gang. Cache på Cloudflare-edge svarer brukeren fra nærmeste punkt i nettverket i stedet for fra én origin-server.

Hvert prosjekt starter med en baseline: TTFB, LCP, INP og CLS målt på reelle brukere før endringen, ikke i laboratoriet. Etter lansering samles de samme metrikkene inn via RUM og sammenlignes i en side-ved-side måleperiode. Prosjektets resultat er differansen i feltdata, ikke et skjermbilde fra Lighthouse. Den offentlige måleprotokollen for Astro mot Next.js på WooCommerce, med åpen metodikk, finner du i referanseseksjonen nederst på siden.

Headless WooCommerce på Next.js

En nettbutikk er den mest krevende headless-varianten, fordi den kombinerer statisk innhold med transaksjoner i sanntid. Produktsider og kategorier rendres som ISR: raske som statisk, oppdatert via webhook når pris eller lagerstatus endres. Handlekurv, checkout og kundekonto kjører som SSR med sesjon, koblet til WooCommerce Store API. Priser per kunde, B2B-rabattrinn og kataloger bak innlogging, typiske krav fra grossister, tvinger ikke lenger hele butikken til å gi opp cache, fordi rendering-beslutningen tas på rutenivå.

I tillegg kommer et lag stadig flere butikker spør om: beredskap for KI-drevne handleagenter. Ren, serverrendret HTML med korrekt Product- og Offer-schema er inngangsbilletten for at en agent i det hele tatt skal se katalogen. Det er den samme arkitekturen som serverer raske sider til mennesker, så du betaler ikke for den to ganger.

SEO, GEO og AEO i Next.js

Serverrendring er fundamentet for synlighet som klientside-React aldri kan gi: KI-crawlere som GPTBot, ClaudeBot og PerplexityBot kjører ikke JavaScript, og Googlebot kjører det med forsinkelse og budsjett. Next.js med SSR og RSC leverer alt innholdet i det første HTML-svaret, så det brukeren ser, ser også boten.

På det fundamentet bygger vi det tekniske laget: metadata-API per rute, canonical og hreflang via metadata.alternates, sitemap via generateSitemaps, strukturerte data som JSON-LD tilpasset sidetypen (Product, Article, FAQPage, HowTo), Open Graph med bilder generert per side. For synlighet i generative søkemotorer legger vi til GEO-elementer: seksjoner med direkte svar, FAQ med strukturerte data, llms.txt og innholdsforhandling for agenter. Hvert prosjekt går gjennom en 30-punkts SEO-sjekkliste før DNS-overgangen.

Sikkerhet og EU-jurisdiksjon

Headless reduserer angrepsflaten på en måte som kan forklares for ledelsen i én setning: WordPress forsvinner fra det åpne internettet. Innloggingspanelet, XML-RPC og utvidelsesfiler slutter å være tilgjengelige for skannere, fordi frontenden serveres av Next.js og origin bare er tilgjengelig for den. I tillegg kommer sikkerhetsheadere konfigurert sentralt, validering av inndata på serversiden og hemmeligheter holdt utenfor repositoriet.

For virksomheter underlagt GDPR, NIS2 eller DORA teller også datageografien: runtime på Cloudflare med prosessering i EU, databehandleravtaler på engelsk eller polsk, dokumentasjon av dataflyter til protokollen over behandlingsaktiviteter. En B2B-kontrakt i europeisk jurisdiksjon, ikke vilkårene til en plattform utenfor den.

Hvem dette er for

• WooCommerce-butikker med tilpasset checkout eller pris per bruker
• SaaS-dashbord og autentiserte arbeidsområder med WordPress som innholdslag
• Multiregionale merker som trenger ISR med webhook-drevet invalidering
• Redaksjonelle utgivere med live datastrømmer, kommentarer eller sanntidsanalyseflater
• B2B-grossister med kataloger bak innlogging og prislister forhandlet per kunde

Samarbeidsmodell

Senior B2B-kontrakter i EU-jurisdiksjon. Fire faser: discovery med innholdsrevisjon og ytelsesbaseline, scoping med rendering-beslutninger per rute, iterativ bygging med ukentlige demoer og en side-ved-side måleperiode, og til slutt tuning og oppfølging med observability og kvartalsvise stack-gjennomganger. Fast omfang eller time-and-materials. Pris er individuell, tidsplan per fase med beslutningspunkter.