إيفان أكولوف - خبير مطور برامج Google في تقنيات الويب ومؤسس شركة الأداء PerfPerfPerf . قريباً جداً ، في HolyJS 2019 في موسكو ، سيعقد ورشة عمل مخصصة ، بشكل غريب بما فيه الكفاية ، لإيجاد مشاكل في الأداء في React ، وتصحيح أخطاء التطبيقات البطيئة وغيرها من أشياء وقت التشغيل.
لمزيد من القراء والانغماس في HolyJS 2019 موسكو في الموضوع ، ناقشنا مع إيفان:
- مشاكل الأداء الأكثر شعبية ؛
- كيفية قياس الأداء وما قد تكون المشكلة ؛
- كيفية تحسين الأداء ؛
- البحث عن مشاكل الأداء في React؛
- فوائد التبديل إلى HTTP / 2 و HTTP / 3 ؛
- من الأفضل استخدام إطار مضغوط في المشاريع الجديدة ؛
- حول فوائد WebAssembly ؛
- أين تبحث عن معلومات الأداء المفيدة ؛
- ماذا ستكون ورشة العمل الخاصة به ومن سيهتم بالحضور إليها (ولماذا يذهب إلى ورش العمل على الإطلاق).
يتم طرح الأسئلة من قبل ديمتري مخنيف وأرتيوم كوبزار من لجنة برنامج HolyJS.
ديمتري: أخبرني بضع كلمات عن نفسك.
إيفان: أنا إيفان أكولوف ، مستشار الأداء وخبير مطوري Google ، وأقوم بوكالة استشارات الأداء الخاصة بي.
ديمتري: أنت تقول إن الوكالة الاستشارية ليست الوظيفة الرئيسية. لكن في الأساس ماذا تفعل؟
إيفان: يتم توزيع وقتي الآن تقريبًا بحيث أصبحت محملة بنصف العمل مع عميل قديم. أنا أعمل مع شركة برازيلية واحدة ، معًا نقوم بإنشاء منصة لتسويق محتوى Wordpress ، وأدير البنية التحتية هناك وقليلًا من تطوير المنتجات ، ونوع من الرؤية المشتركة.
بقية الوقت الذي خصصه للاستشارات والخطب والمقالات وكل ذلك.
ديمتري: هل هناك العديد من النداءات للاستشارات في الأداء؟ كيف يعمل حتى؟
إيفان: بشكل عام ، يعتمد الأمر كثيرًا على الشهر أو شيء من هذا القبيل ...
ديمتري: متى يعلن المنجمون عن شهر الأداء؟ :)
إيفان: بدلاً من ذلك ، عندما يعلن المحاسبين عن ربع جديد! (يضحك). أنا لا أبحث بنشاط عن العملاء في الوقت الحالي ، والسبب الرئيسي هو أنه لا يوجد وقت لذلك الآن ، لأنني بالفعل محمّل بما لدي. ولكن بشكل عام ، يبدو كل شيء أنني أكتب بعض المقالات ، وألقي بعض الخطب ، وعند العمل مع بعض العملاء ، يتذكرونني ويوصونني بأخبار جديدة. معظمهم من الناس يأتي بفضل الشبكة ، ويأتي الرجال بارد جدا.
أرتيوم: كيف وصلت إلى موضوع الأداء قبل أن تنشئ شركة استشارية خاصة بك؟
إيفان: في الواقع ، بدأ كل شيء بحقيقة أننا أعادنا كتابة مشروع قديم في Epam لمدة نصف عام على wepback. كان هناك مشروع قديم مع مجموعة من الإرث ، مع إطار الواجهة الأمامية الخاص به ، نصفه يعمل في مكدس جافا. ونظرًا لأننا أمضينا نصف عام في جعل حزمة الويب سريعة نسبيًا ، فقد حصلت على خبرة مع حزمة الويب. وفي ذلك الوقت ، كان بإمكاني كتابة webpack-config من التعقيد المتوسط ، أسطر من 20 إلى 40 ، حرفيًا من الذاكرة ، دون أي غوغلينغ ، ودون أي اختصار ، وحتى دون استخدام التحسس الذكي.
وأدركت أن مثل هذه التجربة يمكن أن تكون مفيدة لشخص آخر ، فقد قررت محاولة بدء نوع من الاستشارات في مجال حزمة الويب. قمت بالهبوط لنفسي ، ونشرته في مكان ما ، جاء زوجين ، وعملت مع أحدهما. وبطريقة ما بدأ كل شيء.
وفي وقت لاحق ، تدفقت بسلاسة من أداء webpack ذات الصلة إلى استشارات الأداء بشكل عام.
أرتيوم: هل تمكنت من تحسين أداء التجميع في هذا المشروع؟
إيفان: هذا المشروع لم ينجح تمامًا ، وليس بالطريقة التي أرغب في الحصول عليها في النهاية. كان الأمر شبيهاً بأن الرجال جاءوا في وقت كنت في حاجة ماسة إليه وما زلت لا أفهم كيف أتفاوض ، وأعتني بنفسي وأخذ اهتماماتي في الاعتبار في هذه المفاوضات. لقد اقترحت بعض الأسعار الثابتة الصغيرة مع كمية غير مضمونة من العمل ، وعملنا ، وساعدتهم ، واتخذوا قرارًا يبدو أنه يعمل ، وحددوا الأداء.
ثم اتضح أن هناك أخطاء في هذا الحل ، واتضح أن هذه الأخطاء معقدة للغاية وأنشئت أخطاء غريبة في حالات حافة نادرة. بدأنا في إصلاحه ، قمت بإصلاح خطأ واحد ، وثاني ، وثالث ، واستمر كل هذا لمدة شهر. وفي النهاية ، في مرحلة ما ، توقفت الأخطاء ، لكن الرجال قرروا أن يطلبوا مني شيئًا آخر ، لكن بما أن لدي ميزانية داخلية لهذا الأمر ، فقد انتهيت تمامًا ، قلت للتو: "آسف ، لقد تم تحميلي بالفعل ، وليس يمكنني المساعدة ".
كنتيجة لذلك ، على حد علمي ، استبدلوا هذا الحل في غضون شهرين بحل آخر أقل تعقيدًا وعملوا في 100٪ من الحالات.
بصراحة ، لا أعرف نفسي ... يبدو أنني أتيت وساعدت ، والقرار النهائي الذي اتخذوه قد وُلد في محادثاتنا السابقة ، لكنني لا أعرف كم ساعدوا ما فعلته. وما مدى رضاهم عن هذا كله. باختصار ، لم تكن مثالية كما أريد.
أرتيوم: وبالتحدث اليوم ، هل تتعقب العملاء السابقين بطريقة أو بأخرى ، كيف يفعلون هناك ، هل ساعد كل ذلك؟
إيفان: نعم بالتأكيد. أنا وضعت تدريجيا بعض النهج. أولاً ، في نهاية عملي ، أحاول الحصول على بعض التعليقات العامة من كل عميل ، والتي يمكن نشرها على الموقع أو نشرها في مكان ما.
ثانياً ، لقد قمتُ بتطوير منهج لطرح العملاء في عملية أو نهاية مهمة ما على السؤال "ما مدى رضاك عن العملية الحالية ، وسير العمل الحالي ، والشيء الحالي؟" مع خيارات الإجابة "أكثر من راضي" ، "راضي" ، "راضي تقريبًا" ، "غير راضي حقًا".
وأنا أحب هذا السؤال ، لأنه يقدم إجابات محددة ، وليس مقياسًا سخيفًا من 1 إلى 5 ، وهو ما يتصوره الجميع بطريقتهم الخاصة. حتى الآن ، لم يرد أي من العملاء "راضٍ تقريبًا" أو "غير راضٍ حقًا". كان راضيا ، سعيد ، وشيء من هذا القبيل.
أرتيوم: هل أفهم بشكل صحيح أن مجال خبرتك في الأداء يستهدف بشكل أساسي جانب العميل؟ أم أن لديك مكدس ويب بالكامل ككل متأثرًا بالمشاورات؟
إيفان: نعم ، يهدف مجال الخبرة بشكل أساسي إلى تكديس العميل ، مع تحسين الأداء في الخلفية أو في قواعد البيانات ، لقد عملت كثيرًا. لكن في الممارسة العملية ، إذا كان تطبيق الويب يتباطأ ، حتى بعض المقالات أو الدراسات ، فإن ذلك يتراوح بين 80 و 90 ٪ من الحالات - يتباطأ بالضبط بسبب الواجهة الأمامية.
إذا جاء عميل وتباطأ شيء ما ، فإن خبرتي في معظم الحالات تكون صحيحة.
حول القضايا الأكثر شعبية
أرتيوم: وماذا يحدث عندما يكون هناك بعض حالات الحافة؟ عندما نواجه مشكلة ، لا في تحليل JavaScript وإطلاقه ، ولكن مع مشاكل النقل. عندما يتم تعيين التفاعل الأول للعميل ، وكذلك للواجهة الخلفية. من الجيد أن gzip تم إعداده بشكل غير صحيح ؛ فقد كان يدور لفترة طويلة جدًا. ماذا تفعل في هذه الحالات؟ وإذا كان تحليلك على الخط الأمامي بشكل أساسي ، كيف تجد مثل هذه الحالات؟
إيفان: حسنًا ، هذا يعني عادة أن وقت الاستجابة من الخادم يصبح أطول من اللازم. إذا لاحظت ذلك أثناء إجراء تدقيق ما ، نظرت إلى devtools ، أنظر إلى الشبكة وأرى أن الوقت المستغرق من الخادم هو 800 مللي ثانية - للذهاب في المكسرات ، يستغرق وقتًا طويلاً. وانا ذاهب ، في محاولة لفهم كيف أن الرجال لديهم خادم ، وماذا يفعلون خلال كل إجابة. إذا كان هذا جافا سكريبت أو PHP ، فمن المحتمل أن أكون قادرًا على اكتشافه جيدًا وإصلاح كل شيء ، إذا كانت بعض اللغات الأخرى التي لم أعمل معها قد تحتاج إلى مساعدتهم.
ديمتري: هل يمكنك تسمية أي من أفضل 5 مشكلات أداء شائعة تواجهها في الممارسة؟
إيفان: سأتبع الطريقة التي أتذكرها. واحدة من المشاكل الشائعة التي لا تحدث في تطبيقات الويب المعقدة ، ولكن في المواقع البسيطة هي عندما يضع المطور أو العميل الكثير من البرامج النصية داخل علامة الرأس بدون سمات المزامنة أو التأجيل ، وهذه مشكلة سيئة لأن المستعرض لا يمكن أن يبدأ عرض الصفحة حتى لن يتم تحميل وتنفيذ هذه البرامج النصية.
وإذا كان هناك خادم بطيء أو برنامج نصي كبير يستغرق تنفيذه وقتًا طويلاً ، فلن يرى الشخص الذي يستخدم الموقع الصفحة حتى نهاية التنفيذ.
مشكلة شائعة أخرى هي نصوص الطرف الثالث. أنا أعمل حاليًا مع عميل أساعده في تحسين درجة المنارة . في البداية ، كانت درجة المنارة لديهم حوالي 35-40. لقد جئت ، وفعلت كل أنواع الأشياء المختلفة ، وحذفت جافا سكريبت غير الضرورية ، والموارد التي تمنع عرض الإعلانات ، وتم تحسينها بطريقة أو بأخرى ... بعد كل ما فعلت ، ارتفعت النتيجة فقط في مكان ما إلى 55. واتضح أنه إذا ذهبت وتعلق على مكون React المحسّن الفردي الذي يحمّل جميع التحليلات ، فإن نتيجة المنارة تقفز في مكان ما إلى 88-90 نقطة. يحدث هذا بسبب وجود العديد من JSs التي تزيل المقاييس.
في بعض تطبيقات الويب المعقدة ، يتمثل الموضوع المتكرر في قيام المطورين بتثبيت نوع من المكتبات الكبيرة وحزمها في الحزمة تمامًا ، على الرغم من عدم استخدامها بالكامل. غالبًا ما يكون هذا هو Moment.js ، حيث توجد ملفات تعريب ضخمة ، و 165 كيلوبايت من ملفات الترجمة المصغّرة التي لا يحتاجها أي شخص ، أو lodash ، والتي يوجد بها الكثير من الطرق ، وكلها تستخدم فقط 10-20.
مع أداء العرض ، كانت هناك مشكلة متكررة عندما علق المطورون نوعًا من معالج الأحداث ، على سبيل المثال ، في تمرير الحدث ، استغرق الأمر من 5 إلى 10 دقائق ، وفي كل مرة حاولت فيها التمرير خلال شيء ما ، كانت الصفحة بأكملها متخلفة. الآن أصبح هذا أقل ، لأنه في نفس Chrome [أضاف مستمعو الأحداث السلبية] ( https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners ).
حول كيفية قياس الأداء
ديمتري: في سياق الحالات ، ظهر سؤال حول المنارة. في رأيي ، كان الثلاثة في BeerJS Summit ، وكان هناك تقرير رائع - (المائة) من أليكسي كالمكوف . لا يوجد مدخل ، لكني رأيت مقالًا مشابهًا عن حبري ، وهذه الأمور منارة صغيرة. إذا كنت تأخذها تمامًا كأداة لتقييم عمل مهندس الأداء ، يمكنك القيام ببعض الحيل هناك.
هل لديك أي أدوات ، ربما حتى مكتوبة ذاتيا ، والتي يمكنك من خلالها تقييم بوضوح ما إذا كنت قد نجحت أم لا. على سبيل المثال ، تقوم بالتوقيع على عقد ، ويتم إخبارك أنك بحاجة إلى تقديم أداء x2. ما مجموعة أدوات سوف تستخدمها لهذا؟
إيفان: حسنًا ، أولاً ، إذا أبرمنا عقدًا واتفقنا على x2 ، فسنوافق على نوع من الأداة. ولكن بشكل عام ، إلى جانب المنارة ، أحب WebPageTest حقًا. هذه أداة متقدمة جدًا لأداء الويب تتيح لك اختبار التطبيق الخاص بك من موقع تعسفي حقيقي ، على سبيل المثال ، البرازيل أو أستراليا ، على جهاز حقيقي ، على سبيل المثال ، ضعيف جدًا ، مثل Moto G.
هذا أكثر برودة من Lighthouse ، لأنه يحاكي كل هذا ، وفقط بعد الاختبارات على جهاز حقيقي ، هل تعلم أن الموقع يتم عرضه لمدة 15 ثانية. الفائدة الثانية - توفر مجموعة من المقاييس التفصيلية الفائقة لجميع أنواع المخططات ، مثل التحميل. أنا استخدامها بانتظام للنظر في بعض الأشياء.
ديمتري: هل كتبت أيًا من أدواتك ، على سبيل المثال ، أعلى بروتوكول Chrome DevTools ؟ ماذا تفتقر إلى الأدوات؟
إيفان: كتبت صكتي فوق المنارة. للعمل مع أحد العملاء ، كنت بحاجة إلى إعداد يتيح لي قياس أداء صفحة واحدة باستخدام المنارة في بيئة مستقرة إلى حد ما ، والنظر في درجة المنارة ونسخها إلى الجدول. هناك مشكلة معه: المنارة في PageSpeed Insights ليست مستقرة جدًا. إذا قمت بقياس نفس الصفحة ثلاث مرات ، فيمكنك الحصول على ثلاثة قياسات مختلفة. بالإضافة إلى ذلك ، كنت بحاجة إلى قياس ليس الصفحات التي كانت جاهزة ونشرها على الشبكة ، ولكن على الصفحات المحلية. والخيار الوحيد هو تشغيل المنارة محليًا ، مما يؤثر أيضًا بشكل كبير على درجة المنارة ، لأن النتيجة تبدأ في الاعتماد على ما يعمل على الكمبيوتر المحمول. على سبيل المثال ، أطلقت Docker ، انخفضت النتيجة 2 مرات.
في هذه الحالة كنت بحاجة لقياس المنارة بشكل متوقع. كتبت نصًا قام بتشغيل Lighthouse ثلاث مرات ، درجة ، وحصلت على القيمة المتوسطة للثلاث مرات ، وفعلت ذلك لعدة صفحات مع العديد من الإعدادات. لقد استأجرت خادم DigitalOcean لهذا ، وقمت بتشغيل كل شيء هناك لجعله معزولًا قدر الإمكان عن العوامل الخارجية.
Artyom: لقد ذكرت حالة مثيرة للاهتمام حول مقاييس Lighthouse المختلفة. كان هناك مقال حديث ، مقدمة عن 99 في المئة للمبرمجين ، توصلوا فيها للتو إلى أن أدوات القياس الحديثة ، ومن حيث المبدأ ، القياس الجزئي وحده لا يثبت أي شيء.
باستخدام الأدوات الحديثة ، قد يتضح أنني وضعت معيارًا ، كتبته ، وكتبت ديما ، وسوف يقولون جميعًا أشياء مختلفة تمامًا. والآن في عالم لا يتمتع بمعرفة عميقة أكثر أو أقل في النظرية والإحصاء ، لا يبدو القياس مرجعيًا للغاية. لقد ذكرت المنارة ، ولكن هل هناك أي دليل تلقيته في المؤشر ، بعض التأكيد الإضافي؟
ديمتري: ربما تخلط المنارة مع شيء ما؟ لقد ذكرت WebPageTest. نأخذها ، وربما حتى الملاحظات من Chrome DevTools ، ونمزجها بطريقة أو بأخرى؟
إيفان: في الواقع ، من الناحية المثالية ، إذا كان هناك أي شيء في مشروع يسمح لك بتتبع RUM (مقاييس المستخدم الحقيقي) - إلى أي مدى يتم تحميل الموقع لبعض المستخدمين ، وإذا كان بإمكاننا طرحه على مستخدمين حقيقيين ومعرفة كيفية لقد نجحت لهم - إنها الحالة المثالية.
ولكن بشكل عام ، نعم ، إذا استخدمت نوعًا من الأدوات ، فأنا أقوم بالفعل بإجراء أكثر من اختبار واحد للحصول على القيمة المتوسطة ، ولكن بشكل عام ، تثير المقالة المشكلة الحقيقية المتمثلة في وجود نوع ما من 99 في المئة من المستخدمين الذين لديهم كل شيء للغاية إنه أمر سيئ ولا نعرف ما إذا كنا نستخدم المنارة فقط ، لكن هذا لا يعني أن المنارة عديمة الفائدة ، فهي مستمرة في العمل وتظهر متوسط درجة الحرارة في المستشفى. إذا قمنا بشكل عام بتحسين الأداء ، فستظهر المنارة ذلك.
ديمتري: لقد لمست مقاييس المستخدم الحقيقية. لقد عملت للتو في Odnoklassniki وواجهنا مشاكل في كيفية تتبع ذلك ، لأنه ليس من الواضح كيفية القيام بذلك ، والكميات كبيرة. لقد كتبنا خاصتنا وجمعنا من المستخدمين ، وكان مجرد نوع من الفوضى. وإذا كان لا يزال نوعًا من مشروع متوسط ، فما الذي يمكن قياسه على جانب المستخدم؟ مجرد نافذة. الأداء أو أي شيء آخر الموصى بها؟ أو استخدام بعض التكتيكات الصعبة ، والقصف على حسابات المستخدمين الحقيقية؟
إيفان: أولاً وقبل كل شيء ، ربما توجد مكتبات أو خدمات جاهزة تتيح لك تكوين RUM. على سبيل المثال ، أضف سطرًا واحدًا إلى الصفحة وسيبدأ في التتبع. ثانياً ، في المستعرضات الحديثة ، ظهر شيء مثل PerformanceObserver - هذا هو واجهة برمجة التطبيقات التي تقيس جميع أنواع الأشياء في المتصفحات وتتيح لك معرفة المقاييس التي يحتفظ بها المستعرض عادةً في الداخل ، بما في ذلك الطلاء الأول ذي المحتوى الأول والطلاء الأول ذي المغزى وكل ذلك. ولاكتشاف هذا المقياس ، يكفي عدد قليل من أسطر التعليمات البرمجية ، لا تحتاج إلى كتابة شيء معقد للغاية. لقد اشتركت في الأحداث ، واستلمتها وخدمتها.
ديمتري: وما هو أهم شيء يجب الانتباه إليه أولاً؟ الرسام الأول ، وقت التفاعل ، وقت البايت الأول ، شيء آخر؟
إيفان: لدي عن ذلك [هناك تقرير] ( https://www.youtube.com/watch؟v=-H1l9XBXH6Q ) وأخبرك أن أهم الأشياء التي يجب النظر إليها هي أول وقت ووقت مفيد للتفاعل. وهي مهمة بقدر ما تظهر بالضبط ما جاء المستخدم لأول مرة. لقد أتى إما لقراءة أو رؤية شيء ما ، فهذا هو أول طلاء ذي معنى ، أو للعمل مع التطبيق ، ثم حان الوقت للتفاعل. إذا كنت تقوم بعمل نوع من الصفحات المقصودة أو موقع إخباري ، فقم بتحسين الطلاء الأول ذي المغزى ، وإذا كان لديك تطبيق معقد ، فعليك تحسين الرسم والوقت الأولين للتفاعل.
أرتيوم: ذكرنا الحالات الأكثر شعبية في ممارستك. وأي الحالات هي أندر أو الأكثر إثارة للاهتمام ، والتي كان عليك حفر في الشجاعة في مكان ما؟
إيفان: أعتقد أن لدي حالة مثيرة للاهتمام إلى حد ما الآن. أنا أعمل حاليا مع Framer . هؤلاء الرجال لديهم أداة تصميم عصري ، التناظرية من Figma و Sketch . وأنا أساعدهم على تحسين أداء وقت التشغيل - هذه منطقة رائعة جدًا بالنسبة لي. يستخدمون المتصفح فائقة محددة. لم تكن المتصفحات مصممة أصلاً لكتابة مثل هذه التطبيقات المعقدة ، لذلك أعاد كل من Figma و Framer تنفيذ العديد من قطع المستعرضات بنفسهما. وهناك الكثير من تطوراتهم ، والتي ليست في مشاريع أخرى ، والتي هي مثيرة للاهتمام للغاية. أنا أستمتع بالعمل مع كل هذا. هذا شيء مثير للاهتمام حقًا ، شيء جديد ورائع جدًا.
ديمتري: تحدثنا عن الفروق الدقيقة في المتصفح ، وقبل الانتقال إلى الأطر ، أود أن أتعلم عن تحسين الأداء باستخدام البنية وبعض هياكل البيانات. هل كان عليك تغيير شيء ما دقيق في التطبيق ، على سبيل المثال ، إضافة قائمة بادئات للبحث أو شيء آخر غير معتاد بالنسبة للواجهة الأمامية؟ هل يحدث هذا؟
إيفان: لم أكن أمارس عمليًا على مستوى بنية البيانات أو تعقيد الخوارزميات ، لأنه يجب القيام بالكثير من الأشياء حتى يبطئ التطبيق في هذا ، وليس في شيء آخر. وهكذا ، فيما يتعلق بالقطع الكبيرة ، أوصي الجميع بشدة عند إنشاء مشروع جديد أو إذا كان المشروع قد بدأ لتوه وما زال صغيرًا جدًا ، قم بذلك في إطار مثل Next.js أو Gatsby .
كل من هذا وآخر هو إطار عمل React الذي تم إنشاؤه بحيث يمكنك ببساطة كتابة التطبيق باستخدام زوج من النهج في هذا الإطار ، وأصبح سريعًا تلقائيًا. هذه أطر عمل شائعة للغاية ، وهي تؤدي وظيفتها على أكمل وجه ، وأنا شخصياً أستخدمها في مشاريع الإنتاج الخاصة بي وأوصي بها الجميع بشدة.
Artem: هنا فقط حدثنا مؤخرًا حول كيفية تفاعل V8 مع رد الفعل بسبب جهاز الرقم داخل V8. هل شعرت بهذه المشكلة أو كانت هناك أي عمليات بحث لماذا يبطئ التطبيق؟
إيفان: لم أشعر ولم أقرأ هذا المقال حول إزالة الأضرار. هل كان هناك أي عملية محددة أو تباطأ رد الفعل ككل؟
Artyom: بشكل عام ، لأنه في React ، يوجد طابع زمني داخل FiberNode ، وقد تم تعيينه مبدئيًا على 0 ومنع الامتداد (preventExtension) ، ولهذا السبب ، تم تخصيص شكل واحد مع عدد صحيح صغير لتحسين العمليات على الأرقام. وعندما امتلأ الطابع الزمني بالقيمة الحقيقية ، التي قفزت إلى ما بعد 128 ، اتضح أنه كان من الضروري تغيير الهيكل من عدد صحيح صغير إلى عدد كومة الذاكرة المؤقتة القابلة للتغيير ، ومنذ أن تم استدعاء المنع ، تم بناء أشكال جديدة تمامًا لكل عقدة ألياف. وهناك عشرات ومئات الآلاف.
إيفان: لم ألاحظ ذلك ، وكنت بالكاد لاحظت ذلك ، لأنه عندما أقوم بالتصحيح ، لم يكن لدي واحدة في ذاكرتي مفادها أن هذه العملية يجب أن تستغرق 10 مللي ثانية فقط في React ، ويستغرق 20. أنا فقط تصحيح ، أنا أنظر تتبع الأداء ، أختار بعض عنق الزجاجة حيث يتباطأ شيء ما. إذا تم توزيع الأداء ، فهناك بعض التباطؤ في الإصدار الثامن ويتم توزيعها بالتساوي في جميع أنحاء التطبيق ، ثم إذا لم أذهب إلى الأخطاء العميقة للغاية ، فلن ألاحظ ذلك.
إذا حدث هذا في عملية V8 واحدة محسنة واستغرقت وقتًا طويلاً ، فسوف ألاحظ الدخول في تصحيح عميق.
أرتيوم: هل كان هناك حقًا أي مشكلة في React نفسها ، أو في أطر أخرى حيث كان عليك إنشاء مشكلة ، للوصول إلى أسفل شيء ما؟
إيفان: في رأيي ، أبلغت عن بعض الأخطاء ، لكنني لا أتذكر التفاصيل ... لا أعتقد ما إذا كان هذا سيكون ذا صلة بهذه المشكلة ، لكنني واجهت مؤخرًا حالة مثيرة للاهتمام عندما تحولت متغيرات css إلى أبطأ من تغييرات التطبيق بواسطة React prop. بالنسبة لي ، إنه أمر غريب ، لأننا اعتدنا أن نقول أن المغلق فائق السرعة ، وفجأة يعمل بشكل أبطأ من React.
أحاول إضافة مقال حول هذا الموضوع ، وبشكل عام ، يعمل بشكل جيد لأنه لا يوجد تحسين في المتصفحات - إذا قمت بتغيير متغير css على عنصر به الكثير من الأطفال ، فإن المتصفح ، على الأقل Chrome ، لا يتذكر أي منها يستخدم الأطفال هذا المتغير ، ويقوم بحساب جميع الأطفال والأساليب الخاصة بهم. إذا كان هناك العديد من الأنماط والعقد ، فهذا كثير من الوقت ، وإذا استبدلت بعض المتغيرات بـ React ، فربما لا يحدث حساب الأنماط وسيحدث كل ذلك بسرعة.
أنا متأكد من أن 80 ٪ من هذا هو الحال وفقا لما فهمته من رمز V8 ، ولكن يمكن أن أكون مخطئا. لكن هذا شيء يمكن تسجيله وإصلاحه في المتصفحات ، ولكن هذا ليس جرثومة صغيرة ، ربما هناك الكثير من العمل. لم أبلغ عن ذلك حتى الآن ولا أعرف كم من الوقت سينفق على إصلاحه إذا أصلحته.
أرتيوم: هل اضطررت إلى مشاهدة الرمز البريدي الناتج؟ مع نفس وجهات النظر deoptimization ، يمكنك مشاهدة V8 bytecode ، وهل هناك أي عمليات إضافية يتم إدراجها؟
إيفان: لا ، ربما لم أتطرق مطلقًا إلى الرمز الفرعي ، لكنني تعلمت جيدًا قراءة جافا سكريبت المصغّرة. (يضحك)
ديمتري: وللإجابة السابقة - هل تتواصل بطريقة ما مع مطوري المتصفح لتوضيح مثل هذه الأشياء؟ وإذا كان الأمر كذلك ، كيف يستجيبون؟ وهل يجيبون؟
: GDE (Google Developer Expert), Google- Slack-, Google-, Chrome. - , . , . . .
: ! .
: , Google, GDE ().
: :)
: , , , .
: , Moment.js. , , Day.js -, bundlephobia . , , , Angular, .
, , , , , , , , . ? , issue , ? , ?
: … . - , , . - , , userspace- .
, .
, , , - . webpack - . React, , API Preact , Inferno .
: ? , , , , Vue.js, , , . -?
: , . , , Angular, Angular. Angular, , . … , , . - Ext JS .
, . , . , .
WebAssembly
: , - JS, , high computation . WebAssembly, computational ?
: , WebAssembly - , .
: , , WASM. Figma, Blazor, C# WebAssembly, - . ?
: , - WebAssembly . , c WebAssembly , . .
: ?
: , . -, JavaScript - , WebAssembly , , 10 .
, , JavaScript, C++ Rust — WebAssembly . , , .
: . scroll, , . - - ? , Chrome iOS - ChromeOS - , - ? , , «.»?
: , performance IE11. , - , , IE11. , . IE11.
. «.» Chrome iOS , «.» Chromium, Chrome iOS — WebKit, iOS
: , … ()
HTTP/3
: , , . . HTTP/2, HTTP/3, QUIC . , : HTTP/2 , ?
, HTTP/3 ?
: HTTP/3 ?
: , Chrome , cURL, .
: , . , , , , HTTP/3 . Google , HTTP/3, , HTTP/3.
, , HTTP/2 , , , 2-3 , , HTTP/2 . HTTP/3 . , - , .
: , , ? , , - ?
: -, Twitter, (, []( https://twitter.com/slightlylate ), []( https://twitter.com/zachleat ), []( https://twitter.com/csswizardry ), []( https://twitter.com/igrigorik ), []( https://twitter.com/philwalton )). - Google GDE , - - performance-. .
, Calibre ( performance-) Perf.email , performance-.
: GDE! , - , . , , , ? , .
: , Service License Agreement , 95% . , performance . Juliarderity , , , . , .
: « », , . ? React, Angular .. — framework-specific , , ? TC39?
: (). , — , — .
: ?
: - . proposal, , . proposal, - . — .
: , RSS? - .
: RSS.
: , Habr, « Chrome», RSS . RSS , .
: , -, , , DevTool-, , - , , , .
: , ?
: Twitter, , -, Twitter, 20-30 . , « @vkozula ?».
, « , ». - . . , . , . Facebook- , - 50 , , .
: jsunderhood - ?
: underhood. - , . underhood, — jsunderhood 2017 , , , , , , .
: , , HolyJS jsunderhood, .. . ? , ?
: , , . , , , … , , . 10—20 .
: , ?
: , , , , , , , , . , , , Twitter , , . - Twitter Telegram , , .
: , . , . , , ?
إيفان: لم يكن لدي الكثير من ورش العمل بكميات مطلقة ، ولكن أكثر ما فخور به هو ورشة عمل webpack الخاصة بي ، والتي قمت بتقديمها كمقدمة لحزمة webpack في نهاية عام 2017. لسوء الحظ ، لقد عفا عليه الزمن بالفعل ، لكنه أصبح رائعًا ، لأنني خططت لإجراء بث على الإنترنت ، لكنني في ذلك اليوم بدأت أتخلى عن الإنترنت بشدة.
بدأت في القيادة ، بعد 10 دقائق سقطت وأعدت الاتصال وسقطت مرة أخرى واضطررت إلى إلغاء كل شيء على وجه الاستعجال ، واعتذر وأقول إنني سأقوم بتسجيل جميع المواد على الفيديو ووضعها على هذا النحو. لقد فعلت كل شيء ، ووضعت ، وأظهرت سلسلة من مقاطع الفيديو مثل على egghead.io ، وباستثناء المشكلة التي كان هناك صوت هادئ للغاية ، لأنه لم يكن هناك ميكروفون عادي. سمعت الكثير من المراجعات ، والتي كانت جيدة للغاية وأنها ساعدت الناس حقا.
ديمتري: ما رأيك ، لماذا يستحق الذهاب إلى ورش العمل؟ على سبيل المثال ، إذا ذهبت إلى ورشة عمل على متصفح ، فغالباً ما أسمع أن الناس يريدون أن يروا كيف يتم التخلص من V8 أو أي شيء آخر. وفي الغرب ، على العكس من ذلك ، إذا تذكرت مقابلة ميشيل ويستستر الهادئة ، فقال "سوف أتعلم منها. إذا لم أكن أعرف عامل Docker على الإطلاق ، فأذهب إلى هناك وأحصل على المعلومات بسرعة. " كيف ترى ورش العمل وفي أي الحالات تنصح بحضور ورش العمل الخاصة بك؟ تعلم وتعميق المعرفة ، انظر الشجاعة؟
إيفان: أود أن أقول هذا - إذا كان الوصف يبدو مثيراً للاهتمام بالنسبة لك ، إذن تعال. عندما أقوم بإجراء ورش عمل ، أحاول دائمًا تقديم نوع من الأساس بحيث لا يضيع هؤلاء الأشخاص الذين يأتون ويعملون معه لأول مرة. أستطيع أن أتخيل أن بعض الرجال الذين يعملون في مجال متقدمين للغاية جاءوا للاستماع ، وربما كانت البداية مملة. قد لا تبقى حتى النهاية حيث يمكن رفع موضوع متقدم. من ناحية أخرى ، لا أستطيع أن أعد بأنني سأظهر بعض الشجاعة ، لأن كل الناس لديهم فهم مختلف لـ "الشجاعة". سأحضر وأظهر بعض الحالات النادرة للغاية التي واجهتها في تجربتي ، ويمكن لشخص آخر أن يأتي ويأمل أن أبدأ ظهور الإصدار الثامن من V8 أو تجميع Chromium ، لكنني لن أفعل ذلك.
ديمتري: وما الذي تتوقعه أنت ، من حيث المبدأ ، عادة من ورشة العمل؟
إيفان: أتذكر أنني ذهبت إلى بضع ورش عمل فقط في حياتي. في كلتا الحالتين ، كان هذا موضوعًا جديدًا بالنسبة لي ، ما زلت لا أستطيع التعرف عليه بنفسي. وكانت ورش العمل بمثابة نوع من التقديم بالنسبة لي ، وكانت مفيدة للغاية.
في ورشة العمل الخاصة بي ، لن أقدم مقدمة عن الأداء وفي React ، آمل أن يسمع الأشخاص الذين يأتون شيئًا ما حول هذا الموضوع ، لكنهم يحاولون تغطية بعض الموضوعات الأساسية ويظهرون بعض الأخطاء المتقدمة مثلما أنا أعرفه وصادفته.
ديمتري: ماذا تتوقع من HolyJS ككل؟ ربما لاحظت بعض التقارير أو المتحدثين الذين أود التحدث معهم؟
إيفان: لا أخطط لأي شيء بنفسي قبل أكثر من شهر ، لذلك لم أخطط لأي شيء حتى الآن. هناك استعداد ، والباقي سيحدث. (يضحك)
ديمتري: هذا كل شيء. شكرا جزيلا على المقابلة نحن في انتظار الجميع في ورشة العمل الخاصة بك .