來自 Cloudflare、Mozilla、Facebook 和 Bloomberg 的工程師 新格式 在瀏覽器中開啟網站時加快 JavaScript 程式碼的交付和處理速度。 BinaryAST 將解析階段移至伺服器端並提供已產生的抽象語法樹（）。 收到 BinaryAST 後，瀏覽器可以立即進入編譯階段，繞過解析 JavaScript 原始碼。
供測試用 根據 MIT 許可證提供的參考實作。 Node.js 元件用於解析，優化和 AST 產生的程式碼是用 Rust 編寫的。 瀏覽器端支援
BinaryAST 已經可用 火狐。 BinaryAST 中的編碼器既可用於最終網站工具級別，也可用於在代理或內容交付網路一側打包外部網站的腳本。 目前，工作小組的BinaryAST標準化程序已經開始 ，之後該格式將能夠與現有的內容壓縮方法共存，例如 gzip 和 brotli。
處理 JavaScript 時，大量時間花費在程式碼的載入和解析階段。 考慮到許多流行網站上下載的 JavaScript 量接近 10 MB（例如，LinkedIn - 7.2 MB、Facebook - 7.1 MB、Gmail - 3.9 MB），JavaScript 的初始處理會帶來明顯的延遲。 瀏覽器端的解析階段也會變慢，因為在載入程式碼時無法完全動態建構 AST（瀏覽器必須等待程式碼區塊完成加載，例如函數結束，才能取得解析目前元素時缺少的資訊）。
他們試圖透過以最小化和壓縮的形式分發程式碼以及快取瀏覽器產生的字節碼來部分解決該問題。 在現代網站上，程式碼經常更新，因此快取只能部分解決問題。 WebAssembly 可能是一種解決方案，但它需要明確輸入程式碼，並且不太適合加速現有 JavaScript 程式碼的處理。
另一種選擇是提供現成的編譯字節碼而不是JavaScript 腳本，但瀏覽器引擎開發人員反對，因為第三方字節碼難以驗證，其直接處理會導致Web 分層，產生額外的安全風險，並且開發需要通用字節碼格式。
BinaryAST 可讓您適應目前的程式碼開發和交付模型，而無需建立新的字節碼或更改 JavaScript 語言。 BinaryAST 格式的資料大小與壓縮後的 JavaScript 程式碼相當，並且透過消除原始文字解析階段，處理速度顯著提高。 此外，該格式允許在載入 BinaryAST 時編譯為字節碼，而無需等待所有資料完成。 此外，在伺服器端解析可讓您從傳回的 BinaryAST 表示中排除未使用的函數和不必要的程式碼，這在瀏覽器端解析時會浪費時間解析和傳輸不必要的流量。
BinaryAST 的一個功能還在於能夠恢復與原始版本不完全相同的可讀 JavaScript，但在語義上是等效的，並且包含相同名稱的變數和函數（BinaryAST 保存名稱，但不保存有關位置的資訊）程式碼、格式和註釋）。 硬幣的另一面是新的攻擊向量的出現，但根據開發人員的說法，它們比使用替代方案（例如字節碼分發）時要小得多且更可控。
對 facebook.com 程式碼的測試表明，解析 JavaScript 會消耗 10-15% 的 CPU 資源，並且解析比生成字節碼和 JIT 初始程式碼生成花費更多時間。 在SpiderMonkey引擎中，完全建造一個AST的時間需要500-800毫秒，而BinaryAST的使用使這個數字減少了70-90%。
整體而言，對於大多數Web Fireworks，使用BinaryAST 時，在不進行最佳化的模式下，JavaScript 解析時間減少了3-10%，在啟用忽略未使用函數模式時，JavaScript 解析時間減少了90-97% 。
執行 1.2 MB JavaScript 測試集時，使用 BinaryAST 可以將桌面系統 (Intel i338) 上的啟動時間從 314 毫秒加快到 7 毫秒，在行動裝置 (HTC One M2019) 上從 1455 毫秒加快到 8 毫秒。
來源： opennet.ru