هدف الـ 200ms على شبكات سيّئة

«إجراءات المستخدم تشعر فوريّة حين تكتمل في أقلّ من ٢٠٠ مللي ثانية». هذا الرقم يُقتبَس في كلّ كتابة عن الأداء. ما لا يخبرك به أحد هو أنّه على الشبكات الاستهلاكيّة الحقيقيّة، الـ ٢٠٠ مللي ثانية تختفي قبل أن يعمل كودك. هذا ما يمكنك ضمانه، ما لا يمكنك، ولماذا معظم ميزانيّات الأداء تفكير رغبويّ.

أين تذهب الـ ٢٠٠ مللي ثانية قبل أن تبدأ#

أقلِع هاتف 4G بإشارة خلويّة نموذجيّة (ليست أفضل حالة)، أصدر طلباً إلى خادم في بلد مختلف، قِس أين يعيش الوقت:

TLS handshake (cold)        ١٨٠ مللي ثانية
DNS lookup (cold)            ٧٠ مللي ثانية
TCP three-way                ٤٠ مللي ثانية (خلويّ ريفيّ)
HTTP request body            ~٥ مللي ثانية
معالجة الخادم                يتفاوت
Response body                ~١٠ مللي ثانية (صغيرة)
رسم Render parse + paint     ~١٦ مللي ثانية (إطار واحد)

هذا ~٣١٥ مللي ثانية قبل أن يفعل كودك أيّ شيء، على اتّصال بارد. حتّى اتّصال دافئ (TLS resumption، DNS مُخزَّن، TCP مفتوح) يكلّف ٦٠-٩٠ مللي ثانية من الذهاب والعودة على خلويّ حقيقيّ. ميزانيّة الـ ٢٠٠ مللي ثانية تختفي قبل وصول الطلب إلى خادمك.

هذه ليست حكاية حزن. هي شرط مسبق. عمل الأداء على الإجراءات الشبكيّة في معظمه عن تجنّب الذهاب والعودة، لا تسريعها.

ماذا يتطلّب «يشعر فوريّاً» فعلاً#

ثلاثة أنماط تنتج إجراءات بإحساس فوريّ على الشبكات السيّئة. لا أحد منها يتضمّن جعل الشبكة أسرع.

١. واجهة متفائلة#

الإجراء يأخذ أثره مرئيّاً قبل الذهاب والعودة. المستخدم يضغط «أرسل»؛ الرسالة تظهر في الدردشة مع مؤشّر «جاري الإرسال»؛ الذهاب والعودة يحلّها إلى «أُرسلت» أو «فشلت».

هذا يعمل لأنّ النموذج العقليّ للمستخدم هو أنّه أرسل الرسالة. الحقيقة (الخادم لم يقرّ بعد) تفصيل تنفيذ. مؤشّر «جاري الإرسال» هو الجزء الصادق: نخبره أنّها في الطريق؛ يثق بالنظام لحلّها.

٢. قراءات local-first#

البيانات على الشاشة تُقرأ من قاعدة بيانات محلّيّة، لا الشبكة. الشبكة تُستخدم فقط لإبقاء قاعدة البيانات المحلّيّة طازجة، في الخلفيّة، حين يكون مناسباً. غطّينا هذا النمط في مقال Flutter offline-first؛ هو السبب البنيويّ لماذا تستطيع التطبيقات أن تشعر سريعة على الشبكات السيّئة.

٣. الجلب المسبق للبيانات المحتاجة بشكل متوقّع#

إن كنت تعرف أنّ المستخدم على وشك الحاجة إلى بيانات X (لأنّه على الشاشة التي تسرد X والنقرة الواضحة التالية هي «افتح واحدة»)، اجلبها مسبقاً. زمن الاستجابة المخفيّ خلف نقرة لم تحدث بعد هو زمن استجابة ليس في المسار الحرج.

الشكل الخطر لهذا النمط هو «اجلب كلّ شيء مسبقاً». يكلّف خطّة بيانات المستخدم والبطّاريّة. كن محدّداً: اجلب مسبقاً فقط العناصر التي لها معدّل نقر > ٣٠٪ من الشاشة الحاليّة.

ماذا يمكنك أن تَعِد على الشبكات السيّئة#

ثلاثة SLOs نقدّمها:

صفّ «النقر-إلى-الإقرار» هو الوحيد حيث ينطبق الـ ٢٠٠ مللي ثانية، وذلك لأنّه محلّيّ. صفّ «النقر-إلى-تأكيد-الخادم» واقعيّ لذهاب وعودة شبكة ولا نتظاهر بغير ذلك.

التأطير الصادق للمستخدمين: الإجراءات تشعر فوريّة؛ المزامنة في الخلفيّة؛ إن فشل شيء، نخبرك، مع طريقة لإعادة المحاولة.

ماذا لا يمكنك أن تَعِد#

بعض الأشياء بطيئة على الشبكات السيّئة فقط. كن صادقاً عنها بدلاً من تغطيتها.

أيّ شيء يتطلّب حساب جانب الخادم قبل عرض البيانات#

بحث عبر مجموعة بيانات المستأجر الكاملة. تقرير. «ما هو إجماليّ الفاتورة الحاليّ». كلفة الذهاب والعودة لا يمكن تجنّبها. اعرض هيكلاً، لا تتوقّف على spinner.

الصفحات التي تحمّل موارد من أطراف ثالثة#

الخرائط. مزوّدو المصادقة الخارجيّون. الفيديو المُضمَّن. كلّ منها دورته الخاصّة DNS + TLS + طلب، وتتراكم. إن استطعت تجنّب الطرف الثالث، افعل؛ إن لم تستطع، حمّله بشكل كسول تحت الطيّ واعرض بقيّة الصفحة.

أيّ شيء بالوقت الحقيقيّ خلال الازدحام#

websockets، SSE، إشعارات push، كلّها تتدهور حين تكون الشبكة مزدحمة. البديل ليس «اجعلها تعمل أصعب»؛ البديل هو polling على فاصل أطول وقبول زمن الاستجابة.

أين نُقَيس#

مكانان:

Real User Monitoring (RUM)#

كلّ إجراء مفتاحيّ يُصدر حدثاً واحداً مع طوابع زمن البداية/النهاية ونوع الشبكة وقتها. نجمّع إلى p50 / p95 / p99 لكلّ نوع شبكة. المثيرة للاهتمام هي p95 على الخلويّ؛ p50 على الـ wifi يجامل الأرقام.

محاكاة شبكة بطيئة في CI#

كلّ PR يشغّل اختباراً اصطناعيّاً ضدّ خادم staging مع الشبكة مُخفَّضة إلى «3G بطيء» عبر ملفّ DevTools. أيّ إجراء يستغرق أطول من ميزانيّته على 3G البطيء يحجب الـ PR. هذا يلتقط الانحدارات التي تبدو جيّدة على شبكة منزل سريعة.

الخلاصة المملّة#

الشبكات السيّئة تجعل هدف الـ ٢٠٠ مللي ثانية غير قابل للوصول لأيّ إجراء يتضمّن الشبكة. المسار الصادق إلى الأمام هو تصميم إجراءات لا تتضمّن الشبكة على المسار الحرج: كتابات محلّيّة متفائلة، قراءات local-first، جلب مسبق تنبّؤيّ. ثمّ صرّح بوضوح ما هي ميزانيّة الذهاب والعودة الفعليّة، والوفاء بها.

معظم التطبيقات غير صادقة عن ميزانيّات الأداء لأنّها كُتبت لـ wifi المنزل لفريق الهندسة. أوّل مرّة تشحن لعميل في قبو على 3G، تكتشف أيّ ميزانيّة كانت حقيقيّة.

المنشور التالي عن استراتيجيّات الـ indexing للاستعلامات التحليليّة. أو تصفّح فهرس الكتابة لاتّجاهات أخرى.