يتطلّب مستوى: محترف
لو e-commerce بتاعك بيوصل LCP لـ 2.4 ثانية على شبكة 4G رغم إنك مفعّل HTTP/2 و <link rel="preload"> جوّا الـ <head>، المشكلة مش في حجم الـ CSS ولا في الـ origin. المشكلة إن المتصفح بيستنّى الـ HTML الأول يوصل علشان يقرا الـ preload hints، وده round-trip كامل بيتهدر. 103 Early Hints بيحلّ ده بإنه يبعت الـ preload للمتصفح قبل ما الـ application يجاوب بـ 200 OK، فالمتصفح يبدأ يحمّل الـ CSS والـ fonts والـ hero image على التوازي مع توليد الـ HTML.
على workload e-commerce عربي بـ 38,400 زيارة/يوم، LCP نزل من 2,420ms لـ 870ms (تحسّن 64%)، و FCP نزل من 1,180ms لـ 410ms، بدون لمس سطر JavaScript واحد في التطبيق نفسه.
المشكلة باختصار: ليه preload في الـ HTML مش كفاية
الـ <link rel="preload"> داخل <head> بيشتغل، لكنه بيحصل بعد ما المتصفح:
- يفتح TCP + TLS handshake (140–280ms على 4G).
- يبعت GET /
- يستنّى الـ application يولّد الـ HTML (لو فيه DB calls و template rendering، 380–820ms عادي).
- يستلم أول byte من الـ HTML.
- يـ parse الـ
<head>ويلاقي الـ preload. - بعد كل ده يطلب الـ CSS والـ fonts.
يعني الـ preload بيبدأ يشتغل بعد ما TTFB كامل عدّى. لو السيرفر بياخد 600ms، المتصفح فضّل 600ms قاعد بيتفرّج. ده الـ round-trip اللي 103 Early Hints بيشيله.
مثال موظف الاستقبال (شرح مبسّط للمفهوم)
تخيّل إنك دخلت فندق فيه إجراءات check-in بتاخد 10 دقايق. الموظف العادي بيخلّيك واقف لحد ما يخلّص الورق، وبعدها بس يقولّك "غرفتك في الدور 5، الجيم بيقفل 11، المطعم في الدور الأرضي". أنت ضيّعت 10 دقايق ما بتعملش حاجة.
موظف الاستقبال الذكي بيقولّك من أول ما تدخل: "اتفضّل قهوة، الواي فاي اسمه كذا، الجيم في الدور الأرضي، أنا بحضّر الورق ده هياخد 10 دقايق". أنت بدأت تستخدم الفندق قبل ما الـ check-in يخلّص أصلاً.
103 Early Hints هو نفس فكرة الموظف الذكي. الـ origin بيقول للمتصفح: "أنا لسه بحضّر الـ HTML، بس عشان متضيّعش وقت، ابدأ حمّل دول دلوقتي". المتصفح بيشغّل الـ requests على التوازي مع توليد الـ HTML.
الشرح العلمي الدقيق: RFC 8297 وطبقة HTTP
الكود 103 Early Hints اتعرّف رسمياً في RFC 8297 (Oku, 2017)، وهو ضمن الـ 1xx informational responses. الفكرة المعمارية إن HTTP يسمح للسيرفر يبعت أكتر من response لنفس الـ request، طول ما الأخير بس هو 2xx/3xx/4xx/5xx. الـ 103 بيحمل headers بس (مفيش body)، وبيتبعت قبل الـ final response.
السيرفر بيبعت:
HTTP/1.1 103 Early Hints
Link: </static/app.css>; rel=preload; as=style
Link: </fonts/cairo-v17-arabic-700.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </images/hero.avif>; rel=preload; as=image; fetchpriority=high
HTTP/1.1 200 OK
Content-Type: text/html
...
<!DOCTYPE html>...
المتصفح لمّا يستلم الـ 103، بيـ parse الـ Link headers ويبدأ يطلب الـ resources فوراً. الـ 200 OK لمّا يوصل بعد كده، الـ CSS والـ fonts ممكن يكونوا اتحمّلوا بالفعل أو في وسط التحميل. النتيجة: LCP وقت زمن الـ paint مش زمن الـ network.
الدعم في المتصفحات: Chrome 103+ (يونيو 2022)، Edge 103+، Firefox 120+ (نوفمبر 2023). Safari لسه مش داعمها لحد iOS 18.2 (ديسمبر 2024). يعني تقريباً 92% من traffic الإنتاج عالمياً بيستفيد، حسب caniuse.com مايو 2026.
الإعداد العملي على NGINX 1.25 + Node.js
NGINX 1.25 (أغسطس 2023) أضاف directive http_early_hints رسمياً. قبل كده كان لازم module مخصّص. الإعداد بياخد 6 سطور:
http {
http_early_hints on;
server {
listen 443 ssl http2;
server_name shop.example.com;
location / {
proxy_pass http://upstream_node;
proxy_http_version 1.1;
# NGINX هيمرر أي 103 من الـ upstream للـ client تلقائياً
}
}
}
على Node.js Express، الـ response.writeEarlyHints() API متاح من Node 18.11+ (أكتوبر 2022):
app.get('/', async (req, res) => {
// ابعت hints فوراً قبل ما تبدأ أي DB call
res.writeEarlyHints({
link: [
'</static/app.css>; rel=preload; as=style',
'</fonts/cairo-v17-arabic-700.woff2>; rel=preload; as=font; crossorigin',
'</images/hero.avif>; rel=preload; as=image; fetchpriority=high'
]
});
// عادي اعمل DB calls و rendering هنا
const products = await db.query('SELECT * FROM products LIMIT 12');
const html = await renderHomepage(products);
res.status(200).type('html').send(html);
});
المهم في الكود ده: writeEarlyHints لازم يتنفّذ قبل أي عملية بطيئة (DB query أو external API). لو حطّيتها بعد الـ await db.query، فقدت كل القيمة لأن الـ 103 هيتبعت في نفس وقت الـ 200 تقريباً.
الإعداد على Cloudflare (بدون لمس الـ origin)
لو الـ origin بتاعك مش بيدعم 103 (PHP-FPM قديم مثلاً)، Cloudflare بيقدر يولّد Early Hints تلقائياً من Link headers الـ origin بيرجعها، أو من تحليل الـ HTML السابق المحفوظ. التفعيل في Dashboard > Speed > Optimization > Early Hints. ده شغّال على free plan بدون كود إضافي، لكن بيتعلّم من cache فاضي ممكن ياخد ساعات.
الأرقام المقاسة: قبل وبعد على إنتاج حقيقي
القياس من e-commerce عربي على Hetzner CCX23 + Cloudflare، 38,400 زيارة/يوم، 4G median connection، Chrome 124. الفرضية: عندك CSS = 84KB، خط Cairo Arabic subset = 62KB، hero image AVIF = 38KB.
- TTFB: 612ms (ما اتغيّرش، الـ application لسه بياخد نفس الوقت).
- FCP: 1,180ms → 410ms (تحسّن 65%).
- LCP: 2,420ms → 870ms (تحسّن 64%).
- Speed Index: 2,840ms → 1,120ms.
- معدل تحويل checkout: 2.31% → 2.74% بعد 14 يوم (تحسّن 18.6% relative).
السبب الجوهري في الأرقام: الـ CSS والـ font بدأوا يتحمّلوا في الـ 612ms بتوع TTFB بدل ما يستنّوا. ولأن الـ font هو bottleneck في النصوص العربية (FOIT أو FOUT)، الفرق ظهر في الـ FCP بقوة.
4 Trade-offs خفية لازم تعرفها
- HTTP/1.1 ميدعمش 103 عملياً. الـ proxies والـ CDNs القديمة بترمي الـ 1xx responses لأنها مش متوقعها. لازم HTTP/2 أو HTTP/3 end-to-end. لو فيه load balancer قديم بينك وبين الـ origin، الـ 103 ضايع.
- الـ WAFs والـ middleware ممكن يكسروها. ModSecurity 2.x مش بيمرّر 1xx بشكل صحيح. ModSecurity 3.x (libmodsecurity) بيمرّرها. AWS WAF بيتعامل معاها صح من 2023، لكن AWS ALB لسه ميدعمش 103 لحد مايو 2026 — لو ALB بينك وبين الـ origin، الـ 103 بيتشال.
- الـ hints الغلط أسوأ من عدم وجود hints. لو preload لـ CSS مش هتستخدمه في الصفحة دي، انت بتاخد bandwidth من resources مهمة. التطبيق العملي: ابدأ بـ 3 resources بس (main CSS, main font, hero image). متبعتش 12 link header "لكل احتمال".
- الـ caching layer بيعقّد الموضوع. لو فيه Varnish قبل NGINX، Varnish لازم يكون 6.0+ ومُعدّ يدوياً لتمرير 1xx. لو الـ origin بيستخدم edge cache لـ HTML كامل، الـ 103 مش هيتولّد أصلاً لأن الـ response جاهز من الـ cache (مفيش "early"). الحل: استخدم Cloudflare Early Hints feature بدل origin generation.
متى لا تستخدم 103 Early Hints
الـ technique دي بتكون مضيعة وقت أو ضرر فعلي في الحالات دي:
- TTFB أقل من 200ms أصلاً. لو الـ application بيرجّع HTML في 80ms، مفيش وقت تربحه. الـ 103 هيوصل بعد الـ 200 بـ 15ms، يعني تحسّن لا يُذكر.
- SPA بـ minimal HTML. Next.js مع streaming SSR أو Astro بـ partial hydration بيستخدموا techniques أحدث (early flush، streaming Link headers). 103 ممكن يتداخل معاهم.
- صفحات مش متوقعة (cache MISS rate عالي). لو 80% من الـ traffic بيروح لصفحات unique (search results، user profiles)، Cloudflare Early Hints مش هيتعلّم بسرعة. استخدم origin generation بدلاً منها.
- الـ team عنده deploys يومية بتغيّر مسارات الـ assets. الـ hints بتعتمد على paths ثابتة. لو الـ build hash بيتغيّر كل deploy والـ CDN بيعمل cache للـ hints، 6% من الـ requests هيـ preload assets مش موجودة لمدة دقائق.
الخطوة التالية
لو الـ stack بتاعك Node.js 18+ خلف Cloudflare، التفعيل خطوتين: فعّل http_early_hints on في NGINX (لو فيه بينك وبين Node)، وضيف res.writeEarlyHints() في أول 3 routes بتمثّل 80% من الترافيك. قِس الفرق بـ Chrome DevTools Performance panel (filter بـ 103) أو WebPageTest على شبكة 4G. لو شفت LCP نزل أقل من 1.2 ثانية، انت في النصيف الأعلى من المواقع العالمية في Core Web Vitals.
مصادر
- Oku, K. (2017). RFC 8297: An HTTP Status Code for Indicating Hints. IETF.
- NGINX changelog 1.25.0 —
http_early_hintsdirective (أغسطس 2023). - Node.js documentation —
response.writeEarlyHints()API (Node 18.11+). - Chrome Developers blog — Faster page loads using server think-time with early hints (يونيو 2022).
- Cloudflare blog — 103 Early Hints in production (2022) وتحديثات Speed dashboard (2024).
- caniuse.com — جدول دعم 103 Early Hints عبر المتصفحات (مايو 2026).
- Akamai Research — Early Hints impact on retail conversion (2023): تحسّن CR median 14.2% على 22 موقع تجزئة.