تعرَّف على كيفية تحسين مقياس "وقت وصول أول بايت".
مقياس وقت وصول أول بايت (TTFB) هو مقياس أساسي لأداء الويب يسبق كل مقياس آخر مفيد لتجربة المستخدم، مثل سرعة عرض أول محتوى مرئي (FCP) وسرعة عرض أكبر محتوى مرئي (LCP). وهذا يعني أن قيم TTFB العالية تضيف وقتًا إلى المقاييس التي تتبعها.
ننصح بأن يستجيب الخادم لطلبات التنقّل بسرعة كافية بحيث تصل الشريحة المئوية الخامسة والسبعين من المستخدمين إلى سرعة عرض المحتوى على الصفحة ضمن الحدّ الأدنى "جيد". كدليل تقريبي، يجب أن تسعى معظم المواقع الإلكترونية إلى أن تسعى معظم المواقع الإلكترونية إلى أن تكون نسبة تحويل النص إلى كلام 0.8 ثانية أو أقل.
كيفية قياس TTFB
قبل أن تتمكّن من تحسين TTFB، تحتاج إلى معرفة مدى تأثيره في مستخدمي موقعك الإلكتروني. عليك الاعتماد على البيانات الفعلية كمصدر أساسي لرصد "تحويل النص إلى كلام" لأنّها تتأثر بعمليات إعادة التوجيه، في حين أنّ الأدوات المستنِدة إلى المختبرات تُقاس غالبًا باستخدام رابط عنوان URL النهائي، وبالتالي تفوتها هذه المدة الإضافية.
إحصاءات PageSpeed هي إحدى الطرق للحصول على معلومات كل من الحقول والمختبرات للمواقع الإلكترونية المتاحة للجميع والمتاحة في تقرير تجربة المستخدم على Chrome.
يتم عرض مؤشر TTFB للمستخدمين الفعليين في أعلى قسم اكتشاف ما يواجهه المستخدمون الحقيقيون:
يتم عرض مجموعة فرعية من TTFB في تدقيق وقت استجابة الخادم:
لمعرفة المزيد من طرق قياس TTFB في كل من الحقل والمختبر، يمكنك الاطّلاع على صفحة مقياس TTFB.
تصحيح أخطاء TTFB المرتفعة في الحقل باستخدام Server-Timing
يمكن استخدام عنوان الاستجابة Server-Timing في خلفية التطبيق لقياس العمليات المختلفة في الخلفية التي يمكن أن تساهم في زيادة وقت الاستجابة. بنية قيمة العنوان مرنة ومقبولة على الأقل اسم معرِّف تحدّده. تتضمن القيم الاختيارية قيمة مدة (عبر dur)، بالإضافة إلى وصف اختياري يمكن للمستخدمين قراءته (عبر desc).
يمكن استخدام Serving-Timing لقياس العديد من العمليات في الخلفية للتطبيقات، ولكن هناك بعض العمليات التي يجب التركيز عليها بشكل خاص:
- استعلامات قاعدة البيانات
- مدة العرض من جهة الخادم، إذا كان ذلك منطبقًا
- البحث في القرص
- نتائج/إخفاق ذاكرة التخزين المؤقت لخادم Edge (في حالة استخدام شبكة توصيل المحتوى)
يتم الفصل بين جميع أجزاء إدخال 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 - $dbReadStarTime) / 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". ويتم استخدام Server-Timing هنا لقياس ما إذا كان طلب مورد قد وصل إلى ذاكرة التخزين المؤقت لشبكة توصيل المحتوى (CDN)، والمدة التي يستغرقها وصول الطلب إلى خادم Edge الخاص بشبكة توصيل المحتوى (CDN) ثم الوصول إلى المصدر.
بمجرد أن تكتشف أن لديك مشكلة في TTFB من خلال تحليل البيانات المتاحة، يمكنك الانتقال إلى إصلاح المشكلة.
طرق تحسين TTFB
يتمثل الجانب الأكثر صعوبة في تحسين TTFB في أنه على الرغم من أن مكدس الواجهة الأمامية للويب ستكون دائمًا HTML وCSS وJavaScript، يمكن أن تختلف حزم الخلفية بشكل كبير. هناك العديد من حزم الخلفية ومنتجات قاعدة البيانات التي ولكل منها أساليب التحسين الخاصة به. لذلك، سيركز هذا الدليل على ما ينطبق على معظم البُنى، بدلاً من التركيز فقط على الإرشادات الخاصة بالحزمة.
إرشادات متعلّقة بنظام التشغيل
يمكن للمنصة التي تستخدمها لموقعك الإلكتروني أن تؤثر بشكل كبير في TFB. على سبيل المثال، يتأثر أداء WordPress بعدد المكوّنات الإضافية وجودتها، أو المظاهر المستخدَمة. وتتأثر الأنظمة الأساسية الأخرى بطريقة مماثلة عندما يتم تخصيص النظام الأساسي. يجب الرجوع إلى وثائق نظامك الأساسي للحصول على نصائح خاصة بالبائعين لإكمال نصائح الأداء الأكثر عمومية في هذه المشاركة. تتضمّن عملية تدقيق Lighthouse الخاصة بتقليل أوقات استجابة الخادم أيضًا بعض الإرشادات المحدودة الخاصة بالحزمة.
خدمات الاستضافة والاستضافة والاستضافة
وقبل التفكير في أساليب تحسين أخرى، يجب أن تكون الاستضافة أول ما تفكر فيه. ليس هناك قدر كبير من الإرشادات المحدّدة التي يمكن تقديمها هنا، ولكن القاعدة العامة هي ضمان أن يكون مضيف موقعك الإلكتروني قادرًا على التعامل مع الزيارات التي تُرسلها إليه.
وتكون الاستضافة المشتركة أبطأ بشكل عام. إذا كنت تدير موقعًا إلكترونيًا شخصيًا صغيرًا يعرض ملفات ثابتة في الغالب، لا بأس في ذلك، وستساعدك بعض أساليب التحسين التي تتبعها في التخلص من هذه المشكلة قدر الإمكان.
ومع ذلك، إذا كنت تشغل تطبيقًا أكبر حجمًا والعديد من المستخدمين تتضمن التخصيص والاستعلام عن قاعدة البيانات وغيرها من العمليات المكثّفة من جانب الخادم، يصبح اختيارك للاستضافة أمرًا ملحًا لخفض مقدار تحويل النص إلى كلام (TTFB) في هذا المجال.
عند اختيار مستضيف، يجب أن تراعي بعض النقاط التالية:
- ما مقدار الذاكرة التي يتم تخصيص مثيل التطبيق الخاص بك فيها؟ إذا كانت ذاكرة التطبيق غير كافية، فسيتعطش ويواجه صعوبة في عرض الصفحات بأقصى سرعة.
- هل يواصل المستضيف تحديث حزمة الخلفية؟ ومع طرح إصدارات جديدة من لغات الخلفية للتطبيق وعمليات تنفيذ HTTP وبرامج قواعد البيانات، سيتحسن أداء هذه البرامج بمرور الوقت. ومن المهم التعاون مع مستضيف يمنح الأولوية لهذا النوع من الصيانة المهمة.
- إذا كانت لديك متطلبات تطبيق محدَّدة جدًا وتريد الوصول بأدنى مستوى إلى ملفات إعداد الخادم، اسأل عما إذا كان من المفيد تخصيص الواجهة الخلفية لمثيل التطبيق الخاص بك.
هناك العديد من المستضيفين الذين سيهتمون بهذه الأمور، ولكن إذا بدأت في ملاحظة قيم TTFB الطويلة حتى في المستضيف المخصص، قد يشير ذلك إلى أنك قد تحتاج إلى إعادة تقييم إمكانات المستضيف الحالي حتى تتمكن من تقديم أفضل تجربة ممكنة للمستخدم.
استخدام شبكة توصيل المحتوى (CDN)
يعد موضوع استخدام شبكة توصيل المحتوى (CDN) موضوعًا جيدًا، ولكن لسبب وجيه: قد تكون لديك خلفية تطبيق محسّنة بشكل جيد، ولكن قد يظلّ لدى المستخدمين البعيدين عن خادم المصدر لديك مشكلة بمعدّل كبير في الوقت الفعلي (TTFB) في الحقل.
تحل شبكات توصيل المحتوى (CDN) مشكلة تقارب المستخدم من خادم المصدر باستخدام شبكة موزَّعة من الخوادم التي تخزن الموارد في خوادم أقرب إلى المستخدمين فعليًا. وتُسمى هذه الخوادم الخوادم الهامشية.
قد يقدم موفرو شبكة توصيل المحتوى (CDN) أيضًا مزايا تتجاوز الخوادم الهامشية:
- عادةً ما يوفر موفرو شبكة توصيل المحتوى (CDN) أوقات حل نظام أسماء النطاقات (DNS) سريعة للغاية.
- من المحتمل أن تعرض شبكة توصيل المحتوى المحتوى الخاص بك من خوادم Edge باستخدام بروتوكولات حديثة مثل HTTP/2 أو HTTP/3.
- يعمل HTTP/3 على وجه الخصوص على حل مشكلة حظر العنوان العامة في بروتوكول TCP (التي يعتمد عليها HTTP/2) من خلال استخدام بروتوكول UDP.
- ومن المحتمل أن توفر شبكة توصيل المحتوى (CDN) أيضًا إصدارات حديثة من بروتوكول أمان طبقة النقل (TLS)، ما يقلل من وقت الاستجابة المتضمنة في وقت تفاوض بروتوكول أمان طبقة النقل (TLS). تم تصميم الإصدار 1.3 من بروتوكول أمان طبقة النقل على وجه الخصوص للحفاظ على تفاوض بروتوكول أمان طبقة النقل قدر الإمكان.
- يقدم بعض موفري شبكات توصيل المحتوى (CDN) ميزة تُعرف غالبًا باسم "العامل المتطور"، تستخدم واجهة برمجة تطبيقات مشابهة لتلك الخاصة بواجهة برمجة تطبيقات Service Worker API لاعتراض الطلبات أو الإدارة الآلية للردود في ذاكرات التخزين المؤقت على الحافة أو إعادة كتابة الاستجابات كليًا.
- موفرو شبكات توصيل المحتوى (CDN) بارعون جدًا في تحسين عملية الضغط. من الصعب تنفيذ عملية الضغط بشكل صحيح، وقد يؤدي ذلك إلى حدوث بطء في أوقات الاستجابة في بعض الحالات باستخدام الترميز الذي يتم إنشاؤه ديناميكيًا، والذي يجب ضغطه بشكل سريع.
- وسيقوم موفرو شبكة توصيل المحتوى (CDN) أيضًا بتخزين الاستجابات المضغوطة مؤقتًا للموارد الثابتة، مما يؤدي إلى أفضل مزيج من نسبة الضغط ووقت الاستجابة.
في حين أن استخدام شبكة توصيل المحتوى يتضمن قدرًا متفاوتًا من الجهد من التافه إلى الكبير، إلا أنه يجب أن تكون أولوية عالية لتحسين هذا المنهج إذا كان موقعك على الويب لا يستخدم واحدًا بالفعل.
استخدام المحتوى المخزن مؤقتًا متى أمكن
تسمح شبكات توصيل المحتوى (CDN) بتخزين المحتوى مؤقتًا على خوادم الحافة التي تكون أقرب فعليًا من الزوّار، بشرط أن يتم إعداد المحتوى باستخدام عناوين HTTP Cache-Control المناسبة. وعلى الرغم من أنّ ذلك لا يُعدّ مناسبًا للمحتوى المخصّص، فإنّ طلب رحلة العودة إلى المصدر قد ينفي الكثير من قيمة شبكة توصيل المحتوى (CDN).
بالنسبة إلى المواقع الإلكترونية التي تعدِّل المحتوى بشكل متكرر، يمكن أن يؤدي التخزين المؤقت لفترة قصيرة إلى تحقيق مكاسب ملحوظة في أداء المواقع الإلكترونية المزدحمة، لأنّ الزائر الأول فقط خلال تلك الفترة لا يجرِّب وقت الاستجابة الكامل للعودة إلى خادم المصدر، في حين يمكن لجميع الزوّار الآخرين إعادة استخدام المورد المخزَّن مؤقتًا من خادم Edge. تتيح بعض شبكات توصيل المحتوى (CDN) إيقاف ذاكرة التخزين المؤقت على إصدارات المواقع الإلكترونية، ما يتيح لك تنفيذ أفضل ما في الأمرين، وهو أوقات طويلة لذاكرة التخزين المؤقت، مع إمكانية إجراء تحديثات فورية عند الحاجة.
وحتى في حال ضبط التخزين المؤقت بشكل صحيح، يمكن تجاهل ذلك من خلال استخدام مَعلمات سلسلة طلب البحث الفريدة لقياس أداء "إحصاءات Google". وقد يبدو هذا المحتوى مختلفًا عن شبكة توصيل المحتوى (CDN) على الرغم من تطابقه، وبالتالي لن يتم استخدام النسخة المخزَّنة مؤقتًا.
وقد لا يتم أيضًا التخزين المؤقت للمحتوى الأقدم أو الأقل زيارة، ما قد يؤدي إلى زيادة قيم TTFB في بعض الصفحات عن غيرها. يمكن أن تؤدي زيادة أوقات التخزين المؤقت إلى تقليل تأثير ذلك، ولكن انتبه إلى أنه مع زيادة أوقات التخزين المؤقت، تزداد احتمالية عرض محتوى يُحتمل أن يكون قديمًا.
لا يؤثر تأثير المحتوى المُخزَّن مؤقتًا في مستخدمي شبكات توصيل المحتوى (CDN) فقط. قد تحتاج البنية الأساسية للخادم إلى إنشاء محتوى من عمليات البحث المكلفة في قاعدة البيانات عندما لا يمكن إعادة استخدام المحتوى المخزَّن مؤقتًا. وغالبًا ما تحقق البيانات التي يتم الوصول إليها أكثر أو الصفحات المخزّنة مؤقتًا أداءً أفضل.
تجنُّب عمليات إعادة توجيه الصفحات المتعدّدة
من بين العوامل الشائعة التي تساهم في ارتفاع كبير في عدد النقرات على Shorts هي عمليات إعادة التوجيه. تحدث عمليات إعادة التوجيه عندما يتلقى طلب تنقل لمستند استجابة تعلم المتصفح بوجود المورد في موقع آخر. من المؤكد أن عملية إعادة التوجيه الواحدة يمكن أن تضيف وقت استجابة غير مرغوب فيه إلى طلب التنقل، ولكنها قد تزداد سوءًا إذا أشارت عملية إعادة التوجيه إلى مورد آخر يؤدي إلى إعادة توجيه أخرى، وما إلى ذلك. ويمكن أن يؤثر ذلك بشكل خاص في المواقع الإلكترونية التي تستقبل أعدادًا كبيرة من الزائرين من الإعلانات أو النشرات الإخبارية، حيث تعيد التوجيه غالبًا من خلال خدمات الإحصاءات لأغراض القياس. من خلال إزالة عمليات إعادة التوجيه التي تخضع لسيطرتك المباشرة، يمكن أن يساعدك ذلك على تحقيق هدف TFB بشكل جيد.
هناك نوعان من عمليات إعادة التوجيه:
- عمليات إعادة التوجيه من المصدر نفسه، حيث تتم إعادة التوجيه بالكامل على موقعك الإلكتروني.
- عمليات إعادة التوجيه من مصادر متعددة، والتي تتم فيها عملية إعادة التوجيه في البداية من مصدر آخر، مثل خدمة تقصير عناوين 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 لكل من المستندات والموارد التي يتم تحميلها. ويعود السبب في ذلك إلى أنّ مشغّل الخدمات يعمل كخادم وكيل بين المتصفّح والخادم، ولكن يعتمد ما إذا كان هناك تأثير في TFB على موقعك الإلكتروني على طريقة إعداد مشغّل الخدمات وما إذا كان هذا الإعداد يتوافق مع متطلبات تطبيقك.
- استخدِم استراتيجية قديمة أثناء إعادة التحقّق لمواد العرض. إذا كانت مادة العرض في ذاكرة التخزين المؤقت لمشغّل الخدمات، سواء كانت مستندًا أو موردًا يتطلبه المستند، ستعمل الاستراتيجية القديمة أثناء إعادة التحقّق على استخدام هذا المورد من ذاكرة التخزين المؤقت أولاً، ثم تنزيل مادة العرض هذه في الخلفية وعرضها من ذاكرة التخزين المؤقت للتفاعلات المستقبلية.
- إذا كانت لديك موارد مستندات لا تتغير كثيرًا، فإن استخدام استراتيجية قديمة أثناء إعادة التحقق يمكن أن يجعل من TTFB الصفحة فوريًا تقريبًا. يُرجى العلم أنّ هذا الإجراء لن ينجح إذا كان موقعك الإلكتروني يرسل ترميزًا تم إنشاؤه ديناميكيًا، مثل الترميز الذي يتغيّر استنادًا إلى ما إذا كان المستخدم قد تمت مصادقته. في مثل هذه الحالات، ستحتاج دائمًا إلى النقر على الشبكة أولاً، بحيث يكون المستند حديثًا قدر الإمكان.
- إذا كان المستند يحمِّل موارد غير مهمة تتغير بمعدل تكرار معيّن، إلا أن استرجاع المورد القديم لن يؤثر بشكل كبير في تجربة المستخدم، مثل اختيار الصور أو الموارد الأخرى غير المهمة، فيمكن تقليل مقدار TFB لتلك الموارد إلى حد كبير باستخدام استراتيجية قديمة أثناء إعادة التحقق.
- استخدِم نموذج هيكل التطبيق مع التطبيقات التي يعرضها العميل. ويتناسب هذا النموذج على نحو أفضل مع منتجعات التطبيقات الأساسية (SPA) حيث يمكن عرض "هيكل" الصفحة فورًا من ذاكرة التخزين المؤقت لمشغِّل الخدمات، ويتم تعبئة المحتوى الديناميكي للصفحة وعرضه لاحقًا في دورة حياة الصفحة.
استخدام 103 Early Hints للموارد المهمة للعرض
بغض النظر عن مدى جودة تحسين الواجهة الخلفية للتطبيق، لا يزال هناك قدر كبير من العمل الذي يحتاج الخادم للقيام به من أجل إعداد استجابة، بما في ذلك عمل قاعدة البيانات المكلف (ولكن ضروريًا) الذي يؤخر استجابة التنقل في الوصول بأسرع ما يمكن. وقد يتمثّل التأثير المحتمل لذلك في احتمال تأخر بعض الموارد التالية المهمة للعرض، مثل CSS أو في بعض الحالات، JavaScript الذي يعرض الترميز على البرنامج.
العنوان 103 Early Hints هو رمز استجابة مبكّر يمكن للخادم إرساله إلى المتصفّح أثناء انشغال الخلفية بإعداد الترميز. ويمكن استخدام هذا العنوان للإشارة إلى المتصفّح بوجود موارد مهمة يجب أن تبدأ الصفحة في تنزيلها أثناء إعداد الترميز. وبالنسبة إلى المتصفّحات المتوافقة، قد يكون التأثير عبارة عن عرض أسرع للمستندات (CSS) وتوفُّر وظيفة الصفحة الأساسية (JavaScript) بشكل أسرع.
الخلاصة
نظرًا لوجود العديد من مجموعات حزم التطبيقات في الخلفية، فلا توجد مقالة واحدة يمكن أن تلخّص كل ما يمكنك فعله لخفض مقدار TFB على موقعك الإلكتروني. ومع ذلك، هذه بعض الخيارات التي يمكنك استكشافها لمحاولة تنفيذ الأمور بشكل أسرع قليلاً من جانب الخادم.
وكما هو الحال مع تحسين كل مقياس، هناك نهج مشابه إلى حد كبير: يجب قياس الإبداع في المجال باستخدام الأدوات المعملية للتعمق في الأسباب، ثم تطبيق التحسينات حيثما أمكن. قد لا يكون كل أسلوب فردي هنا صالحًا لموقفك، ولكن البعض الآخر سيكون كذلك. ستحتاج دائمًا إلى متابعة بيانات مجالك عن كثب وإجراء التعديلات حسب الحاجة لضمان أسرع تجربة ممكنة للمستخدم.
صورة رئيسية من إعداد تايلور فيك، مصدرها Unسباش.