مشكلة التمهيد الكامل

Hydration هي العملية التي يأخذ فيها React كود HTML المصيّر على الخادم ويربط به مستمعي أحداث JavaScript. يرسل الخادم HTML الأولي بسرعة، ثم ينزّل المتصفح حزمة JavaScript ويجري React عملية Hydration لـ HTML الثابت حتى يجعله تفاعليًا. وإلى أن تكتمل Hydration، تبدو الصفحة تفاعلية لكنها ليست كذلك.

ترسل تطبيقات الصفحة الواحدة التقليدية حزمة JavaScript كاملة إلى المتصفح. ويجب على React تنزيلها وتحليلها وتنفيذها، ثم ربط مستمعي الأحداث بكل مكوّن في شجرة المكوّنات. وقد تستغرق هذه العملية عدة ثوانٍ في التطبيقات الكبيرة على الأجهزة المحمولة متوسطة الإمكانات.

يقيس الزمن حتى التفاعل المدة اللازمة قبل أن يتمكن المستخدم من التفاعل مع الصفحة. وتؤثر Hydration مباشرةً في TTI: فقد تبدو الصفحة جاهزة، لأن HTML المصيّر على الخادم ظاهر، لكن الأزرار والنماذج لا تستجيب حتى ينتهي React من ربط مستمعي الأحداث. ويشير ارتفاع قيمة TTI إلى تجربة مستخدم سيئة.

لنتأمل صفحة تسويقية: 80% من محتواها عبارة عن نصوص وصور وعناوين ثابتة لا تتغير أبدًا. ولا تتضمن التفاعلية إلا 20%، مثل نموذج الاشتراك في النشرة الإخبارية أو مشغّل الفيديو. ومع ذلك، تظل Hydration في تطبيق SPA تقليدي تعمل على 100% من الصفحة، فتعالج المكوّنات الثابتة بلا داعٍ.

يكشف تحليل الأداء في Chrome DevTools تكلفة Hydration. ففي المخطط الزمني لسلسلة التعليمات الرئيسية، يمكن تحديد مهمة «React hydration» بوصفها كتلة تنفيذ JavaScript طويلة بعد الرسم الأولي. وكلما طالت هذه الكتلة، انشغلت سلسلة التعليمات الرئيسية مدة أطول وأصبحت الصفحة أقل استجابة.

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

قدّم React 18 Hydration المتزامنة، التي تتيح لـ React تقسيم Hydration إلى أجزاء أصغر وإتاحة المجال للمتصفح بينها. ويمنع ذلك المتصفح من الظهور متجمّدًا تمامًا أثناء تنفيذ Hydration للأشجار الكبيرة. لكن Hydration المتزامنة تقلل الأثر ولا تلغي التكلفة الأساسية.

تتيح Hydration الانتقائية، عبر Suspense، لـ React تنفيذ Hydration للمكوّنات حسب الأولوية؛ إذ تؤدي تفاعلات المستخدم إلى تنفيذ Hydration فورًا للمكوّن المعني. ويحسّن ذلك سرعة الاستجابة، لكنه يظل يعمل ضمن شجرة React واحدة، ما يعني تنفيذ Hydration لجميع المكوّنات في الشجرة في نهاية المطاف.

تتمثل الرؤية الأساسية التي تقود Islands Architecture في أن معظم صفحات الويب المعتادة لا تحتاج إلى JavaScript أصلًا. فأشرطة التنقل وأقسام الواجهة الرئيسية وروابط التذييل ونصوص منشورات المدونات ووصف المنتجات هي عناصر عرضية بحتة. وفرض Hydration عليها يُعد إهدارًا بطبيعته.

تُظهر الدراسات التي أجرتها فرق أداء الويب أن وقت تحليل JavaScript وتنفيذها هو التكلفة الأكبر على الأجهزة المحمولة. فتستغرق حزمة JavaScript بحجم 300 كيلوبايت من ثانيتين إلى ثلاث ثوانٍ لتحليلها على هاتف Android متوسط. ويحقق تقليل JavaScript المرسلة إلى المتصفح فوائد كبيرة في الأداء مقارنةً بأي تحسين داخلي في React.

تضيف كل كيلوبايت من JavaScript إلى تطبيق React عملًا إضافيًا أثناء Hydration. وحتى إذا كان المكوّن للزينة فقط، فإنه يشارك في Hydration ما دام موجودًا في شجرة React. وتتسع «ضريبة Hydration» مع زيادة حجم التطبيق، ما يجعل الحفاظ على درجات TTI جيدة أصعب تدريجيًا مع نمو التطبيقات.

ما العلاقة بين Hydration في React والزمن حتى التفاعل (TTI)؟

تعالج Hydration التقليدية في React شجرة المكوّنات بأكملها، حتى المحتوى الثابت الذي لا يحتاج إلى JavaScript. وهذا يحجب الزمن حتى التفاعل ويتوسع بصورة سيئة مع زيادة حجم التطبيق. وتقلل تحسينات Hydration المتزامنة والانتقائية في React 18 الأثر، لكنها لا تلغي التكلفة الأساسية. أما الرؤية الأساسية فهي أن معظم محتوى الصفحة لا يحتاج إلى JavaScript، ولذلك فإن تنفيذ Hydration كاملة يُعد إهدارًا.