كيف تجعل تطبيقك يبدو أسرع بمرتين عبر تحديث الشاشة قبل استجابة السيرفر

سهل الأحد,26 يوليو 2026

1. الفرق بين السرعة الحقيقية والسرعة المحسوسة (Perceived Speed)

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

2. فلسفة التحديث التفاؤلي (Optimistic UI)

تعتمد هذه التقنية على فرضية واقعية: في معظم الأحيان، تنجح طلبات السيرفر البسيطة دون مشاكل. فلماذا نجعل المستخدم ينتظر؟ بمجرد أن يقرر المستخدم القيام بإجراء معين، تتغير الواجهة فوراً لتظهر أن العملية تمت بنجاح، وفي الخلفية يُرسل الطلب للسيرفر. إذا نجح الطلب -وهو المتوقع- لا يلاحظ المستخدم أي انقطاع وتكتمل التجربة بسلاسة.

3. أمثلة حية نستخدمها يومياً

نحن نتفاعل مع هذه التقنية يومياً في أشهر المنصات:

• زر الإعجاب في إنستجرام وتويتر: يكتسي القلب باللون الأحمر فور لمسه، بينما يُرسل الطلب للشبكة خلف الكواليس.

• تطبيقات المحادثة (واتساب وتليجرام): تظهر الفقرة النصية داخل الشات فور الضغط على زر الإرسال، قبل حتى أن تكتمل عملية التوصيل على السيرفر.

• إضافة للمفضلة: يتغير شكل النجمة أو العلامة لحظياً لتأكيد الخيار.
  

4. متى تستخدم التحديث التفاؤلي؟

يكون النمط التفاؤلي ممتازاً في العمليات البسيطة التي تمتلك نسبة نجاح عالية ولا يترتب عليها مخاطر مالية أو أمنية:

• التفاعل مع المنشورات (إعجاب، إعادة نشر، متابعة).

• إضافة المنتجات إلى قائمة المفضلة أو إزالتها.

• كتابة تعليق جديد أو تحديد مهمة كمكتملة في قائمة المهام.

• تغيير إعدادات بسيطة وشخصية في الواجهة.

5. متى يكون التحديث التفاؤلي قراراً خاطئاً؟

هناك حالات يمنع فيها استخدام هذا النمط تماماً، ويجب الاعتماد على النمط التقليدي الذي ينتظر رد السيرفر قبل تعديل الشاشة (Pessimistic UI):

• عمليات الدفع والتحويلات المالية.

• حجز تذاكر الطيران أو مقاعد السينما (تجنباً للتضارب).

• إنشائ حساب جديد أو تغيير كلمة السر.

• حذف الحساب أو مسح بيانات هامة نهائياً.

6. خطة التراجع عند الفشل (Rollback Strategy)

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

1. احتفظ بنسخة من حالة الشاشة القديمة قبل التعديل.

2. إذا أرجع السيرفر خطأ، أعد الشاشة لحالتها السابقة بسلاسة.

3. أظهر تنبيهاً خفيفاً (Toast / Snackbar) يخبر المستخدم بأن الإجراء لم يكتمل مع زر لإعادة المحاولة.
   

7. تطبيق الفكرة برمجياً بدون تعقيد

توفر معظم مكتبات إدارة الحالة وإدارة البيانات (مثل React Query, SWR, BLoC, Riverpod) أدوات مدمجة للتحديث التفاؤلي. تتلخص آلية التنفيذ في ثلاث خطوات بسيطة:

1. إلغاء أي إعادة جلب للبيانات جارية حالياً لعدم مسح التعديل الجديد.

2. أخذ لقطة (Snapshot) من البيانات القديمة وتحديث الشاشة بالبيانات الجديدة فوراً.

3. إرسال الطلب للسيرفر، وفي حال حدوث خطأ يتم استعادة اللقطة القديمة فوراً.