مهندسون من Cloudflare وMozilla وFacebook وBloomberg صيغة جديدة لتسريع تسليم ومعالجة كود JavaScript عند فتح المواقع في المتصفح. ينقل BinaryAST مرحلة التحليل إلى جانب الخادم ويوفر شجرة بناء جملة مجردة تم إنشاؤها بالفعل (). عند تلقي BinaryAST، يمكن للمتصفح المتابعة فورًا إلى مرحلة التجميع، وتجاوز تحليل كود مصدر JavaScript.
للاختبار التنفيذ المرجعي المقدم بموجب ترخيص MIT. يتم استخدام مكونات Node.js للتحليل، ويتم كتابة التعليمات البرمجية للتحسين وإنشاء AST بلغة Rust. دعم من جانب المتصفح
BinaryAST متاح بالفعل في ثعلب النار. يمكن استخدام برنامج التشفير في BinaryAST على مستوى أدوات الموقع النهائي ولتعبئة البرامج النصية للمواقع الخارجية على جانب الوكيل أو شبكة توصيل المحتوى. حاليًا، بدأت بالفعل عملية توحيد BinaryAST من قبل مجموعة العمل ، وبعد ذلك سيكون التنسيق قادرًا على التعايش مع طرق ضغط المحتوى الموجودة، مثل gzip وbrotli.
عند معالجة JavaScript، يتم قضاء قدر كبير من الوقت في مرحلة التحميل والتحليل للتعليمات البرمجية. بالنظر إلى أن حجم JavaScript الذي تم تنزيله على العديد من المواقع الشائعة يقترب من 10 ميغابايت (على سبيل المثال، لـ LinkedIn - 7.2 ميغابايت، Facebook - 7.1 ميغابايت، Gmail - 3.9 ميغابايت)، فإن المعالجة الأولية لـ JavaScript تقدم تأخيرًا كبيرًا. يتم أيضًا إبطاء مرحلة التحليل من جانب المتصفح بسبب عدم القدرة على إنشاء AST بشكل كامل أثناء تحميل التعليمات البرمجية (يجب على المتصفح انتظار اكتمال تحميل كتل التعليمات البرمجية، مثل نهاية الوظائف، للحصول على المعلومات المفقودة لتحليل العناصر الحالية).
إنهم يحاولون حل المشكلة جزئيًا عن طريق توزيع الكود في شكل مصغر ومضغوط، وكذلك عن طريق تخزين الكود الثانوي الذي تم إنشاؤه بواسطة المتصفح مؤقتًا. في المواقع الحديثة، يتم تحديث التعليمات البرمجية في كثير من الأحيان، وبالتالي فإن التخزين المؤقت يحل المشكلة جزئيا فقط. يمكن أن يكون WebAssembly حلاً، ولكنه يتطلب كتابة صريحة في التعليمات البرمجية وليس مناسبًا تمامًا لتسريع معالجة تعليمات JavaScript البرمجية الموجودة.
هناك خيار آخر يتمثل في تقديم أكواد بايت مجمعة جاهزة بدلاً من نصوص جافا سكريبت، لكن مطوري محركات المتصفح يعارضون ذلك نظرًا لصعوبة التحقق من أكواد بايت كود الطرف الثالث، ويمكن أن تؤدي معالجتها المباشرة إلى تقسيم الويب، وظهور مخاطر أمنية إضافية، وتطوير مطلوب تنسيق رمز بايت عالمي.
يتيح لك BinaryAST إمكانية التوافق مع نموذج تطوير التعليمات البرمجية والتسليم الحالي الخاص بك دون إنشاء كود ثانوي جديد أو تغيير لغة JavaScript. حجم البيانات في تنسيق BinaryAST يمكن مقارنته بكود JavaScript المصغر المضغوط، وتزداد سرعة المعالجة عن طريق التخلص من مرحلة تحليل النص المصدر بشكل ملحوظ. بالإضافة إلى ذلك، يسمح التنسيق بالتجميع إلى الرمز الثانوي أثناء تحميل BinaryAST، دون انتظار اكتمال جميع البيانات. بالإضافة إلى ذلك، يتيح لك التحليل من جانب الخادم استبعاد الوظائف غير المستخدمة والتعليمات البرمجية غير الضرورية من تمثيل BinaryAST الذي تم إرجاعه، والذي، عند التحليل من جانب المتصفح، يهدر الوقت في كل من التحليل ونقل حركة المرور غير الضرورية.
من ميزات BinaryAST أيضًا القدرة على استعادة جافا سكريبت القابل للقراءة والذي لا يشبه الإصدار الأصلي تمامًا، ولكنه مكافئ لغويًا ويتضمن نفس أسماء المتغيرات والوظائف (يحفظ BinaryAST الأسماء، لكنه لا يحفظ معلومات حول المواضع في التعليمات البرمجية والتنسيق والتعليقات). الجانب الآخر للعملة هو ظهور نواقل هجوم جديدة، ولكن وفقًا للمطورين، فهي أصغر بكثير وأكثر قابلية للتحكم مقارنة باستخدام البدائل، مثل توزيع الكود الثانوي.
أظهرت اختبارات كود facebook.com أن تحليل JavaScript يستهلك 10-15% من موارد وحدة المعالجة المركزية ويستغرق التحليل وقتًا أطول من إنشاء الكود الثانوي وتوليد الكود الأولي لـ JIT. في محرك SpiderMonkey، يستغرق الوقت اللازم لبناء AST بالكامل 500-800 مللي ثانية، وقد أدى استخدام BinaryAST إلى تقليل هذا الرقم بنسبة 70-90%.
بشكل عام، بالنسبة لمعظم الألعاب النارية على الويب، عند استخدام BinaryAST، يتم تقليل وقت تحليل JavaScript بنسبة 3-10% في الوضع بدون تحسين وبنسبة 90-97% عند تمكين وضع تجاهل الوظائف غير المستخدمة.
عند تشغيل مجموعة اختبار JavaScript بحجم 1.2 ميجابايت، أتاح استخدام BinaryAST تسريع وقت بدء التشغيل من 338 إلى 314 مللي ثانية على نظام سطح المكتب (Intel i7) ومن 2019 إلى 1455 مللي ثانية على جهاز محمول (HTC One M8).
المصدر: opennet.ru