اسمي بول كينلان، وأنا رئيس قسم العلاقات مع المطوّرين في Chrome. كجزء من وظيفتي، أعمل مع فريق من المدافعين عن الويب المتحمّسين الذين تم تكليفهم بنقل وجهة نظر المطوّرين في العالم الواقعي إلى فِرق المنتجات والهندسة، مع استخدام مقياس الأداء الرئيسي لتحسين رضا المطوّرين.
ندرك أنّ "الرضا" هو مقياس طموح وموضوعي يجب تتبُّعه وتحسينه، لذا نراجع باستمرار كيفية إحداث تأثير مع التركيز على احتياجات المطوّرين. من المبادئ الأساسية التي تبيّن لنا أنّه من المفيد اتّباعها هو "التواصل مع المطوّرين في المكان الذي يرونه مناسبًا". أظهرت دراسة حديثة أجرتها Stack Overflow أنّ % 75 من المطوّرين يستخدمون إطارات عمل أو نوعًا من التجريد. لذلك، سألنا أنفسنا كيف يمكننا تقديم أفضل خدمة للمطوّرين الذين سبق لهم اتّخاذ قرارات بشأن حِزم التكنولوجيا أو لا يمكنهم التحكّم فيها؟ كيف يمكننا تحسين إنتاجيتهم بدون زيادة النفقات العامة؟
يعمل فريق صغير في Chrome على مشروع يُسمى Aurora بهدف استخدام أدوات تجريدية تابعة لجهات خارجية لمنصّة الويب، مثل الإطارات والكتب. ويهدف إلى المساعدة في تحقيق مكاسب في الأداء مباشرةً في هذه العناصر المجردة، بدلاً من تحميل هذا العبء على عملائها، وهم مطوّرو الويب.
في العدد الثالث من Chrome Dev Insider، تحدثت مع أدي أوسماني وكارا إريكسون وحسين جيرديه من فريق Project Aurora لمعرفة المزيد عن كيفية تعاملهم مع هذا المشروع وما ينتظرهم في المستقبل.
معلومات من الداخل: العمل مع إطارات عمل تابعة لجهات خارجية
لنبدأ بمعرفة كيفية بدء هذا المشروع. كيف حدث ذلك؟
أدّي: بدأت Aurora بفكرة بسيطة: لنلبّي احتياجات المطوّرين في الوقت الحالي ونساعدهم في الوصول إلى ما يريدون. على سبيل المثال، تحسين الأداء باستخدام حِزمة التكنولوجيا الشائعة التي اختاروها. يستخدم العديد من مطوّري التطبيقات حاليًا React أو Vue أو Angular أو إطارات عمل ميتافورامية* مثل Next.js وNuxt (بالإضافة إلى العديد من الإطارات الأخرى). Svelte وLit وPreact وAstro والقائمة تطول). بدلاً من توقّع أن يصبح هؤلاء المطوّرون خبراء في مجال معيّن (مثل الأداء)، يمكننا ضمان نجاحهم من خلال تضمين المزيد من أفضل الممارسات تلقائيًا في هذه الحِزم. بهذه الطريقة، تصبح المواقع الإلكترونية ذات الجودة الأفضل نتيجة ثانوية لإنشاء المواقع الإلكترونية فقط.
تختار Aurora بعض الإطارات الأساسية والإطارات المرجعية المستخدَمة على نطاق واسع للشراكة معها، ونوثّق ما نتعلمه (مثل كيفية إنشاء مكوّن صورة جيد)، حتى يتمكّن الآخرون من اتّباع الخطوات بسرعة ومحاولة التوسّع من خلال إطارات عمل وأدوات أخرى من خلال "صندوق إطارات عمل Chrome". على الرغم من أنّه من الممكن تحسين جودة تجارب الويب من خلال المتصفّح، نعتقد أنّه يمكن تحقيق هذا الهدف أيضًا (في بعض الحالات) من خلال إطارات العمل أيضًا. نأمل أن يساعدنا ذلك في تحقيق أهدافنا المتمثلة في توفير ويب بجودة أعلى للجميع.
كارا: للتوضيح أكثر، الفكرة هي تحسين الأداء على الويب من خلال تحسين تجربة المطوّر. لا يكفي نشر أفضل الممارسات المتعلّقة بالأداء، لأنّها تتغيّر غالبًا ويصعب على الشركات مواكبتها. لديهم أولويات خاصة بنشاطهم التجاري، ومن المرجّح أن تكون لها الأولوية على الأداء.
لذلك، نعتقد أنّه إذا كان لدى المطوّرين وقت محدود يمكنهم تخصيصه للأداء، لنسهّل عليهم (وأسرع) إنشاء تطبيق عالي الأداء. وإذا عقدنا شراكة مع إطارات عمل الويب الشائعة، سنكون في الطبقة المناسبة من التجريد لتحسين تجربة المطوّرين من خلال المكوّنات ذات المستوى الأعلى وتحذيرات الامتثال وما إلى ذلك. وسيستفيد أي مستخدم لهذه الأدوات الشائعة من هذه المزايا. من الناحية النظرية، إذا تغيّرت النصيحة المقترَحة، يمكننا تعديل مكوّناتنا من الخلفية ولن يحتاج المطوّرون إلى القلق بشأن البقاء على اطّلاع دائم.
حسين: لقد انضممت إلى Google كممثّل للمطوّرين قبل أن أنتقل إلى دور مهندس برامج بعد بضع سنوات. كان معظم عملي السابق يتضمن تعليم مطوّري الويب الطرق العديدة المختلفة لإنشاء تجارب رائعة للمستخدمين. وقد تم تقديم أشكال مختلفة من الإرشادات نفسها مرارًا وتكرارًا لتحذير المطوّرين من المشاكل الشائعة التي من المحتمل أن تؤثّر في أداء مواقعهم الإلكترونية وقابلية استخدامها. عندما بدأنا التفكير في مشروع Aurora، طرحنا على أنفسنا السؤال التالي: هل يمكننا السير في اتجاه لا نضطر فيه إلى إخبار المطوّرين بما يجب فعله لأنّ سلسلة الأدوات الخاصة بهم تهتم بكل شيء نيابةً عنهم؟
إذا فهمتُ الأمر بشكل صحيح، يضم فريقك ستة مهندسين، أليس كذلك؟ أراهن بأنّه لا يمكنك العمل مع كل إطار عمل أو مكتبة ممكنة. كيف تختار الجهة التي تريد التعاون معها؟ من هم هؤلاء المستخدمون؟
آدي: يشبه الويب من نواحٍ كثيرة الغرب المتوحش. يمكنك اختيار أي إطار عمل أو أداة تجميع حِزم أو مكتبات أو جهات خارجية تريدها. ويؤدي ذلك إلى ظهور عدة طبقات من التعقيد التي يمكن أن تساهم في تحقيق أداء جيد أو ضعيف. من بين أفضل الطرق لتحسين الأداء هي العثور على هذه الطبقات التي تشعر بالراحة عند التعبير عن آرائها وإضافة المزيد من الآراء إليها.
على سبيل المثال، تحاول إطارات عمل الويب (Next.js وNuxt.js وAngular إلى حدٍّ ما) تضمين المزيد من الآراء والإعدادات التلقائية مقارنةً بحلّ مُعدّ يدويًا. وهذا أحد الأسباب التي تجعلنا نحب العمل معهم. من المنطقي أن يكون لديك إعدادات تلقائية أكثر فعالية لكيفية تحميل الصور والخطوط والنصوص البرمجية من أجل تحسين "مؤشرات أداء الويب الأساسية" في هذه النماذج.
ويُعدّ أيضًا طريقة رائعة لتأكيد مدى فعالية أفضل الممارسات الحديثة أو الحاجة إلى إعادة النظر فيها، ويمكن أن يساعد في إطلاع المنظومة المتكاملة بأكملها على كيفية التعامل مع مشكلات التحسين.
كارا: من المنطقي أيضًا أن نأخذ مدى رواج المحتوى في الاعتبار. إذا أردنا تحقيق أكبر تأثير ممكن على الويب، من الأفضل العمل مع إطارات العمل والمكتبات التي تضمّ منتدى كبيرًا من المطوّرين الحاليين. بهذه الطريقة، يمكننا الوصول إلى المزيد من المطوّرين والتطبيقات. ولكن لا يمكن أن يكون ذلك بسبب مدى رواج المحتوى فقط. في النهاية، يعتمد ذلك على مدى رواج المكتبة ومدى تنوع الآراء حولها ومجموعة الميزات المتاحة التي يمكننا العمل بها.
على سبيل المثال، إذا نظرنا إلى مدى الانتشار فقط، نجد أنّ React وVue وAngular هي "الثلاث الكبار" التي يجب أخذها في الاعتبار. ولكننا نعمل بشكل أساسي مع Next.js وNuxt وAngular. ويعود السبب في ذلك إلى أنّ مكتبات العرض، مثل React وVue، تركّز في الأساس على العرض، لذا من المستحيل إنشاء جميع الميزات التي نريدها فيها مباشرةً. لذلك، نعمل بشكل وثيق مع إطارات العمل الوصفية التي تم إنشاؤها على أساسها: Next.js وNuxt. في هذا المستوى من التجريد، يمكننا إنشاء مكونات مضمّنة. وتتضمّن هذه الأدوات أيضًا خوادم مدمجة، ما يتيح لنا تضمين تحسينات من جهة الخادم.
قد تلاحظ أنّ Angular كان مُدرَجًا في قائمة الشراكات المطوّلة هذه، ولكنّه ليس إطار عمل ميتافيرس. يُعدّ Angular حالة خاصة إلى حدٍ ما لأنّه رائج جدًا، ولكنّه لا يتضمّن إطار عمل ميتافيرس مكمّلاً مثل React وVue. لذلك، نعمل معه مباشرةً ونساهم في إضافة ميزات من خلال واجهة سطر الأوامر كلما أمكن ذلك.
تجدر الإشارة إلى أنّ لدينا العديد من العلاقات المستمرة مع مشاريع أخرى، مثل Gatsby، حيث تتم مزامنة التصميم بشكل منتظم إلى حدٍ ما، ولكن لا نساهم بشكل نشط في الترميز.
كيف يبدو ذلك عمليًا؟ ما هو النهج الذي اتّبعته لحلّ هذه المشكلة؟
كارا: في الواقع، لدينا بعض الأطر التي نتعاون معها عن كثب. سنستغرق بعض الوقت لإنشاء ملف شخصي للتطبيقات باستخدام هذا الإطار وتحديد المشاكل الشائعة في الأداء. بعد ذلك، نعمل مع فريق إطار العمل لتصميم ميزات تجريبية لحلّ هذه المشاكل وتقديم الرمز البرمجي مباشرةً إلى مستودع البرامج مفتوحة المصدر لتنفيذها.
من المهم جدًا بالنسبة إلينا التأكّد من أنّ تأثير الأداء هو ما توقّعناه، لذا نعمل أيضًا مع شركات خارجية لإجراء اختبارات الأداء في مرحلة الإصدار العلني. إذا كانت النتائج مشجّعة، سنساعد في تحسين الميزة إلى أن تصبح "مستقرة"، وقد نجعلها ميزة تلقائية.
لا يمكن أن يكون كل هذا سهلاً كما يبدو. ما هي بعض التحديات أو الدروس التي تعلمتها حتى الآن؟
حسين: من الأمور المهمة التي نحاول التركيز عليها قدر الإمكان هي المساهمة في مستودعات البرامج الرائجة ذات المصدر المفتوح والتي تتضمّن العديد من الأولويات المتنافسة. لا يعني أنّنا فريق Google أنّه سيتم منح الأولوية لميزاتنا، لذا نبذل قصارى جهدنا للالتزام بالعملية المعتادة لاقتراح الميزات الجديدة وطرحها بدون التأثير في أي فريق آخر. لقد كان من حسن حظنا العمل مع مشغّلي الصيانة المتعاونين في الأنظمة المتكاملة Next.js وNuxt وAngular. نحن ممتنون لاستعدادهم للاستماع إلى مخاوفنا بشأن المنظومة المتكاملة للويب وتعاونهم معنا بعدة طرق.
في العديد من الأطر التي نعمل بها، تبقى مهمتنا العامة هي نفسها: كيف يمكن للمطوّرين الحصول على تجربة مستخدم محسّنة بشكلٍ تلقائي مع الاستمتاع أيضًا بتجربة مطوّرين رائعة؟ ندرك ونحترم أنّ هناك مئات، إن لم يكن آلاف، من المساهمين في المنتدى ومشرفي الإطارات الذين يعملون كلٌّ منهم على مشاريع مختلفة تتداخل مع بعضها.
كارا: بالإضافة إلى ذلك، لأنّنا نهتم بالتحقق من تأثير الأداء واتّخاذ الإجراءات استنادًا إلى البيانات، تستغرق العملية بعض الوقت. نحن في مجال غير معروف، لذا سنجرّب أحيانًا تحسينًا لا يحقّق النتائج المرجوة ولا يؤدّي إلى إنشاء ميزة مخطّط لها. وحتى في حال نجاح إحدى الميزات، تستغرق هذه الخطوات الإضافية القليلة للتحقّق من الأداء بعض الوقت وتؤدّي إلى تمديد المخططات الزمنية.
قد يكون من الصعب أيضًا العثور على شركاء إنتاج لاختبار ميزاتنا. كما ذكرنا سابقًا، هذه أنشطة تجارية لها أولوياتها الخاصة، لذا قد يكون من الصعب عليها دمج مبادرات جديدة إذا لم تكن متوافقة بشكل جيد مع المشاريع الحالية التي يجب أن تكون لها الأولوية. بالإضافة إلى ذلك، إنّ الشركات الأكثر اهتمامًا بالمساعدة تميل إلى تخصيص الوقت لاستثماره في الأداء، لذا فهي ليست جمهورنا المستهدَف. نحاول جمع الملاحظات من شريحة كبيرة من المنتدى لا يمكنها الاستثمار في الأداء، ولكنّهم الأقلّ احتمالًا للتواصل معنا.
بعد ذلك، ما هو نوع التحسينات التي كنت تركّز عليها؟
حسين: بعد تحليل آلاف التطبيقات، تبيّن لنا أنّ أكبر مشاكل الأداء تعود عادةً إلى الأنماط المضادة في رمز التطبيق بدلاً من إطار العمل نفسه. على سبيل المثال، إرسال صور كبيرة جدًا بدون داعٍ، وتحميل خطوط مخصّصة بعد فوات الأوان، وجلب عدد كبير جدًا من طلبات الجهات الخارجية التي تحظر سلسلة المحادثات الرئيسية، وعدم التعامل مع كيفية تأثير المحتوى غير المتزامن في تغيير عناصر أخرى على الصفحة. يمكن أن تحدث كل هذه المشاكل بغض النظر عن الأداة التي تستخدمها، لذلك فكرنا في إمكانية تضمين بعض التحسينات التلقائية التي تتعامل معها بشكل جيد ولكن مع توفير تجربة مطوّرين رائعة تتناسب بشكل جيد مع أدوات إطار العمل.
استنادًا إلى هذه الفكرة، أطلقنا الميزات التالية:
- مكوّن الصورة في Next.js
- مكوّن نص Next.js
- إدراج الخطوط تلقائيًا في عملية إنشاء Next.js
- توجيه الصور في Angular
- مكوّن ESLint الإضافي لضمان امتثال Next.js لتوفير إرشادات قابلة للتنفيذ للمطوّرين
وقد ألهم عملنا أُطر عمل وأدوات أخرى لتنفيذ تحسينات مشابهة. ويشمل ذلك على سبيل المثال لا الحصر:
هل يمكنك مشاركة بعض النتائج الإيجابية لعملك مع بعض هؤلاء اللاعبين؟
حسين: شهدت العديد من المواقع الإلكترونية تحسينات في الأداء بسبب التحسينات التي طرحناها. أحد الأمثلة المفضّلة لدي هو Leboncoin، الذي خفض سرعة عرض أكبر محتوى مرئي من 2.4 ثانية إلى 1.7 ثانية بعد التبديل إلى مكوّن الصورة في Next.js. هناك العديد من الميزات الأخرى التي لا تزال قيد التجربة والاختبار، وسنواصل مشاركة النتائج التي نحصل عليها من هذه الميزات هنا.
حسنًا، أتفهّم أنّ تركيزك ينصب على الإطارات أو المكتبات الأكثر رواجًا، ولكن هل هناك طرق يمكن من خلالها أيضًا الاستفادة بشكل استباقي من إطارات العمل أو المكتبات الأخرى التي لا تعمل معها؟
آدم: يمكن لأي إطار عمل تكرار العديد من تحسينات الأداء التي تتعاون عليها "أورورا". يمكنك الاطّلاع على جهودنا في ما يتعلّق بمكوّنات "الصورة" أو "النص البرمجي"، على سبيل المثال، إذ غالبًا ما تُعدّ هذه المكوّنات مجموعة حالية من أفضل الممارسات. نحاول توثيق كيفية إنشاء هذه المكوّنات وشكلها في كل إطار عمل. نأمل أن تكون هذه بداية جيدة لنسخ الفكرة.
لقد حقّقنا بعض النجاحات من خلال الاستفادة من الدروس المستفادة من منظومة متكاملة واحدة (مثل React وNext.js) وتطبيقها على أنظمة متكاملة أخرى. على سبيل المثال، توجيه Angular Image الجديد (المستند إلى ما تعلمناه أثناء إنشاء مكوّن Next.js Image) أو Gatsby الذي يُطلق أسلوبنا في تقسيم JavaScript إلى أجزاء دقيقة.
في الوقت نفسه، ندرك أنّ بعض الأطر لن تتوفّر فيها السعة أو التمويل الكافيان ليتمكّن المساهمون من إنشاء ميزات أداء مشابهة أو الاستثمار في تحسينات أخرى يعتقدون أنّها مهمة للمستخدمين. يشكّل صندوق Chrome Web Frameworks طريقة لنا لرعاية العمل على الأداء في المنظومة المتكاملة لـ JavaScript من أجل تمكين المشاريع من الدفع للمساهمين فيها وتوسيع نطاق العمل على الأداء في المنظومة المتكاملة.
ما هي خارطة الطريق التي تحدّدها لفريقك؟
كارا: لدينا الكثير من المشاريع المشوّقة القادمة. بعض الملاحظات المهمة:
- تقليل متغيّر CLS المرتبط بالخط: من الشائع جدًا حدوث تغييرات في التصميم عند تحميل خط ويب واستبدال الخط الاحتياطي. نحن نستكشف استخدام عمليات إلغاء مقاييس الخط والسمة size-adjust لتقليل مقياس CLS المرتبط بالخط تلقائيًا في Next.js. لقد استشرنا أيضًا فريق Nuxt بشأن هذا الموضوع وننوي توسيع نطاق هذه الفكرة ليشمل المزيد من أطر العمل في العام المقبل.
- تصحيح أخطاء مقياس "مدة عرض الاستجابة لتفاعل المستخدم": بعد طرح مقياس مدة عرض الاستجابة لتفاعل المستخدم (INP)، نعمل على استخدام إطارات العمل للتحقيق في الأسباب الجذرية الأكثر شيوعًا لمشاكل مقياس INP في المنتديات واقتراح حلول لها. لقد تعاونّا بشكل وثيق مع Angular في هذا الشأن ونأمل أن نحصل على بعض النتائج لنشاركها قريبًا.
- تحسين النصوص البرمجية الشائعة التابعة لجهات خارجية: يمكن أن يكون لتحميل النصوص البرمجية التابعة لجهات خارجية في الوقت غير المناسب تأثير سلبي كبير في الأداء. بما أنّ هناك بعض الجهات الخارجية الشائعة جدًا، ننظر في ما إذا كان بإمكاننا تقديم بعض الحِزم لهذه الجهات لضمان تحميلها على النحو الأمثل باستخدام إطارات العمل وعدم حظر سلسلة المهام الرئيسية. نحن نستخدم مكوّن نص Next.js الذي أنشأناه كنقطة بداية لهذا التحقيق.
يمكن للمطوّرين متابعة مستوى تقدّمنا على هذا الموقع الإلكتروني.
في الأخبار
قبل إنهاء هذه الرسالة، أودّ أن أشارك معك بعض المعلومات الجديدة والمفيدة حول الأطر التي يتم العمل عليها في Google.
في تموز (يوليو)، أعلن فريق Chrome عن جولة التمويل الأخيرة التي تبلغ قيمتها 500 ألف دولار أمريكي لصندوق الأطر والأدوات الذي يركز على تمويل المشاريع التي تهدف إلى المساعدة في تحسين الأداء وتجربة المستخدم وتجربة المطوّر على الويب. سيتم النظر في تمويل المشروعات الجديدة في المستقبل، لذا يُرجى إرسال طلبك.
وهناك أيضًا الكثير من الفعاليات الرائعة التي تحدث في المنتدى. تتضمّن المنظومة المتكاملة إطارات عمل جديدة، مثل Fresh من Deno، وتجارب رائعة، مثل الدليل التعليمي لإعداد Svelte الذي لا يقدّم عرضًا توضيحيًا داخل المتصفّح فحسب، بل يستخدم أيضًا Web Container API لتشغيل Node.js بشكل أصلي في المتصفّح. محتوى رائع
يسعدني حقًا رؤية المنظومة المتكاملة تتكامل، وتقديم كل ما يمكن في المتصفّح ومساعدة المطوّرين في إنشاء منتجات تناسب الجميع. إنّه وقت مثير أن تكون مطوّر ويب.
إلى اللقاء في المقالة التالية، مع أطيب التحيّات.
ما رأيك في هذا العدد من The Chrome Dev Insider؟ مشاركة ملاحظاتك