نهج المترجم لأداء الويب: وجهة نظر Rich Harris

لماذا يشعر بعض تطبيقات الويب بالبطء حتى على أجهزة جيدة

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

الأعراض معروفة: تحميل أول بطيء (واجهة فارغة أو نصف مبنية)، تفاعلات متقطعة (نقرات تظهر بعد هزة، تمرير مهتز)، ودورات انتظار طويلة بعد إجراءات التي يجب أن تكون فورية، مثل حفظ نموذج أو تصفية قائمة.

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

مشاكل الأداء تظهر أيضاً مع الزمن. في البداية، التطبيق صغير: شاشات قليلة، بيانات خفيفة، واجهة بسيطة. ثم ينمو المنتج. يضيف التسويق أدوات تتبع، التصميم يضيف مكونات أغنى، الفرق تضيف حالة وميزات واعتمادات وتخصيص. كل تغيير يبدو تافهًا لوحده، لكن العمل الكلي يتراكم.

هذا سبب بدء الفرق بالاهتمام بأفكار الأداء التي تركز على المترجم/وقت البناء. الهدف عادةً ليس الحصول على درجات مثالية. الهدف هو الاستمرار في الشحن دون أن يصبح التطبيق أبطأ كل شهر.

وقت التشغيل الثقيل مقابل وقت البناء: الفكرة الأساسية

معظم أطر الواجهة الأمامية تساعدك في أمرين: بناء تطبيق، ومزامنة الواجهة مع البيانات. الاختلاف الأساسي هو متى يحدث الجزء الثاني.

مع إطار ثقيل على وقت التشغيل، يحدث المزيد من العمل في المتصفح بعد تحميل الصفحة. ترسل محركًا عامًا يمكنه التعامل مع حالات كثيرة: تتبع التغييرات، تقرير ما يجب تحديثه، وتطبيق تلك التحديثات. تلك المرونة مفيدة للتطوير، لكنها غالبًا تعني المزيد من JavaScript يجب تنزيله وتحليله وتشغيله قبل أن تبدو الواجهة جاهزة.

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

نموذج ذهني مفيد:

• الوقت-التشغيلي الثقيل يشبه إرسال تعليمات وصندوق أدوات، ثم التجميع في بيت العميل.
• وقت-البناء يشبه إرسال أجزاء مقطعة وملصقة بالفعل، بحيث يكون التجميع أسرع.

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

Rich Harris ولماذا "الإطار هو مترجم" مهم

Rich Harris واحد من أوضح الأصوات الداعمة لفكر الواجهة الأمامية القائم على المترجم. حجته بسيطة: قم بالمزيد مسبقًا حتى ينزل للمستخدمين كود أقل ويقوم المتصفح بعمل أقل.

الدافع عملي. العديد من الأطر الثقيلة على وقت التشغيل ترسل محركًا عامًا: منطق المكونات، التفاعلية، التفريق، الجدولة، ومساعدات يجب أن تعمل لكل التطبيقات الممكنة. تلك المرونة تكلف وحدات بكايت واستخدام CPU. حتى عندما تكون واجهتك صغيرة، قد تدفع ثمن محرك كبير.

نهج المترجم يعكس النموذج. أثناء وقت البناء، ينظر المترجم إلى مكوناتك الفعلية ويولد شيفرة تحديث DOM محددة لما تحتاجه. إذا كان نص ملصق لا يتغير أبدًا، يصبح HTML عاديًا. إذا كان قيمة واحدة فقط هي المتغيرة، يصدر المترجم مسار التحديث لتلك القيمة فقط. بدلاً من إرسال آلة واجهة عامة، تُرسل مخرجات مخصّصة لمنتجك.

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

التنازلات ما تزال مهمة:

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

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

ما الذي يمكن أن تحسّنه تحسينات وقت البناء عمليًا

تحسينات وقت البناء تغيّر مكان حدوث العمل. تُتخذ المزيد من القرارات أثناء البناء، ويُترك للمتصفح عمل أقل.

نتيجة مرئية واحدة هي إرسال JavaScript أقل. الحزم الأصغر تقلل زمن الشبكة، وقت التحليل، والتأخير قبل أن تستجيب الصفحة للنقر أو اللمس. على هواتف متوسطة المواصفات، هذا مهم أكثر مما تتوقع الفرق كثيرًا.

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

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

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

كنتيجة جانبية، غالبًا ما يحسن التجميع نطاق CSS. يمكن للخطوات في البناء إعادة كتابة أسماء الأصناف، إزالة الأنماط غير المستخدمة، وتقليل تسرب الأنماط بين المكونات. هذا يقلل التكاليف المفاجئة مع نمو الواجهة.

تخيل لوحة بيانات بها فلاتر وجدول بيانات كبير. نهج المترجم يمكنه الحفاظ على تحميل أولي أخف، تحديث الخلايا التي تغيرت فقط بعد نقرة على فلتر، وتجنّب تحييد أجزاء من الصفحة التي لا تصبح تفاعلية.