البناء لاتصال بطيء

القيد الذي يحكم كل شيء

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

لذلك فالسؤال الأول عن أي شاشة ليس «كم حجمها» بل «كم عدد الأشياء التي يجب أن تحدث بالترتيب قبل أن يرى المستخدم شيئاً».

الميزانيات التي نلتزم بها

هذه ميزانيات لا قوانين. والمهم أن أحداً حدد رقماً مسبقاً، ليصبح تجاوزه مفاضلة واعية لا حادثاً.

ابثّوا ولا تنتظروا

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

لم تتغير المدة الإجمالية. لكن التجربة مختلفة تماماً.

احترموا إشارات المتصفح

• navigator.connection.saveData: طلب المستخدم صراحةً بيانات أقل. احترموا ذلك.
• effectiveType: يبلّغ 2g و3g و4g. يكفي لتقرروا تحميل الوسائط الثقيلة تلقائياً أو لا.
• prefers-reduced-motion: إعداد إتاحة، وهو أيضاً سبب وجيه لتخطي فيديو زخرفي.

في هذا الموقع لا يُربط فيديو الواجهة إلا بعد هذه الفحوص. ومن كان على Save-Data أو شبكة 2G/3G يحصل على صورة ثابتة ولا ينزّل منه شيئاً.

افترضوا انقطاع الاتصال

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

ما ليس هذا

ليست هذه دعوة إلى مواقع قبيحة ومقتضبة، بل دعوة إلى تحديد ما يُحمَّل أولاً. فصفحة ثقيلة تعرض محتوى مفيداً فوراً وتحمّل الباقي بعده لا بأس بها. أما صفحة خفيفة لا تعرض شيئاً لأربع ثوانٍ فلا.

اطّلعوا على صفحة الخدمة: مواقع ويب بذكاء اصطناعي مدمج للشركات الجزائرية.