تعرَّف على ماسح التحميل المُسبَق في المتصفّح وكيف يساعد في تحسين الأداء وكيف يمكنك تجنُّب إعاقته.
أحد الجوانب التي يتم تجاهلها عند تحسين سرعة الصفحة هو معرفة بعض التفاصيل الداخلية للمتصفح. تُجري المتصفّحات بعض التحسينات لتحسين الأداء بطرق لا يمكننا كمطوّرين تنفيذها، ولكن فقط طالما أنّ هذه التحسينات لا يتم إحباطها عن غير قصد.
أحد التحسينات الداخلية للمتصفّح التي يجب معرفتها هو أداة فحص التحميل المُسبَق للمتصفّح. ستتناول هذه المشاركة طريقة عمل أداة الفحص المسبق للتحميل، والأهم من ذلك، كيفية تجنُّب إعاقة عملها.
ما هو ماسح التحميل المُسبَق؟
يحتوي كل متصفّح على محلّل 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 ثانية، يصل البايت الأول من طلب التنقّل.
- بعد مرور ثانيتَين، يتم طلب 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). عندما يتعذّر على فاحص التحميل المُسبَق جلب مصدر الصورة بشكل تخميني قبل الوقت المحدد، ربما خلال النقطة التي تحظر فيها أوراق الأنماط في الصفحة العرض، تتأثر سرعة عرض أكبر محتوى مرئي.
الحلّ هو تغيير ترميز الصورة:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
هذا هو النمط الأمثل للصور التي تظهر في إطار العرض أثناء بدء التشغيل، لأنّ أداة فحص التحميل المُسبَق ستعثر على مورد الصورة وتجلبه بشكل أسرع.
في هذا المثال المبسّط، تكون النتيجة تحسُّنًا بمقدار 100 ملي ثانية في سرعة LCP على اتصال بطيء. قد لا يبدو هذا تحسّنًا كبيرًا، ولكنّه كذلك عندما تأخذ في الاعتبار أنّ الحلّ هو إصلاح سريع للترميز، وأنّ معظم صفحات الويب أكثر تعقيدًا من هذه المجموعة من الأمثلة. وهذا يعني أنّ عناصر LCP المرشّحة قد تضطر إلى التنافس على معدّل نقل البيانات مع العديد من الموارد الأخرى، لذا تصبح عمليات التحسين من هذا النوع مهمة بشكل متزايد.
صور الخلفية بلغة CSS
تذكَّر أنّ فاحص التحميل المسبق في المتصفّح يفحص الترميز. ولا يفحص أنواع الموارد الأخرى، مثل CSS التي قد تتضمّن عمليات جلب للصور المشار إليها بواسطة السمة background-image.
مثل HTML، تعالج المتصفحات CSS في نموذج عناصر خاص بها، يُعرف باسم CSSOM. إذا تم العثور على موارد خارجية أثناء إنشاء CSSOM، يتم طلب هذه الموارد في وقت العثور عليها، وليس من خلال أداة فحص التحميل المُسبَق.
لنفترض أنّ عنصر LCP المرشّح في صفحتك هو عنصر يتضمّن السمة background-image في CSS. في ما يلي ما يحدث أثناء تحميل الموارد:
background-image في CSS (الصف 3). لا يبدأ جلب الصورة التي يطلبها إلا بعد أن يعثر عليها محلّل CSS.
في هذه الحالة، لا يتم إيقاف الماسح الضوئي للتحميل المُسبَق، بل لا يتم استخدامه. مع ذلك، إذا كان العنصر المرشّح لمقياس LCP على الصفحة من خاصية background-image CSS، عليك تحميل تلك الصورة مسبقًا:
<!-- 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) أيضًا بهذا النمط. في إصدار الصفحة الذي لا يتم فيه تضمين أي محتوى، تبلغ سرعة عرض المحتوى على الصفحة حوالي 2.7 ثانية. في الإصدار الذي يتم فيه تضمين كل شيء، تبلغ سرعة عرض أول محتوى مرئي (FCP) حوالي 5.8 ثانية.
يجب توخّي الحذر الشديد عند تضمين عناصر في HTML، خاصةً الموارد المرمّزة بـ base64. لا يُنصح بذلك بشكل عام، باستثناء الموارد الصغيرة جدًا. استخدِم التضمين بأقل قدر ممكن، لأنّ الإفراط في التضمين قد يؤدي إلى مشاكل.
عرض الترميز باستخدام JavaScript من جهة العميل
لا شك في أنّ JavaScript يؤثّر في سرعة الصفحة. ولا يعتمد المطوّرون على هذه التقنية لتوفير التفاعل فحسب، بل هناك أيضًا ميل إلى الاعتماد عليها لتقديم المحتوى نفسه. يؤدي ذلك إلى تحسين تجربة المطوّرين في بعض النواحي، ولكن لا تتحوّل مزايا المطوّرين دائمًا إلى مزايا للمستخدمين.
أحد الأنماط التي يمكن أن تتغلّب على فاحص التحميل المسبق هو عرض الترميز باستخدام JavaScript من جهة العميل:
عندما يتم تضمين حمولات الترميز وعرضها بالكامل باستخدام JavaScript في المتصفّح، تكون أي موارد في هذا الترميز غير مرئية بشكل فعّال لأداة فحص التحميل المُسبَق. يؤدي ذلك إلى تأخير العثور على الموارد المهمة، ما يؤثّر بالتأكيد في مقياس LCP. في هذه الأمثلة، يتأخر طلب صورة أكبر عنصر مرئي في محتوى الصفحة بشكل كبير مقارنةً بتجربة العرض المكافئة من جهة الخادم التي لا تتطلب ظهور JavaScript.
يختلف هذا قليلاً عن تركيز هذه المقالة، ولكن تأثيرات عرض الترميز على العميل تتجاوز بكثير إيقاف عمل أداة الفحص المسبق. على سبيل المثال، يؤدي إدخال JavaScript لتوفير تجربة لا تتطلّب ذلك إلى إدخال وقت معالجة غير ضروري يمكن أن يؤثر في مدى استجابة الصفحة لتفاعلات المستخدم (INP). من المرجّح أن يؤدي عرض كميات كبيرة جدًا من الترميز على العميل إلى إنشاء مهام طويلة مقارنةً بإرسال الكمية نفسها من الترميز بواسطة الخادم. والسبب في ذلك، بالإضافة إلى المعالجة الإضافية التي تتضمّنها JavaScript، هو أنّ المتصفّحات تبث الترميز من الخادم وتقسّم عملية العرض بطريقة تحدّ من المهام الطويلة. من ناحية أخرى، يتم التعامل مع الترميز المعروض من جهة العميل كمهمة واحدة ومتكاملة، ما قد يؤثر في مقياس INP للصفحة.
يعتمد الحلّ لهذه الحالة على الإجابة عن السؤال التالي: هل هناك سبب لعدم إمكانية توفير الترميز الخاص بصفحتك من خلال الخادم بدلاً من عرضه على العميل؟ إذا كانت الإجابة "لا"، يجب مراعاة العرض من جهة الخادم (SSR) أو الترميز الذي يتم إنشاؤه بشكل ثابت حيثما أمكن، لأنّ ذلك سيساعد أداة فحص التحميل المُسبَق في العثور على الموارد المهمة وجلبها بشكل انتهازي مسبقًا.
إذا كانت صفحتك تحتاج إلى JavaScript لربط وظائف ببعض أجزاء ترميز الصفحة، يمكنك إجراء ذلك باستخدام العرض من جهة الخادم، إما باستخدام JavaScript العادي أو تحويل صفحة ويب ثابتة إلى صفحة ديناميكية للاستفادة من مزايا الطريقتين.
مساعدة ماسح التحميل المُسبَق في مساعدتك
ماسح التحميل المُسبَق هو أداة فعّالة جدًا لتحسين المتصفّح وتساعد في تحميل الصفحات بشكل أسرع أثناء بدء التشغيل. من خلال تجنُّب الأنماط التي تعيق قدرة المتصفّح على اكتشاف الموارد المهمة مسبقًا، لن تسهّل عملية التطوير على نفسك فحسب، بل ستوفّر أيضًا تجارب أفضل للمستخدمين تؤدي إلى تحسين العديد من المقاييس، بما في ذلك بعض مؤشرات أداء الويب.
في ما يلي النقاط الرئيسية التي يجب استخلاصها من هذه المشاركة:
- فاحص التحميل المُسبق في المتصفّح هو محلّل ثانوي لملفات HTML، وهو يبحث قبل المحلّل الأساسي إذا كان محظورًا لاكتشاف الموارد التي يمكنه جلبها بشكل أسرع.
- لا يمكن لأداة فحص التحميل المُسبَق اكتشاف الموارد غير المتوفّرة في الترميز الذي يقدّمه الخادم عند طلب التنقّل الأوّلي. قد تشمل طرق إيقاف عمل أداة الفحص المسبق (على سبيل المثال لا الحصر) ما يلي:
- إضافة موارد إلى DOM باستخدام JavaScript، سواء كانت نصوصًا برمجية أو صورًا أو أوراق أنماط أو أي شيء آخر من الأفضل تضمينه في حمولة الترميز الأولية من الخادم
- التحميل الكسول للصور أو إطارات iframe الظاهرة على الشاشة باستخدام حلّ JavaScript
- عرض الترميز على العميل الذي قد يحتوي على مراجع إلى موارد فرعية للمستند باستخدام JavaScript
- يفحص برنامج التحميل المسبق HTML فقط. ولا يفحص محتوى الموارد الأخرى، وخاصةً CSS، التي قد تتضمّن إشارات إلى مواد عرض مهمة، بما في ذلك العناصر المرشّحة لمقياس سرعة عرض أكبر محتوى مرئي (LCP).
إذا تعذّر عليك لأي سبب تجنُّب نمط يؤثر سلبًا في قدرة أداة فحص التحميل المُسبَق على تسريع أداء التحميل، ننصحك باستخدام تلميح المورد rel=preload. إذا كنت تستخدم rel=preload، اختبِرها في أدوات المختبر للتأكّد من أنّها تحقّق التأثير المطلوب. أخيرًا، لا تحمّل عددًا كبيرًا جدًا من الموارد مسبقًا، لأنّه عندما تمنح الأولوية لكل شيء، لن يكون هناك أي شيء مهم.
الموارد
- "النصوص البرمجية غير المتزامنة" التي تم حقنها بنصوص برمجية تعتبر ضارة
- كيف تساهم ميزة "التحميل المُسبَق في المتصفّح" في زيادة سرعة تحميل الصفحات؟
- التحميل المُسبَق للموارد المهمة لتحسين سرعة التحميل
- إنشاء اتصالات الشبكة مبكرًا لتحسين سرعة الصفحة الظاهرية
- تحسين سرعة عرض أكبر محتوى مرئي
الصورة الرئيسية من Unsplash، من تصوير محمد رحماني .