كنا نخسر تحويلات إعلاناتنا بسبب تحسين أداء قمنا به بأنفسنا

حين تُحسّن سرعة الصفحة، قد تكسر بدون قصد نفس الشيء الذي كنت تحاول حمايته. هذا ما حدث بالضبط مع تتبع تحويلات Google Ads وTikTok الخاصة بنا، ولم نكتشف الخلل إلا حين قرأنا كودنا كما لو كنا نراجعه لعميل. قبل أسابيع قليلة، أجّلنا تحميل gtag.js وبكسل TikTok باستخدام requestIdleCallback حتى لا يتنافسا مع عملية الـ hydration على اتصالات الجوال البطيئة، وهي بيئة معظم زوارنا. هذا تحسين شائع ونجح فعلاً: سكربتات أقل تعطّل الرسم، وتفاعل أسرع. لكنه كسر تتبع التحويلات بصمت. كلا السكربتين لا يرسلان طلب الشبكة الفعلي إلا بعد تحميل السكربت المؤجَّل وتفريغ قائمة انتظار الأحداث. هذه القائمة تعمل جيداً لزائر يواصل التصفح، لأن الـ idle callback سيُنفَّذ عاجلاً أم آجلاً في مكان ما من الموقع. لكنها لا تعمل لزائر يسجّل خلال ثوانٍ ثم يغلق التبويب فوراً، وهو بالضبط شكل كثير من زيارات الإعلانات، خصوصاً من المتصفحات الداخلية لتطبيقات TikTok وMeta. بكسل TikTok كان أسوأ: كائن التتبع نفسه لم يكن معرَّفاً أصلاً حتى يعمل الـ idle callback، فالاستدعاءات قبل ذلك لم تُوضع في قائمة انتظار، بل ضاعت ببساطة. الحل كان التوقف عن تأجيل السكربتين اللذين تعتمد عليهما التحويلات. كلاهما يُحمَّل بخاصية async أصلاً، فلم تكن هناك تكلفة حقيقية على أول عرض للصفحة، بل تكلفة نظرية فقط كان يجب ألا ندفعها أبداً مقابل خسارة نفس الأحداث التي تبرر الإنفاق الإعلاني. الدرس الذي أخذناه لخطوة التحسين القادمة: أي شيء يعتمد على حدث سريع يحدث مرة واحدة (تسجيل، شراء، تثبيت) يجب أن يُعامل كحساس للتأخير دون استثناء. أما الباقي فيمكنه الانتظار حتى يخف الحمل.