تعرَّف على كيفية تحسين مقياس "مدة تحميل أول بايت".
تاريخ النشر: 19 يناير 2023، تاريخ آخر تعديل: 28 نوفمبر 2025
مدة تحميل أول بايت (TTFB) هي مقياس أساسي لأداء الويب يسبق كل مقاييس تجربة المستخدم المهمة الأخرى، مثل سرعة عرض أول محتوى مرئي (FCP) وسرعة عرض أكبر محتوى مرئي (LCP). وهذا يعني أنّ القيم العالية لـ TTFB تضيف وقتًا إلى المقاييس التي تليها.
ننصح بأن يستجيب الخادم لطلبات التنقّل بسرعة كافية لكي يحصل 75% من المستخدمين على سرعة عرض أول محتوى مرئي (FCP) ضمن الحدّ "الجيد". كدليل تقريبي، يجب أن تسعى معظم المواقع الإلكترونية إلى تحقيق مدة تحميل أول بايت تبلغ 0.8 ثانية أو أقل.
كيفية قياس مدة تحميل أول بايت
قبل أن تتمكّن من تحسين مدة تحميل أول بايت، عليك ملاحظة مدى تأثيرها في مستخدمي موقعك الإلكتروني. يجب الاعتماد على البيانات الميدانية كمصدر أساسي لمراقبة مدة تحميل أول بايت (TTFB) لأنّها تتأثر بعمليات إعادة التوجيه، في حين أنّ الأدوات المستندة إلى المختبر غالبًا ما يتم قياسها باستخدام عنوان URL النهائي، وبالتالي لا يتم احتساب هذا التأخير الإضافي.
تُعدّ إحصاءات PageSpeed إحدى الطرق للحصول على معلومات الاستخدام الفعلي والمعلومات الاختبارية للمواقع الإلكترونية العامة المتوفّرة في تقرير تجربة المستخدم على Chrome.
يتم عرض مدة تحميل أول بايت للمستخدمين الحقيقيين في قسم التعرّف على تجربة المستخدمين الحقيقيين في أعلى الصفحة:
بالنسبة إلى بيانات المختبر، تظهر مشاكل TTFB في إحصاءات وقت الاستجابة لطلب المستند:
لمزيد من المعلومات حول كيفية قياس مدة تحميل أول بايت في كل من المجال والمختبر، راجِع صفحة مقياس مدة تحميل أول بايت.
فهم الاختلافات بين بيانات الحقل وبيانات المختبر في ما يتعلّق بمدة تحميل أول بايت
يمكن أن تختلف مدة تحميل أول بايت في المختبر عن مدة تحميل أول بايت في الميدان لعدة أسباب، وعندما تختلف، من المهم فهم السبب لتتمكّن من استخدام بيانات المختبر بفعالية لتحسين تجارب المستخدمين.
عندما تكون مدة تحميل أول بايت في بيئة معملية أكبر بكثير من مدة تحميل أول بايت في بيئة ميدانية، يشير ذلك إلى أنّ البيئة المعملية مقيّدة أكثر من تجارب المستخدمين العادية. لا يشكّل ذلك مشكلة بالضرورة، لأنّ نتائج المختبر والاقتراحات تظلّ صالحة، ولكن قد تبالغ في تقدير التأثير والتحسين.
عندما تكون مدة تحميل أول بايت في الميدان أكبر بكثير من مدة تحميل أول بايت في المختبر، يشير ذلك إلى مشاكل غير ظاهرة في عملية التشغيل في المختبر، مثل استخدام التخزين المؤقت من جهة الخادم أو عمليات إعادة التوجيه أو الاختلافات في الشبكة. في هذه الحالة، قد تكون نتائج الاختبارات والتوصيات أقل فائدة، لأنّها لا تتناول إحدى المشاكل الرئيسية.
لمعرفة ما إذا كان التخزين المؤقت من جهة الخادم يؤثر في مقياس TTFB في المختبر، جرِّب اختبار صفحات أقل شيوعًا أو استخدام مَعلمات عناوين URL مختلفة للحصول على محتوى غير مخزَّن مؤقتًا لمعرفة ما إذا كان مقياس TTFB يتوافق بشكل أكبر مع مقياس TTFB في الميدان. قد يكون من المفيد أيضًا أن تتمكّن من تجاوز التخزين المؤقت من جهة الخادم باستخدام مَعلمة معيّنة لعنوان URL. يُرجى الاطّلاع على قسم المحتوى المخزَّن مؤقتًا.
بالنسبة إلى عمليات إعادة التوجيه والاختلافات في الشبكة، يمكن أن تكون إحصاءات كيفية وصول الزيارات إلى موقعنا الإلكتروني ومصدرها مفيدة لتشخيص ما إذا كانت هذه المشاكل محتملة.
تصحيح أخطاء مدة تحميل أول بايت (TTFB) العالية في الميدان باستخدام Server-Timing
يمكن استخدام عنوان الاستجابة Server-Timing في الخلفية الخاصة بتطبيقك لقياس عمليات الخلفية المختلفة التي قد تؤدي إلى زيادة وقت الاستجابة. تتسم بنية قيمة العنوان بالمرونة، وتقبل، كحد أدنى، اسم معرّف تحدّده أنت. تشمل القيم الاختيارية قيمة المدة (من خلال dur)، بالإضافة إلى وصف اختياري يمكن لشخص عادي قراءته (من خلال desc).
يمكن استخدام Serving-Timing لقياس العديد من عمليات الخلفية في التطبيق، ولكن هناك بعض العمليات التي قد تحتاج إلى إيلاء اهتمام خاص بها:
- استعلامات قاعدة البيانات
- الوقت المستغرَق للعرض من جهة الخادم، إن وُجد
- عمليات البحث في القرص
- نتائج ذاكرة التخزين المؤقت للخادم الطرفي أو عدم العثور عليها (في حال استخدام شبكة توصيل المحتوى)
يتم الفصل بين جميع أجزاء إدخال Server-Timing بنقطتين، ويمكن الفصل بين الإدخالات المتعددة بفاصلة:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
يمكن ضبط العنوان باستخدام لغة البرمجة التي تختارها في الخلفية لتطبيقك. في PHP، على سبيل المثال، يمكنك ضبط العنوان على النحو التالي:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
عند ضبط هذا العنوان، يعرض معلومات يمكنك استخدامها في كل من المختبر والميدان.
في المجال، أي صفحة تتضمّن عنوان استجابة Server-Timing تملأ السمة serverTiming في Navigation Timing API:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
في بيئة الاختبار، يتم عرض البيانات من عنوان الاستجابة Server-Timing في لوحة التوقيتات ضمن علامة التبويب الشبكة في "أدوات مطوّري البرامج في Chrome":
في هذه الحالة، يتم استخدام Server-Timing لقياس ما إذا كان طلب الحصول على مورد قد وصل إلى ذاكرة التخزين المؤقت لشبكة توصيل المحتوى، والمدة التي يستغرقها الطلب للوصول إلى خادم الحافة في شبكة توصيل المحتوى ثم إلى المصدر.
تظهر أيضًا أوقات الخادم في مسار "الشبكة" ضمن لوحة الأداء في "أدوات مطوّري البرامج في Chrome":
بعد تحديد أنّ مدة تحميل أول بايت (TTFB) غير مناسبة من خلال تحليل البيانات المتاحة، يمكنك الانتقال إلى حلّ المشكلة.
طُرق تحسين مدة تحميل أول بايت (TTFB)
إنّ الجانب الأكثر صعوبة في تحسين مدة تحميل أول بايت هو أنّه على الرغم من أنّ حزمة الواجهة الأمامية للويب تكون دائمًا HTML وCSS وJavaScript، يمكن أن تختلف حزم الواجهة الخلفية بشكل كبير. هناك العديد من حزم الخلفية ومنتجات قواعد البيانات التي يتضمّن كل منها أساليب تحسين خاصة به. لذلك، يركّز هذا الدليل على ما ينطبق على معظم البُنى، بدلاً من التركيز فقط على الإرشادات الخاصة بمجموعة معيّنة من الأدوات.
إرشادات خاصة بكل منصة
يمكن أن تؤثر المنصة التي تستخدمها لموقعك الإلكتروني بشكل كبير في مدة تحميل أول بايت (TTFB). على سبيل المثال، يتأثر أداء WordPress بعدد المكوّنات الإضافية وجودتها أو المظاهر المستخدَمة. وتتأثر المنصات الأخرى بشكل مماثل عند تخصيص المنصة. يجب الرجوع إلى مستندات المنصة التي تستخدمها للحصول على نصائح خاصة بالمورّد، وذلك بالإضافة إلى النصائح العامة حول الأداء الواردة في هذه المقالة. تتضمّن إحصاءات Lighthouse أيضًا بعض الإرشادات المحدودة الخاصة بالحزمة.
الاستضافة، الاستضافة، الاستضافة
قبل التفكير في أي أساليب أخرى لتحسين الأداء، يجب أن تكون الاستضافة هي أول ما تفكر فيه. لا تتوفّر إرشادات محدّدة يمكن تقديمها هنا، ولكن القاعدة العامة هي التأكّد من أنّ مضيف موقعك الإلكتروني قادر على التعامل مع عدد الزيارات التي ترسلها إليه.
تكون الاستضافة المشتركة أبطأ بشكل عام. إذا كنت تدير موقعًا إلكترونيًا شخصيًا صغيرًا يعرض في الغالب ملفات ثابتة، من المحتمل أن يكون هذا الخيار مناسبًا. استخدِم بعض أساليب التحسين التالية لمساعدتك في تقليل مدة تحميل أول بايت (TTFB) قدر الإمكان.
ومع ذلك، إذا كنت تدير تطبيقًا أكبر يضم العديد من المستخدمين ويتضمّن عمليات تخصيص وطلبات بحث في قاعدة البيانات وعمليات أخرى مكثّفة من جهة الخادم، يصبح اختيارك للاستضافة أمرًا بالغ الأهمية لخفض مدة تحميل أول بايت (TTFB) في المجال.
عند اختيار مقدّم خدمة استضافة، إليك بعض الأمور التي يجب الانتباه إليها:
- ما مقدار الذاكرة المخصّصة لمثيل تطبيقك؟ إذا لم تكن ذاكرة تطبيقك كافية، سيواجه صعوبة في عرض الصفحات بأسرع ما يمكن.
- هل يحرص مقدّم خدمة الاستضافة على تحديث حزمة الخلفية؟ مع إصدار نُسخ جديدة من لغات الواجهة الخلفية للتطبيقات وعمليات تنفيذ HTTP وبرامج قواعد البيانات، يتحسّن أداء هذه البرامج بمرور الوقت. من المهم التعاون مع مقدّم خدمة استضافة يمنح الأولوية لهذا النوع من الصيانة المهمة.
- إذا كانت لديك متطلبات محدّدة جدًا للتطبيق وأردت الحصول على أدنى مستوى من الوصول إلى ملفات إعداد الخادم، اسأل عما إذا كان من المنطقي تخصيص الخلفية لمثيل التطبيق الخاص بك.
هناك العديد من مقدّمي خدمات الاستضافة الذين يتولّون هذه الأمور نيابةً عنك، ولكن إذا بدأت تلاحظ قيمًا طويلة لـ TTFB حتى لدى مقدّمي خدمات الاستضافة المخصّصة، قد يكون ذلك علامة على أنّك بحاجة إلى إعادة تقييم إمكانات مقدّم خدمة الاستضافة الحالي لكي تتمكّن من تقديم أفضل تجربة ممكنة للمستخدم.
استخدام شبكة توصيل المحتوى (CDN)
موضوع استخدام شبكة توصيل المحتوى (CDN) هو موضوع شائع، ولكن لسبب وجيه: قد يكون لديك واجهة خلفية محسّنة بشكل جيد للتطبيق، ولكن قد يظل المستخدمون البعيدون عن خادمك الأصلي يواجهون مدة تحميل أول بايت (TTFB) عالية في المجال.
تحلّ شبكات توصيل المحتوى مشكلة قرب المستخدم من خادم المصدر من خلال استخدام شبكة موزّعة من الخوادم التي تخزّن الموارد مؤقتًا على خوادم أقرب فعليًا إلى المستخدمين. وتُعرف هذه الخوادم باسم خوادم الحافة.
قد يقدّم موفّرو شبكات CDN أيضًا مزايا تتجاوز خوادم Edge:
- عادةً ما يوفّر مقدّمو خدمات شبكة توصيل المحتوى (CDN) أوقاتًا سريعة للغاية للتحويل باستخدام نظام أسماء النطاقات (DNS).
- من المرجّح أن تعرض شبكة توصيل المحتوى (CDN) المحتوى الخاص بك من خوادم حافة باستخدام بروتوكولات حديثة، مثل HTTP/2 أو HTTP/3.
- يحلّ بروتوكول HTTP/3 على وجه الخصوص مشكلة حظر رأس السطر الموجودة في بروتوكول TCP (الذي يعتمد عليه HTTP/2) باستخدام بروتوكول UDP.
- من المرجّح أن توفّر شبكة توصيل المحتوى إصدارات حديثة من بروتوكول أمان طبقة النقل (TLS)، ما يقلّل من وقت الاستجابة في وقت التفاوض على بروتوكول أمان طبقة النقل (TLS). تم تصميم الإصدار 1.3 من بروتوكول أمان طبقة النقل (TLS) على وجه الخصوص لإبقاء تفاوض بروتوكول أمان طبقة النقل (TLS) قصيرًا قدر الإمكان.
- يوفّر بعض مزوّدي شبكات توصيل المحتوى ميزة تُعرف غالبًا باسم "عامل الحافة"، والتي تستخدم واجهة برمجة تطبيقات مشابهة لواجهة Service Worker API لاعتراض الطلبات أو إدارة الردود آليًا في ذاكرة التخزين المؤقت للحافة أو إعادة كتابة الردود بالكامل.
- يُعدّ مقدّمو خدمات شبكة توصيل المحتوى (CDN) بارعين جدًا في تحسين الضغط. من الصعب تنفيذ عملية الضغط بشكل صحيح بنفسك، وقد يؤدي ذلك إلى بطء أوقات الاستجابة في بعض الحالات التي يتم فيها إنشاء ترميز ديناميكي، والذي يجب ضغطه بسرعة.
- بالإضافة إلى ذلك، يخزّن مقدّمو خدمات شبكة توصيل المحتوى (CDN) تلقائيًا الردود المضغوطة للموارد الثابتة، ما يؤدي إلى أفضل مزيج من نسبة الضغط ووقت الاستجابة.
على الرغم من أنّ استخدام شبكة توصيل المحتوى يتطلّب قدرًا متفاوتًا من الجهد يتراوح بين البسيط والكبير، يجب أن يكون له أولوية عالية في تحسين مدة تحميل أول بايت إذا لم يكن موقعك الإلكتروني يستخدم هذه الشبكة.
استخدام المحتوى المخزَّن مؤقتًا حيثما أمكن
تسمح شبكات توصيل المحتوى بتخزين المحتوى مؤقتًا في خوادم الحافة التي تقع فعليًا بالقرب من الزوّار، شرط أن يتم ضبط المحتوى باستخدام عناوين HTTP Cache-Control المناسبة. على الرغم من أنّ هذا الإجراء غير مناسب للمحتوى المخصّص، فإنّ طلب العودة إلى المصدر يمكن أن يلغي جزءًا كبيرًا من قيمة شبكة توصيل المحتوى (CDN).
بالنسبة إلى المواقع الإلكترونية التي تعدّل محتواها بشكل متكرّر، حتى فترة التخزين المؤقت القصيرة يمكن أن تؤدي إلى تحسينات ملحوظة في الأداء للمواقع الإلكترونية المزدحمة، لأنّ الزائر الأول فقط خلال تلك الفترة يواجه وقت الاستجابة الكامل للعودة إلى الخادم الأصلي، بينما يمكن لجميع الزائرين الآخرين إعادة استخدام المورد المخزَّن مؤقتًا من خادم الحافة. تسمح بعض شبكات توصيل المحتوى بإيقاف التخزين المؤقت في إصدارات المواقع الإلكترونية، ما يتيح الاستفادة من الميزتَين، أي فترات التخزين المؤقت الطويلة والتحديثات الفورية عند الحاجة.
حتى في حال ضبط التخزين المؤقت بشكل صحيح، يمكن تجاهل ذلك من خلال استخدام مَعلمات سلسلة طلبات بحث فريدة لقياس الإحصاءات. قد تبدو هذه الطلبات مختلفة بالنسبة إلى شبكة توصيل المحتوى على الرغم من أنّها متطابقة، وبالتالي لن يتم استخدام النسخة المخزّنة مؤقتًا.
وقد لا يتم أيضًا تخزين المحتوى القديم أو الأقل زيارة في الذاكرة المؤقتة، ما قد يؤدي إلى ارتفاع قيم TTFB في بعض الصفحات مقارنةً بغيرها. يمكن أن تؤدي زيادة أوقات التخزين المؤقت إلى تقليل تأثير ذلك، ولكن يُرجى العِلم أنّ زيادة أوقات التخزين المؤقت تزيد من احتمالية عرض محتوى قديم.
لا يقتصر تأثير المحتوى المخزّن مؤقتًا على مستخدمي شبكات توصيل المحتوى (CDN). قد تحتاج البنية الأساسية للخادم إلى إنشاء محتوى من عمليات بحث مكلفة في قاعدة البيانات عندما يتعذّر إعادة استخدام المحتوى المخزَّن مؤقتًا. غالبًا ما يكون أداء البيانات التي يتم الوصول إليها بشكل متكرر أو الصفحات المخزّنة مؤقتًا أفضل.
تجنُّب عمليات إعادة توجيه الصفحات المتعدّدة
عمليات إعادة التوجيه هي أحد العوامل الشائعة التي تؤدي إلى ارتفاع مدة تحميل أول بايت (TTFB). تحدث عمليات إعادة التوجيه عندما يتلقّى طلب التنقّل في مستند ردًا يُعلم المتصفّح بأنّ المرجع موجود في موقع جغرافي آخر. يمكن أن تؤدي عملية إعادة توجيه واحدة بالتأكيد إلى زيادة وقت الاستجابة غير المرغوب فيه لطلب التنقّل، ولكن يمكن أن يزداد الأمر سوءًا إذا كانت عملية إعادة التوجيه هذه تشير إلى مورد آخر يؤدي إلى عملية إعادة توجيه أخرى، وهكذا. ويمكن أن يؤثر ذلك بشكل خاص في المواقع الإلكترونية التي تتلقّى أعدادًا كبيرة من الزوّار من الإعلانات أو النشرات الإخبارية، لأنّها غالبًا ما تعيد التوجيه من خلال خدمات الإحصاءات لأغراض القياس. يمكن أن يساعد التخلّص من عمليات إعادة التوجيه التي تخضع لسيطرتك المباشرة في تحقيق مدة تحميل أول بايت جيدة.
هناك نوعان من عمليات إعادة التوجيه:
- عمليات إعادة التوجيه من المصدر نفسه، حيث تتم عملية إعادة التوجيه بالكامل على موقعك الإلكتروني.
- عمليات إعادة التوجيه المتعدّدة المصادر، حيث تتم إعادة التوجيه في البداية على مصدر آخر، مثل خدمة تقصير عناوين URL على وسائل التواصل الاجتماعي، قبل الوصول إلى موقعك الإلكتروني.
ركِّز على التخلص من عمليات إعادة التوجيه من المصدر نفسه، لأنّ هذا أمر يمكنك التحكّم فيه مباشرةً. يتضمن ذلك التحقّق من الروابط على موقعك الإلكتروني لمعرفة ما إذا كان أي منها يؤدي إلى رمز الاستجابة 302 أو 301. غالبًا ما يكون ذلك نتيجة عدم تضمين المخطط https:// (لذلك تستخدم المتصفحات تلقائيًا http:// الذي يعيد التوجيه بعد ذلك) أو بسبب عدم تضمين الشرطات المائلة اللاحقة أو استبعادها بشكل مناسب في عنوان URL.
تكون عمليات إعادة التوجيه المتعدّدة المصادر أكثر صعوبة لأنّها غالبًا ما تكون خارج نطاق سيطرتك، ولكن حاوِل تجنُّب عمليات إعادة التوجيه المتعدّدة حيثما أمكن، على سبيل المثال، باستخدام أدوات متعدّدة لتقصير الروابط عند مشاركة الروابط. تأكَّد من أنّ عنوان URL المقدَّم للمعلِنين أو النشرات الإخبارية هو عنوان URL النهائي الصحيح، وذلك لعدم إضافة عملية إعادة توجيه أخرى إلى تلك التي تستخدمها هذه الخدمات.
ومن المصادر المهمة الأخرى لوقت إعادة التوجيه عمليات إعادة التوجيه من HTTP إلى HTTPS. يمكنك تجنُّب هذه المشكلة باستخدام عنوان Strict-Transport-Security (HSTS) الذي يفرض استخدام HTTPS عند الزيارة الأولى لمصدر معيّن، ثم يطلب من المتصفّح الوصول فورًا إلى المصدر من خلال نظام HTTPS في الزيارات المستقبلية.
بعد وضع سياسة HSTS جيدة، يمكنك تسريع الأمور في الزيارة الأولى إلى المصدر من خلال إضافة موقعك الإلكتروني إلى قائمة التحميل المُسبق لسياسة HSTS.
عرض الترميز تدريجيًا في المتصفّح
يتم تحسين المتصفّحات لمعالجة الترميز بكفاءة عند بثّه، ما يعني أنّه تتم معالجة الترميز في أجزاء عند وصوله من الخادم. وهذا أمر بالغ الأهمية في ما يتعلّق بحمولات الترميز الكبيرة، لأنّه يعني أنّ المتصفّح يمكنه تحليل أجزاء الترميز بشكل تدريجي، بدلاً من انتظار وصول الردّ بالكامل قبل بدء التحليل.
على الرغم من أنّ المتصفّحات رائعة في التعامل مع ترميز البث، من المهم بذل كل ما في وسعك للحفاظ على تدفق هذا البث حتى تصل هذه الأجزاء الأولية من الترميز في أقرب وقت ممكن. إذا كانت الخلفية تعيق الأمور، فهذه مشكلة. بما أنّ حِزم الخلفية عديدة، لن يتناول هذا الدليل كل حزمة والمشاكل التي قد تنشأ في كل حزمة محدّدة.
على سبيل المثال، تستخدم React وأُطر العمل الأخرى التي يمكنها عرض الترميز عند الطلب على الخادم نهجًا متزامنًا للعرض من جهة الخادم. ومع ذلك، نفّذت الإصدارات الأحدث من React طرق الخادم لترميز البث أثناء عرضه. هذا يعني أنّه ليس عليك الانتظار حتى تنتهي طريقة واجهة برمجة التطبيقات في خادم React من عرض الردّ بالكامل قبل إرساله.
هناك طريقة أخرى لضمان بث الترميز إلى المتصفّح بسرعة، وهي الاعتماد على العرض الثابت الذي ينشئ ملفات HTML أثناء وقت الإنشاء. بما أنّ الملف الكامل متاح على الفور، يمكن لخوادم الويب البدء في إرسال الملف على الفور، وتؤدي الطبيعة المتأصلة لبروتوكول HTTP إلى ترميز البث. على الرغم من أنّ هذا النهج ليس مناسبًا لكل صفحة على كل موقع إلكتروني، مثل تلك التي تتطلب استجابة ديناميكية كجزء من تجربة المستخدم، إلا أنّه يمكن أن يكون مفيدًا لتلك الصفحات التي لا تتطلب تخصيص الترميز لمستخدم معيّن.
استخدام مشغِّل خدمات
يمكن أن يكون لواجهة Service Worker API تأثير كبير في مدة تحميل أول بايت (TTFB) لكل من المستندات والموارد التي يتم تحميلها. والسبب في ذلك هو أنّ مشغّل الخدمات يعمل كخادم وكيل بين المتصفّح والخادم، ولكن يعتمد تأثيره في مدة تحميل أول بايت (TTFB) لموقعك الإلكتروني على كيفية إعداد مشغّل الخدمات، وما إذا كان هذا الإعداد يتوافق مع متطلبات تطبيقك.
- استخدِم استراتيجية stale-while-revalidate لمواد العرض. إذا كان أحد مواد العرض في ذاكرة التخزين المؤقت لمشغّل الخدمات، سواء كان مستندًا أو موردًا يتطلبه المستند، فإنّ استراتيجية stale-while-revalidate تعرض هذا المورد من ذاكرة التخزين المؤقت أولاً، ثم تنزّل مادة العرض هذه في الخلفية وتعرضها من ذاكرة التخزين المؤقت للتفاعلات المستقبلية.
- إذا كانت لديك موارد مستندات لا تتغيّر كثيرًا، يمكن أن يؤدي استخدام استراتيجية stale-while-revalidate إلى جعل مدة تحميل أول بايت (TTFB) للصفحة فورية تقريبًا. ومع ذلك، لا يعمل هذا بشكل جيد إذا كان موقعك الإلكتروني يرسل ترميزًا يتم إنشاؤه ديناميكيًا، مثل الترميز الذي يتغير بناءً على ما إذا تمت مصادقة المستخدم. في هذه الحالات، عليك دائمًا الوصول إلى الشبكة أولاً، ليكون المستند حديثًا قدر الإمكان.
- إذا كان المستند يحمّل موارد غير مهمة تتغيّر بشكل متكرر، ولكن جلب المورد القديم لن يؤثر بشكل كبير في تجربة المستخدم، مثل اختيار صور أو موارد أخرى غير مهمة، يمكن تقليل مدة تحميل أول بايت (TTFB) لهذه الموارد بشكل كبير باستخدام استراتيجية stale-while-revalidate.
- استخدِم نموذج هيكل التطبيق للتطبيقات التي يتم عرضها من جهة العميل. هذا النموذج هو الأنسب لتطبيقات الصفحة الواحدة (SPA) التي يمكن فيها عرض "هيكل" الصفحة على الفور من ذاكرة التخزين المؤقت لمشغّل الخدمات، ويتم ملء المحتوى الديناميكي للصفحة وعرضه لاحقًا في مراحل نشاط الصفحة.
استخدام 103 Early Hints للموارد المهمة للعرض
بغض النظر عن مدى تحسين الخلفية في تطبيقك، قد يظل هناك قدر كبير من العمل الذي يحتاج الخادم إلى القيام به من أجل إعداد استجابة، بما في ذلك عمل قاعدة البيانات المكلف (ولكنه ضروري) الذي يؤخر وصول استجابة التنقل بأسرع ما يمكن. قد يؤدي ذلك إلى تأخير بعض الموارد اللاحقة المهمة للعرض، مثل CSS أو JavaScript في بعض الحالات التي تعرض الترميز على العميل.
العنوان 103 Early Hints هو رمز استجابة مبكر يمكن للخادم إرساله إلى المتصفّح عندما تكون الخلفية مشغولة بإعداد الترميز. يمكن استخدام هذا العنوان لتنبيه المتصفّح إلى أنّ هناك موارد مهمة للعرض يجب أن تبدأ الصفحة في تنزيلها أثناء إعداد الترميز. بالنسبة إلى المتصفّحات المتوافقة، يمكن أن يكون التأثير هو عرض المستندات بشكل أسرع (CSS) وتحميل الصفحات بشكل أسرع.
من سلبيات الرمز 103 Early Hints أنّه، مثل التخزين المؤقت، يمكن أن يخفي مدة تحميل أول بايت "الحقيقية" للموقع الإلكتروني. إذا كانت البنية الأساسية للخادم بطيئة (إما لأنّها ضعيفة أو لأنّ الرمز البرمجي يحتاج إلى تحسين)، قد يكون ذلك أقل وضوحًا عند استخدام الرمز 103 Early Hints لأنّ مدة تحميل أول بايت (TTFB) تبدو سريعة. على المواقع الإلكترونية التي تستخدم الرمز 103 Early Hints قياس وقت الخادم الفعلي (من خلال Server-Timing أو finalResponseHeadersStart من واجهة برمجة التطبيقات PerformanceNavigationTiming).
الخاتمة
بما أنّ هناك العديد من المجموعات من حِزم التطبيقات في الخلفية، لا توجد مقالة واحدة يمكنها تلخيص كل ما يمكنك فعله لخفض مدة تحميل أول بايت لموقعك الإلكتروني. ومع ذلك، هذه بعض الخيارات التي يمكنك استكشافها لمحاولة تسريع الأمور قليلاً على جانب الخادم.
كما هو الحال مع تحسين كل مقياس، فإنّ النهج متشابه إلى حد كبير: يمكنك قياس مدة تحميل أول بايت في الميدان، واستخدام أدوات التمرين العملي للتعمّق في الأسباب، ثم تطبيق التحسينات حيثما أمكن. على الرغم من أنّ بعض الأساليب قد لا تكون مناسبة لحالتك، من المرجّح أن يكون بعضها الآخر مناسبًا. كما هو الحال دائمًا، عليك مراقبة بياناتك الميدانية عن كثب وإجراء التعديلات اللازمة لضمان تقديم أسرع تجربة مستخدم ممكنة.