تعرَّف على ماسح التحميل المُسبق في المتصفّح، وكيفية مساعدته في تحسين الأداء، وكيفية تجنُّب تداخله مع عمليات أخرى.
من الجوانب التي يتم إغفالها عند تحسين سرعة الصفحة هو معرفة بعض المعلومات عن العناصر الداخلية للمتصفّح. تُجري المتصفّحات تحسينات معيّنة لتحسين الأداء بطرق لا يمكننا كمطوّرين إجراؤها، ولكن فقط طالما أنّ هذه التحسينات لا يتم إحباطها عن غير قصد.
من بين عمليات تحسين المتصفّح الداخلية التي يجب فهمها هي "أداة الفحص المسبق" في المتصفّح. ستتناول هذه المشاركة طريقة عمل الماسح الضوئي للتحميل المُسبَق، والأهم من ذلك، كيفية تجنُّب اعتراض طريقه.
ما هو الماسح الضوئي للتحميل المُسبَق؟
يحتوي كل متصفّح على محلّل لغوي أساسي لترميز HTML يحلّل الترميز الأولي ويعالجه في نموذج كائن. يستمر هذا الإجراء إلى أن يتوقف المحلل اللغوي مؤقتًا عندما يعثر على مورد حظر، مثل ورقة أنماط تم تحميلها باستخدام عنصر <link>، أو نص برمجي تم تحميله باستخدام عنصر <script> بدون سمة async أو defer.
<link> لملف CSS خارجي، ما يمنع المتصفّح من تحليل بقية المستند، أو حتى عرض أي جزء منه، إلى أن يتم تنزيل CSS وتحليله.
في حالة ملفات CSS، يتم حظر العرض لمنع ظهور المحتوى غير المنسَّق (FOUC)، أي عندما تظهر نسخة غير منسَّقة من الصفحة لفترة وجيزة قبل تطبيق الأنماط عليها.
يحظر المتصفّح أيضًا تحليل الصفحة وعرضها عندما يواجه عناصر <script> بدون سمة defer أو async.
والسبب في ذلك هو أنّ المتصفّح لا يمكنه التأكّد مما إذا كان أي نص برمجي معيّن سيعدّل نموذج DOM بينما لا يزال المحلّل اللغوي الأساسي لـ HTML يؤدي وظيفته. لهذا السبب، من الشائع تحميل JavaScript في نهاية المستند لكي تصبح تأثيرات حظر التحليل والعرض هامشية.
هذه أسباب وجيهة تجعل المتصفّح يجب أن يحظر كلاً من التحليل والعرض. ومع ذلك، فإنّ حظر أي من هاتين الخطوتين المهمتين غير مرغوب فيه، لأنّهما قد تؤديان إلى تأخير العرض من خلال تأخير اكتشاف الموارد المهمة الأخرى. لحسن الحظ، تبذل المتصفّحات قصارى جهدها للتخفيف من هذه المشاكل من خلال محلّل لغوي ثانوي لـ HTML يُعرف باسم أداة فحص التحميل المُسبَق.
<body>، ولكن يمكن لأداة الفحص المسبق للتحميل البحث في الترميز الأولي للعثور على مورد الصورة هذا وبدء تحميله قبل إلغاء حظر المحلل اللغوي الأساسي لـ HTML.
يؤدي الماسح الضوئي للتحميل المُسبَق دورًا تخمينيًا، ما يعني أنّه يفحص الترميز الأولي للعثور على الموارد وجلبها بشكل استباقي قبل أن يكتشفها المحلل اللغوي الأساسي لترميز HTML.
كيفية معرفة ما إذا كان الماسح الضوئي للتحميل المُسبَق يعمل
يتوفّر الماسح الضوئي للتحميل المُسبَق بسبب حظر العرض والتحليل اللغوي. إذا لم تكن هاتان المشكلتان في الأداء موجودتَين، لن تكون أداة الفحص المسبق مفيدة جدًا. يعتمد تحديد ما إذا كانت صفحة الويب تستفيد من الماسح الضوئي للتحميل المُسبق على ظواهر الحظر هذه. لإجراء ذلك، يمكنك إدخال تأخير اصطناعي للطلبات لمعرفة مكان عمل الماسح الضوئي للتحميل المُسبَق.
هذه الصفحة التي تحتوي على نصوص وصور أساسية مع ورقة أنماط هي مثال على ذلك. بما أنّ ملفات CSS تحظر كلاً من العرض والتحليل، يمكنك إدخال تأخير اصطناعي لمدة ثانيتين لورقة الأنماط من خلال خدمة وكيل. يسهّل هذا التأخير معرفة مكان عمل "الماسح الضوئي للتحميل المُسبَق" في العرض الانحداري لطلبات الشبكة.
كما ترى في العرض الانحداري لطلبات الشبكة، تكتشف أداة الفحص المُسبق العنصر <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 خارجيًا، ستحصل على نتيجة غير مثالية:
async تم حقنه. لا يمكن لأداة فحص التحميل المُسبَق اكتشاف النص البرمجي أثناء مرحلة حظر العرض، لأنّه يتم إدخاله على العميل.
لنشرح ما حدث هنا:
- في الثانية 0، يتم طلب المستند الرئيسي.
- عند 1.4 ثانية، يصل البايت الأول من طلب التنقّل.
- في الثانية 2.0، يتم طلب CSS والصورة.
- بما أنّ المحلّل اللغوي محظور من تحميل ورقة الأنماط، وبما أنّ رمز JavaScript المضمّن الذي يضيف نص
asyncالبرمجي يأتي بعد ورقة الأنماط هذه عند 2.6 ثانية، فإنّ الوظيفة التي يوفّرها هذا النص البرمجي لا تكون متاحة في أقرب وقت ممكن.
هذا ليس مثاليًا لأنّ طلب النص البرمجي لا يتم إلا بعد انتهاء تنزيل ورقة الأنماط. يؤدي ذلك إلى تأخير تشغيل النص البرمجي في أقرب وقت ممكن. في المقابل، بما أنّ العنصر <img> قابل للاكتشاف في الترميز الذي يوفّره الخادم، يتم اكتشافه من خلال أداة فحص التحميل المُسبق.
ماذا يحدث إذا استخدمت علامة <script> عادية مع السمة async بدلاً من إدخال النص البرمجي في نموذج العناصر في المستند (DOM)؟
<script src="/yall.min.js" async></script>
وهذه هي النتيجة:
async <script> واحد. يكتشف الماسح الضوئي للتحميل المُسبق النص البرمجي أثناء مرحلة حظر العرض، ويحمّله بالتزامن مع CSS.
قد يميل البعض إلى اقتراح أنّه يمكن حلّ هذه المشاكل باستخدام rel=preload. هذا بالتأكيد سيعمل، لكنه قد يحمل بعض الآثار الجانبية. ففي النهاية، لماذا نستخدم rel=preload لحلّ مشكلة يمكن تجنّبها من خلال عدم إدخال عنصر <script> في نموذج العناصر في المستند (DOM)؟
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 الخاص بالتحميل الكسول وتجميعه وتنفيذه.
واستنادًا إلى حجم الصورة الذي قد يعتمد على حجم إطار العرض، قد تكون الصورة عنصرًا مرشّحًا لمقياس سرعة عرض أكبر محتوى مرئي (LCP). عندما يتعذّر على الماسح الضوئي للتحميل المُسبق جلب مورد الصورة بشكل تخميني قبل الوقت المحدّد، ربما خلال النقطة التي تحظر فيها أوراق أنماط الصفحة العرض، يتأثر مقياس LCP سلبًا.
الحلّ هو تغيير ترميز الصورة:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
هذا هو النمط الأمثل للصور التي تظهر في إطار العرض أثناء بدء التشغيل، لأنّ الماسح الضوئي للتحميل المُسبَق سيكتشف مورد الصورة ويجلبه بسرعة أكبر.
النتيجة في هذا المثال المبسّط هي تحسُّن بمقدار 100 ملي ثانية في مقياس LCP على اتصال بطيء. قد لا يبدو هذا تحسينًا كبيرًا، ولكنّه كذلك عندما تضع في اعتبارك أنّ الحلّ هو إصلاح سريع للترميز، وأنّ معظم صفحات الويب أكثر تعقيدًا من هذه المجموعة من الأمثلة. وهذا يعني أنّ العناصر المرشّحة لتكون "سرعة عرض أكبر جزء من المحتوى على الصفحة" قد تضطر إلى التنافس على معدل نقل البيانات مع العديد من الموارد الأخرى، لذا تصبح التحسينات مثل هذه مهمة بشكل متزايد.
صور الخلفية في CSS
يُرجى العِلم أنّ الماسح الضوئي للتحميل المُسبق في المتصفّح يفحص الترميز. ولا يفحص أنواع الموارد الأخرى، مثل CSS التي قد تتضمّن عمليات جلب للصور التي تشير إليها السمة background-image.
مثل HTML، تعالج المتصفحات CSS في نموذج العناصر الخاص بها، والمعروف باسم CSSOM. إذا تم اكتشاف موارد خارجية أثناء إنشاء CSSOM، يتم طلب هذه الموارد في وقت الاكتشاف، وليس من خلال الماسح الضوئي للتحميل المُسبَق.
لنفترض أنّ العنصر المرشّح ليكون الأكبر محتوًى في صفحتك هو عنصر يتضمّن السمة background-image في CSS. في ما يلي ما يحدث أثناء تحميل الموارد:
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 هذا صغير، ولكنه يساعد المتصفّح في اكتشاف الصورة في وقت أقرب مما كان سيفعله لولا ذلك:
background-image في CSS (الصف 3). يساعد تلميح rel=preload المتصفّح في اكتشاف الصورة قبل حوالي 250 ملي ثانية من اكتشافها بدون التلميح.
باستخدام تلميح rel=preload، يتم اكتشاف المحتوى المرشّح ليكون أكبر محتوى مرئي في وقت أقرب، ما يقلّل من وقت LCP. على الرغم من أنّ هذا التلميح يساعد في حلّ هذه المشكلة، قد يكون الخيار الأفضل هو تقييم ما إذا كان يجب تحميل الصورة المرشّحة لمقياس LCP من CSS أم لا. باستخدام علامة <img>، سيكون لديك المزيد من التحكّم في تحميل صورة مناسبة لإطار العرض مع السماح لأداة فحص التحميل المُسبق باكتشافها.
تضمين عدد كبير جدًا من الموارد
التضمين هو ممارسة تضع موردًا داخل HTML. يمكنك تضمين أوراق الأنماط في عناصر <style> والنصوص البرمجية في عناصر <script> وأي مورد آخر تقريبًا باستخدام ترميز base64.
يمكن أن يكون تضمين الموارد أسرع من تنزيلها لأنّه لا يتم إصدار طلب منفصل للمورد. تظهر هذه المعلومات في المستند مباشرةً ويتم تحميلها على الفور. ومع ذلك، هناك عيوب كبيرة:
- إذا لم تكن تخزّن HTML مؤقتًا، ولا يمكنك إجراء ذلك إذا كانت استجابة HTML ديناميكية، فلن يتم تخزين الموارد المضمّنة مؤقتًا مطلقًا. يؤثر ذلك في الأداء لأنّ الموارد المضمّنة لا يمكن إعادة استخدامها.
- حتى إذا كان بإمكانك تخزين HTML مؤقتًا، لا تتم مشاركة الموارد المضمّنة بين المستندات. يؤدي ذلك إلى تقليل كفاءة التخزين المؤقت مقارنةً بالملفات الخارجية التي يمكن تخزينها مؤقتًا وإعادة استخدامها في مصدر كامل.
- إذا قمت بتضمين الكثير، فإنك تؤخر الماسح الضوئي للتحميل المسبق من اكتشاف الموارد لاحقًا في المستند، لأن تنزيل هذا المحتوى الإضافي المضمّن يستغرق وقتًا أطول.
لنأخذ هذه الصفحة كمثال. في بعض الحالات، يكون العنصر المرشّح لمقياس LCP هو الصورة في أعلى الصفحة، ويكون ملف CSS في ملف منفصل يتم تحميله بواسطة عنصر <link>. تستخدم الصفحة أيضًا أربعة خطوط ويب يتم طلبها كملفات منفصلة من مورد CSS.
<img>، ولكن يتم اكتشافها من خلال الماسح الضوئي للتحميل المُسبق لأنّ ملفات CSS والخطوط المطلوبة للصفحة يتم تحميلها في موارد منفصلة، ما لا يؤدي إلى تأخير الماسح الضوئي للتحميل المُسبق عن أداء عمله.
ماذا يحدث إذا تم تضمين CSS وجميع الخطوط كموارد base64؟
<img>، ولكنّ تضمين CSS وموارد الخطوط الأربعة في `` يؤدي إلى تأخير أداة فحص التحميل المُسبق في اكتشاف الصورة إلى أن يتم تنزيل هذه الموارد بالكامل.
يؤدي تأثير التضمين إلى عواقب سلبية على LCP في هذا المثال، وعلى الأداء بشكل عام. أما نسخة الصفحة التي لا تتضمّن أي محتوى مضمّن، فتعرض صورة LCP في غضون 3.5 ثوانٍ تقريبًا. لا تعرض الصفحة التي تدمج كل شيء صورة LCP إلا بعد مرور أكثر من 7 ثوانٍ بقليل.
هناك المزيد من العوامل التي تؤثر في ذلك، وليس فقط أداة فحص التحميل المُسبَق. لا يُعدّ تضمين الخطوط استراتيجية جيدة لأنّ base64 هو تنسيق غير فعّال للموارد الثنائية. هناك عامل آخر يؤثر في ذلك، وهو أنّ موارد الخطوط الخارجية لا يتم تنزيلها إلا إذا تم تحديدها على أنّها ضرورية من خلال CSSOM. عندما يتم تضمين هذه الخطوط كـ base64، يتم تنزيلها سواء كانت مطلوبة للصفحة الحالية أم لا.
هل يمكن أن يؤدي التحميل المُسبق إلى تحسين الأداء هنا؟ حَسَنًا. يمكنك تحميل صورة LCP مسبقًا وتقليل وقت LCP، ولكنّ تضخيم ملف HTML الذي قد لا يكون قابلاً للتخزين المؤقت باستخدام موارد مضمّنة له عواقب سلبية أخرى على الأداء. يتأثر أيضًا مقياس سرعة عرض أول محتوى مرئي (FCP) بهذا النمط. في إصدار الصفحة الذي لا يتضمّن أي محتوى مضمّن، تبلغ سرعة عرض أول محتوى مرئي (FCP) حوالي 2.7 ثانية. في الإصدار الذي يتم فيه تضمين كل شيء، تبلغ سرعة عرض أول محتوى مرئي (FCP) حوالي 5.8 ثانية.
يجب توخي الحذر الشديد عند تضمين عناصر في HTML، خاصةً الموارد المرمّزة بترميز Base64. بشكل عام، لا يُنصح بذلك، باستثناء الموارد الصغيرة جدًا. استخدِم التضمين بأقل قدر ممكن، لأنّ الإفراط في استخدامه قد يؤدي إلى مشاكل.
عرض الترميز باستخدام JavaScript من جهة العميل
لا شك في أنّ JavaScript تؤثر في سرعة الصفحة. لا يعتمد المطوّرون عليها لتوفير التفاعل فحسب، بل هناك أيضًا ميل للاعتماد عليها لتقديم المحتوى نفسه. يؤدي ذلك إلى تحسين تجربة المطوّرين من بعض النواحي، ولكن المزايا التي يحصل عليها المطوّرون لا تعود دائمًا بالنفع على المستخدمين.
من الأنماط التي يمكن أن تتغلّب على الماسح الضوئي للتحميل المُسبق هو عرض الترميز باستخدام JavaScript من جهة العميل:
عندما تكون حمولات الترميز مضمّنة في JavaScript ويتم عرضها بالكامل من خلاله في المتصفّح، تكون أي موارد في هذا الترميز غير مرئية فعليًا لأداة فحص التحميل المُسبق. ويؤدي ذلك إلى تأخير اكتشاف الموارد المهمة، ما يؤثر بالتأكيد في مقياس LCP. في هذه الأمثلة، يتأخر طلب صورة LCP بشكل كبير مقارنةً بالتجربة المكافئة التي يتم عرضها من خلال الخادم والتي لا تتطلب ظهور JavaScript.
يختلف هذا قليلاً عن تركيز هذه المقالة، ولكن تأثيرات عرض الترميز على العميل تتجاوز بكثير هزيمة الماسح الضوئي للتحميل المُسبق. على سبيل المثال، يؤدي استخدام JavaScript لتشغيل تجربة لا تتطلب ذلك إلى زيادة وقت المعالجة غير الضروري الذي يمكن أن يؤثر في مدى استجابة الصفحة لتفاعلات المستخدم (INP). من المرجّح أن يؤدي عرض كميات كبيرة جدًا من الترميز على العميل إلى إنشاء مهام يستغرق تنفيذها وقتًا طويلاً مقارنةً بكمية الترميز نفسها التي يرسلها الخادم. والسبب في ذلك، بصرف النظر عن المعالجة الإضافية التي تتضمّنها JavaScript، هو أنّ المتصفّحات تبث الترميز من الخادم وتقسّم العرض بطريقة تحدّ من المهام التي يستغرق تنفيذها وقتًا طويلاً. في المقابل، يتم التعامل مع الترميز المعروض من جهة العميل كمهمة واحدة متكاملة، ما قد يؤثر في مقياس INP للصفحة.
يعتمد الحلّ في هذا السيناريو على الإجابة عن السؤال التالي: هل هناك سبب يمنع الخادم من توفير ترميز صفحتك بدلاً من عرضه على العميل؟ إذا كانت الإجابة "لا"، يجب استخدام العرض من جهة الخادم (SSR) أو الترميز الذي يتم إنشاؤه بشكل ثابت حيثما أمكن، لأنّ ذلك سيساعد الماسح الضوئي للتحميل المُسبق في اكتشاف الموارد المهمة وجلبها بشكل استباقي قبل الوقت المحدّد.
إذا كانت صفحتك تحتاج إلى JavaScript لإرفاق وظائف ببعض أجزاء ترميز الصفحة، يمكنك إجراء ذلك باستخدام العرض من جهة الخادم، إما باستخدام JavaScript الأساسية أو الدمج للاستفادة من الميزتَين.
مساعدة الماسح الضوئي للتحميل المُسبَق في مساعدتك
أداة الفحص المسبق هي أداة تحسين فعّالة للغاية للمتصفّح تساعد في تحميل الصفحات بشكل أسرع أثناء بدء التشغيل. من خلال تجنُّب الأنماط التي تعيق قدرة الماسح على اكتشاف الموارد المهمة مسبقًا، لن تجعل عملية التطوير أسهل بالنسبة إليك فحسب، بل ستوفّر أيضًا تجارب أفضل للمستخدمين من شأنها تحقيق نتائج أفضل في العديد من المقاييس، بما في ذلك بعض Web Vitals.
باختصار، إليكم النقاط الرئيسية التي يجب تذكّرها من هذا المنشور:
- "أداة فحص التحميل المُسبق في المتصفّح" هي محلّل لغوي ثانوي لملفات HTML يفحص الصفحات قبل المحلّل اللغوي الأساسي إذا كان محظورًا، وذلك لاكتشاف الموارد التي يمكن جلبها في وقت أقرب.
- لا يمكن لأداة فحص التحميل المُسبق اكتشاف الموارد غير المتوفّرة في الترميز الذي يوفّره الخادم في طلب التنقّل الأولي. قد تشمل الطرق التي يمكن من خلالها إيقاف الماسح الضوئي للتحميل المُسبق ما يلي (على سبيل المثال لا الحصر):
- إدخال الموارد في نموذج DOM باستخدام JavaScript، سواء كانت نصوصًا برمجية أو صورًا أو أوراق أنماط أو أي شيء آخر من الأفضل أن يكون في حمولة الترميز الأولية من الخادم.
- تحميل الصور أو إطارات iframe في الجزء المرئي من الصفحة بشكل بطيء باستخدام حلّ JavaScript
- عرض الترميز على العميل الذي قد يحتوي على مراجع للموارد الفرعية للمستند باستخدام JavaScript
- يفحص الماسح الضوئي للتحميل المُسبَق ملفات HTML فقط. ولا يفحص محتوى الموارد الأخرى، لا سيما CSS، التي قد تتضمّن مراجع لملفات أصول مهمة، بما في ذلك العناصر المرشحة لمقياس LCP.
إذا تعذّر عليك لأي سبب تجنُّب نمط يؤثر سلبًا في قدرة الماسح الضوئي للتحميل المُسبَق على تسريع أداء التحميل، ننصحك باستخدام تلميح المورد rel=preload. إذا كنت تستخدم rel=preload، اختبِرها في أدوات المختبر للتأكّد من أنّها تمنحك التأثير المطلوب. أخيرًا، لا تحمِّل مسبقًا عددًا كبيرًا من الموارد، لأنّك عندما تمنح الأولوية لكل شيء، لن يحصل أي شيء على الأولوية.