يتم تحميل الصفحات بشكل أسرع باستخدام وقت التفكير الخاص بالخادم من خلال ميزة Early Hints

تعرَّف على كيفية إرسال الخادم لمعلومات إلى المتصفّح حول الموارد الفرعية المهمة.

Kenji Baheux

Barry Pollard

ما هي "التلميحات المبكّرة"؟

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

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

في بعض الحالات، يمكن أن يؤدي تحسين الأداء في سرعة عرض أكبر جزء من المحتوى على الصفحة إلى تحسين بقيمة تصل إلى عدة مئات من المللي ثانية، كما لاحظت Shopify وCloudflare، وإلى تحسين بقيمة تصل إلى ثانية واحدة، كما هو موضّح في هذه المقارنة بين الأداء قبل التحسين وبعده:

طريقة استخدام ميزة Early Hints

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

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

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

عند استخدام هذه الموارد في HTML، تحتاج عادةً إلى preconnect أو preload موارد لن يكتشفها Preload Scanner في HTML، مثل الخطوط أو صور الخلفية التي كان من الممكن اكتشافها في وقت متأخر لولا ذلك. بالنسبة إلى ميزة Early Hints، لن تتوفّر لغة HTML، لذا قد تحتاج بدلاً من ذلك preconnect إلى النطاقات المهمة أو preload الموارد المهمة التي قد يتم اكتشافها في وقت مبكر من HTML، على سبيل المثال، التحميل المُسبق main.css أو app.js. بالإضافة إلى ذلك، لا تتيح جميع المتصفحات استخدام preload للتلميحات المبكرة. يُرجى الاطّلاع على دعم المتصفِّح.

تتألف الخطوة الثانية من الحدّ من خطر استخدام "الإشارات المبكّرة" في الموارد أو المصادر التي قد تكون قديمة أو لم تعُد تستخدمها المرجع الرئيسي. على سبيل المثال، قد لا تكون الموارد التي يتم تعديلها وإصدار نُسخ منها بشكل متكرّر (مثل example.com/css/main.fa231e9c.css) هي الخيار الأفضل. يُرجى العِلم أنّ هذا القلق ليس خاصًا بميزة "الإشارات المبكرة"، بل ينطبق على أي preload أو preconnect أينما كانا متوفّرين. هذا هو النوع من التفاصيل التي يُفضَّل التعامل معها باستخدام الأساليب المبرمَجة أو النماذج (على سبيل المثال، من المرجّح أن تؤدي العملية اليدوية إلى عدم تطابق عناوين URL الخاصة بالإصدار أو التجزئة بين preload وعلامة HTML الفعلية التي تستخدِم المرجع).

على سبيل المثال، فكِّر في الخطوات التالية:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

يتوقّع الخادم أن تكون هناك حاجة إلى main.abcd100.css، ويقترح تحميله مسبقًا باستخدام "الإشارات المبكّرة":

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

بعد بضع لحظات، يتم عرض صفحة الويب، بما في ذلك ملف CSS المرتبط. يُرجى العِلم أنّه يتم تعديل مرجع CSS هذا بشكل متكرّر، وأنّ المرجع الرئيسي يسبق مرجع CSS المتوقّع بخمس إصدارات (abcd105).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

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

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

أخيرًا، من جهة الخادم، ابحث عن طلبات الموارد الرئيسية التي ترسلها المتصفّحات المعروفة بتوفّر رسائل "الإشارات المبكّرة" فيها، ويجب الردّ عليها فورًا باستخدام رسائل 103 Early Hints. في ردّ 103، يجب تضمين التلميحَين المعنيّين بالربط المُسبَق وتحميل المَعلمات مُسبَقًا. بعد أن يصبح المرجع الرئيسي جاهزًا، يمكنك المتابعة مع الاستجابة المعتادة (على سبيل المثال، ‎200 OK في حال نجاح العملية). من الممارسات الجيدة أيضًا تضمين عناوين HTTP الخاصة بـ Link في الاستجابة النهائية، مع إضافة موارد مهمة ظهرت أثناء إنشاء المورد الرئيسي (على سبيل المثال، الجزء الديناميكي من المورد الرئيسي في حال اتّباع اقتراح "تقسيم إلى قسمَين"). إليك الشكل الذي سيظهر به ذلك:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

بعد بضع لحظات:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

دعم المتصفح

على الرغم من أنّ رسائل التلميح المبكّرة 103 متوافقة مع جميع المتصفحات الرئيسية، تختلف التوجيهات التي يمكن إرسالها في رسالة التلميح المبكّر حسب المتصفّح:

إتاحة ميزة "الربط المُسبَق":

التوافق مع ميزة "التنزيل المُسبَق":

تتوفّر أيضًا في "أدوات مطوري البرامج في Chrome" إمكانية استخدام 103 من الإشارات المبكّرة، ويمكن الاطّلاع على رؤوس Link في موارد المستندات:

تظهر عناوين

يُرجى العلم أنّه لاستخدام موارد "الإشارات المبكّرة"، يجب عدم وضع علامة في المربّع Disable cache في "أدوات مطوّري البرامج" لأنّ ميزة "الإشارات المبكّرة" تستخدِم ذاكرة التخزين المؤقت للمتصفّح. بالنسبة إلى الموارد المحمَّلة مسبقًا، سيظهر المشغِّل على أنّه early-hints والحجم على أنّه (Disk cache):

يتطلّب ذلك أيضًا شهادة موثوق بها لاختبار HTTPS.

لا يتيح Firefox (بدءًا من الإصدار 126) استخدام 103 Early Hints بشكل صريح في DevTools، ولكنّ الموارد التي يتم تحميلها باستخدام Early Hints لا تعرض معلومات عناوين HTTP، وهو أحد المؤشرات على أنّه تم تحميلها باستخدام Early Hints.

دعم الخادم

في ما يلي ملخص سريع لمستوى دعم ميزة Early Hints ضمن برامج خادم HTTP الشائعة ذات المصدر المفتوح:

• Apache: متاح باستخدام mod_http2.
• H2O: متوافق.
• NGINX: وحدة تجريبية.
• العقدة: متاحة منذ 18.11.0 لنظامَي التشغيل http وhttp2

تفعيل ميزة "التلميحات المبكّرة" بالطريقة الأسهل

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

• Early Hints في Cloudflare
• نصائح مبكّرة في Fastly
• Early Hints في Akamai

كيفية تجنُّب مشاكل العملاء الذين لا يوفّرون ميزة Early Hints

إنّ ردود HTTP الإجرائية ضمن النطاق 100 هي جزء من معيار HTTP، ولكن قد يواجه بعض العملاء أو برامج الزحف القديمة صعوبة في التعامل معها لأنّه نادرًا ما كان يتم استخدامها قبل إطلاق 103 Early Hints في تصفّح الويب بشكل عام.

من خلال إرسال إشارات 103 Early Hint فقط استجابةً للعملاء الذين يرسلون عنوان طلب HTTP‏ sec-fetch-mode: navigate، من المفترض أن يتم ضمان إرسال هذه الإشارات للعملاء الجدد فقط الذين يفهمون انتظار الاستجابة اللاحقة. بالإضافة إلى ذلك، بما أنّ "الإشارات المبكّرة" متاحة فقط لطلبات التنقّل (راجِع القيود الحالية)، فإنّ ذلك يقدّم ميزة إضافية تتمثل في تجنُّب إرسال هذه الإشارات بدون داعٍ في الطلبات الأخرى.

بالإضافة إلى ذلك، لا يُنصح بإرسال "التلميحات المبكرة" إلا عبر اتصالات HTTP/2 أو HTTP/3 ولن تقبلها معظم المتصفحات إلا عبر هذه البروتوكولات.

نمط متقدّم

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

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

القيود الحالية

في ما يلي القيود المفروضة على ميزة "الإشارات المبكّرة" كما تم تنفيذها في Chrome:

• لا تتوفّر إلا لطلبات التنقّل (أي المرجع الرئيسي لمستند المستوى الأعلى).
• يُسمح فقط بالقيمتَين preconnect وpreload (أي أنّ القيمة prefetch غير مسموح بها).
• إنّ ميزة "التلميحات المبكرة" التي تليها عملية إعادة توجيه من مصادر متعددة ضمن الاستجابة النهائية ستؤدي إلى إيقاف Chrome للموارد والاتصالات التي حصل عليها باستخدام ميزة "التلميحات المبكرة".
• يتم تخزين الموارد التي يتم تحميلها مسبقًا باستخدام الإشارات المبكّرة في ذاكرة التخزين المؤقت لبروتوكول HTTP، وتسترجعها الصفحة من هناك لاحقًا. لذلك، يمكن فقط تحميل الموارد القابلة للتخزين المؤقت مسبقًا باستخدام ميزة "التلميحات المبكرة" أو سيتم استرجاع المورد مرّتين (مرة عن طريق ميزة "التلميحات المبكرة" ومرة أخرى بواسطة المستند). في Chrome، يتم إيقاف ذاكرة التخزين المؤقت لبروتوكول HTTP لشهادات HTTPS غير الموثوق بها (حتى إذا تابعت تحميل الصفحة).
• لا يمكن تحميل الصور المتجاوبة مسبقًا (باستخدام imagesrcset أو imagesizes أو media) باستخدام رؤوس HTTP <link> لأنّه لا يتم تحديد مساحة العرض إلى أن يتم إنشاء المستند. يعني ذلك أنّه لا يمكن استخدام ميزة "التلميحات المبكرة" لتحميل الصور المتجاوبة مسبقًا، وقد يتم تحميل الصورة غير الصحيحة عند استخدامها في ذلك. اطّلِع على المناقشة حول الاقتراحات حول كيفية التعامل مع هذه المشكلة بشكل أفضل.

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

ما هي الخطوات التالية؟

واستنادًا إلى اهتمام المنتدى، قد نعمل على تعزيز عملية استخدام ميزة "التلميحات المبكرة" من خلال الإمكانيات التالية:

• إشارات مبكّرة للموارد التي لا يمكن تخزينها مؤقتًا باستخدام ذاكرة التخزين المؤقت بدلاً من ذاكرة التخزين المؤقت لبروتوكول HTTP
• إرسال إشارات مبكّرة عند طلبات الموارد الفرعية
• يتم إرسال الإشارات المبكّرة في طلبات الموارد الرئيسية لإطار iframe.
• إتاحة ميزة "التحميل المُسبَق" في "الإشارات المبكّرة"

نرحب بملاحظاتك حول الجوانب التي يجب إعطاء الأولوية لها وكيفية تحسين ميزة "التلميحات المبكّرة" بشكلٍ أكبر.

العلاقة بإعلانات H2/الإعلانات الفورية

إذا كنت على دراية بميزة HTTP2/Push المتوقّفة نهائيًا، قد تتساءل عن الفرق بين هذه الميزة وميزة "الإشارات المبكّرة". في حين أنّ ميزة "الإشارات المبكّرة" تتطلّب تنقّل البيانات ذهابًا وإيابًا ليتمكّن المتصفّح من بدء جلب الموارد الفرعية المهمة، يمكن للخادم بدء دفع الموارد الفرعية إلى جانب الاستجابة باستخدام HTTP2/Push. على الرغم من أنّ هذا يبدو رائعًا، إلا أنّه أدّى إلى عيوب أساسية في البنية: باستخدام HTTP2/Push، كان من الصعب جدًا تجنُّب دفع الموارد الفرعية التي كان المتصفّح يمتلكها. وقد أدى هذا التأثير "التجاوز المفرط" إلى استخدام معدل نقل بيانات الشبكة بكفاءة أقل، مما أعاق مزايا الأداء بصورة كبيرة. بشكل عام، أظهرت بيانات Chrome أنّ HTTP2/Push كان في الواقع سلبيًا بشكلٍ صافٍ للأداء على الويب.

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

الصورة المصغّرة من إنشاء Pierre Bamin.