1991 年 8 月，第一個靜態頁面誕生了，這是由 Tim Berners-Lee 發布的，想要告訴人們什么是萬維網。從靜態頁面到 Ajax 技術，從 Server Side Render 到 React Server Components，歷史的車輪滾滾向前，一個又一個技術誕生和沉寂。
前言
1994 年，萬維網聯盟（W3C，World Wide Web Consortium）成立，超文本標記語言（HTML，Hyper Text Markup Language）正式確立為網頁標準語言，我們的旅途從此開始。本文將沿著時間線，從“發現問題-解決問題”的角度，帶領大家了解 Web 技術發展的關鍵歷程，了解典型技術的誕生以及技術更迭的緣由，思考技術發展的原因。
Server Side Render，服務端渲染，簡稱 SSR，又稱服務端同構、直出，一般使用 NodeJS 實現。這里的服務端渲染和以前的不一樣，SSR 會利用已經“脫水”的首屏數據來渲染首屏頁面返回給客戶端，到了瀏覽器再注入瀏覽器事件，并且保留單頁應用的能力，對 SEO 非常友好。但學習成本高，限制較多。讓我們看看傳統 SPA 和加入了 SSR 的 SPA 在請求上的區別：客戶端渲染示意服務端渲染示意傳統 SPA 可以更快的返回頁面，請求響應時間更短；加載 JS 后才開始渲染，白屏時間更長，loading 結束后用戶感知到的相對可交互時間更早。而 SSR 在接到瀏覽器請求時，先從后端拉取首屏數據渲染在頁面內才返回，請求響應時間更長；因為節約了一段瀏覽器請求首屏數據的時間，白屏時間更短。由于 JS 異步加載，用戶感知的相對可交互時間變晚。但體驗上 SSR 一般更好。在極端情況下，用戶眼中傳統 SPA 會一直顯示 loading，使用了 SSR 的頁面則會出現“點不動”的情況。大多數時候 SSR 體驗會更佳，因為服務端承擔了大部分渲染工作，這也導致服務端負載變高。但在業務復雜的情況下，SSR 首屏請求的接口數很多，導致返回 HTML 變慢。歸根結底，SSR 不能很好的應付業務復雜的情況，首屏要加載的東西還是太多了。所以我們要怎樣讓用戶感知到的白屏時間變短呢？
智能手機的飛速發展，這張圖表現的淋漓盡致。第三次瀏覽器大戰是爭奪移動端市場份額的一戰，也是當下正在進行的一戰。Benedict Evans: “Mobile is eating the world.”（移動設備正在蠶食世界） “Mobile remakes the Internet.”（移動設備正在重構Internet）而未來，瀏覽器真正的對手不再是瀏覽器，而是小程序這樣結合了APP和網頁優點的新興技術。
未來
早在 2009 年，Facebook 的工程師就開發了 bigPipe，讓 Facebook 頁面打開速度提高了兩倍。bigPipe 使用 分塊渲染 的思想，將網頁的渲染變成了一小塊一小塊的，服務端渲染好一塊頁面就發送給客戶端。他們直接把木桶拆了，打破了短板效應。服務端渲染 VS 流式分塊渲染時隔 11 年，也就是 2020 年 12 月，React 團隊提出了 React Server Components，算是一個可擴展的前后端融合方案。其理念和 bigPipe 類似，把組件放在服務端渲染，節省了從瀏覽器進行數據請求的開支，一些運行時也可以不用放到瀏覽器，減小了包大小（如 markdown 在服務端渲染好了，也就不再需要把工具庫發送給瀏覽器了）。React Server Components 的引入，也同步做到了自動的 Code Split。React Server Components 原理不同的是 React Server Components 返回的不是 HTML，而是帶有結構和數據的自定義類 JSON 數據。這種結構，是對服務端渲染的核心（結構+數據）進行抽象，結合 React 的工作方式（如 Suspense），平緩的從服務端過渡到了客戶端，維持了組件狀態，并且可以更自由的拼裝服務器組件和客戶端組件。客戶端組件和服務端組件混用關于拆分這條思路，讓我想到微前端，雖然現在微前端還有很多問題，但微應用即服務也不乏為一條解決之道。未來前端或許會往“小而美”的方向發展，甚至形成一個以服務端組件為單位的包管理器，網頁打包大小會越來越小，更多的組件是從網絡上直接獲取。此外，我也很期待 Web Components 的發展，有了原生的支持，0kb runtime 也不是不可能了。合久必分分久必合，現存很多前端框架也可以得到統一了。當然現在 Web Components 想要投入使用，首先離不開瀏覽器的支持，而且必須有一個平緩的過渡，此外兼容性也是一個大問題（最后還是苦了程序員們）。本文首發公眾號：騰訊技術工程（ID：Tencent_TEG），如需轉載請聯系出處。
