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