وقت بناء المشروع الأمثل

عندما أعمل (في موقع بدء التشغيل Spot.IM ، الذي يتراوح حجمه بين الصغير والمتوسط) ، يتم استخدام Webpack لإنشاء مشاريع متنوعة. بعد 4 سنوات من العمل على منتجنا الرئيسي ، عندما ساهم عدد كبير من الأشخاص في الكود الخاص به بحيث لا يمكن حسابه ، وصل وقت التجميع الأولي إلى 90 ثانية ، ووقت إعادة التجميع - 14.

هذا هو حوالي 14 ثانية للانتظار بعد كل نقرة على زر "حفظ".

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



في هذه المقالة ، أود أن أتحدث عن بعض التغييرات البسيطة ، مما يجعل المشروع يمكنه تحسين وقت التجميع بشكل كبير. يرجى ملاحظة أنه إذا كنت تستخدم CreateReactApp (أو بعض منشئ التطبيق المألوف الآخر) ، فقد لا تكون هذه المقالة مفيدة بشكل خاص لك. ولكن إذا كنت لا تستخدم أي شيء من هذا القبيل ، فإن ما نتحدث عنه هنا يمكن أن يكون مفيدًا جدًا لك.

قياس الوقت المستغرق لبناء المشروع

قبل القيام بأي نوع من التحسين ، دعونا نضع مقياسًا للمؤشرات التي يمكننا من خلالها تقييم نتائج العمل. من أجل القيام بذلك ، استخدم المكوّن الإضافي speed-measure-webpack-plugin (SMP):

const webpackConfig = require('./webpack.config') const SpeedMeasurePlugin = require('speed-measure-webpack-plugin') const smp = new SpeedMeasurePlugin({   disable: !process.env.MEASURE, }) module.exports = smp.wrap(webpackConfig) 

نضع ملف تكوين Webpack في غلاف SMP (بدء تشغيل آلية أخذ قياسات الأداء باستخدام متغير البيئة) ، وبعد ذلك نقوم بتمرير كائن تكوين Webpack. بعد ذلك ، لدينا تحت تصرفنا تقرير لطيف المظهر يسمح لنا لمعرفة مقدار الوقت الذي يقضيه على كل محمل الإقلاع أثناء التجميع. باستخدام SMP ، نحصل على فوائد مضاعفة. أولاً ، بعد إجراء بعض التحسينات ، يمكننا على الفور معرفة كيفية تأثيرها على وقت بناء المشروع. ثانياً ، لدينا على الفور تقرير كامل تحت تصرفنا عن الوقت الذي يستغرقه كل محمل للإقلاع (أو بشكل أدق "سلسلة محمل الإقلاع").


تقرير تم إنشاؤه باستخدام البرنامج المساعد speed-measure-webpack-plugin

تحسين وقت البناء الأولي للمشروع

بعد أن بدأنا في استخدام SMP ، كانت لدينا معلومات حول كيفية تغير وقت إنشاء المشروع عند إجراء تحسينات على عملية الإنشاء. أول شيء بدأنا في تحسينه هو وقت الإنشاء الأولي (أي الوقت الذي استغرقه Webpack لإنشاء الحزمة بعد التهيئة). لتسريع عملية الإنشاء الأولي ، قررنا استخدام أداة تحميل cache-loader .

Cache-loader هو محمل يقوم بتخزين وحفظ نتائج عمل اللوادر التي تتبعها في القرص (أو قاعدة البيانات). هذا يعني أنه في المرة التالية التي تبدأ فيها تشغيل Webpack ، يمكنك رؤية تحسن كبير في سرعة البناء ، أو على الأقل يمكنك أن تأمل ذلك.

هنا مثال:

 {  rules: [    {      test: /\.jsx?$/,      use: [        'cache-loader',        'babel-loader',      ],    },    {      test: /\.scss$/,      use: [        'style-loader',        'cache-loader',        'css-loader',        'postcss-loader',        'sass-loader',      ],    },  ] } 

سمحت لنا إضافة cache-loader قبل css-loader (for CSS) وقبل babel-loader (for JS) بإزالة حوالي 75 ثانية من الوقت المستغرق في الإنشاء الأولي للمشروع.

الآن دعونا نعمل في وقت إعادة التجميع. سنحاول تحسين هذا الوقت عن طريق تغيير خاصية devtool .

بطاقات كود Webpack

في إعدادات Webpack ، يمكنك العثور على خاصية devtool ، والتي ، وفقًا للوثائق ، "تتيح لك اختيار نمط إنشاء بطاقات الرموز المستخدمة لتحسين إمكانيات تصحيح الأخطاء. يمكن أن تؤثر نقاط الضبط بشكل كبير على سرعة التجميع وإعادة التجميع. "

بمعنى آخر ، يؤثر تعديل خاصية devtool على بطاقة الكود التي ستكون متاحة للمطور بعد بناء المشروع. وهذا ، بدوره ، يعتمد على مقدار الوقت الذي يستغرقه إنشاء بطاقة الرموز هذه.

تعتبر التجارب مع هذه الخاصية شيئًا من الحقل يمكن أن يغير حياة المبرمج بشكل دائم. هذا له تأثير كبير على سرعة بناء المشروع. أي ، قمنا بتغيير قيمة devtool من source-map (ربما يكون هذا هو الوضع الأبطأ) إلى eval-source-map وتمكنا من تقليل وقت إعادة تجميع المشروع من 14 إلى 3.5 ثانية:

 {  devtool: process.env.NODE_ENV === 'development'    ? 'eval-source-map'    : 'source-map' } 

الخاصية devtool قادرة على قبول المتغيرات القيمة 12. CreateReactApp ، على سبيل المثال ، يستخدم خريطة رخيصة المصدر وحدة . لذلك ، إذا كنت ستقوم بتكوين هذه الخاصية ، فجرّب والعثور على القيمة الأفضل لك.

تجدر الإشارة إلى أنه عند استخدام طرق سريعة لإنشاء بطاقات الرموز ، تتدهور جودة البطاقات الناتجة. يمكن الشعور بهذه التدهورات عن طريق بدء تصحيح الأخطاء. لحسن الحظ ، فإن المتصفحات الحديثة مواكبة TC39. نتيجة لذلك (على الأقل أثناء التطوير) ، ليست هناك حاجة حقيقية لنقل كميات كبيرة من الشفرات. إذا قمت بتكوين Babel بحيث تنقل هذه الأداة جافا سكريبت إلى مستوى يفهمه أحدث إصدار من المتصفح (كما هو الحال في CRA ) ، فمن المفترض أن يكون كل شيء على ما يرام مع تصحيح الكود ، لأن خرائط الأكواد لن تختلف كثيرًا عن الكود نفسه.

إليك babel.config.js يجب أن يبدو عليه babel.config.js إذا قررت نقل الرمز إلى حالة واضحة لأحدث الإصدارات من المتصفحات المختلفة:

 module.exports = {  presets: [    [      '@babel/preset-env',      {        targets: [          'last 1 chrome version',          'last 1 safari version',          'last 1 firefox version',        ].join(', '),      },    ],  ],  // ... } 

هذا كل شيء. تم تخفيض ثلاث خطوات بسيطة ، ووقت بناء مشروعنا إلى حد كبير.

أود أن أشير إلى أن الشخص الذي يبدأ في حل مشكلة مماثلة قد يكون لديه رغبة في إلقاء نظرة أولى على وثائق Webpack وقراءتها بشكل صحيح. ومع ذلك ، ليس هذا هو المصدر الوحيد للمعرفة.

لقد وجدت طريقة أخرى لإيجاد معلومات قيمة حول بناء المشاريع. وقد أثبت هذا النهج نفسه في الممارسة العملية. وهو يتألف من تحليل ملفات webpack.config القائمة مفتوحة المصدر. على وجه الخصوص ، ملف مشروع CreateReactApp . عند قراءة هذا الملف بدقة ، يمكنك معرفة الكثير من الأشياء المفيدة.

النتائج

قد يلاحظ القارئ اليقظ أنه في البداية كان الأمر يتعلق بتقليل وقت إعادة التجميع إلى ثانية واحدة. وكانت أفضل قيمة لهذا المؤشر المذكور في النص هي 3.5 ثانية. من الواضح ، تم حذف شيء ما عند وصف تقدم التحسين لعملية التجميع. هكذا هو. كان من الممكن تحسين وقت إعادة تجميع المشروع إلى ثانية واحدة عن طريق الفوز بـ2.5 ثانية أخرى بفضل التحسينات الدقيقة ، والتي تعتمد إلى حد كبير على ميزات مشروع معين ، وهي Spot.IM. لذلك ، لم يتم تقديم وصف لهذه التحسينات هنا.

أعزائي القراء! هل تحسين وقت بناء مشاريعك؟