Vejledning1. juni 2026 | FlexyConsent

Cookie-samtykke til Next.js, Gatsby og statiske sider: En udviklervejledning til integration

Samtykkeproblemet med statiske sider

Moderne JavaScript-frameworks som Next.js, Gatsby og Nuxt.js introducerede et paradigmeskift i måden, websider bygges og leveres på. Sider pre-renderes ved build-tid eller på serveren og hydreres derefter på klienten. Dette skaber en unik udfordring for cookie-samtykke: samtykkebanneret skal være klar, før nogen sporingsscripts kører, men selve siden kan allerede være renderet og cachet på kanten.

Traditionelle CMP'er var designet til serverrenderede PHP- eller simple HTML-sider, hvor dokumentet indlæses lineært fra top til bund. I en framework-verden med kodeopdeling, doven indlæsning og streamende serverside-rendering bryder disse antagelser sammen. At få samtykke rigtigt i disse miljøer kræver forståelse af rendering-pipelinen.

Hvorfor timing betyder mere, end du tror

På en standard HTML-side er det ligetil at placere et CMP-script i <head> før andre scripts. I Next.js App Router eller Gatsby er situationen mere kompleks:

Pre-renderet HTML ankommer først: Browseren modtager komplet HTML fra CDN'et eller serveren. Hvis der er indlejret inline scripts eller tredjepartstags i den HTML, kan de køre, før din samtykkelogik indlæses.
Hydreringsgab: React-hydrering sker efter, at HTML'en er malet. Hvis din samtykkekomponent er en React-komponent, eksisterer den ikke i en funktionel tilstand, før hydrering er fuldført. Under dette gab kan Google-tags eller analysescripts udløses uden samtykke.
Edge-caching-komplikationer: Hvis du bruger ISR (Incremental Static Regeneration) eller edge-funktioner, er HTML'en cachet. Du kan ikke dynamisk injicere samtykkeafhængig logik i cachet HTML uden en klientside-mekanisme.

Det grundlæggende princip er dette: samtykke skal etableres på script-niveau, ikke på komponentniveau. En React-komponent, der renderer et samtykkebanner, er for sent, hvis den kun bliver interaktiv efter hydrering.

Next.js App Router-integration

Next.js 13+ med App Router introducerede en ny måde at håndtere scripts på. Her er den anbefalede tilgang til samtykkeintegration:

Trin 1: Indlæs CMP-scriptet i rod-layoutet

Brug Next.js' Script-komponent med beforeInteractive-strategien i dit rod-layout.tsx. Dette fortæller Next.js at injicere scriptet i det indledende HTML-dokument, før hydrering begynder:

beforeInteractive-strategien er afgørende. Standard afterInteractive-strategien indlæser scripts efter hydrering, hvilket er for sent til samtykke. Med beforeInteractive inkluderes CMP-scriptet i den serverrenderede HTML og kører, mens siden indlæses.

Trin 2: Sæt standardsamtykke før Google-tags

Før dit Google Tag Manager- eller gtag.js-snippet skal du inkludere et inline script, der sætter standardsamtykkestatus. Dette sikrer, at selvom GTM indlæses, før CMP-banneret vises, respekterer det de afviste standardindstillinger:

Dette inline script skal placeres i <head> i dit rod-layout, før CMP- og GTM-scripts. I Next.js kan du bruge et regulært <script>-tag inde i <head>-elementet i dit layout til dette formål.

Trin 3: Håndter ruteændringer

I single-page application-navigation indlæses CMP-scriptet én gang, men ruteændringer udløser ikke en fuld sidegenindlæsning. Din CMP skal bestå på tværs af klientside-navigationer. FlexyConsent håndterer dette automatisk — når det er indlæst, forbliver det aktivt på tværs af alle ruteændringer uden geninitialisering.

Next.js Pages Router-integration

For projekter, der stadig bruger Pages Router, er tilgangen lignende, men bruger _document.tsx i stedet for rod-layoutet. Placer CMP-scriptet i <Head>-komponenten i din brugerdefinerede Document-klasse. beforeInteractive-strategien fungerer på samme måde i Pages Router.

Den vigtigste forskel er, at _document.tsx kun renderes på serveren, så al samtykkelogik her er garanteret at være i den indledende HTML-payload.

Gatsby statisk side-integration

Gatsby genererer fuldt statisk HTML ved build-tid. Der er ingen serverside-rendering ved forespørgselstid, hvilket forenkler nogle aspekter, men komplicerer andre:

Brug gatsby-ssr.tsx til at injicere CMP-scriptet i <head> på hver side. onRenderBody-API'en lader dig tilføje scripts til hovedet, der vil være til stede i enhver statisk HTML-fil.
Undgå Gatsby-plugins, der dovnt indlæser samtykke: Nogle community-plugins wrapper samtykke i React-komponenter, der først monteres efter hydrering. Dette skaber det tidsgab, der blev diskuteret tidligere.
Placer samtykke-standardindstillinger inline: Brug setHeadComponents i gatsby-ssr.tsx til at tilføje et inline script, der sætter standardsamtykkestatus. Dette script vil være i den statiske HTML og køre øjeblikkeligt.

Gatsbys build-tid-tilgang betyder, at enhver HTML-fil på dit CDN vil inkludere samtykkescriptet. Dette er faktisk ideelt — der er ingen serverlogik, der kan fejle eller caches forkert.

Nuxt.js-overvejelser

Nuxt.js (Vue-baseret) har sine egne mønstre. I Nuxt 3 skal du bruge useHead-composable eller app head-konfigurationen i nuxt.config.ts til at tilføje CMP-scriptet globalt. Nuxt understøtter en body: false-indstilling (som placerer scripts i hovedet) og et async-attribut til ikke-blokerende indlæsning.

For Nuxt's serverside-rendering-tilstand gælder det samme princip: CMP-scriptet skal være i det indledende HTML-svar, ikke dynamisk injiceret af en Vue-komponent efter montering.

Undgå layoutforskydning

Samtykkebannere er berygtede for at forårsage Kumulativ Layoutforskydning (CLS), en Core Web Vital, der påvirker SEO-placeringer. Når et banner dukker op efter, at siden er renderet, skubber det indhold ned eller overlejrer det uventet.

Strategier til at minimere CLS fra samtykkebannere:

Brug et bundplaceret banner: Bannere i bunden af viewporten forskyder ikke sideindhold. Dette er den mest CLS-venlige tilgang.
Reserver plads: Hvis du skal bruge et topbanner, skal du reservere den vertikale plads i din CSS, så sidelayoutet tager højde for banneret, før det renderes.
Undgå modale overlays ved indlæsning: Fuldskærms samtykkevægge, der vises, efter at siden er renderet, forårsager opfattet layoutustabilitet. Hvis du har brug for en væg, render den som en del af den indledende sidetilstand.
Indlæs CMP'en synkront i hovedet: Når CMP'en indlæses som et render-blokerende script i hovedet, kan banneret vises som en del af den indledende maling i stedet for at dukke op senere.

FlexyConsents framework-agnostiske tilgang

FlexyConsent blev designet til at fungere med ethvert framework — eller slet intet framework — ved at operere på script-niveau i stedet for komponentniveau. Her er grunden til, at det betyder noget:

Enkelt asynkront script-tag: Ét <script>-tag i <head> er alt, der skal til. Ingen npm-pakker at installere, ingen framework-specifikke wrappers, ingen build-konfiguration.
Samtykke-standardindstillinger udløses øjeblikkeligt: Scriptet sætter Consent Mode V2-standardindstillinger som sin første handling, før nogen callback eller DOM-manipulation. Det betyder, at Google-tags respekterer samtykke fra den allerførste millisekund.
Ingen DOM-afhængighed: Samtykkelogikken venter ikke på, at React, Vue eller Svelte hydrerer. Den opererer uafhængigt af framework-livscyklussen.
Fungerer med SSG, SSR, ISR og CSR: Fordi det er et simpelt script, fungerer det identisk, uanset om siden blev statisk genereret, serverrenderet, inkrementelt regenereret eller klientside-renderet.

Udviklertip: Den simpleste test for korrekt CMP-integration er at åbne din browsers Netværk-fane, filtrere efter Google-domæner og genindlæse siden. Ingen Google-forespørgsler bør udløses, før standardsamtykkekommandoen vises i konsollen. Hvis de gør, indlæses din CMP for sent.

FlexyConsents gratis plan understøtter ubegrænsede sidevisninger og fungerer med Next.js, Gatsby, Nuxt, Astro, SvelteKit, Remix og ren HTML. Integrationen er den samme på tværs af dem alle: ét script-tag, korrekt placeret.