تقسيم الحزمة (Bundle Splitting)
عند بناء تطبيق ويب حديث، تأخذ أدوات التجميع مثل Webpack أو Rollup شيفرة التطبيق ويجمعونها معًا في حزمة أو أكثر. عندما يزور المستخدم موقعًا، تُطلب الحزمة وتُحمَّل لعرض البيانات على شاشة المستخدم.
محركات JavaScript مثل V8 قادرة على تحليل البيانات التي طلبها المستخدم وترجمتها أثناء تحميلها. على الرغم من أن المتصفحات الحديثة تطورت لتحليل الشيفرة وترجمتها بأسرع طريقة ممكنة وأعلى أداء، إلا أن المطوّر ما زال مسؤولًا عن تحسين خطوتين في هذه العملية: زمن التحميل وزمن تنفيذ البيانات المطلوبة. نريد أن نحرص على إبقاء زمن التنفيذ أقصر ما ممكن لمنع حجب الخيط الرئيسي.
على الرغم من قدرة المتصفحات الحديثة على بث الحزمة أثناء وصولها، قد يمر وقت طويل قبل أن تُرسم أول بكسلات على جهاز المستخدم. كلما كانت الحزمة أكبر، طال الوقت قبل أن يصل المحرك إلى السطر الذي تم فيه استدعاء أول عملية رسم. وقبل ذلك الوقت، يضطر المستخدم إلى النظر إلى شاشة فارغة لفترة طويلة، وهو أمر قد يكون محبطًا للغاية!
نريد عرض البيانات على المستخدم في أقرب وقت ممكن. تؤدي الحزمة الأكبر إلى زيادة زمن التحميل والمعالجة والتنفيذ. سيكون رائعًا لو اخترنا تقليل حجم هذه الحزمة لتسريع الأمور.
بدلاً من طلب حزمة واحدة ضخمة تحتوي على شيفرة غير ضرورية، يمكننا تقسيم الحزمة إلى حزم أصغر متعددة!
بتقسيم الحزمة (bundle splitting)، يمكننا تقليل الوقت الذي يستغرقه تحميل الحزمة ومعالجتها وتنفيذها! وتقليل زمن التحميل والتنفيذ يتيح لنا تقليل الوقت الذي يمر قبل رسم أول محتوى على شاشة المستخدم، وهو First Contentful Paint، والوقت الذي يمر قبل عرض أكبر مكوّن على الشاشة، وهو Largest Contentful Paint.
على الرغم من أن رؤية البيانات على شاشتنا رائعة، لا نريد أن نرى المحتوى فحسب. ولتشغيل التطبيق بالكامل، نريد أن يكون المستخدم قادرًا على التفاعل معه أيضًا! لا تصبح واجهة المستخدم تفاعلية إلا بعد تحميل الحزمة وتنفيذها. ويطلق على الوقت الذي يمر قبل رسم كل المحتوى على الشاشة وجعله تفاعليًا اسم Time To Interactive.
الحزمة الأكبر لا تعني بالضرورة زمن تنفيذ أطول. قد يحدث أن حمّلنا قدرًا كبيرًا من الشيفرة التي لن يستخدمها المستخدم! ربما لا تُنفَّذ بعض أجزاء الحزمة إلا عند تفاعل معين من المستخدم، وقد يفعل المستخدم هذا التفاعل أو لا يفعله.
لا يزال على محرك التشغيل تحميل الشيفرة وتحليلها وترجمتها، حتى الشيفرة غير المستخدمة في العرض الأولي، قبل أن يرى المستخدم أي شيء على شاشته. ومع أن تكاليف التحليل والترجمة يمكن تجاهلها عمليًا بسبب الطريقة عالية الأداء التي يعالج بها المتصفح هاتين الخطوتين، فإن جلب حزمة أكبر من اللازم قد يضر بأداء تطبيقك. سيرى المستخدمون على الأجهزة منخفضة المواصفات أو الشبكات الأبطأ زيادة كبيرة في زمن التحميل قبل جلب الحزمة.
كان لا بد من تحميل الجزء الأول ومعالجته، رغم أن المحرك استخدم الجزء الأخير من الملف فقط من أجل ذلك. بدلاً من طلب أجزاء الشيفرة التي لا أولوية عالية لها في التنقل الحالي في البداية، يمكننا فصل هذه الشيفرة عن الشيفرة اللازمة لعرض الصفحة الأولية.
بتقسيم الحزمة الكبيرة إلى حزمتين أصغر، main.bundle.js وemoji-picker.bundle.js، نقلل زمن التحميل الأولي عبر جلب كمية أقل من البيانات.
في هذا المشروع، سنغطي بعض الطرق التي تتيح لنا تقسيم الحزمة إلى حزم أصغر متعددة، وتحميل الموارد بأكثر الطرق كفاءة وأداءً.