溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“SSR的利與弊有哪些”，在日常操作中，相信很多人在SSR的利與弊有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”SSR的利與弊有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
一.SSR 簡介
SSR(Server-Side Rendering)并不是什么新奇的概念，前后端分層之前很長的一段時間里都是以服務端渲染為主(JSP、PHP)，在服務端生成完整的 HTML 頁面
摘自圖解 SSR 等 6 種前端渲染模式
之所以要在服務端完成組件渲染工作，是因為有性能與可訪問性兩大優(yōu)勢
二.2 大優(yōu)勢
性能
與 CSR(Client-side rendering)模式相比，SSR 的性能優(yōu)勢體現(xiàn)在 2 方面：
網(wǎng)絡鏈路
省去了客戶端二次請求數(shù)據(jù)的網(wǎng)絡傳輸開銷
服務端的網(wǎng)絡環(huán)境要優(yōu)于客戶端，內部服務器之間通信路徑也更短
內容呈現(xiàn)
首屏加載時間(FCP)更快
瀏覽器內容解析優(yōu)化機制能夠發(fā)揮作用
網(wǎng)絡鏈路上，由服務端發(fā)出接口請求，將返回數(shù)據(jù)隨 HTML 響應內容一次性傳遞到客戶端，比 CSR 二次請求更快。并且服務端網(wǎng)絡傳輸速度更快(可以有更大帶寬)、通信路徑更短(可以同機房部署)、通信效率也更高(可以走 RPC)
內容呈現(xiàn)方面，CSR 的 HTML 大多是個空殼兒：
<!DOCTYPE html> <html> <head> <title>My Awesome Web App</title> <meta charset="utf-8"> </head> <body> <div id="app"></div> <script src="bundle.js"></script> </body> </html>
客戶端拿到這種 HTML 只能立即渲染出一頁空白，二次請求的數(shù)據(jù)回來之后才能呈現(xiàn)出有意義的內容，而 SSR 返回的 HTML 是有內容(數(shù)據(jù))的，客戶端能夠立刻渲染出有意義的首屏內容(First Contentful Paint)。同時，靜態(tài)的 HTML 文檔讓流式文檔解析(streaming document parsing)等瀏覽器優(yōu)化機制也能發(fā)揮其作用
關鍵區(qū)別是 SSR 不依賴客戶端環(huán)境，包括網(wǎng)絡環(huán)境和設備性能，即使用戶的網(wǎng)絡情況很糟(弱網(wǎng))、設備性能很差(廉價、老舊設備)，服務端渲染同樣能夠保障與最優(yōu)用戶環(huán)境(Wi-Fi 網(wǎng)絡、高端設備)下相近的內容加載體驗
可訪問性
可訪問性(accessibility)從兩方面理解：
對人：古老、特殊的用戶設備，比如禁用了 JavaScript
對機器人：爬蟲程序等，典型的，搜索引擎爬蟲
前者一般不必太過在意，后者要關注兩大“客戶”：
搜索引擎：SEO
社交媒體：抓取頁面內容展示縮略信息(比如 Twitter 卡片等)
對 PC 站點而言，保證搜索引擎能夠正確索引、準確理解頁面內容，有重要的商業(yè)價值(搜索結果靠前，曝光量更大)。移動端雖不必考慮搜索引擎爬取，但也有類似的社交分享需求，社交媒體會抓取目標頁面中的圖片等作為縮略信息
P.S.誠然，有些搜索引擎能夠正確爬取重 CSR 的 SPA，但不是全部，并且一大批社交媒體大都只從響應 HTML 中提取部分內容作為縮略信息，動態(tài)渲染 HTML(部分)內容的需求真切存在
雖具有這些優(yōu)勢，但 SSR 卻遠不如 CSR 應用廣泛，是因為 SSR 面臨著 6 大難題
三.6 個難題
難題 1：如何利用存量 CSR 代碼實現(xiàn)同構
為了降級、復用、降低遷移成本等目的，通常會采用一套 JavaScript 代碼跨客戶端、服務端運行的同構方式來實現(xiàn) SSR，然而，要讓現(xiàn)有的 CSR 代碼在服務端跑起來，先要解決諸多問題，例如：
客戶端依賴：分為 API 依賴和數(shù)據(jù)依賴兩種，比如window/document之類的 JS API、設備相關數(shù)據(jù)信息(屏幕寬高、字體大小等)
生命周期差異：例如 React 中，componentDidMount在服務端不執(zhí)行
異步操作不執(zhí)行：服務端組件渲染過程是同步的，setTimeout、Promise之類的都等不了
依賴庫的適配：React、Redux、Dva 等等，甚至還有第三方庫等不確定能否跑在 universal 環(huán)境，是否需要跨環(huán)境共享狀態(tài)，以狀態(tài)管理層為例，SSR 要求其 store 必須是可序列化的
兩邊共享狀態(tài)：每一份需要共享的狀態(tài)都要考慮(服務端)如何傳遞、(客戶端)如何接收
難題 2：服務的穩(wěn)定性和性能要求
與客戶端程序相比，服務端程序對穩(wěn)定性和性能的要求嚴苛得多，例如：
穩(wěn)定性：異常崩潰、死循環(huán)
性能：內存/CPU 資源占用、響應速度(網(wǎng)絡傳輸距離等都要考慮在內)
因此面臨后端專業(yè)性問題，Demo 級的 SSR 可能并不難，但高可用的 SSR 服務卻絕非易事，如何應對大流量/高并發(fā)，如何識別故障，如何降級/快速恢復，哪些環(huán)節(jié)需要加緩存，緩存如何更新……
難題 3：配套設施的建設
SSR 最核心的部分是渲染服務，但除此之外還要考慮：
本地開發(fā)套件(校驗 + 構建 + 預覽/HMR + 調試)
發(fā)布流程(版本管理)
一整套的工程設施，在 SSR 模式下都需要重新考慮
難題 4：錢的問題
引入 SSR 渲染服務，實際上實在網(wǎng)絡結構上加了一層節(jié)點，而大流量所過之處，每一層都是錢：
Most importantly, SSR React apps cost a lot more in terms of resources since you need to keep a Node server up and running.
將組件渲染邏輯從客戶端改到服務器執(zhí)行，計算資源的成本必須考慮在內
難題 5：hydration 的性能損耗
客戶端接到 SSR 響應之后，為了支持(基于 JavaScript 的)交互功能，仍然需要創(chuàng)建出組件樹，與 SSR 渲染的 HTML 關聯(lián)起來，并綁定相關的 DOM 事件，讓頁面變得可交互，這個過程稱為 hydration
hydration 所需加載、執(zhí)行的 JavaScript 代碼不見得比 CSR 模式少多少，這部分工作在客戶端執(zhí)行，受限于用戶設備的性能，在較差的設備下可能會造成可感知的不可交互時間：
CSR：可交互但是沒有數(shù)據(jù)(還在異步請求數(shù)據(jù)，可能會持續(xù)很長)
SSR：有數(shù)據(jù)但是不可交互(拉到 JS 后開始 hydrate 的過程，能看到內容但是不可交互，一般不會持續(xù)很長)
富交互的場景下，后者不一定比前者用戶體驗更好
難題 6：數(shù)據(jù)請求
服務端同步渲染要求先發(fā)請求，拿到數(shù)據(jù)后才開始渲染組件，那么面臨 3 個問題：
數(shù)據(jù)依賴要從業(yè)務組件中剝離出來
缺失客戶端公參(包括 cookie 等客戶端會默認帶上的 header 信息)
兩邊數(shù)據(jù)協(xié)議不同：服務端可能有更高效的通信方式，比如 RPC
目前主流的 CSR 模式下，數(shù)據(jù)依賴與業(yè)務組件存在緊耦合，要由服務端發(fā)起的數(shù)據(jù)請求全都摻雜在組件生命周期函數(shù)中，剝離數(shù)據(jù)依賴意味著需要同時改造 CSR 代碼。公參、數(shù)據(jù)協(xié)議等差異對代碼復用、可維護性也提出了一些新的挑戰(zhàn)
四.應用場景
無論首屏加載性能還是可訪問性，都是對內容密集型頁面才有意義，而對于交互密集型的頁面，SSR 所能提前渲染的內容不多，對用戶意義不大，SEO 的必要性也值得商榷。因此，SSR 適用于偏靜態(tài)的內容展示場景，典型的，商品詳情、攻略、文章等圖文混排的場景
另一方面，不一定非要 100% SSR，渲染特定頁面，甚至只渲染個頁面框架也是不錯的應用：
“Application Shell” is an excellent concept. But sometimes, we might need to render a part of the page in the server. It could be the header with user info. In such cases, you need server-side rendering.
到此，關于“SSR的利與弊有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內容。
