أنشئ جردًا واحدًا مما يحمله المتصفح
ابدأ بصفحات تمثيلية: الصفحة الرئيسية، صفحات الهبوط، صفحات التفاصيل، البحث، السلة، الدفع، الحساب، والحملات. سجّل الزيارات الجديدة والعودة في Chrome DevTools. قارن أدلة المتصفح مع مدير الوسوم (tag manager)، إضافات نظام إدارة المحتوى (CMS plug-ins)، واعتماديات الكود؛ فوجهة نظر واحدة قد تفوّت السكربتات المحقونة.
استخدم صفًا واحدًا لكل بائع أو تكامل، وليس لكل URL فقط. سجّل النطاقات التي يتصل بها وما إذا كان بإمكانه إضافة علامات. عيّن له مالكًا تجاريًا يمكنه الدفاع عن الهدف والموافقة على الإزالة. أعد التحقق بعد الحملات، تغييرات البائع، إصدارات القوالب، وإعادة التصميم.
احفظ الصفحة، المسار، نطاقات البائع، الطلبات، حجم النقل، عمل الخيط الرئيسي (main-thread work)، وظروف الاختبار. أثر المختبر (lab trace) هو دليل تشخيصي، وليس وعدًا لكل زائر.
ضمّن الهدف، المالك، فئة الموافقة، المُحفّز، البيانات المكشوفة، ترتيب الاعتماديات، الحل البديل (fallback)، وتاريخ المراجعة.
اجعل قرارات الاحتفاظ، الإزالة، والميزانية مرئية
اسأل كل مالك ما الأسوأ إن اختفى التكامل. إن كان الجواب غامضًا، عطلّه أو أزلّه. توصي web.dev بوضع ميزانيات، تجنب الوظائف المكررة، وتنظيف السكربتات الزائدة.
الميزانية هي حاجز توجيهي للفريق، وليست حدًا عالميًا. اضبط مخصصات لكل بائع ولكل صفحة للبايتات، الطلبات، وقت الخيط الرئيسي، وتوقيت التحميل. قارن الحالة الأساسية مع التغيير. اطلب من المالك الالتزام بالمخصص، أو إزالة تكلفة أخرى، أو الحصول على استثناء منتهي الصلاحية. استخدم مسارات قابلة للمقارنة ومقاييس تتمحور حول المستخدم.
احتفظ بالاعتماديات التي لها هدف حالي، وتكلفة واستخدام بيانات مقبولة من المالك، ومسار فشل مقبول.
أخرج من الخدمة البكسلات المنتهية، التحليلات المكررة، الدردشة غير النشطة، التجارب غير المستخدمة، والإضافات المهجورة عبر إصدار مرحلي.
سجّل السبب، التكلفة، الموافق، الإجراء التعويضي، وتاريخ المراجعة.
حمّل متأخرًا فقط عندما يكون التأخير آمنًا
اختر سلوك التحميل عن دراية. السكربت الخارجي الكلاسيكي دون async أو defer أو module يُحمَّل ويُنفّذ قبل استمرار تحليل HTML. مع async، يجري التنزيل بشكل متوازي لكن يبدأ التنفيذ عند الجاهزية، لذا لا يُضمن الترتيب. مع defer، تُنفّذ السكربتات الكلاسيكية بعد التحليل وبترتيب المستند، قبل DOMContentLoaded. مناسب للسكربتات المرتبة؛ ولكنه ليس حلًا عالميًا.
لواجهات الدردشة الاختيارية، التضمينات الاجتماعية، الخرائط، الفيديو، أو التوصيات، اعرض عنصرًا نائبًا خفيف الوزن وحمّل البائع بعد النقر أو عند الاقتضاء. نمط الواجهة الوهمية (facade) يبدأ بتحكمك بدلًا من التضمين الكامل. حافظ على التفاعل عبر لوحة المفاتيح واحجز المساحة. لا تؤخر (defer) الكود اللازم لحساب السعر، تسجيل الدخول، معالجة الدفع، توفير إمكانية وصول أساسية، أو الوفاء بالتزام مؤكد دون بديل مُراجع.
حمّل فورًا فقط لعِتمدية المهمة الأولى؛ استخدم ما بعد التحليل للكود المرتب، والتفاعل أو الظهور للتضمينات الاختيارية.
لا تضع علامة async على السكربتات المترابطة وتتوقع الحفاظ على الترتيب. وثّق واختبر سلسلة النشر.
لا تربط واجهة المستخدم الحرجة بحدث window load؛ التضمينات الطرف ثالث يمكن أن تؤخره حتى مع استخدام async أو defer.
اجعل الموافقة بوابتك، لا فكرة ثانوية
صنّف كل بائع مع أصحاب المصلحة في الخصوصية والشؤون القانونية الذين يفهمون الاختصاصات وتدفقات البيانات. للتكامل الخاضع للموافقة، ثبّت حالة الموافقة قبل أن يرسل الوسم البيانات ذات الصلة. تقول Google إن أمر الموافقة الافتراضي يجب أن يعمل قبل أوامر القياس، ويجب أن تَتبع التحديثات تغيير الخيار. هذا التوجيه المنتج ليس نصيحة قانونية.
اختبر الزيارة الأولى دون خيار، والقبول، والرفض، والسحب. افحص الواجهة والشبكة: وجود ويدجيت مخفي لا يثبت عدم إرسال طلب أو مُعرّف. إذا كانت منصة الموافقة تُحمّل بشكل غير متزامن، اختبر التوقيت. احفظ الخيارات بشكل مناسب وطبّق التغييرات على الصفحة الحالية والزيارات اللاحقة.
لا تعتمد على تسمية البائع. سجّل سبب كون الوسم أساسيًا أو اختياريًا أو محظورًا لمنطقة أو مسار معين واحصل على الموافقة.
بعد السحب، تأكد من أن الوسوم غير الأساسية المكوّنة لا تتحمّل أو ترسل بيانات واحتفظ بأدلة الاختبار.
قلل من دائرة التأثير (blast radius) للكود الذي لا تملكه
تحدد OWASP فقدان التحكم في تغييرات العميل، تنفيذ كود عشوائي في المتصفحات، وتسريب البيانات الحساسة كمخاطر مركزية. حدّ من صلاحيات نشر الوسوم، راجع HTML المخصص أو ميزات الكود العشوائي، ووثق حقول طبقة البيانات المسموح بها. يمكن أن تساعد اتفاقيات البائع والمراجعة الأمنية المؤهلة في التكاملات عالية المخاطر؛ لكن لا شيء منهما يحل محل الاختبار.
Subresource Integrity، أو SRI، يتيح للمتصفح التحقق من سكربت مقابل هش تشفيري. يساعد فقط عندما يمكن تثبيت المورد وتدعم خدمة التوصيل عبر الأصل (cross-origin) CORS؛ تقول W3C إن استخدام SRI دون CORS خطأ منطقي. إنه غير مناسب للعديد من روابط البائع المتغيرة. قد يقلل iframe sandbox الوصول المباشر إلى DOM والكوكيز (cookies)، لكنه يحتاج إلى مراجعة مختصين. تستحق تدفقات الدفع والحساسة أمنيًا مراجعة مؤهلة.
مرّر فقط الحقول الموثقة اللازمة للغرض. لا تكشف الأسرار، بيانات الدفع، أو سمات العملاء غير الضرورية.
SRI يتحقق من البايتات، وليس ما إذا كان استخدام البيانات أو الطلبات اللاحقة مناسبة؛ العزل ليس حلاً قابلاً للتطبيق فورًا.
درّب على فشل البائع قبل أن يواجهه العملاء
لكل بائع محتفظ به، احظر نطاقاته في بيئة اختبار أو باستخدام مانع طلبات المتصفح، ثم نفّذ المسار. اختبر أيضًا الاستجابات البطيئة وتكوين مدير الوسوم بدون التكامل. تأكد من أن المحتوى الأساسي، التنقل، النماذج، عملية الدفع، والوصول إلى الحساب تعمل كما هو مقصود. يكشف هذا الافتراضات قبل الإصدار.
حدّد إجراءات الإصلاح قبل الحادث: من يمكنه تعطيل الوسم، هل يلزم علم (flag) أو نشر عبر مدير الوسوم، كيف تتراجع، وكيفية التحقق. SIU هي تحسين وقت التشغيل والاستجابة الاستباقية: استخدم الجرد، الميزانيات، فحوصات ما قبل الإطلاق، وممارسات التراجع لتقليل مخاطر الاعتماد. لا تستطيع SIU التحكم في بنية البائع التحتية، أو ضمان التوافر، أو استبدال المراجعة.
اذكر ما يظل قابلاً للاستخدام بدون البائع، ما قد يتدهور، الحل البديل، والحد الأقصى للتأخير قبل التعطيل.
أرفق أثر قبل وبعد، نتيجة الموافقة، نتيجة الحجب للبائع، ومالك التراجع في سجل التغيير.