المقال ده يتطلب مستوى محترف. لو لسه بتتعرّف على 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.
