الأداء 2 أكتوبر 2026 1 دقائق للقراءة

كيف تُسرّع تلميحات الموارد مثل Preload وPrefetch عملية التصفح

تلميحات preload وprefetch وpreconnect هي وسوم HTML صغيرة يمكنها أن تحسّن فعليًا وقت تحميل الصفحة، إذا عرفت متى تستخدم كل واحدة ومتى تبالغ في استخدامها.

متصفحك أذكى مما يتصور معظم الناس. فهو قادر على البدء في جلب الموارد قبل أن يحتاجها فعليًا، إذا أخبرته بذلك. هذه هي الفكرة الكاملة وراء تلميحات الموارد مثل preload وprefetch وpreconnect وdns-prefetch. إنها وسوم HTML صغيرة تعطي المتصفح فكرة مسبقة عما سيأتي لاحقًا، وعند استخدامها بشكل صحيح، يمكنها أن تختصر مئات أجزاء الثانية من وقت تحميل صفحتك، ضمن جهود تحسين وقت تحميل الصفحة، دون الحاجة لتعديل خادمك أو كودك كثيرًا.

دعنا نوضح ما يفعله كل تلميح فعليًا، ومتى تستخدمه، وأين يخطئ الناس عادةً في استخدامه.

ما الذي تفعله تلميحات الموارد فعليًا

عادةً ما تكتشف المتصفحات الموارد أثناء تحليل HTML سطرًا بسطر. ورقة الأنماط الموضوعة بالقرب من أسفل وسم head يتم طلبها لاحقًا مقارنة بتلك الموجودة في الأعلى. والخط المُشار إليه داخل ملف CSS لا يُطلب إلا بعد أن يكون المتصفح قد حمّل وحلّل ذلك الـCSS. هذا التسلسل التراكمي يتراكم بمرور الوقت.

تلميحات الموارد تتيح لك تجاوز هذا الدور. فأنت تخبر المتصفح: "ستحتاج هذا قريبًا، ابدأ الآن بدلًا من انتظار اكتشافه بشكل طبيعي."

Preload: للموارد التي تعلم أنك تحتاجها الآن

صورتك الأكبر ضمن مقياس Largest Contentful Paint (LCP)، مثل صورة البانر الرئيسية
الخطوط الأساسية التي بدونها قد يظهر وميض نص غير مرئي
ملف CSS أو JS مهم يُكتشف عادةً متأخرًا

إليك مثالًا نموذجيًا لصورة رئيسية:

ومثال لخط:

في الاختبارات العملية، أدى استخدام preload لصورة LCP إلى تقليل زمن LCP بمقدار 300-600 جزء من الثانية في المواقع التي كانت فيها الصورة تُكتشف سابقًا عبر قاعدة background-image في CSS. هذا فرق مهم خاصة أن الحد الذي تعتبره Google "جيدًا" لـLCP هو 2.5 ثانية.

لكن انتبه: preload هو بمثابة وعد. فإذا استخدمته لمورد ما ثم لم تستخدم ذلك المورد فعليًا في الصفحة، سيُظهر Chrome تحذيرًا في الـ console وتكون قد أهدرت النطاق الترددي دون فائدة. استخدم preload فقط للموارد التي تتأكد أن الصفحة تحتاجها فعلًا.

Prefetch: للموارد التي ستحتاجها قريبًا، لكن ليس الآن

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

بعض أطر العمل، مثل Next.js، تقوم بهذا تلقائيًا لأي رابط ظاهر ضمن نطاق الرؤية. إن كنت تبني هذا يدويًا، فمن الأنماط الشائعة تنفيذ prefetch عند التحويم بتأخير قصير (نحو 65 جزء من الثانية) لتجنب إهدار الطلبات بسبب تمرير الماوس العرضي.

مثلًا، تحميل الصفحة التالية في عملية الدفع مسبقًا يمكن أن يجعل الانتقال يبدو فوريًا، لأن HTML وCSS وJS تكون موجودة مسبقًا في ذاكرة التخزين المؤقت للمتصفح وقت نقر المستخدم.

Preconnect وDNS-Prefetch: للمصادر الخارجية

إذا كانت صفحتك تحمّل موارد من نطاقات أخرى (مثل Google Fonts، أو شبكة CDN، أو سكربت تحليلات، أو بوابة دفع)، فعلى المتصفح أن يقوم بعملية DNS lookup ومصافحة TCP وتفاوض TLS قبل أن يبدأ حتى بتحميل أي شيء من ذلك النطاق. وحدها هذه الرحلة يمكن أن تكلف ما بين 100 إلى 300 جزء من الثانية حسب اتصال المستخدم.

preconnect ينفذ كل هذه الخطوات الثلاث مسبقًا:

بينما dns-prefetch هو نسخة أخف تقوم فقط بحل DNS، وهي مفيدة كخيار احتياطي للمتصفحات التي لا تدعم preconnect، أو للمصادر التي لست متأكدًا تمامًا من استخدامها:

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

كم عدد تلميحات الموارد الزائد عن الحد

هنا يخطئ كثير من المطورين ذوي النوايا الحسنة. تلميحات الموارد ليست مجانية. كل واحدة منها تتنافس على النطاق الترددي وفتحات الاتصال مع الموارد التي تحتاجها صفحتك فعليًا الآن.

اقصر استخدام preconnect على 3-4 مصادر خارجية أساسية كحد أقصى
استخدم preload فقط للموارد الظاهرة أعلى الصفحة والتي قد تُكتشف متأخرة لولا ذلك
لا تستخدم prefetch لكل رابط في الصفحة، اختر أهم 1-3 وجهات محتملة تالية
اختبر النتائج عبر لوحة الشبكة في Chrome DevTools للتأكد أن التلميح يغيّر فعليًا توقيت الطلبات

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

قياس الأثر

لا تخمّن، بل قِس. شغّل صفحتك عبر Lighthouse أو WebPageTest قبل وبعد إضافة التلميحات، وراقب هذه الأرقام تحديدًا:

الوقت حتى أول بايت (TTFB) - لا يتأثر بتلميحات الموارد، لكن من المفيد وجوده كخط أساس للمقارنة
Largest Contentful Paint (LCP) - يجب أن ينخفض عند استخدام preload بشكل صحيح لمورد LCP
Total Blocking Time (TBT) - راقب أي تراجع إذا استخدمت preload لكمية كبيرة من JS

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

أين يندرج هذا ضمن WordPress

إذا كنت تدير موقع WordPress، فلست بحاجة بالضرورة لكتابة هذه الوسوم يدويًا. أدوات التحسين الجيدة تتعامل مع preload الخاص بـLCP والخطوط كإعداد قابل للتخصيص، بحيث يمكنك تحديد صورتك الرئيسية أو خطوطك الأساسية دون تعديل ملفات القالب. وهذا بالضبط ما قمنا ببنائه ضمن لوحة التحكم الخاصة بالتحسين لدينا، حيث يتيح لك تبويب Preload وLCP إعداد هذا الأمر بنقرتين بدلًا من البحث داخل قالب header الخاص بموقعك.

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

الخلاصة

تلميحات الموارد رخيصة الإضافة، وعند استخدامها بتمعّن، فعّالة حقًا في تحسين وقت تحميل الصفحة. استخدم preload لما تحتاجه الصفحة الحالية الآن. استخدم prefetch لما سينقر عليه المستخدم على الأرجح لاحقًا. استخدم preconnect لعدد قليل من المصادر الخارجية التي لا يمكنك تجنبها. وقس النتائج دائمًا قبل وبعد، لأن الخط الفاصل بين "تلميح مفيد" و"نطاق ترددي مهدر" أرفع مما يبدو.

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