北京
HTML其實一直支持流式傳輸。服務器不必在內存中構建整個頁面再發送給瀏覽器，它能先發首段HTML，然后每個片段就緒后陸續推送，瀏覽器依次解析并渲染。這也是HTML顯得快的原因之一。
但傳統流式HTML有一條嚴格規則：內容必須按照文檔順序到來。瀏覽器先收到頭部，接著是側欄，最后才是正文部分，它就按這個順序解析。如果某個緩慢的數據庫查詢堵住了頁面前半部分的一個區塊，后面的片段往往只能在服務器端等待它就緒。
JavaScript框架多年來一直在解決這個問題。服務端渲染框架會處理外殼、懸念邊界、加載狀態和延遲內容流式傳輸。有些框架用內聯腳本修補當前DOM，像HTMX這類庫允許開發者用服務器生成的HTML更新頁面的部分區域。但這些方案都離不開JavaScript。聲明式局部更新提出了一個不同的問題：如果HTML自己就能表達“當這段內容到達時，把它放到那邊”，那會怎樣？這正是Chrome聲明式局部更新提案背后的想法。
聲明式局部更新想要解決的典型場景，可以看一個商品詳情頁。服務器端已經確定了頁面標題、導航、頁腳和商品詳情，唯獨推薦區域需要執行一個慢的數據庫查詢。傳統服務端渲染HTML通常有兩種選擇：要么服務器等所有數據都準備好再發送完整響應，這保持代碼簡單，但用戶要等很久才能看到有用內容；要么服務器分階段流式輸出HTML，先發送頁面上半部分，其余部分就緒后再發送，這看起來能改善性能，因為瀏覽器在完整響應結束前就開始渲染了。
但單靠流式傳輸并不能完全解決這個問題。瀏覽器仍然順序解析HTML，如果文檔前部有一個慢的推薦區塊，它后面的內容就會被擋在后面，除非重新組織文檔結構、添加JavaScript或使用框架抽象。WICG的修補說明文檔描述了傳統HTML流式傳輸的兩個限制：一是HTML內容按DOM順序流式傳輸，二是初始文檔解析步驟之后，流式傳輸就不再像之前那樣活躍。聲明式局部更新試圖放寬第一條限制，它允許服務器先發送一個占位符，然后在響應中發送實際內容。瀏覽器會在內容到達時，用新內容替換對應的占位符，而不必等待整個文檔流結束。
這種方式讓服務端渲染中的“慢查詢阻塞”問題有了一個不需要JavaScript介入的解法。不過需要留意的是，該提案目前仍屬于瀏覽器實驗特性，還不適合運用到生產環境的HTML中。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
