Debounce vs Throttle بالعربي: وفّر 95% من طلبات الـ API في الـ search box

ممنوع تستورد Lodash كاملة علشان دالة 10 أسطر. اكتبها بنفسك وافهم اللي بيحصل:

الاستخدام العملي في الواجهة:

امتى debounce وامتى throttle

القاعدة: لو المهم هو القيمة النهائية بعد ما تهدى الأحداث → debounce. لو المهم هو التحديث المستمر بمعدّل يقدر الجهاز عليه → throttle.

• Search autocomplete: debounce بـ 300ms. محتاج نتائج الكلمة اللي خلّصها المستخدم، مش نتائج كل حرف وسطها.
• Resize window: debounce بـ 200ms. عايز تعيد تخطيط الصفحة مرة واحدة بعد ما يخلّص التحريك، مش 200 مرة وسطه.
• Scroll position (shrinking header، lazy load، infinite scroll): throttle بـ 100ms. عايز التحديث يحصل باستمرار بس مش 60 مرة/ثانية.
• Mouse move على canvas رسم: throttle بـ 16ms (≈ 60fps). فقدان بعض الحركات مقبول، توقّف كامل لأ.
• Form validation أثناء الكتابة: debounce بـ 400ms. بتبان رسالة خطأ واحدة بعد ما المستخدم يستريح.
• Button submit: لا debounce ولا throttle. استخدم disabled state بعد أول ضغطة.

قياس فعلي على search box

الإعداد: مستخدم كتب جملة 20 حرف بمعدّل 5 ضغطات/ثانية، زمن الـ API 280ms في المتوسط.

• بدون حماية: 20 طلب API، مدة إجمالية 5.6 ثانية، تكلفة AWS API Gateway ≈ $0.00007 للطلب الواحد × 20 = $0.0014.
• Debounce 300ms: طلب واحد بعد ما يقف، زمن استجابة 320ms، توفير 95% في عدد الطلبات.
• Throttle 400ms: 5 طلبات، تجربة مستخدم أحسن شوية لأن النتائج بتيجي وهو بيكتب، بس زيادة 5× في الطلبات مقارنة بـ debounce.

ملاحظة: الأرقام مبنية على فرضية إن الـ API latency ≤ 400ms. لو الـ latency أعلى، debounce بيبقى إجباري لأن throttle هيكدّس طلبات معلّقة بتنفّذ بعد ما خلص المستخدم يكتب.

Trade-offs لازم تعرفها قبل ما تكتب سطر

Debounce: بتكسب توفير هائل في الطلبات وإلغاء الـ race conditions. بتخسر responsiveness — المستخدم بيحس إن الـ UI ساكت لحد ما يخلّص. الحل: اعرض spinner فورًا مع أول ضغطة، ده بيشتري صبر 300ms بسهولة.

Throttle: بتكسب تحديث سلس ومستمر. بتخسر دقة آخر قيمة — لو الحدث الأخير وصل في آخر 50ms قبل انتهاء الـ limit، بيتلغى نهائيًا. الحل: implementation مع trailing edge يضمن التنفيذ في آخر الفترة، زي اللي في Lodash بخيار { trailing: true }.

الافتراض في كل الأرقام فوق: متصفح حديث، زمن API ≤ 400ms، ومعدّل كتابة ≤ 7 حروف/ثانية. لو عندك WebSocket real-time أو معدّل أعلى، القيم بتتغيّر وتحتاج تقيس بنفسك.

متى لا تستخدم أي منهما

لو الحدث بيحصل مرة واحدة في كل تفاعل (زي click على submit)، مفيش حاجة اسمها debounce لزرار — المشكلة دي بتتحل بـ button.disabled = true بعد أول ضغطة.

لو بتتعامل مع WebSocket بيبعث رسائل real-time مهمّة (ألعاب متعددة اللاعبين، تطبيقات trading)، debounce بيحذف معلومات فعلية عن حالة السيستم. استخدم batching بـ requestAnimationFrame أو micro-batching بـ queue زمني بدلًا منه.

لو بتكتب React، ما تعملش debounce على function جوا المكوّن بدون useCallback أو useMemo. هتخلق debounced function جديدة كل render، وكل استدعاء هيكون على timer مستقل. استخدم useMemo(() => debounce(fn, 300), []) أو hook جاهز زي useDebouncedCallback من مكتبة use-debounce.

الخطوة التالية

افتح الـ search box في مشروعك الحالي. افتح DevTools ← تبويب Network. اكتب كلمة 8 حروف. لو شفت 8 طلبات شبكة، عندك المشكلة دي بالظبط. ضيف debounce بـ 300ms بالكود اللي فوق، جرّب تاني، ولازم تشوف طلب واحد بس. ده توفير فوري 87% من الحمل، بدون أي تأثير سلبي على تجربة المستخدم.

المصادر

• MDN: setTimeout و clearTimeout
• Lodash docs: debounce options (leading / trailing / maxWait)
• Lodash docs: throttle
• CSS-Tricks: Debouncing and Throttling Explained
• MDN: requestAnimationFrame كبديل للـ throttle البصري
• npm: use-debounce (React hook موثّق)