Sīkdatņu piekrišana Next.js, Gatsby un statiskajās vietnēs: izstrādātāja integrācijas ceļvedis
Statisko vietņu piekrišanas problēma
Mūsdienīgi JavaScript ietvari, piemēram, Next.js, Gatsby un Nuxt.js, ir ieviesuši paradigmas maiņu tajā, kā tīmekļa lapas tiek veidotas un piegādātas. Lapas tiek iepriekš renderētas būvēšanas laikā vai serverī, pēc tam klienta pusē tiek veiktas hidratācija. Tas rada unikālu izaicinājumu sīkdatņu piekrišanai: piekrišanas joslai ir jābūt gatavai pirms tiek izpildīti jebkādi izsekošanas skripti, taču pati lapa jau var būt renderēta un kešota uz malas serveriem.
Tradicionālie CMP tika izstrādāti servera renderētām PHP vai vienkāršām HTML lapām, kur dokuments ielādējas lineāri no augšas uz leju. Ietvaru pasaulē ar koda sadalīšanu, slinko ielādi un straumējošu servera puses renderēšanu šie pieņēmumi vairs nestrādā. Lai šādā vidē pareizi ieviestu piekrišanu, ir jāsaprot renderēšanas cauruļvads.
Kāpēc laika moments ir svarīgāks, nekā šķiet
Standarta HTML lapā CMP skripta ievietošana <head> pirms citiem skriptiem ir vienkārša. Next.js App Router vai Gatsby gadījumā situācija ir sarežģītāka:
- Vispirms pienāk iepriekš renderētais HTML: Pārlūks saņem pilnu HTML no CDN vai servera. Ja šajā HTML ir iekļauti inline skripti vai trešo pušu tagi, tie var izpildīties pirms tiek ielādēta jūsu piekrišanas loģika.
- Hidratācijas plaisa: React hidratācija notiek pēc tam, kad HTML ir uzzīmēts. Ja jūsu piekrišanas komponents ir React komponents, tas funkcionālā stāvoklī neeksistē, kamēr hidratācija nav pabeigta. Šīs plaisas laikā Google tagi vai analītikas skripti var palaisties bez piekrišanas.
- Malu kešošanas sarežģījumi: Ja izmantojat ISR (Incremental Static Regeneration) vai edge funkcijas, HTML tiek kešots. Jūs nevarat dinamiski injicēt no piekrišanas atkarīgu loģiku kešotā HTML bez klienta puses mehānisma.
Pamatprincips ir šāds: piekrišana ir jānosaka skripta līmenī, nevis komponentes līmenī. React komponents, kas renderē piekrišanas joslu, ir par vēlu, ja tas kļūst interaktīvs tikai pēc hidratācijas.
Next.js App Router integrācija
Next.js 13+ ar App Router ieviesa jaunu veidu, kā apstrādāt skriptus. Šeit ir ieteicamā pieeja piekrišanas integrācijai:
1. solis: ielādējiet CMP skriptu saknes izkārtojumā
Izmantojiet Next.js Script komponenti ar beforeInteractive stratēģiju jūsu saknes layout.tsx. Tas norāda Next.js injicēt skriptu sākotnējā HTML dokumentā pirms hidratācijas sākuma:
beforeInteractive stratēģija ir kritiski svarīga. Noklusējuma afterInteractive stratēģija ielādē skriptus pēc hidratācijas, kas piekrišanai ir par vēlu. Ar beforeInteractive CMP skripts tiek iekļauts servera renderētajā HTML un izpildās lapas ielādes laikā.
2. solis: iestatiet noklusējuma piekrišanu pirms Google tagiem
Pirms jūsu Google Tag Manager vai gtag.js fragmenta iekļaujiet inline skriptu, kas iestata noklusējuma piekrišanas stāvokļus. Tas nodrošina, ka pat ja GTM ielādējas pirms parādās CMP josla, tas ievēro noraidītos noklusējumus:
Šim inline skriptam jāatrodas jūsu saknes izkārtojuma <head>, pirms CMP un GTM skriptiem. Next.js gadījumā šim nolūkam varat izmantot parastu <script> tagu <head> elementā.
3. solis: apstrādājiet maršrutu maiņas
Vientekmes lietotnes navigācijā CMP skripts ielādējas vienreiz, bet maršrutu maiņas neizraisa pilnu lapas pārlādi. Jūsu CMP ir jāsaglabājas visās klienta puses navigācijās. FlexyConsent to apstrādā automātiski — tiklīdz tas ir ielādēts, tas paliek aktīvs visās maršrutu maiņās bez atkārtotas inicializācijas.
Next.js Pages Router integrācija
Projektiem, kas joprojām izmanto Pages Router, pieeja ir līdzīga, taču izmanto _document.tsx saknes izkārtojuma vietā. Novietojiet CMP skriptu savas pielāgotās Document klases <Head> komponentē. beforeInteractive stratēģija Pages Router darbojas tāpat.
Galvenā atšķirība ir tā, ka _document.tsx renderējas tikai serverī, tāpēc jebkura piekrišanas loģika šeit noteikti būs sākotnējā HTML atbildē.
Gatsby statisko vietņu integrācija
Gatsby būvēšanas laikā ģenerē pilnībā statisku HTML. Pieprasījuma brīdī nav servera puses renderēšanas, kas dažus aspektus vienkāršo, bet citus sarežģī:
- Izmantojiet
gatsby-ssr.tsx, lai injicētu CMP skriptu katras lapas<head>.onRenderBodyAPI ļauj pievienot skriptus head daļai, kas būs klātesoši katrā statiskajā HTML failā. - Izvairieties no Gatsby spraudņiem, kas slinki ielādē piekrišanu: Daži kopienas spraudņi aptin piekrišanu React komponentēs, kas tiek montētas tikai pēc hidratācijas. Tas rada iepriekš aprakstīto laika plaisu.
- Noklusējuma piekrišanu ievietojiet inline: Izmantojiet
setHeadComponentsfailāgatsby-ssr.tsx, lai pievienotu inline skriptu, kas iestata noklusējuma piekrišanas stāvokļus. Šis skripts būs statiskajā HTML un izpildīsies nekavējoties.
Gatsby būvēšanas laika pieeja nozīmē, ka katrs HTML fails jūsu CDN saturēs piekrišanas skriptu. Patiesībā tas ir ideāli — nav servera loģikas, kas varētu kļūdīties vai tikt nepareizi kešota.
Nuxt.js īpatnības
Nuxt.js (balstīts uz Vue) izmanto savus rakstus. Nuxt 3 gadījumā izmantojiet useHead composable vai nuxt.config.ts lietotnes head konfigurāciju, lai pievienotu CMP skriptu globāli. Nuxt atbalsta body: false opciju (kas novieto skriptus head daļā) un async atribūtu neblokējošai ielādei.
Nuxt servera puses renderēšanas režīmā spēkā ir tas pats princips: CMP skriptam ir jābūt sākotnējā HTML atbildē, nevis dinamiski injicētam ar Vue komponenti pēc montēšanas.
Izvairīšanās no izkārtojuma nobīdes
Piekrišanas joslas ir bēdīgi slavenas ar to, ka izraisa Cumulative Layout Shift (CLS), Core Web Vital rādītāju, kas ietekmē SEO pozīcijas. Kad josla parādās pēc lapas renderēšanas, tā pabīda saturu uz leju vai negaidīti to pārklāj.
Stratēģijas, kā samazināt CLS no piekrišanas joslām:
- Izmantojiet joslu ekrāna apakšā: Joslas skatloga apakšā nebīda lapas saturu. Tā ir visdraudzīgākā pieeja CLS ziņā.
- Rezervējiet vietu: Ja jums jāizmanto josla augšpusē, rezervējiet vertikālo vietu CSS, lai lapas izkārtojums ar to rēķinātos vēl pirms joslas renderēšanas.
- Izvairieties no modālo logu pārklājumiem ielādes brīdī: Pilnekrāna piekrišanas sienas, kas parādās pēc lapas renderēšanas, rada uztveramu izkārtojuma nestabilitāti. Ja jums nepieciešama šāda siena, renderējiet to kā daļu no sākotnējā lapas stāvokļa.
- Ielādējiet CMP sinhroni head daļā: Kad CMP tiek ielādēts kā renderēšanu bloķējošs skripts head daļā, josla var parādīties jau sākotnējā zīmējumā, nevis uzlekt vēlāk.
FlexyConsent ietvaru-neatkarīgā pieeja
FlexyConsent ir izstrādāts tā, lai darbotos ar jebkuru ietvaru — vai bez jebkāda ietvara — darbojoties skripta līmenī, nevis komponentes līmenī. Lūk, kāpēc tas ir svarīgi:
- Viens async skripta tags: Pietiek ar vienu
<script>tagu<head>. Nav jāinstalē npm pakotnes, nav ietvaram specifisku aplokšņu, nav būvēšanas konfigurācijas. - Piekrišanas noklusējumi izpildās nekavējoties: Skripts kā pirmo darbību iestata Consent Mode V2 noklusējumus, pirms jebkādiem atzvaniem vai DOM manipulācijām. Tas nozīmē, ka Google tagi ievēro piekrišanu jau no pirmās milisekundes.
- Nav atkarības no DOM: Piekrišanas loģika negaida React, Vue vai Svelte hidratāciju. Tā darbojas neatkarīgi no ietvara dzīves cikla.
- Darbojas ar SSG, SSR, ISR un CSR: Tā kā tas ir parasts skripts, tas funkcionē identiski neatkarīgi no tā, vai lapa ir statiski ģenerēta, servera puses renderēta, pakāpeniski atjaunota vai renderēta klienta pusē.
Izstrādātāja padoms: Vienkāršākais tests pareizai CMP integrācijai ir atvērt pārlūka Network cilni, filtrēt pēc Google domēniem un pārlādēt lapu. Pirms konsolē parādās piekrišanas noklusējuma komanda, nedrīkst būt neviena Google pieprasījuma. Ja tādi ir, jūsu CMP ielādējas par vēlu.
FlexyConsent bezmaksas plāns atbalsta neierobežotu lapu skatījumu skaitu un darbojas ar Next.js, Gatsby, Nuxt, Astro, SvelteKit, Remix un tīru HTML. Integrācija visur ir vienāda: viens skripta tags, pareizi novietots.