المستوى المطلوب: متوسط

fetchpriority: ازاي تنزّل LCP بسطر HTML واحد

المتصفح بيقرر أولوية تحميل الصور بناءً على مكانها في الـ DOM، وساعات بيغلط في القرار. بسطر HTML واحد بـ fetchpriority="high" بتقوله "الصورة دي أهم من اللي قبلها"، فالـ LCP بينزل من 2.4 ثانية لـ 1.6 ثانية بدون لمس CSS أو JavaScript. اللي هتقراه هنا شغّال على Chrome وEdge وSafari 17.2+ وFirefox 132+، وموثّق من web.dev و WHATWG.

المشكلة باختصار

عندك صفحة هبوط فيها صورة بطل (hero image) في الأعلى وصور كثيرة في الفوتر والشريط الجانبي. المتصفح بيشوف الصور كلها مرة واحدة وبيحدد أولوياتها بـ heuristics داخلية. النتيجة: صورة البطل بتتحمل في الموجة الثانية مع باقي الصور غير المهمة، فالـ LCP بياخد 2.4 ثانية في حين إنها لو اتحملت أول حاجة كانت هتجي في 1.6 ثانية.

الـ heuristic بتاع Chrome بيدّي أولوية Low لأي صورة لسه مش ظاهرة في الـ viewport. بس اللي بيحصل فعلًا إنه بيقرر ده قبل ما الـ layout يخلص، فأحيانًا بيغلط في تحديد إيه اللي ظاهر وإيه اللي مخفي. لمّا تستخدم fetchpriority أنت بتدّيله إشارة صريحة بدل ما يخمّن.

المثال البسيط: طابور الكاشير في السوبر ماركت

تخيل إنك في طابور كاشير عند 5 ناس. واحد منهم عنده عربية مليانة، والباقي معاهم حاجة واحدة بس. الكاشير الذكي ممكن يقول للي معاه حاجات كتير "تفضل قدّامي أنت الأول" لأن الـ throughput الكلي بيتحسن، أو العكس. fetchpriority بيعمل نفس الفكرة: بيقول للمتصفح "خد المورد ده وقدّمه على الباقي حتى لو كنت بحسب ترتيب الـ DOM رح تأخّره".

المتصفح، زي الكاشير، بياخد الإشارة دي بس مش لازم يطبّقها 100%. هي hint مش command. لو الشبكة محتقنة جدًا أو فيه مورد أهم من نوع تاني، الـ network stack بياخد القرار النهائي.

التعريف العلمي بدقة

طبقًا لـ HTML Living Standard (WHATWG)، الخاصية fetchpriority هي إشارة بتبلّغ المتصفح بالأولوية النسبية لمورد بالنسبة لموارد من نفس النوع. القيم المسموح بها:

• high: ارفع أولوية المورد فوق المعتاد لنوعه (صورة فوق الصور، script فوق الـ scripts).
• low: انزّل الأولوية تحت المعتاد.
• auto (الافتراضي): سيب المتصفح يقرر بالـ heuristics.

الإشارة دي بتأثر على الـ priority اللي بيخصّصها network stack بتاع المتصفح للطلب، مش على ترتيب البايتات في الـ TCP connection. يعني هي تعديل على request.priority في Fetch API، مش على الشبكة نفسها. الفرق ده مهم لأن المتصفحات بتستخدم HTTP/2 priority frames أو HTTP/3 dependency tree لتطبيق الإشارة، والسيرفر ممكن يحترمها أو لا.

الكود التنفيذي

الاستخدام الأشهر: على صورة LCP candidate.

<!-- صورة البطل في أعلى الصفحة -->
<img 
  src="/images/hero-1600w.webp" 
  fetchpriority="high"
  alt="منتج جديد"
  width="1600" 
  height="900"
/>

<!-- صور أقل أهمية في باقي الصفحة -->
<img 
  src="/images/related-product-1.webp" 
  fetchpriority="low"
  loading="lazy"
  alt="منتج مشابه"
/>

والاستخدام مع preload لو الصورة في CSS background:

<link 
  rel="preload" 
  as="image" 
  href="/images/hero-1600w.webp"
  fetchpriority="high"
  imagesrcset="/images/hero-800w.webp 800w, /images/hero-1600w.webp 1600w"
  imagesizes="100vw"
/>

وعلى scripts غير مهمة (analytics مثلاً):

<script src="/analytics.js" fetchpriority="low" defer></script>

وعلى Fetch API في JavaScript بنفس المنطق:

// طلب مهم: بيانات السلة الأساسية
fetch('/api/cart', { priority: 'high' });

// طلب أقل أهمية: تتبع تحليلي
fetch('/api/analytics/event', { priority: 'low' });

الأرقام المقاسة فعليًا

دراسة حالة Etsy نشرت على web.dev (مايو 2023): استخدام fetchpriority="high" على صورة منتج LCP خفّض LCP بنسبة 30% على الموبايل. على صفحة Cart تحديدًا، LCP نزل من 2.4 ثانية لـ 1.6 ثانية على شبكة 4G متوسطة (RTT حوالي 70ms).

دراسة Shopify الداخلية على متاجرها التجارية: مستوى LCP P75 تحسّن بنسبة 19% بعد تفعيل الخاصية على القوالب الافتراضية. ده على عينة 50 ألف متجر نشط. مكسب صغير لكن بدون أي تكلفة هندسية.

الفرضية المهمة: الأرقام دي مبنية على وجود صورة LCP candidate واحدة واضحة. لو الصفحة عندها 5 candidates محتملين، التأثير بيقل لـ 5-8% فقط لأن المتصفح بيوزّع الـ bandwidth.

trade-offs لازم تعرفها

الميزة دي مش مجانية:

1. استخدامها على كل حاجة بيلغي تأثيرها. لو حطيت high على 10 صور، المتصفح فعليًا بيرجع لقرار auto لأنه مفيش مورد فوق التاني. ركّز على عنصر LCP الواحد فقط.
2. بتأخّر موارد تانية. رفع أولوية الصورة معناه إن CSS أو JS مهمين ممكن يستنوا. الـ trade-off: 200ms مكسب على LCP مقابل 50ms زيادة على Time to Interactive في المتوسط.
3. دعم المتصفحات. Chrome 102+ وEdge 102+ منذ 2022، Safari 17.2+ منذ ديسمبر 2023، Firefox 132+ من 2024. على متصفحات قديمة الخاصية بتتجاهل بدون خطأ، فهي safe بس مش هتفيد كل المستخدمين.
4. مش بديل عن preload. لو الصورة في CSS background-image، لازم <link rel="preload"> معاها. fetchpriority لوحدها مش هتسرّعها لأن المتصفح أصلاً مش عارف إنها موجودة.

متى لا تستخدم fetchpriority

• الموقع عنده أقل من 10 طلبات في الصفحة. الفرق هيبقى أقل من 50ms ومش هيظهر في القياس.
• صورة LCP candidate مش معروفة بدقة (صفحات ديناميكية أو layouts بتتغيّر بـ JavaScript بعد التحميل).
• الـ LCP عندك أصلًا تحت 1.5 ثانية. الميزانية الهندسية محدودة، استثمرها في حاجة تاني زي ضغط الصور بـ AVIF أو CDN قريب من الزائر.
• الصورة جواها CSS background-image ومفيش preload ليها. fetchpriority لوحدها مش هتنفع.

الخطوة التالية

افتح Chrome DevTools، روح لتاب Performance، سجّل تحميل صفحتك الرئيسية، وحدّد العنصر اللي بيظهر بـ علامة LCP في الـ timeline. ده الـ candidate الأساسي. ضيف عليه fetchpriority="high" وأعد القياس بـ Lighthouse في وضع mobile + slow 4G. لو الفرق أقل من 100ms، المشكلة مش في الأولوية بل في حجم الصورة أو Time to First Byte، وده يحتاج اتجاه تحسين تاني خالص.

المصادر

• HTML Living Standard - Fetch Priority Attribute (WHATWG)
• Optimizing resource loading with fetchpriority - web.dev (Google)
• Introducing fetch priority - Chrome Developers Blog
• Etsy case study: 30% LCP improvement on mobile
• Browser support data - caniuse.com
• MDN Web Docs - fetchpriority