اسمي بول كينلان، وأنا رئيس قسم علاقات المطوّرين في Chrome. كجزء من وظيفتي، أعمل مع فريق من مؤيدي الويب الشغوفين المكلفين بعرض وجهة نظر مطوّري البرامج في العالم الحقيقي إلى فرق المنتجات والهندسة لدينا، باستخدام مقياس "النجمة الشمالية" لتحسين رضا المطوّرين.
ندرك أنّ "مستوى الرضا" هو مقياس طموح وذاتي يجب تتبُّعه وتحسينه، لذلك نكرّر باستمرار جهودنا لإحداث تأثير مع التركيز في الوقت نفسه على احتياجات المطوّرين. لقد وجدنا أنّ هناك مبدأ إرشادي مفيد هو "مقابلة مطوّري البرامج أينما كانوا". أظهرت دراسة حديثة في Stack Overflow أنّ 75% من المطوّرين يستخدمون أطر عمل أو مجرّد فكرة من نوع ما. لذا سألنا أنفسنا عن أفضل طريقة لخدمة المطوّرين الذين اتّخذوا قرارات بشأن حزمة التكنولوجيا أو لا يمكنهم التحكّم فيها. كيف نجعلها أكثر إنتاجية دون إضافة المزيد من النفقات العامة؟
يعمل فريق صغير هنا في Chrome على مشروع يُسمّى Aurora، سعيًا إلى التعامل مع تجريدات تابعة لجهات خارجية من النظام الأساسي للويب، مثل أُطر العمل والمكتبات. وتهدف هذه التطبيقات إلى المساعدة في تحقيق مكاسب على مستوى الأداء مباشرةً ضمن هذه التجارب المجرّدة، بدلاً من وضع أعباء العمل على عملائها، وهم مطوّري برامج الويب.
في الإصدار الثالث من Chrome Dev Insider، تحدثت مع Addy Osmani وKara Erickson وHoussein Djirdeh من فريق Project Aurora لمعرفة المزيد حول كيفية التعامل مع هذا المشروع وما ينتظرهم مستقبلاً.
تفاصيل النشرة الإخبارية الداخلية: العمل باستخدام أُطر العمل التابعة لجهات خارجية
لنبدأ بنشأة هذا المشروع. كيف تم إنشاء ذلك؟
Addy: بدأت "أورورا" بفكرة بسيطة وهي: دعونا نلتقي بالمطوّرين أينما كانوا ونساعدهم في الوصول إلى ما يريدون. مثلاً، يمكنك مساعدة حزمة التكنولوجيا الرائجة التي اختاروها لتحسين الأداء. يصمم العديد من مطوري التطبيقات باستخدام 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. ولذلك، نعمل معهما مباشرةً ونقدّم ميزات من خلال واجهة سطر الأوامر عندما يكون ذلك ممكنًا.
ومن الجدير بالذكر أنّ لدينا العديد من العلاقات المستمرة مع مشاريع أخرى مثل "غاتسبي"، حيث نعمل على مزامنة التصميم بانتظام إلى حدٍ ما ولكن لا نساهم في الرموز البرمجية بشكل فعال.
كيف يبدو ذلك عمليًا؟ ما هو نهجك في حلّ هذه المشكلة؟
كارا: من الناحية العملية، لدينا بعض أطر العمل التي نتعاون معها عن كثب. سيستغرق الأمر بعض الوقت لتحديد التطبيقات باستخدام إطار العمل هذا وتحديد المشكلات الشائعة في الأداء. ثم نعمل مع فريق إطار العمل لتصميم ميزات تجريبية لحل هذه المشكلات والمساهمة في التعليمات البرمجية مباشرةً في مستودع OSS لتنفيذها.
من المهمّ حقًا أن نتحقّق من أنّ تأثير الأداء هو ما توقّعناه، لذا نعمل أيضًا مع شركات خارجية لإجراء اختبار الأداء في مرحلة الإنتاج. إذا كانت النتائج مشجّعة، سنساعدك على جعل الميزة "مستقرة" وربما جعلها تلقائية.
إنّ الأمر ليس بالسهولة نفسها التي تعلّمتها. ما هي بعض التحديات أو الدروس التي تعلّمتها حتى الآن؟
حسين: نحن نحاول الاستفادة إلى أقصى حدّ من قدراتنا من خلال المساهمة في المستودعات المعروفة ومفتوحة المصدر التي لديها العديد من الأولويات التنافسية. وكوننا فريقًا في Google لا يعني بالضرورة أنه سيتم إعطاء الأولوية لميزاتنا، لذا نبذل قصارى جهدنا للتماشي مع العملية المعتادة لاقتراح ميزات جديدة وشحنها من دون أن يهمّنا أحد. لقد كنا محظوظين جدًا للعمل مع مقدمي خدمات الصيانة المتقبّلين في الأنظمة البيئية Next.js وNuxt وAngular. ونحن ممتنون لقد تعاملت الشركة مع مخاوفنا بشأن منظومة الويب المتكاملة وعلى استعدادها للتعاون معنا بأكثر من طريقة.
ومن خلال العديد من أطر العمل التي نعمل معها، تكون مهمتنا العامة هي نفسها: كيف يمكن للمطوّرين الحصول على تجربة مستخدم محسّنة بشكل غير تقليدي، مع الاستمتاع أيضًا بتجربة رائعة للمطوّرين؟ نحن ندرك ونحترم المئات، إن لم يكن الآلاف، من المساهمين في المنتدى والقائمين على إطار العمل يعملون على مشاريع مختلفة تتقاطع مع بعضها البعض.
كارا: بالإضافة إلى ذلك، تستغرق العملية وقتًا أطول لأنّنا نهتم بالتحقق من تأثير الأداء والتصرف استنادًا إلى البيانات. نحن في منطقة مجهولة، لذا سنجري أحيانًا تجربة مع تحسين لا يتخطى نطاق الأداء ولا ينتهي بنا الأمر إلى إنشاء ميزة مخططة لها. حتى عندما تتوقّف الميزة عن العمل، تستغرق هذه الخطوات الإضافية القليلة لمراجعة الأداء وقتًا وتوسيع الجداول الزمنية.
قد يواجه المستخدمون صعوبات أيضًا في العثور على شركاء إنتاج لاختبار ميزاتنا. كما ذكرنا سابقًا، إنها شركات ولديها أولوياتها الخاصة، لذلك قد يكون من الصعب عليها ملاءمتها مع المبادرات الجديدة إذا لم تتوافق بشكل جيد مع المشروعات الحالية التي يجب أن تأتي في المقام الأول. بالإضافة إلى ذلك، تميل الشركات الأكثر اهتمامًا بالمساعدة إلى قضاء بعض الوقت للاستثمار في تحسين الأداء، ولذلك هم ليسوا من الجمهور المستهدف. نحن نحاول جمع ملاحظات من شريحة كبيرة من المنتدى ليس بإمكان الاستثمار في تحسين الأداء، ولكن من غير المرجّح أن يتواصلوا معنا.
من الآن فصاعدًا، ما نوع التحسينات التي كنت تركّز عليها؟
حسين: بعد تحليل آلاف التطبيقات، تبيّن لنا أنّ أكبر مشاكل الأداء ترجع عادةً إلى تناقضات الأنماط في رمز التطبيق وليس إطار العمل نفسه. على سبيل المثال، شحن الصور الكبيرة غير الضرورية، وتحميل الخطوط المخصّصة بعد فوات الأوان، وجلب عدد كبير جدًا من طلبات الجهات الخارجية التي تحظر سلسلة التعليمات الرئيسية، وعدم التعامل مع الكيفية التي يمكن أن يؤدي بها المحتوى غير المتزامن إلى تغيير الأمور الأخرى على الصفحة. هذه هي المشاكل التي يمكن أن تنشأ بغض النظر عن الأداة التي تستخدمها. لذلك، فكّرنا في أنّه هل يمكننا إعداد بعض التحسينات التلقائية التي تتعامل معها بشكل جيد ولكن من خلال تجربة دقيقة للمطوّرين تتلاءم بشكل جيد مع أدوات إطار العمل التي يستخدمونها؟
بناءً على ذلك، تم شحن ما يلي:
- مكوِّن صورة Next.js.
- مكوِّن النص البرمجي Next.js.
- التضمين التلقائي للخط في عملية إنشاء Next.js.
- توجيه الصورة الزاوية:
- مكوّن ESLint الإضافي Next.js لتقديم إرشادات قابلة للتنفيذ للمطوّرين
وقد ألهم عملنا أطر عمل وأدوات أخرى لتنفيذ تحسينات مماثلة. ويشمل ذلك على سبيل المثال لا الحصر:
- وحدة صورة Nuxt
- عمليات إلغاء مقياس الخط Nuxt
- مكوِّن نص Nuxt البرمجي (قيد التقدّم)
- مكوِّن Gatsby Script
هل يمكنك مشاركة بعض النتائج الإيجابية لعملك مع بعض هؤلاء اللاعبين؟
حسين: شهدت العديد من المواقع الإلكترونية تحسّنًا في الأداء نتيجة التحسينات التي تم شحنها. ومن الأمثلة المفضّلة لديّ هو Leboncoin التي خفّضت سرعة عرض أكبر محتوى مرئي (LCP) من 2.4 إلى 1.7 ثانية بعد التبديل إلى مكوّن الصورة Next.js. يتوفّر حاليًا العديد من المنصات التي لا تزال في مرحلة التجربة والاختبار، وسنواصل مشاركة الخلاصات والمكاسب من هذه الصفحة.
حسنًا، يبدو أنّ تركيزك على المجموعات الأكثر رواجًا، لكن هل هناك طرق تستفيد منها بشكل استباقي لأُطر عمل أو مكتبات أخرى لا تعمل معها؟
Addy: يمكن تكرار العديد من تحسينات الأداء التي تتعاون Aurora عليها في أي إطار عمل. ألقِ نظرة على جهود مكوّنات الصور أو النصوص البرمجية على سبيل المثال، فهي غالبًا ما تحدّد مجموعة حالية من أفضل الممارسات. نحاول توثيق "كيفية" إنشاء هذه المكوّنات والشكل الذي تبدو عليه في كل إطار عمل. نأمل أن تكون هذه بداية جيدة لنسخ الفكرة.
لقد حققنا نجاحًا كبيرًا في استخلاص الدروس المستفادة من إحدى المنظومة المتكاملة (على سبيل المثال، React وNext.js) وتقديمها إلى الأنظمة الأخرى. على سبيل المثال، توجيه الصور الزاوي الجديد (الذي يستند إلى ما نتعلمه لإنشاء مكوّن صور Next.js) أو يشحن غاتسبي طريقتنا في تقسيم أجزاء JavaScript الدقيقة.
وفي الوقت نفسه، ندرك أنه لن يتوفّر لكل إطار عمل معدل نقل البيانات أو التمويل اللازمَين للمساهمين لإنشاء ميزات أداء مشابهة أو الاستثمار في تحسينات أخرى يعتقدون أنّها مهمة للمستخدمين. يشكّل صندوق إطارات عمل الويب من Chrome وسيلة تتيح لنا رعاية أعمال الأداء في منظومة JavaScript المتكاملة بهدف السماح للمشاريع بدفع مبالغ للمساهمين فيها وتمكين أعمال الأداء من التوسّع بشكل أكبر في المنظومة المتكاملة.
ما هي خطة العمل المقبلة لفريقك؟
كارا: لدينا الكثير من المشاريع الشيّقة القادمة. بعض الملاحظات المهمة:
- تقليل متغيّرات التصميم التراكمية (CLS) المتعلّقة بالخطوط: من الشائع جدًا رؤية متغيّرات التصميم عند تحميل خط على الويب واستبدال الخط الاحتياطي. نعمل حاليًا على استكشاف استخدام عمليات إلغاء مقاييس الخط وسمة "ضبط الحجم" لتقليل متغيّرات التصميم التراكمية (CLS) المرتبطة بالخطوط تلقائيًا في مقتطف Next.js. كما تشاورنا مع فريق Nuxt في هذا الشأن ونخطط لتوسيع نطاق هذه الفكرة لتشمل المزيد من أطر العمل في العام المقبل.
- تصحيح أخطاء INP: بعد إطلاق مقياس مدى استجابة الصفحة لتفاعلات المستخدم (INP)، نعمل حاليًا على وضع أُطر عمل للتحقّق من الأسباب الأساسية الأكثر شيوعًا لمشاكل INP في المنتديات واقتراح حلول. لقد تعاونّا بشكل وثيق مع Angular في هذا الشأن ونأمل أن نحصل على بعض النتائج لمشاركتها قريبًا!
- تحسين النصوص البرمجية الشائعة التابعة لجهات خارجية: يمكن أن يؤدي تحميل النصوص البرمجية التابعة لجهات خارجية في الوقت غير الصحيح إلى تأثير سلبي كبير على الأداء. بما أنّ بعض البرامج التابعة لجهات خارجية شائعة جدًا، ننظر في ما إذا كان بإمكاننا توفير بعض برامج تضمين لهذه البرامج لضمان تحميلها على النحو الأمثل باستخدام أُطر العمل وعدم حظر سلسلة التعليمات الرئيسية. نحن نستخدم مكون النص البرمجي Next.js الذي أنشأناه كنقطة بداية لهذا التحقيق.
يمكن للمطوّرين متابعة مستوى تقدّمنا على هذا الموقع الإلكتروني.
في الأخبار
قبل موافقتي، أود أن أشارك معك بعض الأخبار المهمة من عالم أطر العمل التي تحدث في Google.
في تموز (يوليو)، أعلن فريق Chrome عن أحدث جولة لتمويل بقيمة 500 ألف دولار أمريكي لصندوق "Frameworks and Tools" (صندوق أدوات الإطار) الذي يركّز على تمويل المشاريع التي تهدف إلى المساعدة في تحسين الأداء وتجربة المستخدم وتجربة المطوّرين على الويب. سيراعي التمويل المستقبلي مشاريع جديدة، لذا احرص على إرسال طلبك.
وبالطبع، هناك أيضًا الكثير من الأشياء الرائعة التي تحدث في المجتمع. المنظومة المتكاملة مليئة بأُطر عمل جديدة، مثل الإصدار Fresh من Deno، وتجارب رائعة مثل برنامج Svelte التعليمي الذي يقدّم عرضًا توضيحيًا في المتصفّح والذي لا تقتصر على استخدام واجهة برمجة التطبيقات Web Container API لتشغيل Node.js بشكل أساسي في المتصفّح. أمور جيدة جدًا!
يسرّني كثيرًا رؤية تكامُل المنظومة المتكاملة معًا وتعزيز إمكانات المتصفّح ومساعدة المطوّرين على تصميم منتجات تناسب الجميع. إنه وقت رائع أن تكون مطوّر برامج على الويب.
حتى النشرة القادمة من قناة Hwyl fawr.
ما رأيك بهذا الإصدار من Chrome Dev Insider؟ يُرجى مشاركة ملاحظاتك.