لا تكافح ماسح فحص التحميل المسبق في المتصفّح.

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

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

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

يحتوي كل متصفّح على معالج أساسي لـ HTML يقسّم الترميز الأوّلي ويعالجه إلى نموذج عنصر. ويستمر ذلك جيدًا إلى أن يتوقف المحلل مؤقتًا عندما يعثر على مورد حظر، مثل ورقة أنماط تم تحميلها بعنصر <link> أو نص برمجي تم تحميله مع عنصر <script> بدون السمة async أو defer.

مخطّط بياني لمحلّل HTML
الشكل 1: مخطّط بياني يوضّح كيفية حظر وحدة تحليل HTML الأساسية للمتصفّح في هذه الحالة، يصادف المحلِّل عنصر <link> لملف CSS خارجي، ما يمنع المتصفّح من تحليل بقية المستند أو حتى عرض أي جزء منه إلى أن يتم تنزيل ملف CSS وتحليله.

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

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

يحظر المتصفّح أيضًا تحليل الصفحة وعرضها عندما يصادف عناصر <script> بدون السمة defer أو async.

ويعود السبب في ذلك إلى أنّ المتصفح لا يمكنه معرفة ما إذا كان أي نص برمجي معيّن سيُعدّل نموذج DOM أثناء تنفيذ منظِّم HTML الأساسي وظيفته. وهذا هو سبب انتشار استخدام JavaScript في نهاية المستند لكي تصبح تأثيرات التحليل والعرض المحظورين هامشية.

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

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

دور الماسح الضوئي للتحميل المُسبَق هو تخميني، ما يعني أنّه يفحص الترميز الأوّلي للعثور على الموارد التي يمكن جلبها بشكل انتهازي قبل أن يكتشفها محلل HTML الأساسي.

كيفية معرفة ما إذا كان الماسح الضوئي لميزة "التثبيت المُسبَق" يعمل

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

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

يوضّح الرسم البياني للشبكة على WebPageTest تأخيرًا اصطناعيًا لمدة ثانيتَين تم فرضه على جدول الأنماط.
الشكل 4: مخطّط تدفق الشبكة من WebPageTest لـ صفحة ويب يتم تشغيلها على Chrome على جهاز جوّال عبر اتصال شبكي يحاكي شبكة الجيل الثالث على الرغم من أنّه يتم تأخير جدول الأنماط بشكل مصطنع من خلال خادم وكيل لمدة ثانيتَين قبل بدء تحميله، يتم اكتشاف الصورة المتوفّرة لاحقًا في الحمولة البرمجية للترميز من خلال أداة فحص التحميل المُسبَق.

كما هو موضّح في المخطّط البياني، يرصد "أداة فحص التحميل المُسبَق" عنصر <img> حتى في حال حظر عرض المحتوى وتحليل المستند. وبدون هذا التحسين، لا يمكن أن يجلب المتصفّح المحتوى في وقت مناسب أثناء فترة الحظر، وستكون المزيد من طلبات الموارد متتابعة وليست متزامنة.

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

تم إدخال async نص برمجي.

لنفترض أنّ لديك رمز HTML في <head> يتضمّن بعض رموز JavaScript المضمّنة، مثل ما يلي:

<script>
  const scriptEl = document.createElement('script');
  scriptEl.src = '/yall.min.js';

  document.head.appendChild(scriptEl);
</script>

تكون النصوص البرمجية التي تم إدخالها هي async بشكل تلقائي، لذا فعند إدخال هذا النص البرمجي، سيعمل كما لو تم تطبيق السمة async عليه. وهذا يعني أنّه سيتم تشغيله في أقرب وقت ممكن ولن يؤدي إلى حظر العرض. يبدو هذا مثاليًا، أليس كذلك؟ ومع ذلك، إذا افترضت أنّ عنصر <script> المضمّن هذا يأتي بعد عنصر <link> يحمّل ملف CSS خارجيًا، ستحصل على نتيجة غير مثالية:

يعرض الرسم البياني هذا من WebPageTest تعذُّر فحص التحميل المُسبَق عند حقن نص برمجي.
الشكل 5: رسم بياني انحداري لشبكة WebPageTest يعرض صفحة ويب ويتم تشغيله على Chrome على جهاز جوّال من خلال محاكاة اتصال شبكة الجيل الثالث. تحتوي الصفحة على جدول تنسيقات واحد ونص برمجي async تمّت حقنه. لا يمكن لأداة فحص التحميل المُسبَق اكتشاف البرنامج النصي أثناء مرحلة حظر عرض المحتوى، لأنّه يتم حقنه على العميل.

لنلقِ نظرة على ما حدث:

  1. بعد مرور 0 ثانية، يتم طلب المستند الرئيسي.
  2. بعد 1.4 ثانية، يصل البايت الأول من طلب التنقّل.
  3. بعد مرور ثانيتين، يتم طلب ملف CSS والصورة.
  4. بما أنّه يتم حظر المُحلِّل من تحميل ملف أسلوب التنسيق، ويأتي نص JavaScript المضمّن الذي يُدخل نص async بعد ملف أسلوب التنسيق بعد 2.6 ثانية، لا تتوفّر الوظيفة التي يوفّرها النص البرمجي في أقرب وقت ممكن.

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

ماذا يحدث إذا استخدمت علامة <script> عادية مع سمة async بدلاً من إدخال النص البرمجي في DOM؟

<script src="/yall.min.js" async></script>

في ما يلي النتيجة:

شلال شبكة WebPageTest يعرض كيف لا يزال بالإمكان اكتشاف نص برمجي غير متزامن تم تحميله باستخدام عنصر نص HTML البرمجي بواسطة الماسح الضوئي للتحميل المسبق في المتصفح، على الرغم من حظر محلّل HTML الأساسي في المتصفح أثناء تنزيل ورقة أنماط ومعالجتها.
الشكل 6: رسم بياني للشبكة على WebPageTest يعرض صفحة ويب يتم تشغيلها على Chrome على جهاز جوّال عبر اتصال شبكي يحاكي شبكة الجيل الثالث تحتوي الصفحة على جدول تنسيقات واحد وعنصر async <script> واحد. يرصد برنامج فحص التحميل المُسبَق النص البرمجي أثناء مرحلة حظر العرض، ويحمِّله بشكل متزامن مع لغة CSS.

قد يكون من المغري اقتراح أنّه يمكن حلّ هذه المشاكل باستخدام rel=preload. سيؤدي ذلك بالتأكيد إلى حلّ المشكلة، ولكن قد يكون له بعض الآثار الجانبية. بعد كل شيء، لماذا تستخدم rel=preload لحلّ مشكلة يمكن تجنّبها من خلال عدم إدخال عنصر <script> في نموذج DOM؟

عرض إعلانات بدون انقطاع في WebPageTest يوضّح كيفية استخدام التلميح الخاص بمورد rel=preload للترويج لاكتشاف نص برمجي مُدرَج بشكل غير متزامن، وذلك بطريقة قد يكون لها تأثيرات جانبية غير مقصودة.
الشكل 7: رسم بياني للشبكة على WebPageTest يعرض صفحة ويب يتم تشغيلها على Chrome على جهاز جوّال عبر اتصال شبكي 3G محاكي تحتوي الصفحة على جدول تنسيقات واحد ونص برمجي async تمّ إدراجه، ولكن يتم تحميل نص async البرمجي مسبقًا لضمان اكتشافه في وقت أقرب.

يؤدي التحميل المُسبق إلى "إصلاح" المشكلة هنا، ولكنه يؤدي إلى ظهور مشكلة جديدة: يتم تحميل النص البرمجي async في أول عرضَين تجريبيَين، على الرغم من تحميله في <head>، بأولوية "منخفضة"، بينما يتم تحميل ورقة الأنماط عند أولوية "الأعلى". في العرض الترويجي الأخير الذي تم فيه تحميل النص البرمجي async مسبقًا، لا يزال يتم تحميل جدول الأنماط بأولوية "أعلى"، ولكن تم ترقية أولوية النص البرمجي إلى "عالية".

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

الإجابة هنا واضحة: إذا كانت هناك حاجة إلى نص برمجي أثناء بدء التشغيل، فلا تتغلب على الماسح الضوئي للتحميل المسبق من خلال إدخاله في نموذج العناصر في المستند (DOM). جرِّب حسب الحاجة موضع عنصر <script>، بالإضافة إلى سمات مثل defer وasync.

التحميل الكسول باستخدام JavaScript

يُعدّ التحميل البطيء طريقة رائعة للحفاظ على البيانات، ويتم تطبيقه غالبًا على الصور. ومع ذلك، يتم أحيانًا تطبيق ميزة "التحميل البطيء" بشكلٍ غير صحيح على الصور التي تظهر "أعلى الصفحة"، على حدّ تعبيرنا.

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

<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

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

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

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

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

الحلّ هو تغيير ترميز الصورة:

<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

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

رسم بياني للشبكة على WebPageTest يعرض سيناريو تحميل صورة في إطار العرض أثناء بدء التشغيل لا يتم التحميل الكسول للصورة، ما يعني أنّها لا تعتمد على النص البرمجي المطلوب تحميله، ما يعني أنّ &quot;الماسح الضوئي للتحميل المسبق&quot; يمكنه اكتشافها بشكل أسرع.
الشكل 9: رسم بياني انحداري لشبكة WebPageTest يعرض صفحة ويب ويتم تشغيله على Chrome على جهاز جوّال من خلال محاكاة اتصال شبكة الجيل الثالث. يرصد أداة فحص التحميل المُسبَق مورد الصورة قبل بدء تحميل CSS وJavaScript، ما يمنح المتصفّح ميزة إضافية في تحميله.

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

صور الخلفية في CSS

تذكَّر أنّ أداة فحص التحميل المُسبَق في المتصفّح تفحص الترميز. ولا تبحث هذه الأداة عن أنواع الموارد الأخرى، مثل CSS التي قد تتضمّن عمليات جلب للصور التي تشير إليها خاصية background-image.

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

لنفترض أنّ مرشح LCP في صفحتك هو عنصر يحتوي على سمة CSS background-image. في ما يلي ما يحدث عند تحميل الموارد:

رسم بياني للشبكة على WebPageTest يعرض صفحة تتضمّن عنصرًا مرشحًا لـ LCP تم تحميله من CSS باستخدام السمة background-image بما أنّ صورة المرشّح لسرعة عرض أكبر محتوى مرئي (LCP) تندرج ضمن نوع مورد يتعذّر على فاحص التحميل المسبق في المتصفّح فحصه، يتأخر تحميل المورد حتى يتم تنزيل خدمة CSS ومعالجتها، ما يؤدي إلى تأخير وقت عرض المرشّح لسرعة عرض أكبر محتوى مرئي.
الشكل 10: رسم بياني انحداري لشبكة WebPageTest يعرض صفحة ويب ويتم تشغيله على Chrome على جهاز جوّال من خلال محاكاة اتصال شبكة الجيل الثالث. مُرشَّح LCP للصفحة هو عنصر يحتوي على سمة background-image في CSS (الصف 3). ولا يبدأ جلب الصورة التي يطلبها إلى أن يعثر عليها محلل CSS.

في هذه الحالة، لا يتم إيقاف أداة فحص التحميل المُسبَق، بل لا يتم استخدامها. ومع ذلك، إذا كان أحد عناصر سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) من أحد مواقع CSS على background-image، ستحتاج إلى تحميل هذه الصورة مسبقًا:

<!-- Make sure this is in the <head> below any
     stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">

تلميح rel=preload هذا صغير، لكنّه يساعد المتصفّح في اكتشاف الصورة بشكل أسرع مما يمكنه فعله:

رسم بياني للشبكة على WebPageTest يعرض صورة خلفية CSS (وهي المرشح لأكبر محتوى مرئي) يتم تحميلها في وقت أقرب بكثير بسبب استخدام التلميح rel=preload تحسّن مدة LCP بمقدار 250 ملي ثانية تقريبًا.
الشكل 11: رسم بياني للشبكة على WebPageTest يعرض صفحة ويب يتم تشغيلها على Chrome على جهاز جوّال عبر اتصال شبكي يحاكي شبكة الجيل الثالث المرشح لقياس LCP في الصفحة هو عنصر يتضمّن سمة background-image في CSS (الصف 3). يساعد التلميح rel=preload المتصفح في اكتشاف الصورة قبل 250 ملي ثانية تقريبًا مقارنةً بغير ذلك.

باستخدام التلميح rel=preload، يتم اكتشاف المرشح لأكبر محتوى مرئي (LCP) في وقت أقرب، ما يؤدي إلى تقليل وقت LCP. على الرغم من أنّ هذه التلميحة تساعد في حلّ هذه المشكلة، قد يكون الخيار الأفضل هو تقييم ما إذا كان يجب تحميل عنصر LCP المرتبط بالصورة من CSS أم لا. عند استخدام علامة <img>، يمكنك التحكّم بشكل أكبر في تحميل صورة مناسبة لإطار العرض مع السماح للماسح الضوئي للتحميل المُسبق باكتشافها.

تضمين عدد كبير جدًا من الموارد

التضمين هو ممارسة تضع موردًا داخل رمز HTML. يمكنك تضمين أوراق أنماط في عناصر <style> والنصوص البرمجية في عناصر <script> وأي مورد آخر تقريبًا باستخدام ترميز base64.

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

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

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

رسم بياني للشبكة على WebPageTest للصفحة التي تتضمّن ملف CSS خارجيًا يتضمّن أربعة خطوط مُشار إليها يرصد الماسح الضوئي لميزة &quot;التحميل المُسبَق&quot; الصورة المُحتمَلة لمقياس LCP في الوقت المناسب.
الشكل 12: رسم بياني انحداري لشبكة WebPageTest يعرض صفحة ويب ويتم تشغيله على Chrome على جهاز جوّال من خلال محاكاة اتصال شبكة الجيل الثالث. إنّ العنصر المرشح الخاص بـ LCP للصفحة هو صورة تم تحميلها من عنصر <img>، ولكن تم اكتشافها بواسطة الماسح الضوئي للتحميل المسبق، بسبب أن CSS والخطوط المطلوبة لتحميل الصفحة في موارد منفصلة، ما لا يؤخّر الماسح الضوئي للتحميل المسبق في أداء عمله.

الآن ماذا يحدث إذا تم تضمين CSS وجميع الخطوط كموارد base64؟

رسم بياني للشبكة على WebPageTest للصفحة التي تتضمّن ملف CSS خارجيًا يتضمّن أربعة خطوط مُشار إليها تأخّر الماسح الضوئي للتحميل المُسبق كثيرًا في اكتشاف صورة LCP .
الشكل 13: رسم بياني للشبكة على WebPageTest يعرض صفحة ويب يتم تشغيلها على Chrome على جهاز جوّال عبر اتصال شبكي يحاكي شبكة الجيل الثالث إنّ المقياس "سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)" المُقترَح للصفحة هو صورة يتم تحميلها من عنصر <img>، ولكنّ تضمين CSS وموارد الخطوط الأربعة في ‎"‎style" يؤخّر فحص أداة التحميل المُسبَق للصورة إلى أن يتم تنزيل هذه الموارد بالكامل.

يؤدّي تأثير الحشو إلى عواقب سلبية على LCP في هذا المثال، وعلى الأداء بشكل عام. يعرض إصدار الصفحة الذي لا يتضمّن أي محتوى مضمّنًا صورة LCP في غضون 3.5 ثانية تقريبًا. إنّ الصفحة التي تتضمّن كل المحتوى لا تعرض صورة LCP إلا إذا كانت مدتها أكثر من 7 ثوانٍ.

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

هل يمكن أن يؤدي التحميل المُسبَق إلى تحسين الأداء؟ حسنًا يمكنك تحميل صورة مقياس LCP مسبقًا وتقليل وقت LCP، ولكنّ تضخيم ملف HTML الذي لا يمكن تخزينه مؤقتًا باستخدام موارد مضمّنة له عواقب سلبية أخرى على الأداء. ويتأثر سرعة عرض أول محتوى (FCP) بهذا النمط أيضًا. في نسخة الصفحة التي لم يتم تضمين أي محتوى فيها، تبلغ سرعة عرض المحتوى على الصفحة 2.7 ثانية تقريبًا. في النسخة التي تم تضمين كل المحتوى فيها، تبلغ سرعة عرض المحتوى على الصفحة 5.8 ثانية تقريبًا.

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

عرض العلامات باستخدام JavaScript من جهة العميل

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

من الأنماط التي يمكنها إيقاف أداة فحص التحميل المُسبَق هي عرض الترميز باستخدام JavaScript من جهة العميل:

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

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

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

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

إذا كانت صفحتك تحتاج إلى JavaScript لإرفاق وظائف ببعض أجزاء ترميز الصفحة، سيظل بإمكانك إجراء ذلك باستخدام ميزة SSR، إما باستخدام JavaScript العادي أو المعالجة المتقدّمة للاستفادة من مزايا كلتا الطريقتَين.

المساعدة في تحسين أداء أداة فحص التحميل المُسبَق

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

باختصار، في ما يلي النقاط التالية التي يجب أخذها في الاعتبار من هذه المشاركة:

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

إذا تعذّر عليك تجنُّب نمط يؤثر سلبًا في قدرة أداة فحص التحميل المُسبَق على تسريع أداء التحميل لأي سبب، ننصحك باستخدام تلميح المورد rel=preload. إذا كنت تستخدِم rel=preload، اختبِره في أدوات المختبر للتأكّد من أنّه يحقّق التأثير المطلوب. أخيرًا، لا تحمِّل مسبقًا عددًا كبيرًا جدًا من الموارد، لأنّه عندما تمنح الأولوية لكل شيء، لن يكون هناك أي شيء.

الموارد

الصورة الرئيسية من Unsplash، لأحد أعمال Mohammad Rahmani .