Ръководство1 юни 2026 | FlexyConsent

Съгласие за бисквитки за Next.js, Gatsby и статични сайтове: Ръководство за интеграция за разработчици

Проблемът със съгласието при статичните сайтове

Модерните JavaScript фреймуърки като Next.js, Gatsby и Nuxt.js въведоха промяна на парадигмата в начина, по който се изграждат и доставят уеб страници. Страниците се пре-рендерират по време на билд или на сървъра, след което се хидратират от страна на клиента. Това създава уникално предизвикателство за съгласието за бисквитки: банерът за съгласие трябва да е готов преди изпълнението на каквито и да е проследяващи скриптове, но самата страница може вече да е рендерирана и кеширана на ръба.

Традиционните CMP платформи бяха проектирани за сървърно рендерирани PHP или прости HTML страници, където документът се зарежда линейно отгоре надолу. В свят на фреймуърки с разделяне на код, мързеливо зареждане и стрийминг сървърно рендериране, тези предположения се разпадат. Правилното управление на съгласието в тези среди изисква разбиране на конвейера за рендериране.

Защо времето е по-важно, отколкото мислите

В стандартна HTML страница поставянето на CMP скрипт в <head> преди другите скриптове е просто. В Next.js App Router или Gatsby ситуацията е по-сложна:

Основният принцип е следният: съгласието трябва да се установява на ниво скрипт, а не на ниво компонент. React компонент, който рендерира банер за съгласие, е твърде късно, ако става интерактивен едва след хидратацията.

Интеграция с Next.js App Router

Next.js 13+ с App Router въведе нов начин за работа със скриптове. Ето препоръчителния подход за интеграция на съгласието:

Стъпка 1: Заредете CMP скрипта в основния Layout

Използвайте компонента Script на Next.js със стратегия beforeInteractive във вашия основен layout.tsx. Това казва на Next.js да инжектира скрипта в първоначалния HTML документ, преди да започне хидратацията:

Стратегията beforeInteractive е от решаващо значение. Стратегията по подразбиране afterInteractive зарежда скриптове след хидратацията, което е твърде късно за съгласието. С beforeInteractive CMP скриптът се включва в сървърно рендерирания HTML и се изпълнява при зареждане на страницата.

Стъпка 2: Задайте съгласие по подразбиране преди Google таговете

Преди вашия Google Tag Manager или gtag.js фрагмент, включете инлайн скрипт, който задава състояния на съгласие по подразбиране. Това гарантира, че дори ако GTM се зареди преди появата на CMP банера, той спазва отказаните настройки по подразбиране:

Този инлайн скрипт трябва да се постави в <head> на основния ви layout, преди CMP и GTM скриптовете. В Next.js можете да използвате обикновен <script> таг вътре в елемента <head> на вашия layout за тази цел.

Стъпка 3: Обработка на промени в маршрута

При навигация в приложение с една страница CMP скриптът се зарежда веднъж, но промените в маршрута не предизвикват пълно презареждане на страницата. Вашият CMP трябва да продължи да работи при клиентска навигация. FlexyConsent обработва това автоматично — веднъж зареден, остава активен при всички промени на маршрута без повторна инициализация.

Интеграция с Next.js Pages Router

За проекти, които все още използват Pages Router, подходът е подобен, но използва _document.tsx вместо основния layout. Поставете CMP скрипта в компонента <Head> на вашия потребителски Document клас. Стратегията beforeInteractive работи по същия начин в Pages Router.

Основната разлика е, че _document.tsx се рендерира само на сървъра, така че всяка логика за съгласие тук е гарантирано в първоначалния HTML payload.

Интеграция на статичен сайт с Gatsby

Gatsby генерира напълно статичен HTML по време на билд. Няма сървърно рендериране по време на заявка, което опростява някои аспекти, но усложнява други:

Подходът на Gatsby по време на билд означава, че всеки HTML файл на вашия CDN ще включва скрипта за съгласие. Това всъщност е идеално — няма сървърна логика, която да се провали или да бъде кеширана некоректно.

Съображения за Nuxt.js

Nuxt.js (базиран на Vue) има свои собствени модели. В Nuxt 3 използвайте composable-а useHead или конфигурацията на главата на приложението в nuxt.config.ts, за да добавите CMP скрипта глобално. Nuxt поддържа опция body: false (която поставя скриптовете в главата) и атрибут async за неблокиращо зареждане.

За режима на сървърно рендериране на Nuxt важи същият принцип: CMP скриптът трябва да бъде в първоначалния HTML отговор, а не динамично инжектиран от Vue компонент след монтирането.

Избягване на изместване на оформлението

Банерите за съгласие са известни с причиняването на Кумулативно изместване на оформлението (CLS) — Core Web Vital метрика, която влияе на SEO класирането. Когато банер се появи след рендериране на страницата, той избутва съдържанието надолу или го припокрива неочаквано.

Стратегии за минимизиране на CLS от банери за съгласие:

Подходът на FlexyConsent, независим от фреймуърка

FlexyConsent е проектиран да работи с всеки фреймуърк — или изобщо без фреймуърк — като работи на ниво скрипт, а не на ниво компонент. Ето защо това е важно:

Съвет за разработчици: Най-простият тест за правилна CMP интеграция е да отворите панела Network на браузъра, да филтрирате по Google домейни и да презаредите страницата. Никакви Google заявки не трябва да се задействат преди появата на командата за съгласие по подразбиране в конзолата. Ако се задействат, вашият CMP се зарежда твърде късно.

Безплатният план на FlexyConsent поддържа неограничен брой показвания на страници и работи с Next.js, Gatsby, Nuxt, Astro, SvelteKit, Remix и обикновен HTML. Интеграцията е еднаква за всички тях: един скрипт таг, правилно поставен.

← Блaderegistrdelays delays Прочети всичко →