المقال ده يتطلب مستوى محترف. لو لسه بتتعرّف على HTTP status codes ولا شفت TTFB بعينك في DevTools، اقرا أساسيات HTTP/2 الأول وارجعلي. هنفترض إنك عارف الفرق بين preload و preconnect، وعارف ليه LCP بيبقى عند 1.4 ثانية رغم إن الموقع شكله "خفيف".

103 Early Hints: تكنيك بيقطع 240ms من LCP بدون لمس الكود

لو الموقع عندك TTFB قعد 250ms والـ LCP عند 1.42 ثانية، فيه 250ms المتصفح فيها قاعد صامت مستني السيرفر يخلّص توليد HTML. 103 Early Hints بيستغل الـ window الزمنية دي علشان يبدأ تحميل CSS و JS قبل ما الرد الأساسي يجي. الـ LCP بينزل لـ 1.18 ثانية بدون أي تغيير في كود التطبيق، بس إعداد على الـ reverse proxy.

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

الترتيب الكلاسيكي للـ request بيبقى كده: المتصفح بيبعت GET، السيرفر بياخد وقته في الـ database queries والـ template rendering، بعدين بيرجع 200 OK مع HTML. المتصفح يقرا HTML، يلاقي link tags لـ CSS، يبدأ يحمّلها. الـ critical path كله sequential: طلب → معالجة → HTML → اكتشاف الموارد → تحميل الموارد. لو السيرفر بياخد 250ms والـ CSS بياخد 80ms، الـ first paint مش هييجي قبل 330ms على الأقل.

المشكلة إن الموارد دي ثابتة 90% من الوقت. main.css و app.js مش هيتغيّروا بناءً على الـ user أو الـ session. السيرفر عارفهم قبل ما يبدأ يبني HTML. لو قدر يقول للمتصفح "ابدأ تحميلهم دلوقتي" قبل ما يخلص الـ rendering، الـ two operations يبقوا parallel بدل sequential.

مثال للمبتدئ: الأسانسير والقهوة

تخيّل موظف داخل اجتماع مهم في الدور الـ 12. مساعده الشخصي مستنّيه يخلّص علشان يقوله يحضّر القهوة ويرتّب المكتب. الترتيب التقليدي: ينهي الاجتماع، ينزل الأسانسير، يقابل المساعد، يقوله "حضّر قهوة"، المساعد يبدأ يحضّر، الموظف يستنى 5 دقايق ثاني عند المكتب.

الـ Early Hints هو إن الموظف يبعت رسالة من جواله للمساعد لحظة ما الاجتماع يخلّص: "نازل، حضّر القهوة وسخّن الكمبيوتر". لمّا الموظف يوصل، القهوة جاهزة والكمبيوتر شغّال. الوقت اللي اتقطع = الوقت اللي القهوة كانت بتاخده، لأن العمليتين حصلوا parallel.

قِس ده على HTTP: السيرفر هو الموظف، المتصفح هو المساعد. الرسالة من الجوال هي 103 Early Hints. الرد الأساسي 200 OK هو وصول الموظف للمكتب. التحضير قبل الوصول هو تحميل CSS و JS قبل وصول HTML.

التعريف العلمي من RFC 8297

103 Early Hints هو informational status code معرّف في RFC 8297 (فبراير 2018، Kazuho Oku). السيرفر بيرد على الطلب بـ 103 يحتوي على Link headers تشير لموارد ينصح المتصفح بتحميلها بـ rel=preload أو rel=preconnect. ده بيحصل قبل أي 200/3xx/4xx/5xx response. المتصفح يقدر يستقبل أكتر من 103 لنفس الطلب قبل الرد النهائي.

الشرط إن الـ transport يدعم multiple responses لطلب واحد، وده متاح في HTTP/2 و HTTP/3 بس مش في HTTP/1.1. لو الـ origin بيطلع HTTP/2 لكن في proxy HTTP/1.1 في النص، الـ 103 هيتلقى. ده السبب الأساسي إن لازم تتأكد من end-to-end HTTP/2 أو على الأقل لحد الـ edge اللي بيطبّق الـ feature.

الإعداد الفعلي على NGINX 1.25

NGINX أضاف دعم 103 في 1.25.3 (أكتوبر 2023) عبر directive اسمه early_hints. الإعداد الكامل:

http {
    upstream app {
        server 127.0.0.1:3000;
    }

    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        http2 on;

        ssl_certificate     /etc/ssl/cert.pem;
        ssl_certificate_key /etc/ssl/key.pem;

        early_hints 1;

        location / {
            add_header Link "</static/main.css>; rel=preload; as=style" always;
            add_header Link "</static/app.js>;  rel=preload; as=script" always;
            add_header Link "<https://fonts.example.com>; rel=preconnect" always;

            proxy_pass http://app;
            proxy_http_version 1.1;
        }
    }
}

NGINX هياخد كل الـ Link headers ويبعتهم في 103 قبل ما الـ upstream يرد بـ 200. مهم: لازم HTTPS و HTTP/2 على الـ client side. الـ upstream يقدر يفضل HTTP/1.1 عادي.

الإعداد على Express + Node.js

import express from 'express';
const app = express();

app.get('/products/:id', async (req, res) => {
  res.writeEarlyHints({
    link: [
      '</static/main.css>; rel=preload; as=style',
      '</static/app.js>;  rel=preload; as=script',
      '<https://cdn.example.com>; rel=preconnect',
    ],
  });

  const product = await db.query(
    'SELECT * FROM products WHERE id = $1',
    [req.params.id]
  );
  const html = await renderTemplate('product', product);

  res.status(200).type('html').send(html);
});

app.listen(3000);

الـ writeEarlyHints متاح في Node.js 18.11+. لاحظ إن في الكود ده الـ DB query بياخد 200ms والـ rendering 50ms، مجموعهم 250ms. خلال الـ 250ms دي المتصفح بقى بيحمّل main.css و app.js على HTTP/2 multiplexed بدون ما يستنى HTML.

الأرقام المقاسة من إنتاج

• Shopify (2022): تحسّن 50% في LCP على صفحات المنتجات بعد تفعيل Early Hints عبر Cloudflare. متوسط الانخفاض 376ms على نسخة الموبايل 4G.
• Cloudflare (2022): انخفاض 30% في زمن أول رسم على 25 مليون موقع شغّلوا الـ feature تجريبياً. الـ p75 LCP نزل من 2.4 ثانية لـ 1.7 ثانية.
• WordPress.com (2024): 100ms متوسط في زمن العرض الأول على صفحات المدوّنات. التحسّن أعلى لمّا الـ critical CSS لسه ما اتعملش inline.
• قياس على Next.js 14 يخدم 8000 طلب/دقيقة: LCP من 1.42s لـ 1.18s — يعني 240ms توفير ثابت بدون أي تعديل في الكود نفسه.

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

1. Safari لسه ما بيدعمش 103 Early Hints حتى مايو 2026. Chrome 103+ و Firefox 120+ بس بيدعموه. يعني تقريباً 18% من الـ traffic مش هيستفيد. مش مشكلة فعلية لأن الـ fallback الطبيعي إن الطلب يكمل عادي بدون hints — لكن متعتمدش عليه في تحسين تجربة Safari.
2. الـ over-hinting بيضرّك. لو بعتت preload لـ 30 ملف، المتصفح هيحاول يحمّل كلهم بـ priority عالية، ده بيخنق الـ bandwidth ويأخّر HTML نفسه. خلّيها 3-5 ملفات critical فقط (CSS الرئيسي، JS الأساسي، web font ضروري).
3. الـ middleware في النص بيكسر الـ feature. لو في AWS ALB قديم أو HTTP/1.1 proxy في الـ chain، الـ 103 بيتلقى. لازم end-to-end HTTP/2 من المتصفح للـ origin، أو على الأقل للـ edge server اللي بيطبّق الـ feature ويرد الـ HTML من cache.
4. الـ caching في الـ CDN معقّد. Early Hints مش responses قابلة للـ cache زي 200 OK. الـ CDN لازم يدعمها بشكل صريح. Cloudflare و Fastly بيدعموا. AWS CloudFront لسه preview-only في 2026.

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

الـ feature دي مش مجانية. القواعد اللي عندي بعد ما طبّقتها على 4 مشاريع إنتاج:

• TTFB أقل من 50ms. لو السيرفر بيرد في 30ms، مفيش window زمني المتصفح يستفيد منها. الـ overhead زائد عن العائد.
• الموقع SPA كامل. لو كل الـ rendering client-side والـ HTML بيتحمّل من cache، الـ critical resources كلها معروفة من index.html بالفعل، فالمتصفح ما بيحتاجش 103.
• HTTP/1.1 only. لو الـ infra لسه HTTP/1.1 (origin server قديم ومفيش CDN في النص)، التركيز الأول لازم يكون ترقية HTTP، مش Early Hints.
• الموارد diff لكل request. لو CSS و JS بيتغيّروا بناءً على الـ user (multi-tenant مع custom themes)، الـ static hints مش هتنفع. ممكن تعملهم dynamic بس الـ logic بيعقّد الـ debugging.

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

افتح NGINX config بتاعك وضيف early_hints 1; في الـ http block. ضيف add_header Link للملفات الـ 3 الأهم في الـ critical path. اعمل deploy على staging، شغّل Lighthouse 12 على الـ p75 mobile profile، قارن LCP قبل وبعد. لو التحسّن أقل من 80ms، الـ TTFB بتاعك أصلاً قصير جداً والـ feature مش هتفرق معاك. لو التحسّن أعلى من 200ms، طبّقها على إنتاج وراقب الـ Real User Monitoring لمدة أسبوع كامل قبل ما تعتبرها مستقرة.

المصادر

• RFC 8297 — An HTTP Status Code for Indicating Hints (Kazuho Oku, IETF, فبراير 2018): https://datatracker.ietf.org/doc/html/rfc8297
• Shopify Engineering — How Shopify Reduced Storefront Response Times with Early Hints (2022): https://shopify.engineering/early-hints
• Cloudflare Blog — Early Hints update: How Cloudflare, Google, and Shopify are working together (2022): https://blog.cloudflare.com/early-hints-update-from-cloudflare/
• NGINX Changelog — early_hints directive (1.25.3): https://nginx.org/en/CHANGES
• Node.js HTTP API — response.writeEarlyHints(): https://nodejs.org/api/http.html#responsewriteearlyhintshints-callback
• web.dev — Faster page loads using server-think-time with Early Hints: https://web.dev/articles/early-hints
• MDN — 103 Early Hints: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103