وقت البايت الأول: ما هو ولماذا هو مهم

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



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

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

ما هو TTFB؟

لا يبدو TTFB غني بالمعلومات ( صورة بالحجم الكامل )

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

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

الآن ، مسلحين بهذه المعرفة ، يمكننا أن نفهم بسهولة السبب الذي يجعل عرض مؤشر TTFB عند عرض المواقع من الأجهزة المحمولة كبيرًا بشكل غير لائق. من الممكن تمامًا في وقت سابق في مثل هذه الحالات ، أن تطلب شيئًا من هذا القبيل: "أنا متأكد من أن الخادم لا يعلم أنني أشاهد الموقع من هاتف محمول. كيف بعد ذلك يزيد TTFB؟ " والسبب في ذلك هو ، كقاعدة عامة ، أن اتصالات شبكة الهاتف المحمول هي اتصالات عالية زمن الوصول. إذا كان مؤشر RTT ، الذي يعكس الوقت اللازم لنقل البيانات من الهاتف إلى الخادم والعودة ، على سبيل المثال ، 250 مللي ثانية ، فسيزيد TTFB بالقيمة المقابلة.

إذا كنت ترغب في أن يقوم قراء هذه المادة باستخراج فكرة رئيسية واحدة منها ، فسأقوم بصياغة هذه الفكرة على النحو التالي: "تؤثر تأخيرات الشبكة على TTFB."

ماذا يؤثر على TTFB؟ في الواقع - الكثير من كل شيء. هذه قائمة بعيدة عن القائمة الكاملة لما يساهم في تكوين هذا المؤشر. العناصر في هذه القائمة بترتيب عشوائي.

• تأخير الشبكة. كما ذكرنا سابقًا ، يتضمن TTFB الوقت الذي يستغرقه تسليم الطلب إلى الخادم وإرجاع استجابة من الخادم. خذ على سبيل المثال ، الوقت اللازم لجلسة تبادل البيانات بين جهاز موجود في لندن وخادم في نيويورك. من الناحية المثالية ، عند استخدام اتصال الألياف البصرية ، هذا هو 28 مللي ثانية. لكن هذا يعتمد على العديد من الافتراضات المتفائلة للغاية. في الواقع ، يجب أن تتوقع شيئًا مثل 75 مللي ثانية . هذا هو السبب في أنه من المهم للغاية استخدام CDN. حتى الآن ، في عصر الإنترنت ، يعد القرب الجغرافي لأعمال معينة وعملائها ميزة.
• التوجيه. إذا كنت تستخدم CDN (ويجب أن يكون كذلك!) ، فيمكنك إعادة توجيه طلب عميلك ، على سبيل المثال ، من Leeds ، إلى مركز بيانات MAN فقط حتى يتضح أن المورد الذي يحتاجه العميل ليس في ذاكرة التخزين المؤقت PoP المقابلة . بعد ذلك ، سيتم إعادة توجيه الطلب إلى الخادم الحقيقي مع المواد الخاصة بك من أجل نقل ما يحتاجه إلى العميل. إذا كان هذا الخادم موجودًا ، على سبيل المثال ، في فرجينيا ، فسيؤدي كل ما سبق إلى زيادة كبيرة في TTFB دون سبب واضح.
• العمل مع الملفات. حتى إذا كان الخادم يقرأ ببساطة البيانات الثابتة من نظام الملفات الخاص به ، مثل الصور أو ملفات النمط ، فإن الأمر يستغرق بعض الوقت لإكمال هذه العملية. هذه المرة هي أيضًا جزء من TTFB.
• تحديد الأولويات. يشتمل بروتوكول HTTP / 2 على آليات لتحديد أولويات معالجة الطلبات. نتيجة لذلك ، قد يتضح أنه يمكن تأخير الطلبات ذات الأولوية المنخفضة على الخادم ، مما يفسح المجال لطلبات الأولوية القصوى. حتى إذا لم تأخذ في الاعتبار آليات تحديد الأولويات HTTP / 2 وتفترض أن كل شيء يعمل بشكل سلس ، فإن هذه التأخيرات المتوقعة يمكن أن تسهم في TTFB.
• تشغيل التطبيقات. هذا ، في الواقع ، واضح تمامًا ، لكن أود أن أشير إلى أن الوقت اللازم لتشغيل تطبيقات الخادم يؤثر بشكل خطير على TTFB.
• استعلامات قاعدة البيانات. إذا كنت بحاجة إلى طلب شيء من قاعدة البيانات لتكوين الصفحة ، فسيتم أيضًا تضمين الوقت اللازم لإكمال هذه العملية في TTFB.
• مكالمات API إذا كانت هناك حاجة لبيانات من واجهات برمجة التطبيقات (داخلية أو خارجية) لإعداد الصفحة ، فستؤثر المكالمات إلى واجهات برمجة التطبيقات هذه على TTFB.
• تقديم الخادم من الواضح تمامًا أن العرض من جانب الخادم يستغرق وقتًا ، ولكن هذه المرة يسهل تقييمه ، لكن هذا لا ينفي مساهمة هذه العملية في TTFB.
• استضافة رخيصة. إذا كنت تستخدم استضافة رخيصة ، وتحاول توفير أكبر قدر ممكن من الأداء والتضحية ، فهذا يعني عادةً أن عددًا من المشاريع الأخرى تستخدم الخادم الذي يوجد عليه مشروعك. ربما كمية كبيرة. نتيجة لذلك ، يمكن أن يتوقع شخص يستخدم استضافة رخيصة انخفاضًا في أداء الخادم ، مما قد يؤثر على قدرة المشروع على معالجة الطلبات. في الواقع ، نحن نتحدث عن حقيقة أن قوة أجهزة الخادم لا تكفي لتلبية احتياجات التطبيق.
• هجمات DDoS ، حمولة عالية على المشروع. نواصل هنا الموضوع الذي تمت مناقشته في الفقرة السابقة من هذه القائمة. أي ، إذا زاد الحمل على الخادم ، ولم يوفر المشروع تحجيمًا مرنًا لقدرات الخادم ، فإن هذا يؤدي إلى حقيقة أن الجهاز يبدأ في العمل إلى الحد الأقصى. ونتيجة لذلك ، ينخفض ​​أداء التطبيق.
• WAF ، موازن التحميل. الخدمات ، مثل WAF أو موازنات التحميل الموجودة أمام تطبيق الخادم ، تزيد من TTFB.
• بعض ميزات CDN. يعد استخدام CDNs أحد العوامل التي لها بالتأكيد تأثير مفيد على TTFB ، لكن بعض ميزات CDNs قد تزيد الأمر سوءًا. على سبيل المثال ، هذا طلب قابل للطي ، ESI ، إلخ.
• التأخير في "الميل الأخير". عندما نتحدث عن جهاز كمبيوتر من لندن يصل إلى خادم موجود في نيويورك ، فإننا عادة ما نبالغ في تبسيط الموقف ، ونقله تقريبًا إلى حقيقة أن الكمبيوتر والخادم متصلان مباشرة مع بعضهما البعض. ولكن في الواقع ، كل شيء أكثر تعقيدًا. تمر الإشارة بين الكمبيوتر والخادم عبر العديد من الوسطاء. يرسل جهاز التوجيه الخاص بنا إلى المزود ؛ من شبكة لاسلكية ، دخل في كبل موصول عبر قاع المحيط ... تشمل التأخيرات في "الميل الأخير" جميع الصعوبات التي تعترض طريق نقل البيانات بين الأجهزة الطرفية.

A 0 مللي TTFB هو حلم الأنابيب. لذلك ، من المهم ملاحظة أنه لا يوجد شيء في القائمة يؤثر سلبًا دائمًا على TTFB أو يفاقم هذا المؤشر دائمًا. من الأفضل فهم هذه القائمة على أنها وصف لبنية TTFB للمشروع. هدفي ليس انتقاد تقنيات معينة ، ولكن إظهار كيف يمكن لبعض التقنيات التأثير على TTFB. ولكي نكون صادقين ، بالنظر إلى مقدار الأشياء التي تحدث قبل أن يتلقى العميل البايت الأول من الاستجابة من الخادم ، من المدهش بالفعل أن يتم تحميل المواقع بشكل عام.

كشف الغموض مع TTFB

الآن ، على أمل ، أن TTFB لا يبدو غامضًا بعد الآن. وإذا كنت تقضي بعض الوقت في تطبيق توقيت خادم API ، فيمكنك البدء في قياس مؤشرات وقت الخادم الصعبة وإرسالها إلى أنظمة العميل. سيتيح ذلك لمطوري الويب اكتشاف اختناقات الأداء المحتملة التي كانت مخفية عن أعينهم والقضاء عليها.

تتيح واجهة برمجة تطبيقات خادم التوقيت للمطورين توسيع استجابات الاستعلام باستخدام رأس HTTP Server-Timing الاختياري. أنه يحتوي على معلومات الوقت تقاس التطبيق نفسه.

هذه هي الآلية التي استخدمناها في العام الماضي عند العمل على BBC iPlayer.


يمكن إضافة رأس جديد لخادم التوقيت إلى أي إجابة ( الصورة بالحجم الكامل )

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


الآن ، في المتصفح مباشرة ، يمكنك رؤية بنية TTFB ( صورة بالحجم الكامل )

إذا كنت تريد تطبيق API Server Timing ، فقم بإلقاء نظرة على هذه المواد .

النتائج

من المهم جدًا أن يفهم مطورو الويب مدى تأثير TTFB على ما يسمونه "أداء الموقع". وقت البايت الأول هو حد معين ، بعد العبور يمكننا التحدث عن تحسين موقع الويب. كلما انخفض هذا المؤشر ، كان ذلك أفضل.

أعزائي القراء! هل تحسين مشاريع الويب الخاص بك مع TTFB؟