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