تلميحات HTTP 103 Early Hints هي رمز حالة معلوماتي يسمح للخادم بإرسال ترويسات Link: preload وpreconnect إلى المتصفح قبل أن تكون الاستجابة النهائية (200 OK) جاهزة، بحيث يستغل المتصفح "وقت تفكير الخادم" لتحميل الموارد الحرجة كصورة LCP والخطوط ورقائق CSS بشكل متوازٍ. صراحةً، هذه الميزة أنقذت لي مشروعًا كاملًا في متجر إلكتروني كان LCP فيه يقفز فوق 3.5 ثانية على شبكات 4G. في هذا الدليل، سأشاركك ما رأيته عمليًا عند تفعيلها خلف Cloudflare وNGINX وVercel، وكيف تقيس أثرها الفعلي على Core Web Vitals دون أن تخدعك أرقام TTFB الجديدة في Chrome 133+.
تلميحات 103 Early Hints تصل المتصفح خلال مرحلة توليد الاستجابة، ما يُتيح بدء تنزيل موارد LCP قبل وصول أول بايت من HTML.
قياسات Cloudflare على أكثر من 100,000 عميل أظهرت تحسّن LCP بنسبة 6% عند p50 و16% عند p75 على أجهزة سطح المكتب.
Shopify سجّلت اختصار LCP بمقدار 500 مللي ثانية عند p50 خلال ذروة Black Friday بفضل إرسال تلميحات 103 تلقائيًا.
Chrome 133 غيّر تعريف responseStart ليشمل الاستجابة 103؛ لذا استخدم firstResponseHeadersStart لقياس زمن الخادم الحقيقي.
لا ترسل أكثر من 2–4 موارد في التلميح الواحد؛ الإفراط يُشبع الاتصال ويعكس المكسب على شبكات الهاتف.
الدعم متوفر على Chromium وFirefox وSafari 16.4+، لكن Safari يتجاهل preload ويقبل preconnect فقط.
ما هو HTTP 103 Early Hints ولماذا وُجد؟
Early Hints (رمز الحالة 103) هي استجابة معلوماتية مؤقتة عرّفها توثيق MDN لرمز الحالة 103 ضمن سلسلة استجابات 1xx. الفكرة الجوهرية بسيطة جدًا: عندما يستقبل الخادم طلب صفحة، فإنه غالبًا ما يقضي مئات من الملّي ثانية في تنفيذ الاستعلامات، وقراءة قاعدة البيانات، وتوليد HTML. خلال هذا "وقت التفكير" (server think time)، تظل قناة TCP/QUIC مفتوحة، ولا يعرف المتصفح ما الذي سيحتاج إليه لاحقًا. وقت مهدور بالكامل.
تُتيح الاستجابة 103 للخادم أن يقول للمتصفح: "لا تنتظرني، هذه هي أهم الموارد التي ستحتاجها، ابدأ تحميلها الآن." يصل ذلك عبر ترويسات Link بنفس صياغة سمة <link rel="preload">. عندما يستلم Chromium أو Firefox هذه الترويسات، يبدأ فعليًا فتح اتصالات إضافية أو تنزيل صور LCP قبل أن يصل أول بايت من HTML الحقيقي.
هذا النموذج جاء بديلًا لتقنية HTTP/2 Server Push المهجورة (وهي قصة أخرى مؤلمة). Server Push فرض على الخادم أن يدفع الموارد دون معرفة ما إذا كانت في ذاكرة المتصفح، مما تسبب في هدر عرض النطاق. في المقابل، Early Hints تسمح للمتصفح باتخاذ القرار: إن كان المصدر مخزّنًا مؤقتًا، يتجاهل التلميح؛ وإن لم يكن، يبدأ بجلبه بأولوية عالية. النتيجة: مكسب أداء بلا هدر بيانات.
كيف تُحسّن Early Hints مقياسي LCP وTTFB؟
التأثير الأكبر لـ Early Hints يظهر على صفحات تعاني من زمن استجابة خادم متوسط أو مرتفع (400 مللي ثانية فأكثر). خلال تلك الفترة، يستطيع المتصفح إنجاز تنزيل CSS الحرج أو صورة LCP بالكامل. وفق قياسات Cloudflare عبر 100,000 عميل، تحسّن LCP بنسبة 6% عند الوسيط (p50) و16% عند p75 على أجهزة سطح المكتب. وفي تجربة Shopify لإرسال Early Hints تلقائيًا، اختصر LCP 500 مللي ثانية عند p50 خلال أعلى نقاط حركة المرور في Black Friday.
الأمر لا يقتصر على LCP؛ فمقياس FCP يستفيد أيضًا. Cloudflare قاست تحسّن FCP بمقدار 76 مللي ثانية وLCP بمقدار 100 مللي ثانية عند p75 على مستوى الصفحات التي استقبلت التلميحات فعلاً. لاحظ أن كل 100 مللي ثانية إضافية من "وقت التفكير" تُترجم إلى مكسب إضافي تقريبي قدره 7.5 مللي ثانية في FCP و7.6 مللي ثانية في LCP عند p90. بمعنى آخر: كلما كان خادمك أبطأ، زاد المكسب النسبي من Early Hints. تناقض جميل، أليس كذلك؟
بالنسبة إلى TTFB، الصورة أدقّ. تاريخيًا، اعتمدت الأدوات على responseStart لقياس زمن الوصول إلى أول بايت. بعد Chrome 133، أصبح هذا الحقل يُشير إلى أول بايت من استجابة 103، وليس من 200 النهائية. سيبدو TTFB في تقاريرك أنه انخفض بعشرات المللي ثواني حتى لو لم يتغيّر أداء الخادم فعلاً (وقد وقعت في هذا الفخ في أول أسبوع من التفعيل). لتجنّب الوقوع في هذا الخطأ، استخدم firstResponseHeadersStart الذي أُضيف حديثًا لقياس زمن الخادم الحقيقي بمعزل عن التلميحات. للتعمّق في هذا المقياس اقرأ دليل تحسين TTFB وتسريع استجابة الخادم.
Early Hints مقابل preload التقليدي في <head>
سؤال شائع أتلقّاه من الفرق الخلفية: "لماذا لا نكتفي بـ <link rel="preload"> داخل <head>؟". الجواب البسيط: preload التقليدي لا يبدأ عمله إلا بعد أن يستقبل المتصفح أول بايت من HTML، أي بعد انتهاء وقت تفكير الخادم بالكامل. أما Early Hints فتُطلق التنزيل خلال ذلك الوقت. للفارق العملي، إليك مقارنة سريعة:
الخاصية
Early Hints (103)
preload في <head>
موعد بدء التنزيل
خلال توليد HTML
بعد وصول أول بايت من HTML
يحتاج تعديلًا في التطبيق
لا؛ يُضبط على الخادم أو CDN
نعم؛ سمة داخل الصفحة
يعمل على HTTP/1.1
لا (HTTP/2 وHTTP/3 فقط)
نعم
دعم Safari
preconnect فقط
preload وpreconnect
مخاطر الهدر
منخفضة (المتصفح يقرر)
منخفضة (المتصفح يقرر)
الأثر على TTFB الظاهر
ينخفض بسبب Chrome 133+
لا تأثير
مناسب لصفحات ديناميكية
ممتاز (وقت الخادم طويل)
محدود
في الممارسة، الطريقتان مكمّلتان لا متنافستان. أستخدم Early Hints لبدء تحميل الأصول الحرجة (LCP وخطوط الويب) بأسرع وقت ممكن، ثم أُبقي <link rel="preload"> داخل HTML لضمان عمل التحميل حتى للمتصفحات التي لا تدعم 103 أو خلف بروكسي يُسقط استجابات 1xx. النقطة المهمة: لا تكرّر أكثر من 2–4 موارد بين الطريقتين حتى لا تُشبع الاتصال. للمزيد عن تحديد الأولويات، طالع دليل سمة fetchpriority لتحسين أولويات التحميل.
كيف تُفعّل Early Hints على Cloudflare وNGINX وVercel؟
الطريق الأسرع لتجربة Early Hints يمر عبر شبكات CDN الحديثة. أدناه سأشرح ثلاث بيئات إنتاجية شائعة، مع التركيز على الأنماط التي رأيتها تعمل بلا انكسار.
1) تفعيل Early Hints على Cloudflare
وفق توثيق Cloudflare الرسمي لـ Early Hints، Cloudflare يخزّن ترويسات Link من استجابات 200 الخاصة بموقعك، ثم يُرسل نسخة منها كاستجابة 103 على الطلبات اللاحقة قبل حتى الاتصال بأصلك. التفعيل خطوة واحدة:
ادخل لوحة Cloudflare > Speed > Optimization > Content Optimization.
فعّل مفتاح Early Hints.
تأكد من أن أصلك يُصدر ترويسة Link صحيحة مع rel=preload أو rel=preconnect.
مثال لترويسة تُخبر Cloudflare بحفظها وإعادة إرسالها كتلميح 103:
أعلنت NGINX دعمًا أصيلًا لـ 103 Early Hints في الإصدار 1.29.0 (يونيو 2025) وفق إعلان الميزة الرسمي. للتفعيل، أضف الأمر early_hints on; داخل كتلة server، ثم استخدم add_early_hint لإرسال ترويسات مبكرة قبل تنفيذ منطق الصفحة:
server {
listen 443 ssl http2;
server_name example.com;
early_hints on;
location / {
add_early_hint Link "</css/critical.css>; rel=preload; as=style";
add_early_hint Link "</img/hero.avif>; rel=preload; as=image; fetchpriority=high";
proxy_pass http://app_upstream;
}
}
لاحظ أن NGINX لا يُرسل تلميحات إلا على HTTP/2 وHTTP/3، وأن أوامر add_early_hint تُنفّذ قبل الاتصال بالتطبيق الخلفي. عمليًا هذا مثالي لتطبيقات Rails أو Django البطيئة نسبيًا.
3) تفعيل Early Hints على Vercel وNext.js
على Vercel Edge Network، تُصدر منصة النشر تلميحات 103 تلقائيًا إذا استخدمت ISR أو دوال Edge Middleware مع كائن NextResponse. المثال أدناه يُظهر كيفية إرسال Early Hints من Middleware:
// middleware.ts
import { NextResponse, type NextRequest } from 'next/server'
export function middleware(req: NextRequest) {
const res = NextResponse.next()
// ترويسات تُضاف كتلميحات 103 من Vercel Edge
res.headers.append(
'Link',
'</fonts/Inter.woff2>; rel=preload; as=font; type=font/woff2; crossorigin'
)
res.headers.append(
'Link',
'</hero.avif>; rel=preload; as=image; fetchpriority=high'
)
return res
}
أفضل الممارسات: ما الموارد التي تستحق تلميحًا مبكرًا؟
وقعت فرق كثيرة في فخ "التلميح إلى كل شيء". على أجهزة الهاتف، وجدت Shopify أن إرسال أكثر من 10 موارد أدى إلى تدهور فعلي في TTFB وFCP وLCP لأن الاتصال أُشبع. القاعدة العملية التي أعتمدها: تلميح 2–4 موارد كحد أقصى، والتركيز على مسار العرض الحرج فقط.
الموارد التي أُرشّحها للتلميح
صورة LCP: إن كانت صورة (hero، banner، thumbnail)، اجعلها rel=preload; as=image; fetchpriority=high.
Critical CSS: ملف الأنماط الذي يحوي أول شاشة (above-the-fold)، خصوصًا إن لم يكن مُضمَّنًا داخل HTML.
خطوط الويب الأساسية: ملف .woff2 الوحيد الذي يظهر في أول رسمة (مع crossorigin).
preconnect لأصل الوسائط: نطاق CDN للصور أو نطاق الفيديو المُدمج.
الموارد التي أتجنّبها
مكتبات JavaScript غير حرجة (analytics، chat widgets، A/B testing).
أي مورد قد يتغيّر مع إصدارات النشر السريعة (كإخراج bundlers ذات hash متغيّر) دون إعادة توليد التلميحات.
صور تعتمد على مسار المستخدم (thumbnails لكل مستخدم مثلاً)، لأن Cloudflare يتجاهل query string عند فهرسة كاش التلميحات.
هذه الفكرة الأخيرة مهمة جدًا. عندما يخدم CDN صفحة ديناميكية بمعاملات URL مختلفة، قد يُعيد استخدام تلميحات من طلب سابق ذي محتوى مختلف. قبل التفعيل على صفحات مثل نتائج البحث، اختبر السيناريو مع أدوات المراقبة الحقيقية للمستخدمين. للمزيد عن قياس التأثير في الحقل، طالع دليل المراقبة الحقيقية RUM لقياس Core Web Vitals.
الأخطاء الشائعة وقياس TTFB في Chrome 133+
هذه أكثر ثلاثة أخطاء أراها في مراجعات الأداء الحديثة:
1) نسيان سمة as=
الترويسة التالية لا تُطابق الجلب النهائي، فيقوم المتصفح بجلبين منفصلين ويهدر بايتات ثمينة:
Link: </img/hero.avif>; rel=preload /* خطأ: بلا as= */
Link: </img/hero.avif>; rel=preload; as=image /* صحيح */
2) الجمع بين preload وfetchpriority بلا وعي
عندما يحمل مورد fetchpriority=high بالفعل عبر Early Hints، فإن إعادة تلميحه داخل <head> بلا نفس الأولوية قد تُنزل من رتبته. أعتمد قاعدة: كل مورد يظهر في تلميحات 103 يجب أن يحمل الأولوية نفسها في HTML أو أن يُحذف من HTML كليًا.
3) قراءة TTFB الخاطئة بعد Chrome 133
كما أشرت أعلاه، بعد إطلاق Chrome 133 يُضبط responseStart على أول بايت من استجابة 103. النتيجة: تقارير RUM ستُظهر TTFB أقل بعشرات المللي ثواني، بينما زمن الخادم الفعلي لم يتغيّر. الحل هو استخدام الحقل الجديد firstResponseHeadersStart، أو الاعتماد على المقياس المخصّص الذي أطلقته Shopify باسم finalResponseHeadersStart. للتحقق يدويًا، افتح DevTools > Network > اضغط على طلب المستند، وسترى الاستجابة 103 قبل 200 في تفاصيل الـ Timing.
4) تلميحات مبكرة لصفحات تعيد التوجيه
إذا كان الرد النهائي هو 301 أو 302، فأي مورد جلبه المتصفح استنادًا إلى تلميح 103 سيُهدَر. أوقف Early Hints على المسارات التي تعيد التوجيه بمعدل مرتفع، أو استخدم شرطًا في NGINX/CDN يمنع إرسالها إذا كان مسار الطلب يُرجع 30x معروفًا. تعلّمتُ هذا الدرس بالطريقة الصعبة على مسار /shop/ الذي كان يعيد توجيه المستخدمين إلى تصنيف افتراضي.
الأسئلة الشائعة
هل Early Hints بديل عن preload التقليدي؟
لا. الأداتان متكاملتان: Early Hints تبدأ التنزيل خلال وقت تفكير الخادم، بينما preload داخل <head> يعمل كخطة احتياطية للمتصفحات التي لا تستقبل 103 أو خلف بروكسيات تُسقط استجابات 1xx.
هل يعمل HTTP 103 Early Hints على HTTP/1.1؟
لا. المعيار يشترط HTTP/2 أو HTTP/3 لأن استجابات 1xx تسبّب أخطاء في بعض عملاء HTTP/1.1 القدامى. Cloudflare وFastly وNGINX يُرسلون تلميحات 103 فقط عبر h2/h3.
كيف أعرف أن Early Hints تعمل على موقعي؟
افتح Chrome DevTools ثم Network، فعّل خيار "Disable cache" وأعد تحميل الصفحة. اضغط على طلب المستند وستجد الاستجابة 103 قبل 200 في قسم Timing. للتحقق من سطر الأوامر استخدم curl --http2 -i https://example.com وابحث عن سطر HTTP/2 103.
لماذا انخفض TTFB بشكل غير متوقع بعد تفعيل Early Hints؟
منذ Chrome 133 صار responseStart يشير إلى أول بايت من استجابة 103، وليس من 200 النهائية. TTFB لم "يتحسّن" فعلاً؛ بل تغيّر تعريف نقطة القياس. استخدم firstResponseHeadersStart لقياس زمن الخادم الحقيقي.
هل يدعم Safari تلميحات 103؟
Safari 16.4 فأحدث يقبل rel=preconnect ضمن استجابة 103، لكنه يتجاهل rel=preload. لذلك يظل مستخدمو Chromium وFirefox هم أكبر المستفيدين من تحسينات LCP، بينما يستفيد Safari فقط من فتح الاتصالات المبكرة.
هل هناك حد أقصى لعدد الموارد في تلميح 103؟
لا يوجد حد تقني صارم، لكن التجارب الإنتاجية لدى Shopify وCloudflare تُوصي بـ 2–4 موارد كحد أقصى. الإفراط في التلميحات يُشبع الاتصال ويؤخّر تنزيل صورة LCP الحقيقية على شبكات الهاتف.
دليل عملي لتحسين TTFB في 2026. يغطي تحسين الخادم، شبكات CDN، الحوسبة على الحافة، التخزين المؤقت، ضغط Brotli، وHTTP/3 — مع أمثلة كود عملية وخطة تطبيق مرتّبة حسب التأثير.
