قياس أثر البث: FCP وTTI وLCP

يقيس FCP الزمن من بدء التنقل إلى لحظة رسم أول جزء من المحتوى، سواء أكان نصًا أم صورة أم خلفية، على الشاشة. يحسّن البث FCP عبر إرسال هيكل HTML فورًا؛ إذ يستطيع المتصفح رسم التخطيط وشريط التنقل وأي نص ظاهر أعلى الصفحة بمجرد وصول الأجزاء الأولى.

مع SSR المتزامن باستخدام renderToString، لا يتلقى المتصفح أي HTML حتى يكتمل العرض بالكامل. أما مع البث، فيتلقى المتصفح هيكل HTML خلال أجزاء من الثانية من وصول الطلب، فتظهر البنية والمحتوى الثابت شبه فورًا، مما يقلل FCP بشكل كبير.

يقيس LCP لحظة رسم أكبر عنصر مرئي داخل إطار العرض، ويكون عادةً صورة القسم الرئيسي أو عنوانًا كبيرًا. يحسّن البث LCP إذا كان عنصر LCP جزءًا من الهيكل، وليس داخل حد من حدود Suspense، لأن الهيكل يُبث قبل أي أقسام تعتمد على البيانات.

تتمثل إحدى التحسينات المهمة في تصميم الصفحة بحيث يكون عنصر LCP، مثل القسم الرئيسي أو العنوان الرئيسي أو الصورة المميزة، خارج أي حد من حدود Suspense. فإذا كان عنصر LCP داخل حد من حدود Suspense بانتظار البيانات، فلن يتمكن البث من تحسين LCP حتى تكتمل تلك البيانات.

يقيس TTI اللحظة التي تبدأ فيها الصفحة بالاستجابة بشكل موثوق لإدخال المستخدم، من دون وجود Long Tasks تحجب سلسلة التعليمات الرئيسية. ويقلل الجمع بين البث وhydration الانتقائي TTI عبر توزيع عمل hydration على فترة زمنية بدلًا من تنفيذ مهمة hydration متزامنة واحدة كبيرة بعد تنزيل JavaScript بالكامل.

يتحدد Time to First Byte (TTFB) بزمن استجابة الشبكة ووقت معالجة الخادم قبل إرسال البايت الأول. ولا يغيّر البث TTFB؛ فهذا هو المجال الذي يفيد فيه العرض على الحافة. ولكي يحسّن البث FCP، تحتاج أولًا إلى TTFB منخفض؛ وإلا فلن تفعل سوى البث من خادم أصل بطيء.

يعرض منظور شريط اللقطات في WebPageTest سلسلة من لقطات الشاشة الملتقطة كل 100ms أثناء تحميل الصفحة. تُظهر الصفحة التي تستخدم البث التدريجي ظهور التخطيط مبكرًا، ثم امتلاء الأقسام تدريجيًا. أما الصفحة التي لا تستخدم البث التدريجي فتُظهر شاشة فارغة يتبعها ظهور صفحة مكتملة التصيير فجأة — وهو اختلاف مرئي واضح.

يقارن اختبار الأداء المفيد الصفحة نفسها بعد تصييرها بطريقتين: مع تفعيل بث RSC في Next.js، مقابل SSR متزامن تقليدي. استخدموا WebPageTest مع حالة شبكة ثابتة (مثل Fast 3G، وإبطاء وحدة المعالجة المركزية بمقدار 4x)، وقارنوا مقاييس FCP وLCP وTTI عبر 3 عمليات اختبار لتحقيق ثقة إحصائية.

تحتوي علامة التبويب Network في Chrome DevTools على قائمة منسدلة باسم "Throttling" تتضمن إعدادات مسبقة مثل Fast 3G وSlow 4G. يعمل Fast 3G (سرعة 1.6 Mbps وزمن RTT قدره 150ms) على تضخيم الفرق بين البث التدريجي والبث غير التدريجي، لأنه يزيد زمن تنزيل مستند HTML الكامل، ما يجعل مكاسب البث التدريجي تظهر بوضوح.

يقيس Interaction to Next Paint (INP) الزمن من أي تفاعل للمستخدم حتى عملية التصيير التالية. وقد حل محل FID بوصفه أحد Core Web Vitals في عام 2024. يقلل البث التدريجي من INP عبر إعطاء الأولوية لعملية hydration للمكونات التفاعلية التي يُرجح أن يتفاعل معها المستخدم أولًا، مما يقلل زمن الحظر قبل أن تصبح تلك المكونات مستجيبة.

يجمع الإعداد الأعلى تأثيرًا بين التصيير على الحافة (TTFB منخفض من PoP قريب) والبث التدريجي (تسليم HTML تدريجيًا) وhydration الانتقائي (المعالجة التدريجية لـ JavaScript). تعمل هذه التقنيات الثلاث معًا على تقليل كل مقياس أداء رئيسي طوال دورة التحميل الكاملة.

ما مقياس الأداء الذي يحسّنه بث React مباشرةً للمحتوى الظاهر دون تمرير؟

يحسّن البث التدريجي FCP مباشرةً بدرجة أكبر عبر تسليم هيكل HTML فورًا، كما يحسّن LCP عندما يكون عنصر LCP موجودًا في الهيكل. ويتحسن TTI من خلال hydration الانتقائي الذي يوزع عمل JavaScript على مدار الوقت. ولا يتغير TTFB — عالجوه باستخدام التصيير على الحافة. استخدموا شريط اللقطات في WebPageTest وتقييد الشبكة في Chrome DevTools لقياس تأثير البث التدريجي، وحسّنوا INP بوصفه مقياس التفاعل الأساسي في Core Web Vitals.