في عالم أداء الويب لعام 2026، لم تعد تحسينات Core Web Vitals تتطلب بالضرورة إعادة هيكلة معقدة أو أدوات بناء متطورة. صدقاً، أحياناً يكفي سطر HTML واحد ليُحدث فرقاً ملموساً في سرعة موقعك. وسمة fetchpriority هي بالضبط هذا النوع من الأدوات — تلميح بسيط يُخبر المتصفح بأولوية كل مورد، ويمكن أن يخفض زمن Largest Contentful Paint (LCP) بنسبة تصل إلى 30% دون أي تغيير في بنيتك التحتية.
في هذا الدليل، سأشرح لك كيف تعمل هذه السمة، ومتى تستخدمها (والأهم: متى لا تستخدمها)، مع أمثلة كود عملية ودراسات حالة من Google Flights و Etsy و Oodle، ثم قسم أسئلة شائعة يجيب عن أكثر الاستفسارات تكراراً في 2026.
ما هي سمة fetchpriority؟
باختصار، سمة fetchpriority هي تلميح (hint) HTML يُخبر المتصفح بالأهمية النسبية لمورد معين مقارنة بباقي الموارد على الصفحة. يمكنك استخدامها على العناصر التالية:
<img>للصور<link>لملفات CSS و preload<script>لملفات JavaScript<iframe>للإطارات المضمّنةfetch()عبر JavaScript
الفكرة الجوهرية بسيطة: المتصفح يمتلك نظام أولويات داخلي لتحميل الموارد. عادةً ما تُحمّل ملفات CSS و JavaScript في المستند بأولوية عالية، بينما تُحمّل الصور بأولوية منخفضة افتراضياً — حتى تلك التي تمثل LCP (نعم، حتى هي). وسمة fetchpriority تمنحك القدرة على تجاوز هذا الترتيب الافتراضي.
ملاحظة مهمة: هي تلميح وليست أمراً. المتصفح يحاول احترام رغبتك، لكنه قد يتجاهلها إذا تعارضت مع سياسات التحميل الداخلية. (تذكّر هذا جيداً قبل أن تلوم السمة على عدم عملها.)
دعم المتصفحات في 2026
اعتباراً من 2026، سمة fetchpriority مدعومة بالكامل في جميع المتصفحات الحديثة:
- Chrome و Edge منذ الإصدار 102
- Safari منذ الإصدار 17.2
- Firefox منذ الإصدار 132
- Samsung Internet و Opera وكل المتصفحات المبنية على Chromium
وفي حال استخدام متصفح قديم لا يدعم السمة، لن يحدث أي خطأ — سيتجاهلها المتصفح ببساطة ويعود إلى السلوك الافتراضي. هذا بالضبط ما يجعلها تحسيناً تدريجياً (progressive enhancement) آمناً تماماً للإنتاج.
كيف يُرتّب المتصفح أولويات الموارد؟
قبل أن نستخدم fetchpriority، دعنا نفهم كيف يعمل نظام الأولويات الداخلي للمتصفح. في Chromium، تُصنّف الموارد إلى خمسة مستويات:
- Highest — مستند HTML الرئيسي
- High — CSS والخطوط (في حال الاكتشاف المبكر)
- Medium — سكربتات async/defer بعد الاكتشاف
- Low — الصور في البداية (قبل اكتشاف وجودها ضمن منطقة العرض)
- Lowest — صور lazy وموارد خارج الصفحة
الجزء المثير للاهتمام هنا: عندما تكون صورة LCP ضمن منطقة العرض (viewport)، يبدأ تحميلها بأولوية Low، ثم بعد اكتمال التخطيط (layout) يكتشف المتصفح أنها مرئية ويرفع أولويتها إلى High. هذا التأخير — الفجوة بين اكتشاف الصورة وترقية أولويتها — هو بالضبط ما تُقضي عليه سمة fetchpriority="high". ومن تجربتي الشخصية، هذه الفجوة قد تكلّف مئات المللي ثوانٍ على اتصال متوسط.
القيم الثلاث: high و low و auto
high — رفع الأولوية
استخدمها للموارد الحرجة التي تؤثر مباشرة على التجربة المرئية الأولى (above-the-fold)، مثل صورة Hero أو خط رئيسي.
low — خفض الأولوية
استخدمها للموارد غير الحرجة التي لا تحتاج إلى تحميل فوري، مثل صور Carousel خارج الشاشة أو سكربتات تحليلية ثانوية.
auto — السلوك الافتراضي
هي القيمة الافتراضية إذا لم تُحدد السمة. المتصفح يتخذ القرار بنفسه بناءً على نوع المورد وسياقه. غالباً ما تكون كافية، لكن ليس دائماً.
المثال الأساسي: تسريع صورة LCP
في معظم المواقع، صورة Hero أو صورة المنتج الرئيسية هي عنصر LCP. إضافة fetchpriority="high" لها يُحدث فرقاً فورياً:
<img
src="/hero-banner.webp"
alt="Hero banner"
width="1200"
height="600"
fetchpriority="high"
loading="eager"
/>لاحظ أنني أضفت أيضاً loading="eager" بشكل صريح. هذا ليس ضرورياً تقنياً (لأنه السلوك الافتراضي على أي حال)، لكنه يُوضح النية ويمنع أي أداة بناء من تحويله عن طريق الخطأ إلى lazy. وقد رأيت هذا يحصل في مشاريع Next.js أكثر من مرة.
مع عنصر picture
عند استخدام <picture> لعرض صور متجاوبة، ضع السمة على عنصر <img> الداخلي:
<picture>
<source
media="(max-width: 600px)"
srcset="/hero-mobile.webp"
type="image/webp"
/>
<source
media="(min-width: 601px)"
srcset="/hero-desktop.webp"
type="image/webp"
/>
<img
src="/hero-fallback.jpg"
alt="Hero"
width="1200"
height="600"
fetchpriority="high"
/>
</picture>دمج fetchpriority مع preload
تخيّل هذا السيناريو: صورة LCP مُعلنة عبر background-image في CSS. المتصفح لن يكتشفها إلا بعد تحميل وتحليل CSS، وهذا يعني تأخيراً مزعجاً. الحل هو تلميح preload في الـ <head> مع رفع الأولوية:
<link
rel="preload"
as="image"
href="/hero-background.webp"
fetchpriority="high"
/>بهذه الطريقة، يبدأ المتصفح تحميل الصورة فوراً، بأعلى أولوية ممكنة، قبل أن يلمس CSS حتى.
تحذير: لا تخلط بين preload و fetchpriority. الأول يُجبر المتصفح على الاكتشاف المبكر للمورد، والثاني يُحدد أولويته بعد الاكتشاف. إنهما يعملان معاً، لا بديلاً عن بعضهما. ويمكنك استخدام كليهما معاً للحصول على أقوى تأثير.
خفض أولوية الموارد غير الحرجة
وهنا يكمن سرّ لا ينتبه إليه كثيرون: القوة الحقيقية لـ fetchpriority ليست فقط في رفع الأولويات، بل في خفضها. كل مورد تُقلل أولويته يُحرر نطاق تردد (bandwidth) للموارد المهمة.
مثال: صور Carousel خارج الشاشة
<div class="carousel">
<img src="/slide-1.webp" fetchpriority="high" alt="Slide 1" />
<img src="/slide-2.webp" fetchpriority="low" alt="Slide 2" />
<img src="/slide-3.webp" fetchpriority="low" alt="Slide 3" />
<img src="/slide-4.webp" fetchpriority="low" alt="Slide 4" />
</div>الشريحة الأولى (المرئية) تأخذ أولوية عالية، والباقي أولوية منخفضة. هذا السيناريو بالضبط طبّقه تطبيق Oodle وحقق انخفاضاً بقيمة ثانيتين في زمن تحميل الصفحة. ثانيتان كاملتان — من إضافة كلمتين إلى كل وسم img.
التحكم بأولوية السكربتات
السكربتات المعلنة بـ async أو defer تُحمّل بأولوية منخفضة افتراضياً. إذا كان سكربت ما مهماً للتفاعل الأولي (مثل سكربت A/B testing الذي يُحدد ماذا يظهر للمستخدم)، يمكن رفع أولويته:
<script
src="/ab-testing.js"
async
fetchpriority="high"
></script>
<script
src="/analytics.js"
defer
fetchpriority="low"
></script>هذا النمط في رأيي أفضل دلالياً من استخدام <link rel="preload" as="script">، لأن fetchpriority يُعبّر عن النية بوضوح دون اختراع حيلة.
استخدام fetchpriority في JavaScript Fetch API
يمكنك أيضاً التحكم بأولوية الطلبات التي تُنشأ عبر JavaScript باستخدام الخاصية priority:
// طلب حرج لبيانات LCP
const criticalData = await fetch('/api/product-details', {
priority: 'high'
}).then(r => r.json());
// طلب تحليلي غير حرج
fetch('/api/analytics/event', {
method: 'POST',
priority: 'low',
body: JSON.stringify({ event: 'page_view' })
});هذا مفيد بشكل خاص في تطبيقات SPA حيث تُحمَّل البيانات ديناميكياً بعد التحميل الأول للصفحة — وحيث كل مللي ثانية في الطلبات الأولى تعني شاشة فارغة.
fetchpriority مقابل loading="eager"
حسناً، هذا أحد أكثر المفاهيم التي يلتبس فيها المطورون في 2026. السمتان تُعالجان مشكلتين مختلفتين تماماً:
| السمة | الوظيفة | التأثير على الأولوية |
|---|---|---|
loading="eager" |
تمنع التحميل الكسول (lazy) | لا تُغيّر الأولوية — تبقى Low حتى يكتمل التخطيط |
fetchpriority="high" |
ترفع الأولوية إلى High فوراً | تُغيّر الأولوية من البداية دون انتظار |
الخلاصة: لصورة LCP، استخدم الاثنتين معاً: loading="eager" fetchpriority="high". هذا يضمن أن الصورة لا تُحمّل بشكل كسول، وأن تبدأ بأولوية عالية منذ اللحظة الأولى.
دراسات حالة: أرقام حقيقية من 2026
Google Flights
بعد إضافة fetchpriority="high" لصورة Hero الرئيسية، انخفض LCP من 2.6 ثانية إلى 1.9 ثانية — تحسّن بنسبة 27% من سطر HTML واحد. (نعم، سطر واحد.)
Etsy
طبّق فريق Etsy السمة عبر جميع صفحات الموقع ورصد تحسناً متوسطاً بنسبة 4% في LCP على مستوى المستخدمين الحقيقيين (RUM). وفي اختبارات المختبر على صفحات محددة، كان التحسّن بين 20% و 30%. الفرق بين RUM ومختبر هنا مفهوم: المختبر يقيس في ظروف مثالية، بينما RUM يعكس تنوّع الأجهزة والاتصالات الحقيقية.
Oodle App
باستخدام fetchpriority="low" على صور Carousel خارج الشاشة، انخفض زمن تحميل الصفحة الكامل بمقدار ثانيتين تقريباً، دون أي تحسين آخر.
الأخطاء الشائعة وكيف نتجنبها
1. استخدام high على كل شيء
إذا كان كل شيء عالي الأولوية، فلا شيء عالي الأولوية فعلاً. اختر موردين أو ثلاثة موارد حرجة فقط (عادةً صورة LCP وربما خط رئيسي). هذا درس تعلمته بالطريقة الصعبة في مشروع سابق.
2. تحميل صورة LCP بشكل كسول
هذا هو الخطأ الأكثر شيوعاً. loading="lazy" على صورة LCP يُلغي أي تحسين. Lighthouse في 2026 يرفع تحذيراً صريحاً لأي صورة LCP لا تحتوي على fetchpriority="high".
3. استخدام fetchpriority بدل preload للموارد المخفية في CSS
إذا كان المورد معلناً في CSS فقط، فالمتصفح لن يكتشفه مبكراً بغض النظر عن الأولوية. يجب استخدام <link rel="preload"> للاكتشاف المبكر، مع إضافة fetchpriority="high" للأولوية.
4. نسيان width و height
صورة LCP بدون أبعاد صريحة تُسبب Layout Shift وتُضر بمقياس CLS. دائماً أضف width و height حتى مع fetchpriority="high". هذه قاعدة لا تتفاوض عليها.
5. الاعتماد على CDN لاحترام الأولويات في HTTP/2
ليست كل شبكات CDN تحترم تلميحات أولوية HTTP/2. الخبر الجيد أن الترتيب الداخلي للمتصفح يُولّد معظم الفائدة، بصرف النظر عن سلوك CDN.
التصحيح في Chrome DevTools
للتأكد من أن التلميحات تعمل كما هو متوقع:
- افتح DevTools ← تبويب Network
- بالنقر بالزر الأيمن على رأس الجدول، فعّل عمود Priority
- حمّل الصفحة وافحص الأولويات الفعلية
- تحقق من أن صورة LCP لها أولوية High منذ البداية، وليس بعد ترقية لاحقة
في حال ظهرت ترقية أولوية متأخرة (مثل "Low to High")، هذا مؤشر واضح على فرصة ضائعة — يجب ضبط fetchpriority من البداية لا بعدها.
قائمة تحقق سريعة لتطبيق fetchpriority في 2026
- ضع
fetchpriority="high"على صورة LCP - أضف
loading="eager"صراحةً لصورة LCP - استخدم
widthوheightلمنع Layout Shift - لصور CSS background، اجمع بين
preloadوfetchpriority="high" - خفّض أولوية صور Carousel خارج الشاشة بـ
fetchpriority="low" - استخدم
fetchpriority="high"للسكربتات async الحرجة فقط - افحص أعمدة Priority في DevTools بعد التطبيق
- قِس LCP قبل وبعد التغيير باستخدام WebPageTest أو CrUX
الأسئلة الشائعة
هل يعمل fetchpriority مع صور WebP و AVIF؟
نعم. السمة لا تهتم بصيغة الصورة — فهي تتعلق بأولوية الطلب، لا بمحتواه. يمكن استخدامها مع أي صيغة: JPG، PNG، WebP، AVIF، أو حتى SVG.
هل أحتاج إلى preload إذا استخدمت fetchpriority على عنصر img؟
في معظم الحالات، لا. fetchpriority="high" على <img> المصرّح به في HTML يكفي، لأن parser المتصفح يكتشف العنصر مبكراً. preload مطلوب فقط للموارد المخفية (مثل صور CSS background) أو عندما تريد البدء قبل الوصول إلى العنصر في HTML.
ما الفرق بين fetchpriority و Priority Hints؟
في 2026، المصطلحان يُستخدمان بالتبادل. "Priority Hints" هو الاسم الأصلي للميزة عند إطلاقها، وfetchpriority هو اسم السمة الفعلية في HTML. الـ API نفسه في JavaScript يستخدم الخاصية priority في كائن options الخاص بـ fetch().
هل يمكن استخدام fetchpriority داخل إطار iframe؟
نعم، يمكنك استخدامها على عنصر <iframe> نفسه للتحكم بأولوية تحميل الإطار. وداخل الإطار، يمكن استخدامها على الموارد كالمعتاد.
كيف أقيس تأثير fetchpriority فعلياً؟
أفضل الأدوات لعام 2026: CrUX Dashboard لقياسات RUM حقيقية، WebPageTest لتجارب مختبر قابلة للتكرار، و Lighthouse CI في pipeline الخاص بك. قِس LCP وزمن التحميل الإجمالي قبل وبعد التغيير. غالباً ستلاحظ فرقاً بين 100 و 500 مللي ثانية في LCP على اتصالات متوسطة السرعة — وهذا فرق يشعر به المستخدم فعلاً.
الخلاصة
سمة fetchpriority هي، باختصار، أحد أبسط وأقوى الأدوات المتاحة لتحسين أداء الويب في 2026. بسطر HTML واحد، يمكنك تحسين LCP بنسبة 20% أو أكثر، دون تعديل البنية التحتية أو إضافة مكتبات. المفتاح هو استخدامها بذكاء: ارفع أولوية المورد الأهم واحداً فقط، اخفض أولوية الموارد غير الحرجة، وادمجها مع preload حين يلزم الاكتشاف المبكر.
ابدأ الآن بفحص صورة LCP في موقعك، أضف fetchpriority="high" إليها، وراقب الفرق في Lighthouse و CrUX. صدقني، هذه واحدة من أسرع الطرق لتحقيق مكاسب حقيقية في Core Web Vitals هذا العام.