لا تزال المواقع يتم تحميلها ببطء شديد. غالبًا ما تكون القناة خامدة تمامًا في أكثر اللحظات الحرجة لعملية التنزيل. ستساعد تقنية Fastly الجديدة ، التي اقترحها المهندس Kazuho Oku ، على الاستفادة بشكل أفضل من أول ثانيتين مهمتين.

هل سبق لك تنزيل موقع ويب على هاتفك - وتبحثت عن 10 ثوانٍ على صفحة بدون نص؟ لا أحد يحب الجلوس والنظر إلى شاشة فارغة أثناء تحميل بعض الخطوط غير العادية. لذلك ، من المنطقي نقل تحميل هذه الأشياء المهمة في أقرب وقت ممكن. كان من المفترض أن يؤدي رابط التحميل المسبق rel = preload إلى حل المشكلة جزئيًا. أولاً ، يقوم المتصفح بتحليل رؤوس HTTP ، لذلك هذا هو المكان المثالي للإشارة إلى التحميل المسبق لمورد ستحتاجه بالتأكيد لاحقًا.

افتراضيًا ، يكون الإنترنت بطيئًا

دعنا نرى ما يحدث إذا لم تستخدم التحميل المسبق. لا يمكن للمتصفح بدء تحميل الموارد إلا بعد أن يكتشف أنه بحاجة إليها. من المرجح أن يحدث هذا للموارد الموجودة في HTML أثناء التحليل الأولي للمستند (على سبيل المثال ، <script> و <link rel=stylesheet> و <img> ).

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

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

رابط rel = التحميل المسبق يساعد كثيرا

في السنوات القليلة الماضية ، تحسن الوضع بفضل Link rel = preload . على سبيل المثال:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

بفضل هذه التوجيهات ، يمكن للمتصفح بدء تحميل الموارد فورًا بعد تلقي الرؤوس وقبل بدء تحليل نص HTML:



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

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

نستخدم وقت "تفكير الخادم" بمساعدة "النصائح المبكرة"

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

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

ولكن من المثير للاهتمام أنه حتى قبل إنشاء الإجابة ، فأنت تعرف بالفعل بعض الأنماط والخطوط التي تحتاج إلى تنزيلها لعرض الصفحة. بعد كل شيء ، عادة ما تستخدم صفحات الخطأ نفس هوية الشركة والتصميم مثل الصفحات العادية. سيكون من الرائع إرسال هذه Link: rel=preload قبل أن يعمل الخادم . لهذا السبب ، صاغ زميلي Kazuho Oku معيار Standard Hints ، الذي تم إنشاؤه في RFC8297 بواسطة مجموعة عمل HTTP. قم بتقييم سحر أشرطة الحالة المتعددة في إجابة واحدة :

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

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



بالطبع ، سيتطلب هذا تغييرات معينة في تشغيل المتصفحات والخوادم وشبكات CDN ، وقد أبدى مطورو بعض المتصفحات تحفظات حول صعوبات التنفيذ. لذلك ، لا يزال من غير الواضح متى يمكن تشغيل هذه الرؤوس. يمكنك تتبع التقدم في برامج التتبع العامة لمتصفح Chrome وفايرفوكس .

نتوقع أنه في النهاية ، ستتمكن من إصدار رؤوس Early Hints مباشرة من Fastly ، مع الاستمرار في إرسال الطلبات بطريقة قياسية. لم نقرر بعد كيفية تعيين الواجهة عبر VCL ، لذا أخبرني إذا كان لديك أي رغبات في هذا الموضوع!

ولكن ماذا عن دفع خادم HTTP / 2؟

باستخدام HTTP / 2 ، هناك تقنية جديدة تسمى Server Push والتي يبدو أنها تحل نفس المشكلة مثل Link rel = preload in Early Hints answer. على الرغم من أنه يعمل حقًا (ويمكنك حتى إنشاء دفع مخصص بسرعة من خوادم الحافة في Fastly) ، إلا أن هناك اختلافات كبيرة في عدة نقاط:

• لا يعرف الخادم عن توفر مورد على العميل ، لذلك غالبًا ما يدفعه دون داعٍ. نظرًا للتخزين المؤقت للشبكة ووقت الاستجابة ، يتعذر على العميل عادةً إلغاء الإرسال قبل تلقي كل المحتوى. (على الرغم من وجود حل ممكن لهذه المشكلة ، في شكل عنوان Cache Digest المقترح ، والذي يعمل Kazuho عليه مع Joam Weiss من Akamai).
• ترتبط الموارد المتدفقة بالاتصال ، لذلك من السهل بدء تشغيل مورد لا يستخدمه العميل ، لأنه يحاول الحصول عليه من خلال اتصال آخر. قد يحتاج العملاء إلى استخدام اتصال مختلف لأن المورد في مصدر مختلف بشهادة TLS مختلفة أو لأنه يتم استرداده في وضع اعتماد مختلف.
• لم يتم تنفيذ H2 Push بشكل متسق للغاية في متصفحات مختلفة. لذلك ، من الصعب التنبؤ بما إذا كان سيعمل أم لا في حالتك الخاصة.

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

ومع ذلك ، ليس هذا هو الحال دائمًا. دعونا نكون متفائلين ونتخيل أن الناس سيستقرون قريبًا على كوكب المريخ. سوف يتصفحون الويب بتأخير 20-45 دقيقة لكل تبادل للحزم ، لذا فإن التبادل الإضافي مؤلم للغاية ، ووقت الخادم ضئيل مقارنة به. Server Push يفوز بسهولة هنا. ولكن إذا نظرنا في أي وقت إلى صفحات الويب من كوكب المريخ ، فمن الأرجح أن ننزل نوعًا من حزم البيانات ، مثل حزم الويب المقدمة الآن والتبادلات الموقعة .

مكافأة إضافية: انهيار طلب أسرع

على الرغم من أنه من المفترض استخدام تلميحات مبكرة بشكل أساسي في المتصفح ، إلا أن هناك فائدة محتملة مثيرة للاهتمام لـ CDN. عندما يتلقى Fastly العديد من الطلبات للمورد نفسه ، نرسل عادةً واحدًا منهم فقط إلى المصدر ، ونضع الباقي في قائمة انتظار الانتظار. تُعرف هذه العملية بانهيار الطلب . إذا كانت الاستجابة من المصدر تتضمن Cache-Control: private ، فعليك إزالة جميع الطلبات من قائمة الانتظار وإرسالها بشكل منفصل إلى المصدر ، لأنه لا يمكننا استخدام إجابة واحدة لتلبية عدة طلبات.

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

اطلب محتوى أقل أهمية مع النصائح ذات الأولوية

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

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

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

هل يمكن استخدام هذا؟

لم تصبح القرائن المبكرة ولا القرائن ذات الأولوية هي المعيار حتى الآن. في الآونة الأخيرة ، بدأ H2O ، خادم HTTP / 2 المستخدم والمدعوم من قبل Fastly ، في استخدام تلميحات مبكرة (انظر PR 1727 و 1767 ) ، وهناك نية لتطبيق تلميحات الأولوية في Chrome ، بالإضافة إلى تتبع الردود 1xx بشكل نشط. في الوقت نفسه ، لا يوجد ضرر في البدء في إرسال تلميحات مبكرة في الوقت الحالي - وإذا كنت تريد المضي قدمًا في الاتجاه ، فانتقل!