03.02 前後端分離是否會影響首屏加載時間?

古士日188


如今很多公司為了提高開發效率採用前後端分離的開發模式,這是架構上的分離解耦,前後端各司其職,通過RESTful API來調用數據。這樣做的好處也有不少,如:

  • 邏輯分離:業務邏輯放在後端,前端邏輯放在前端,這樣一來,數據及邏輯上都很清晰;

  • 前後端分離部署:減輕了後端服務器的壓力,後端服務器不需要負責前端頁面的渲染,只負責數據處理,性能上會有所提高;

  • 複用性較高:前後端分離本質上也是系統分離,可以做到同一個後端系統提供數據給多個前端系統,擴展性更高;

  • 並行開發,提高效率:前後端並行開發,提前約定好數據格式即可(mock),提升了項目開發效率。

但是,前後端分離也帶來了一些問題,比如大家比較關注的首屏加載渲染時間的問題。

對於前後端分離會不會影響首屏加載,我想說的是,多少都是有的,但影響程度要看代碼的質量了,只要優化得好,首屏加載時間不會太慢。

我們在進行前後端分離時有一些技巧來縮短首屏加載時間的,分享給大家:

  • 前端與後端分別部署,都走CDN加速;

  • 前端儘可能少的調用多個API,建議調用一個API網關來實現多個API的請求合併;

  • 後端API域名使用單獨域名,禁止cookies傳輸;

  • 部分數據本地緩存處理;

  • 不重要的數據惰性請求加載。


綜上,前後端分離在一定程度上是會影響首屏加載時間的,但是也有調優方案,總體上時間不會相差太多。

以上回答希望對大家有所幫助,如果其它網友有不同見解,也歡迎在下方評論交流 ~


網絡圈


首先由於前端要與後端通信才能獲取數據,再渲染到頁面上,這個等待時間在沒有緩存的情況下,一定會使首屏加載時間變慢。

我提供以下4個思路給大家分享:

1 在前後端分離的中間層使用node或者php。中間層可以做很多事情,比如路由控制,接口代理,服務端渲染等等,這裡不妨用php來進行服務端渲染,從而加快數據的獲取速度。

2 做一個loading的覆蓋頁,分散用戶的注意力,從而使其忽視加載時間長短。比如目前APP常見的開屏廣告,很多都是在wifi模式下預下載好的,然後等你下次打開app的時候,作為首屏展示給你,在你等待廣告過去,或者去尋找那個小小的“跳過”按鈕的時候,前後端的通信已經完成了。對於APP來說,即掙了廣告費,又不會讓用戶感覺到自己加載慢,真的是一舉兩得。

3 使用第三方組件,比如react-placeholder。

4 優化網絡,包括減少請求數(比如不要打開首屏的時候就發送一堆請求給後端),減少傳輸體積(header和body中精簡數據),合理安排請求順序(比如在頁面上方的數據調用A接口,下方的數據調用B接口,那麼就要先調用A接口,再調用B接口,儘快把用戶先看到的區域數據加載好)等,通過這些方式,也能夠減少首屏的加載等待時間。

我是蘇蘇思量,來自BAT的Java開發工程師,每日分享科技類見聞,歡迎關注我,與我共同進步。


一個存在感小透明


前後端分離會有白屏時間 這主要是因為spa應用生成首頁的js和數據的傳輸有一定時間 好在發展到現在已經有很多辦法去規避這些問題了

從時間上 就是使用cdn技術 讓數據和js更快的到達用戶端 減少等待時間 如果足夠短 是基本可以消除大部分白屏時間 甚至都感覺不到

從頁面上也有幾種方案

一種是通過service worker這一類緩存方案 使得下一次訪問能夠更快拿到數據和js 減少時間

一種是通過內聯css繪製骨架屏 讓頁面有一些定西看起來沒那麼空 一般骨架屏是按照實際頁面繪製成的色塊 會有一種逐漸加載的感覺

一種是直接從服務器入手 將那種不怎麼和後端交互或者不會因為用戶需要產生個性化的頁面在打包代碼的同時先生成好 就能返回一個不白屏的頁面了 這稱為預渲染

最後一種是ssr 服務器端渲染 讓node.js作為服務器 生成好頁面再返回給瀏覽器 消除白屏

大概流行的就這幾種方案


水華今天又做什麼了


之前在網上看到過一張調侃前後端分離的搞笑動圖(下圖所示),感覺不能在真實了。迴歸到這道問題,前後端分離是否會影響首屏加載時間?我認為是有一定影響的。

前後端分離應用有一個致命缺點,就是首屏渲染。用戶第一次打開頁面,要通過ajax加載後端的數據,因為是首次打開,所以要加載的數據較多,用戶就感知到了延遲;而傳統的後端渲染頁面,直接給瀏覽器返回的是已經包含要填充的數據的HTML頁面,所以幾乎不存在首屏渲染問題。

這麼說吧,服務器渲染,HTML直出,瀏覽器加載到文檔就可以開始渲染。而前後端分離,你得等框架、業務代碼加載到了才能渲染,所以會在一定程度上影響加載速度。


小貝的STEAM教室


應該不會,除非是技術還不過關。


分享到:


相關文章: