تحسين الوقت المطلوب للوصول إلى أول بايت

تعرَّف على كيفية تحسين مقياس "مدة تحميل أول بايت".

Jeremy Wagner

Barry Pollard

وقت الاستجابة لأول بايت (TTFB) هو مقياس أساسي لأداء الويب يسبق كل مقياس آخر ذي أهمية لتجربة المستخدم، مثل سرعة عرض المحتوى على الصفحة (FCP) وسرعة عرض أكبر محتوى مرئي (LCP). وهذا يعني أنّ القيم العالية لمقياس TTFB تضيف وقتًا إلى المقاييس التي تليه.

ننصحك بأن يستجيب خادمك لطلبات التنقّل بسرعة كافية كي يحصل %75 من المستخدمين على قيمة FCP ضمن الحدّ "الجيد". كدليل تقريبي، يجب أن تسعى معظم المواقع الإلكترونية إلى أن يكون وقت استجابة خادمها 0.8 ثانية أو أقل.

كيفية قياس وقت وصول أول بايت

قبل أن تتمكّن من تحسين وقت استجابة خادم الويب، عليك مراقبة تأثيره في مستخدمي موقعك الإلكتروني. يجب الاعتماد على البيانات الميدانية كمصدر أساسي لرصد وقت الاستجابة للصفحة لأنّه يتأثّر بعمليات إعادة التوجيه، في حين أنّ الأدوات المستندة إلى المختبر غالبًا ما يتم قياسها باستخدام عنوان URL النهائي، وبالتالي لا يتم رصد هذا التأخير الإضافي.

إحصاءات PageSpeed هي إحدى الطرق للحصول على معلومات حول المواقع الإلكترونية المتاحة للجميع، سواء من خلال التجارب الميدانية أو التجارب في المختبر، والتي تتوفّر في تقرير تجربة المستخدم على Chrome.

يتم عرض وقت استجابة خادم صفحات الويب للمستخدمين الفعليين في أعلى قسم التعرّف على تجربة المستخدمين:

تظهر مجموعة فرعية من وقت استجابة الخادم في تدقيق وقت استجابة الخادم:

لمعرفة المزيد من الطرق لقياس وقت استجابة خادم الويب في كلّ من المجال والمختبر، يمكنك الاطّلاع على صفحة مقياس وقت استجابة خادم الويب.

تصحيح أخطاء وقت الاستجابة العالي لطلب البيانات في الحقل باستخدام 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 - $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" في هذه الحالة، يتم استخدام Server-Timing لقياس ما إذا كان طلب الحصول على مورد قد وصل إلى ذاكرة التخزين المؤقت لشبكة توصيل المحتوى، ومدة وصول الطلب إلى خادم الحافة في شبكة توصيل المحتوى ثم إلى المصدر.

بعد تحديد أنّ لديك وقت استجابة للصفحة (TTFB) يشكّل مشكلة من خلال تحليل البيانات المتاحة، يمكنك الانتقال إلى حلّ المشكلة.

طرق تحسين وقت استجابة خادم الويب

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

إرشادات خاصة بالمنصة

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

الاستضافة

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

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

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

عند اختيار مقدّم خدمة استضافة، إليك بعض الأمور التي يجب الانتباه إليها:

• ما مقدار الذاكرة المخصّصة لمثيل تطبيقك؟ إذا لم يكن تطبيقك مزوّدًا بذاكرة كافية، سيتعذّر عليه عرض الصفحات بأسرع ما يمكن.
• هل يحرص مقدّم خدمة الاستضافة على تحديث حِزم البرامج في الخلفية؟ ومع طرح إصدارات جديدة من لغات الخلفية للتطبيقات وعمليات تنفيذ بروتوكول HTTP وبرامج قواعد البيانات، سيتم تحسين الأداء في هذه البرامج بمرور الوقت. من المهم التعاون مع مزوّد استضافة يمنح الأولوية لهذا النوع من الصيانة المهمة.
• إذا كانت لديك متطلبات تطبيق محدّدة جدًا وتريد الوصول إلى أدنى مستوى من ملفات إعدادات الخادم، اسأل ما إذا كان من المنطقي تخصيص الخلفية لمثيل تطبيقك.

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

استخدام شبكة توصيل محتوى (CDN)

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

تعمل شبكات توصيل المحتوى (CDN) على حلّ مشكلة قرب المستخدمين من خادم المصدر باستخدام شبكة موزّعة من الخوادم التي تخزِّن الموارد على الخوادم الأقرب جغرافيًا إلى المستخدمين. وتُعرف هذه الخوادم باسم خوادم الحواف.

قد يوفّر مقدّمو خدمات شبكة توصيل المحتوى (CDN) أيضًا مزايا أخرى غير الخوادم الطرفية:

• عادةً ما يقدّم موفّرو خدمات شبكة توصيل المحتوى (CDN) أوقاتًا سريعة جدًا لحلّ نظام أسماء النطاقات.
• من المرجّح أن تعرِض شبكة توصيل المحتوى المحتوى الخاص بك من الخوادم الطرفية باستخدام بروتوكولات حديثة مثل HTTP/2 أو HTTP/3.
• يحلّ HTTP/3 على وجه الخصوص مشكلة حظر طلبات البيانات الأولى في بروتوكول TCP (الذي يعتمد عليه HTTP/2) باستخدام بروتوكول UDP.
• من المرجّح أن توفّر شبكة توصيل المحتوى (CDN) أيضًا إصدارات حديثة من بروتوكول أمان طبقة النقل (TLS)، ما يقلّل من وقت الاستجابة المرتبط بوقت تفاوض بروتوكول أمان طبقة النقل (TLS). تم تصميم الإصدار 1.3 من بروتوكول أمان طبقة النقل (TLS) على وجه الخصوص لإبقاء عملية التفاوض على بروتوكول أمان طبقة النقل قصيرة قدر الإمكان.
• يقدّم بعض موفّري شبكات توصيل المحتوى (CDN) ميزة تُعرف غالبًا باسم "عامل الحافة"، والذي يستخدم واجهة برمجة تطبيقات مشابهة لواجهة Service Worker API لمنع وصول الطلبات أو إدارتها آليًا في ذاكرات التخزين المؤقت للحواف أو إعادة كتابة الردود بالكامل.
• يُجيد مقدّمو شبكات CDN تحسين عملية الضغط. من الصعب إجراء عملية الضغط بنفسك، وقد تؤدي إلى زيادة وقت الاستجابة في بعض الحالات التي تتضمّن ترميزًا يتم إنشاؤه ديناميكيًا، والذي يجب ضغطه أثناء التشغيل.
• سيخزّن مزوّدو شبكة توصيل المحتوى (CDN) أيضًا الردود المضغوطة للموارد الثابتة تلقائيًا، ما يؤدي إلى تحقيق أفضل مزيج من نسبة الضغط ووقت الاستجابة.

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

استخدام المحتوى المخزّن مؤقتًا كلما أمكن

تسمح شبكات CDN بتخزين المحتوى مؤقتًا في الخوادم الطرفية التي تكون أقرب جغرافيًا إلى الزوّار، شرط أن يكون المحتوى مُعدًّا باستخدام Cache-Control رؤوس HTTP المناسبة. على الرغم من أنّ هذا الإجراء غير مناسب للمحتوى المخصّص، إلا أنّ طلب إعادة التوجيه إلى المصدر قد يحدّ من قيمة شبكة توصيل المحتوى (CDN) إلى حد كبير.

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

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

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

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

تجنُّب عمليات إعادة التوجيه إلى صفحات متعددة

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

هناك نوعان من عمليات إعادة التوجيه:

• عمليات إعادة التوجيه من المصدر نفسه، حيث تحدث عملية إعادة التوجيه بالكامل على موقعك الإلكتروني
• عمليات إعادة التوجيه من مصادر متعددة، حيث تحدث عملية إعادة التوجيه مبدئيًا من مصدر آخر، مثل خدمة تقصير عناوين URL على وسائل التواصل الاجتماعي، قبل الوصول إلى موقعك الإلكتروني.

يجب التركيز على إزالة عمليات إعادة التوجيه من مصدر مماثل، لأنّ هذا الأمر يمكنك التحكّم فيه مباشرةً. سيتضمّن ذلك التحقّق من الروابط على موقعك الإلكتروني لمعرفة ما إذا كان أيّ منها يؤدي إلى ظهور رمز استجابة 302 أو 301. يمكن أن يرجع ذلك غالبًا إلى عدم تضمين مخطّط https:// (لذلك يتم ضبط المتصفّحات تلقائيًا على http:// الذي يعيد التوجيه بعد ذلك) أو بسبب عدم تضمين الشَرطات المائلة اللاحقة أو استبعادها بشكلٍ مناسب في عنوان URL.

إنّ عمليات إعادة التوجيه من مصادر متعددة أكثر تعقيدًا لأنّها غالبًا ما تكون خارج نطاق تحكّمك، ولكن حاوِل تجنُّب عمليات إعادة التوجيه المتعدّدة قدر الإمكان، على سبيل المثال، باستخدام أدوات تقصير الروابط المتعدّدة عند مشاركة الروابط. تأكَّد من أنّ عنوان URL المقدَّم للمعلِنين أو النشرات الإخبارية هو عنوان URL النهائي الصحيح، وذلك لتجنّب إضافة عملية إعادة توجيه أخرى إلى تلك التي تستخدمها هذه الخدمات.

يمكن أن يكون مصدر مهم آخر لوقت إعادة التوجيه هو عمليات إعادة التوجيه من HTTP إلى HTTPS. يمكنك تجنُّب ذلك باستخدام عنوان Strict-Transport-Security (HSTS)، الذي سيفرض استخدام HTTPS في أول زيارة إلى مصدر، ثم سيطلب من المتصفّح الوصول إلى المصدر على الفور من خلال مخطّط HTTPS في الزيارات المستقبلية.

بعد وضع سياسة HSTS جيدة، يمكنك تسريع الأداء في أول زيارة إلى مصدر من خلال إضافة موقعك الإلكتروني إلى قائمة التحميل المُسبَق لآلية HSTS.

بث العلامات إلى المتصفّح

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

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

على سبيل المثال، استخدَمت React وغيرها من الإطارات الأساسية التي يمكنها عرض الترميز عند الطلب على الخادم أسلوبًا متزامنًا للعرض من جهة الخادم. ومع ذلك، طبّقت الإصدارات الأحدث من React طرق الخادم لبثّ الترميز أثناء عرضه. وهذا يعني أنّه ليس عليك الانتظار إلى أن تُعرِض طريقة واجهة برمجة التطبيقات لخادم React الردّ بالكامل قبل إرساله.

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

استخدام مشغّل خدمات

يمكن أن يكون لواجهة Service Worker API تأثير كبير في وقت الاستجابة للطلبات (TTFB) لكل من المستندات والموارد التي تحمّلها. ويعود السبب في ذلك إلى أنّ موظّف الخدمة يعمل كوسيط بين المتصفّح والخادم، ولكن ما إذا كان هناك تأثير على وقت استجابة خادم موقعك الإلكتروني يعتمد على كيفية إعداد موظّف الخدمة وما إذا كان هذا الإعداد متوافقًا مع متطلبات تطبيقك.

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

استخدِم 103 Early Hints للموارد المهمة للعرض.

بغض النظر عن مدى تحسين خلفية تطبيقك، قد يبقى هناك قدر كبير من العمل الذي يحتاجه الخادم لإعداد ردّ، بما في ذلك العمل المكلف (ولكن الضروري) في قاعدة البيانات الذي يؤخّر وصول ردّ التنقّل بأسرع ما يمكن. ويؤدي ذلك إلى تأخير بعض الموارد اللاحقة المهمة للعرض، مثل CSS أو JavaScript في بعض الحالات التي تؤدي إلى عرض العلامات على العميل.

عنوان 103 Early Hints هو رمز استجابة مبكر يمكن للخادم إرساله إلى المتصفّح عندما يكون الجزء الخلفي مشغولاً بإعداد العلامات. يمكن استخدام هذا العنوان للإشارة إلى المتصفّح بأنّ هناك موارد مهمة للعرض يجب أن تبدأ الصفحة في تنزيلها أثناء إعداد العلامات. بالنسبة إلى المتصفّحات المتوافقة، يمكن أن يؤدي ذلك إلى عرض المستندات بشكل أسرع (CSS) وتوفير وظائف الصفحة الأساسية بشكل أسرع (JavaScript).

الخاتمة

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

كما هو الحال مع تحسين كل مقياس، فإنّ النهج متشابه إلى حد كبير: قياس وقت استجابة خادم الويب في الميدان، واستخدام أدوات المختبر للتوغّل في الأسباب، ثم تطبيق التحسينات كلما أمكن ذلك. قد لا تكون كل تقنية مُستخدَمة هنا مناسبة لحالتك، ولكن بعضها سيكون مناسبًا. وكما هو الحال دائمًا، عليك مراقبة بيانات الحقول عن كثب وإجراء التعديلات حسب الحاجة لضمان تقديم تجربة أسرع للمستخدمين.

الصورة الرئيسية من إنشاء Taylor Vick، مصدرها Unsplash