اكتشف أحد المطورين أن إرفاق مصحح Chrome DevTools عبر Playwright أو Puppeteer يؤدي إلى إبطاء عمليات الرفع المستندة إلى fetch بأكثر من 20 ضعفاً، مما يحول اختبارات الأداء المعتادة إلى بيانات مضللة.

اللغز الذي أثار التحقيق

يقوم Coffer، وهو مستودع ملفات قائم على المتصفح يقوم بتشفير البيانات قبل إرسالها إلى الخادم، برفع ملفات بسرعة فئة الجيجابت (gigabit-class) بشكل روتيني عبر شبكة محلية. وعندما قام الفريق بقياس سرعات الرفع، لاحظ وجود فجوة: كانت عمليات التنزيل تشبع الرابط تماماً، لكن عمليات الرفع كانت بطيئة للغاية، حيث بلغت حوالي ثمن النطاق الترددي المتاح فقط. أدى هذا التباين إلى إجراء ثلاث جولات من تغييرات الكود التي فشلت في إحداث أي فرق، حتى ظهر "إصلاح" رابع بدا وكأنه يحقق قفزة هائلة، ليختفي هذا التحسن بمجرد إزالة المصحح (debugger).

ما حاول الفريق تجربته أولاً

قام المهندسون بملاحقة المشتبه بهم المعتادين:

  • حجم الكتلة (Chunk size) – لم يؤدِ مضاعفة الكتلة من 16 MiB إلى 32 MiB إلى تغيير معدل النقل.
  • التدفق المتسلسل (Pipelining) – أدى تداخل تشفير الكتلة التالية مع عملية الرفع الحالية إلى تحقيق مكسب متواضع بنسبة 13%، وهو فرق لا يمكن تمييزه عن ضجيج القياس.
  • التزامن (Concurrency) – أدى تشغيل عمليات رفع متعددة بالتوازي إلى الوصول إلى نفس السرعة الإجمالية القصوى، مما يشير إلى وجود سقف عالمي.

لم يفسر أي من هذه التغييرات هذا البطء بمقدار 8 أضعاف.

مقارنة مباشرة مفاجئة

لعزل المشكلة، قام الفريق بتغيير تنفيذ العميل (client implementation). باستخدام .NET HttpClient، سجلوا سرعة 700 Mbps على نفس الشبكة؛ بينما توقفت نفس الطلبات الصادرة من واجهة برمجة التطبيقات fetch() في Chromium عند 140 Mbps. أشار هذا التباين الصارخ إلى أن مكدس الشبكة (network stack) في المتصفح هو المتسبب—إلى أن أثبتت التجربة التالية عكس ذلك.

التكلفة الخفية للمصحح

يقوم Playwright و Puppeteer بتشغيل Chrome عبر بروتوكول Chrome DevTools (CDP). يقوم هذا البروتوكول بإرفاق مصحح (debugger) بعملية المتصفح، مما يكشف عن أحداث الشبكة، ولقطات DOM، وسجلات وحدة التحكم (console logs). أجرى الفريق اختباراً مركزاً: استدعاء fetch() يرسل حمولة من نوع Uint8Array؛ مرة مع إرفاق مصحح CDP ومرة بدونه.

  • المصحح مرفق: 113 Mbps

أدى وجود المصحح إلى تقليل سرعة الرفع بأكثر من 20 ×. بينما وصلت تجربة يدوية في نافذة Edge عادية—بدون إرفاق مصحح—إلى أكثر من 600+ Mbps، مما يؤكد أن المتصفح نفسه يمكنه التعامل مع حركة البيانات عندما لا يكون مقيداً.

تحسن حقيقي ومتواضع

بينما كان المصحح هو المسؤول عن الجزء الأكبر من البطء، اكتشف الفريق أيضاً تحسيناً حقيقياً: حيث أدى تغيير جسم الطلب (request body) من Uint8Array إلى Blob إلى رفع سرعة Chromium بنسبة 30% تقريباً. إنه تعديل مفيد، لكنه لا يقترب أبداً من القفزة "المعجزة" التي كانت مأمولة في الأصل.

لماذا يهم هذا المهندسين

  • أدوات القياس قد تكذب. أدوات الأداء التي تقوم بأتمتة المتصفحات هي نفسها جزء من سلسلة القياس.
  • اختبارات الأداء التي تبدو مستحيلة تستحق التحقق من منطقيتها. إذا تباينت الأرقام بشكل كبير عن سعة الشبكة، فيجب أن تكون بيئة القياس هي المشتبه به الأول.
  • النتيجة الصفرية قيمة. التأكد من أن التغيير لا يفعل شيئاً يمنع إهدار الجهد في مطاردة أخطاء وهمية.
  • التحكم اليدوي هو تأمين رخيص. تشغيل نفس العملية في نافذة متصفح عادية يمكن أن يكشف عن العبء الخفي لأدوات القياس.

وجهة نظر مغايرة: عندما تكون المصححات لا غنى عنها

توفر المصححات رؤية لسلوك الصفحة، وتتبع الأخطاء (error traces)، والجداول الزمنية للشبكة التي لا يمكن الوصول إليها بطرق أخرى. ومن أجل اختبار التراجع (regression testing)، أو عمليات التدقيق الأمني، أو تفاعلات واجهة المستخدم المعقدة، غالباً ما يكون إرفاق مصحح CDP أمراً لا غنى عنه. المفتاح هو الفصل بين الاختبار الوظيفي وقياس الأداء الخام، وتعطيل المصحح عندما يكون الأخير هو الهدف.

الخلاصة: الأدوات التي تجعل الاختبار المؤتمت ممكناً يمكن أن تصبح أيضاً أكبر مصدر لتشويه الأداء. قبل إلقاء اللوم على المتصفح أو الشبكة أو الكود، تأكد من عدم وجود مصحح يقوم بتقليل تدفق البيانات بصمت.