Consentiment de galetes per a Next.js, Gatsby i llocs estàtics: Guia d'integració per a desenvolupadors
El problema del consentiment als llocs estàtics
Els frameworks JavaScript moderns com Next.js, Gatsby i Nuxt.js van introduir un canvi de paradigma en la manera com es construeixen i es lliuren les pàgines web. Les pàgines es pre-renderitzen en temps de compilació o al servidor, i després s'hidraten al client. Això crea un repte únic per al consentiment de galetes: el bàner de consentiment ha d'estar preparat abans que s'executin els scripts de seguiment, però la pàgina en si pot ja estar renderitzada i emmagatzemada en memòria cau a la vora.
Les CMP tradicionals estaven dissenyades per a pàgines PHP renderitzades al servidor o pàgines HTML simples on el document es carrega linealment de dalt a baix. En un món de frameworks amb divisió de codi, càrrega mandrosa i renderització al servidor en temps real, aquestes suposicions es trenquen. Obtenir el consentiment correcte en aquests entorns requereix comprendre el pipeline de renderització.
Per què el temps importa més del que penseu
En una pàgina HTML estàndard, col·locar un script CMP al <head> abans d'altres scripts és senzill. A Next.js App Router o Gatsby, la situació és més complexa:
- L'HTML pre-renderitzat arriba primer: El navegador rep HTML complet del CDN o del servidor. Si hi ha scripts en línia o etiquetes de tercers incrustades en aquell HTML, poden executar-se abans que es carregui la lògica de consentiment.
- Bretxa d'hidratació: La hidratació de React passa després que l'HTML es pinti. Si el component de consentiment és un component React, no existeix en estat funcional fins que la hidratació es completa. Durant aquesta bretxa, les etiquetes de Google o els scripts d'analítica podrien disparar-se sense consentiment.
- Complicacions de la memòria cau a la vora: Si feu servir ISR (Regeneració Estàtica Incremental) o funcions de vora, l'HTML està emmagatzemat en memòria cau. No podeu injectar dinàmicament lògica dependent del consentiment en HTML emmagatzemat en memòria cau sense un mecanisme del costat del client.
El principi fonamental és aquest: el consentiment s'ha d'establir a nivell de script, no a nivell de component. Un component React que renderitza un bàner de consentiment és massa tard si només es torna interactiu després de la hidratació.
Integració amb Next.js App Router
Next.js 13+ amb l'App Router va introduir una nova manera de gestionar scripts. Aquí teniu l'enfocament recomanat per a la integració del consentiment:
Pas 1: Carregar l'script CMP al Layout arrel
Feu servir el component Script de Next.js amb l'estratègia beforeInteractive al vostre layout.tsx arrel. Això indica a Next.js que injecti l'script al document HTML inicial, abans que comenci la hidratació:
L'estratègia beforeInteractive és crítica. L'estratègia per defecte afterInteractive carrega els scripts després de la hidratació, cosa que és massa tard per al consentiment. Amb beforeInteractive, l'script CMP s'inclou a l'HTML renderitzat al servidor i s'executa mentre la pàgina es carrega.
Pas 2: Establir el consentiment per defecte abans de les etiquetes de Google
Abans del vostre fragment de Google Tag Manager o gtag.js, incloeu un script en línia que estableixi els estats de consentiment per defecte. Això assegura que, fins i tot si GTM es carrega abans que aparegui el bàner CMP, respecti els valors per defecte denegats:
Aquest script en línia s'ha de col·locar al <head> del vostre layout arrel, abans dels scripts CMP i GTM. A Next.js, podeu fer servir una etiqueta <script> regular dins de l'element <head> del vostre layout per a aquest propòsit.
Pas 3: Gestionar els canvis de ruta
En la navegació d'aplicacions d'una sola pàgina, l'script CMP es carrega una vegada, però els canvis de ruta no desencadenen una recàrrega completa de la pàgina. La vostra CMP ha de persistir a través de les navegacions del costat del client. FlexyConsent ho gestiona automàticament — un cop carregat, roman actiu a través de tots els canvis de ruta sense reinicialització.
Integració amb Next.js Pages Router
Per a projectes que encara fan servir el Pages Router, l'enfocament és similar però utilitza _document.tsx en lloc del layout arrel. Col·loqueu l'script CMP al component <Head> de la vostra classe Document personalitzada. L'estratègia beforeInteractive funciona de la mateixa manera al Pages Router.
La diferència clau és que _document.tsx només es renderitza al servidor, de manera que qualsevol lògica de consentiment aquí està garantida que estarà a la càrrega útil HTML inicial.
Integració de lloc estàtic amb Gatsby
Gatsby genera HTML completament estàtic en temps de compilació. No hi ha renderització al servidor en temps de sol·licitud, cosa que simplifica alguns aspectes però complica d'altres:
- Feu servir
gatsby-ssr.tsxper injectar l'script CMP al<head>de cada pàgina. L'APIonRenderBodyus permet afegir scripts a la capçalera que estaran presents a cada fitxer HTML estàtic. - Eviteu els plugins de Gatsby que carreguen el consentiment de manera mandrosa: Alguns plugins de la comunitat embolcallen el consentiment en components React que només es munten després de la hidratació. Això crea la bretxa de temps discutida anteriorment.
- Col·loqueu els valors per defecte del consentiment en línia: Feu servir
setHeadComponentsagatsby-ssr.tsxper afegir un script en línia que estableixi els estats de consentiment per defecte. Aquest script estarà a l'HTML estàtic i s'executarà immediatament.
L'enfocament de temps de compilació de Gatsby significa que cada fitxer HTML al vostre CDN inclourà l'script de consentiment. Això és realment ideal — no hi ha lògica de servidor que pugui fallar o emmagatzemar-se en memòria cau incorrectament.
Consideracions per a Nuxt.js
Nuxt.js (basat en Vue) té els seus propis patrons. A Nuxt 3, feu servir el composable useHead o la configuració de capçalera de l'aplicació a nuxt.config.ts per afegir l'script CMP globalment. Nuxt admet l'opció body: false (que col·loca els scripts a la capçalera) i l'atribut async per a la càrrega no bloquejant.
Per al mode de renderització al servidor de Nuxt, s'aplica el mateix principi: l'script CMP ha d'estar a la resposta HTML inicial, no injectat dinàmicament per un component Vue després del muntatge.
Evitar el desplaçament del disseny
Els bàners de consentiment són famosos per causar Desplaçament Acumulatiu del Disseny (CLS), un Core Web Vital que afecta les classificacions SEO. Quan un bàner apareix després que la pàgina es renderitza, empeny el contingut cap avall o el superposa inesperadament.
Estratègies per minimitzar el CLS dels bàners de consentiment:
- Feu servir un bàner posicionat a la part inferior: Els bàners a la part inferior de la finestra gràfica no desplacen el contingut de la pàgina. Aquest és l'enfocament més favorable per al CLS.
- Reserveu espai: Si heu de fer servir un bàner superior, reserveu l'espai vertical al vostre CSS perquè el disseny de la pàgina tingui en compte el bàner abans de renderitzar-lo.
- Eviteu les superposicions modals en carregar: Les parets de consentiment a pantalla completa que apareixen després que la pàgina es renderitza causen inestabilitat de disseny percebuda. Si necessiteu una paret, renderitzeu-la com a part de l'estat inicial de la pàgina.
- Carregueu la CMP de manera sincrònica a la capçalera: Quan la CMP es carrega com un script que bloqueja la renderització a la capçalera, el bàner pot aparèixer com a part del pintat inicial en lloc d'aparèixer més tard.
L'enfocament agnòstic de framework de FlexyConsent
FlexyConsent va ser dissenyat per funcionar amb qualsevol framework — o sense cap framework — operant a nivell de script en lloc de nivell de component. Aquí teniu per què això importa:
- Una sola etiqueta de script asíncrona: Una etiqueta
<script>al<head>és tot el que es necessita. No hi ha paquets npm per instal·lar, no hi ha embolcalls específics del framework, no hi ha configuració de compilació. - Els valors per defecte del consentiment es disparen immediatament: L'script estableix els valors per defecte de Consent Mode V2 com a primera acció, abans de qualsevol callback o manipulació del DOM. Això significa que les etiquetes de Google respecten el consentiment des del primer mil·lisegon.
- Sense dependència del DOM: La lògica de consentiment no espera que React, Vue o Svelte s'hidratin. Opera independentment del cicle de vida del framework.
- Funciona amb SSG, SSR, ISR i CSR: Com que és un script senzill, funciona de manera idèntica tant si la pàgina es va generar estàticament, es va renderitzar al servidor, es va regenerar incrementalment o es va renderitzar al client.
Consell per a desenvolupadors: La prova més senzilla per a una integració CMP correcta és obrir la pestanya Network del navegador, filtrar per dominis de Google i recarregar la pàgina. Cap sol·licitud de Google hauria de disparar-se abans que l'ordre de consentiment per defecte aparegui a la consola. Si ho fan, la vostra CMP s'està carregant massa tard.
El pla gratuït de FlexyConsent admet visualitzacions de pàgina il·limitades i funciona amb Next.js, Gatsby, Nuxt, Astro, SvelteKit, Remix i HTML senzill. La integració és la mateixa a tots ells: una etiqueta de script, correctament col·locada.