Next.js، Gatsby، اور Static Sites کے لیے کوکی رضامندی: ڈویلپر کی انٹیگریشن گائیڈ
Static Site رضامندی کا مسئلہ
جدید JavaScript فریم ورکس جیسے Next.js، Gatsby، اور Nuxt.js نے ویب صفحات کی تعمیر اور ترسیل کے طریقے میں ایک بنیادی تبدیلی متعارف کرائی۔ صفحات بلڈ ٹائم یا سرور پر پہلے سے رینڈر کیے جاتے ہیں، پھر کلائنٹ پر ہائیڈریٹ کیے جاتے ہیں۔ یہ کوکی رضامندی کے لیے ایک منفرد چیلنج پیدا کرتا ہے: رضامندی بینر کو کسی بھی ٹریکنگ اسکرپٹ کے چلنے سے پہلے تیار ہونا چاہیے، لیکن صفحہ خود پہلے ہی رینڈر اور ایج پر کیش ہو سکتا ہے۔
روایتی CMPs سرور سے رینڈر ہونے والے PHP یا سادہ HTML صفحات کے لیے ڈیزائن کیے گئے تھے جہاں دستاویز اوپر سے نیچے خطی طور پر لوڈ ہوتی ہے۔ کوڈ اسپلٹنگ، لیزی لوڈنگ، اور اسٹریمنگ سرور سائیڈ رینڈرنگ والی فریم ورک دنیا میں، مفروضے ٹوٹ جاتے ہیں۔ ان ماحولیات میں رضامندی کو درست طریقے سے حاصل کرنے کے لیے رینڈرنگ پائپ لائن کو سمجھنا ضروری ہے۔
ٹائمنگ آپ کی سوچ سے زیادہ اہم کیوں ہے
ایک معیاری HTML صفحے میں، CMP اسکرپٹ کو دوسری اسکرپٹس سے پہلے <head> میں رکھنا سیدھا سادہ ہے۔ Next.js App Router یا Gatsby میں، صورتحال زیادہ پیچیدہ ہے:
- پہلے سے رینڈر شدہ HTML پہلے آتا ہے: براؤزر CDN یا سرور سے مکمل HTML وصول کرتا ہے۔ اگر کوئی ان لائن اسکرپٹس یا تھرڈ پارٹی ٹیگز اس HTML میں شامل ہیں، تو وہ آپ کی رضامندی لاجک لوڈ ہونے سے پہلے چل سکتی ہیں۔
- ہائیڈریشن گیپ: React ہائیڈریشن HTML پینٹ ہونے کے بعد ہوتی ہے۔ اگر آپ کا رضامندی کمپوننٹ ایک React کمپوننٹ ہے، تو یہ ہائیڈریشن مکمل ہونے تک فنکشنل حالت میں موجود نہیں ہوتا۔ اس گیپ کے دوران، Google ٹیگز یا اینالیٹکس اسکرپٹس رضامندی کے بغیر فائر ہو سکتی ہیں۔
- ایج کیشنگ کی پیچیدگیاں: اگر آپ ISR (Incremental Static Regeneration) یا ایج فنکشنز استعمال کرتے ہیں، تو HTML کیش ہوتا ہے۔ آپ کلائنٹ سائیڈ میکانزم کے بغیر کیش شدہ HTML میں رضامندی پر منحصر لاجک کو متحرک طور پر شامل نہیں کر سکتے۔
بنیادی اصول یہ ہے: رضامندی اسکرپٹ کی سطح پر قائم ہونی چاہیے، کمپوننٹ کی سطح پر نہیں۔ ایک React کمپوننٹ جو رضامندی بینر رینڈر کرتا ہے اگر یہ صرف ہائیڈریشن کے بعد انٹرایکٹو ہوتا ہے تو بہت دیر ہو چکی ہے۔
Next.js App Router انٹیگریشن
Next.js 13+ App Router کے ساتھ اسکرپٹس کو ہینڈل کرنے کا ایک نیا طریقہ متعارف کرایا گیا۔ رضامندی انٹیگریشن کے لیے تجویز کردہ طریقہ یہ ہے:
مرحلہ 1: روٹ لے آؤٹ میں CMP اسکرپٹ لوڈ کریں
اپنے روٹ layout.tsx میں beforeInteractive حکمت عملی کے ساتھ Next.js Script کمپوننٹ استعمال کریں۔ یہ Next.js کو بتاتا ہے کہ اسکرپٹ کو ابتدائی HTML دستاویز میں شامل کرے، ہائیڈریشن شروع ہونے سے پہلے:
beforeInteractive حکمت عملی اہم ہے۔ ڈیفالٹ afterInteractive حکمت عملی ہائیڈریشن کے بعد اسکرپٹس لوڈ کرتی ہے، جو رضامندی کے لیے بہت دیر ہے۔ beforeInteractive کے ساتھ، CMP اسکرپٹ سرور سے رینڈر شدہ HTML میں شامل ہوتی ہے اور صفحہ لوڈ ہوتے وقت چلتی ہے۔
مرحلہ 2: Google ٹیگز سے پہلے ڈیفالٹ رضامندی سیٹ کریں
اپنے Google Tag Manager یا gtag.js کوڈ سے پہلے، ایک ان لائن اسکرپٹ شامل کریں جو ڈیفالٹ رضامندی حالتیں سیٹ کرے۔ یہ یقینی بناتا ہے کہ اگر GTM CMP بینر ظاہر ہونے سے پہلے لوڈ ہو جائے، تو یہ مسترد شدہ ڈیفالٹس کا احترام کرتا ہے:
یہ ان لائن اسکرپٹ آپ کے روٹ لے آؤٹ کے <head> میں CMP اور GTM اسکرپٹس سے پہلے رکھی جانی چاہیے۔ Next.js میں، آپ اس مقصد کے لیے اپنے لے آؤٹ کے <head> عنصر کے اندر ایک عام <script> ٹیگ استعمال کر سکتے ہیں۔
مرحلہ 3: روٹ تبدیلیوں کو ہینڈل کریں
سنگل پیج ایپلیکیشن نیویگیشن میں، CMP اسکرپٹ ایک بار لوڈ ہوتی ہے لیکن روٹ تبدیلیاں مکمل صفحہ ری لوڈ کو متحرک نہیں کرتیں۔ آپ کا CMP کلائنٹ سائیڈ نیویگیشنز میں برقرار رہنا چاہیے۔ FlexyConsent یہ خودکار طور پر ہینڈل کرتا ہے — ایک بار لوڈ ہونے کے بعد، یہ دوبارہ شروع کیے بغیر تمام روٹ تبدیلیوں میں فعال رہتا ہے۔
Next.js Pages Router انٹیگریشن
Pages Router ابھی بھی استعمال کرنے والے پروجیکٹس کے لیے، طریقہ ملتا جلتا ہے لیکن روٹ لے آؤٹ کی بجائے _document.tsx استعمال کرتا ہے۔ اپنی کسٹم Document کلاس کے <Head> کمپوننٹ میں CMP اسکرپٹ رکھیں۔ beforeInteractive حکمت عملی Pages Router میں بھی اسی طرح کام کرتی ہے۔
اہم فرق یہ ہے کہ _document.tsx صرف سرور پر رینڈر ہوتا ہے، لہذا یہاں کوئی بھی رضامندی لاجک ابتدائی HTML پے لوڈ میں ہونے کی ضمانت ہے۔
Gatsby Static Site انٹیگریشن
Gatsby بلڈ ٹائم پر مکمل طور پر static HTML تیار کرتا ہے۔ درخواست کے وقت کوئی سرور سائیڈ رینڈرنگ نہیں ہوتی، جو کچھ پہلوؤں کو آسان بناتی ہے لیکن دوسروں کو پیچیدہ کرتی ہے:
- ہر صفحے کے
<head>میں CMP اسکرپٹ شامل کرنے کے لیےgatsby-ssr.tsxاستعمال کریں۔onRenderBodyAPI آپ کو ہیڈ میں اسکرپٹس شامل کرنے دیتا ہے جو ہر static HTML فائل میں موجود ہوں گی۔ - رضامندی کو لیزی لوڈ کرنے والے Gatsby پلگ انز سے بچیں: کچھ کمیونٹی پلگ انز رضامندی کو React کمپوننٹس میں لپیٹتے ہیں جو صرف ہائیڈریشن کے بعد ماؤنٹ ہوتے ہیں۔ یہ پہلے بیان کردہ ٹائمنگ گیپ پیدا کرتا ہے۔
- رضامندی ڈیفالٹس ان لائن رکھیں: ڈیفالٹ رضامندی حالتیں سیٹ کرنے والی ان لائن اسکرپٹ شامل کرنے کے لیے
gatsby-ssr.tsxمیںsetHeadComponentsاستعمال کریں۔ یہ اسکرپٹ static HTML میں ہوگی اور فوری طور پر چلے گی۔
Gatsby کا بلڈ ٹائم طریقہ یہ معنی رکھتا ہے کہ آپ کے CDN پر ہر HTML فائل میں رضامندی اسکرپٹ شامل ہوگی۔ یہ دراصل مثالی ہے — کوئی سرور لاجک فیل یا غلط طریقے سے کیش نہیں ہوگی۔
Nuxt.js تحفظات
Nuxt.js (Vue پر مبنی) کے اپنے پیٹرنز ہیں۔ Nuxt 3 میں، CMP اسکرپٹ کو عالمی طور پر شامل کرنے کے لیے useHead composable یا nuxt.config.ts app head کنفیگریشن استعمال کریں۔ Nuxt body: false آپشن (جو اسکرپٹس کو ہیڈ میں رکھتا ہے) اور نان بلاکنگ لوڈنگ کے لیے async ایٹریبیوٹ کی حمایت کرتا ہے۔
Nuxt کے سرور سائیڈ رینڈرنگ موڈ کے لیے، وہی اصول لاگو ہوتا ہے: CMP اسکرپٹ ابتدائی HTML ریسپانس میں ہونی چاہیے، ماؤنٹ کے بعد Vue کمپوننٹ کے ذریعے متحرک طور پر شامل نہیں کی جانی چاہیے۔
لے آؤٹ شفٹ سے بچنا
رضامندی بینرز Cumulative Layout Shift (CLS) کا سبب بننے کے لیے بدنام ہیں، جو ایک Core Web Vital ہے جو SEO رینکنگ کو متاثر کرتا ہے۔ جب صفحہ رینڈر ہونے کے بعد بینر ظاہر ہوتا ہے، تو یہ مواد کو نیچے دھکیلتا ہے یا غیر متوقع طور پر اوورلے کرتا ہے۔
رضامندی بینرز سے CLS کو کم کرنے کی حکمت عملیاں:
- نیچے کی پوزیشن والا بینر استعمال کریں: ویو پورٹ کے نیچے والے بینرز صفحے کے مواد کو شفٹ نہیں کرتے۔ یہ سب سے زیادہ CLS دوستانہ طریقہ ہے۔
- جگہ محفوظ رکھیں: اگر آپ کو اوپر کا بینر استعمال کرنا ہے، تو اپنے CSS میں عمودی جگہ محفوظ رکھیں تاکہ صفحے کا لے آؤٹ بینر رینڈر ہونے سے پہلے اس کا حساب رکھے۔
- لوڈ پر موڈل اوورلیز سے بچیں: صفحہ رینڈر ہونے کے بعد ظاہر ہونے والی فل اسکرین رضامندی والز سمجھی جانے والی لے آؤٹ عدم استحکام کا سبب بنتی ہیں۔ اگر آپ کو وال کی ضرورت ہے، تو اسے ابتدائی صفحے کی حالت کے حصے کے طور پر رینڈر کریں۔
- CMP کو ہیڈ میں ہم وقت ساز طور پر لوڈ کریں: جب CMP کو ہیڈ میں رینڈر بلاکنگ اسکرپٹ کے طور پر لوڈ کیا جاتا ہے، تو بینر بعد میں ظاہر ہونے کی بجائے ابتدائی پینٹ کے حصے کے طور پر ظاہر ہو سکتا ہے۔
FlexyConsent کا فریم ورک سے آزاد طریقہ
FlexyConsent کو کسی بھی فریم ورک — یا بالکل بغیر فریم ورک — کے ساتھ کام کرنے کے لیے ڈیزائن کیا گیا ہے، کمپوننٹ کی سطح کی بجائے اسکرپٹ کی سطح پر کام کرتے ہوئے۔ یہ کیوں اہم ہے:
- سنگل async اسکرپٹ ٹیگ:
<head>میں ایک<script>ٹیگ ہی درکار ہے۔ کوئی npm پیکیجز انسٹال کرنے کی ضرورت نہیں، کوئی فریم ورک مخصوص ریپرز نہیں، کوئی بلڈ کنفیگریشن نہیں۔ - رضامندی ڈیفالٹس فوری طور پر فائر ہوتی ہیں: اسکرپٹ اپنی پہلی کارروائی کے طور پر Consent Mode V2 ڈیفالٹس سیٹ کرتی ہے، کسی بھی کال بیک یا DOM ہیرا پھیری سے پہلے۔ اس کا مطلب ہے کہ Google ٹیگز پہلی ملی سیکنڈ سے ہی رضامندی کا احترام کرتے ہیں۔
- کوئی DOM انحصار نہیں: رضامندی لاجک React، Vue، یا Svelte کے ہائیڈریٹ ہونے کا انتظار نہیں کرتی۔ یہ فریم ورک لائف سائیکل سے آزادانہ طور پر کام کرتی ہے۔
- SSG، SSR، ISR، اور CSR کے ساتھ کام کرتی ہے: چونکہ یہ ایک سادہ اسکرپٹ ہے، یہ یکساں طور پر کام کرتی ہے چاہے صفحہ statically تیار کیا گیا ہو، سرور سے رینڈر کیا گیا ہو، incrementally دوبارہ تیار کیا گیا ہو، یا کلائنٹ سائیڈ رینڈر کیا گیا ہو۔
ڈویلپر ٹپ: درست CMP انٹیگریشن کا سب سے آسان ٹیسٹ یہ ہے کہ اپنے براؤزر کا Network ٹیب کھولیں، Google ڈومینز کے لیے فلٹر کریں، اور صفحہ دوبارہ لوڈ کریں۔ کنسول میں رضامندی ڈیفالٹ کمانڈ ظاہر ہونے سے پہلے کوئی Google درخواست فائر نہیں ہونی چاہیے۔ اگر ہوتی ہیں، تو آپ کا CMP بہت دیر سے لوڈ ہو رہا ہے۔
FlexyConsent کا مفت پلان لامحدود پیج ویوز کی حمایت کرتا ہے اور Next.js، Gatsby، Nuxt، Astro، SvelteKit، Remix، اور سادہ HTML کے ساتھ کام کرتا ہے۔ انٹیگریشن ان سب میں ایک جیسی ہے: ایک اسکرپٹ ٹیگ، صحیح جگہ پر رکھا ہوا۔