前后端分離是否會(huì)影響首屏加載時(shí)間？目前，為了提高開(kāi)發(fā)效率，很多公司都采用了前端和后端分離的開(kāi)發(fā)模式，即體系結(jié)構(gòu)的分離和解耦。前端和后端執(zhí)行各自的任務(wù)，并通過(guò)restfulapi調(diào)用數(shù)據(jù)。這種方式有很多

前后端分離是否會(huì)影響首屏加載時(shí)間？

目前，為了提高開(kāi)發(fā)效率，很多公司都采用了前端和后端分離的開(kāi)發(fā)模式，即體系結(jié)構(gòu)的分離和解耦。前端和后端執(zhí)行各自的任務(wù)，并通過(guò)restfulapi調(diào)用數(shù)據(jù)。這種方式有很多優(yōu)點(diǎn)，比如：前后端分離部署：降低了后端服務(wù)器的壓力，后端服務(wù)器不需要負(fù)責(zé)前端頁(yè)面的呈現(xiàn)，只負(fù)責(zé)數(shù)據(jù)的處理，所以性能會(huì)得到提高；

高重用性：前后端分離本質(zhì)上也是系統(tǒng)分離，它可以實(shí)現(xiàn)同一個(gè)后端系統(tǒng)向多個(gè)前端系統(tǒng)提供數(shù)據(jù)，并且具有良好的可擴(kuò)展性更高；

并行開(kāi)發(fā)，提高效率：前端和后端并行開(kāi)發(fā)，提前約定好數(shù)據(jù)格式（mock），提高項(xiàng)目開(kāi)發(fā)效率。

但是，前端和后端的分離也帶來(lái)了一些問(wèn)題，例如第一次屏幕加載和渲染時(shí)間。

至于前端和后端的分離是否會(huì)影響第一次屏幕加載，我想說(shuō)的是有很多，但影響的程度取決于代碼的質(zhì)量。只要優(yōu)化效果好，第一屏加載時(shí)間不會(huì)太慢。

，與大家分享：

前端和后端分開(kāi)部署，CDN加速；

前端盡量少調(diào)用多個(gè)API，建議調(diào)用API網(wǎng)關(guān)，實(shí)現(xiàn)多個(gè)API的請(qǐng)求合并；

后端API域名使用單獨(dú)的域名，禁止cookie傳輸；

一些數(shù)據(jù)本地緩存處理；

不重要的數(shù)據(jù)延遲請(qǐng)求加載。

如果其他網(wǎng)友有不同意見(jiàn)，請(qǐng)?jiān)谙旅姘l(fā)表評(píng)論。單頁(yè)應(yīng)用程序（SPA）是一種網(wǎng)站應(yīng)用程序模型，它可以動(dòng)態(tài)重寫當(dāng)前頁(yè)面以與用戶交互，而無(wú)需重新加載整個(gè)頁(yè)面。目前，在react、Vue和angular的領(lǐng)導(dǎo)下，單頁(yè)應(yīng)用得到了廣泛的應(yīng)用。單頁(yè)應(yīng)用程序的優(yōu)點(diǎn)和缺點(diǎn)是什么？

作為一種流行的網(wǎng)站應(yīng)用模式，單頁(yè)應(yīng)用應(yīng)該充分考慮自身的情況，權(quán)衡利弊，再?zèng)Q定是否采用單頁(yè)應(yīng)用開(kāi)發(fā)。

單頁(yè)應(yīng)用有那些優(yōu)缺點(diǎn)？

手機(jī)app啟動(dòng)為什么都會(huì)有幾秒廣告頁(yè)面，有沒(méi)有辦法屏蔽？

謝燕，頁(yè)面上有很多白屏，比如第一次加載屏幕前的白屏?xí)r間，頁(yè)面代碼崩潰導(dǎo)致整個(gè)頁(yè)面不可用的白屏，業(yè)務(wù)代碼錯(cuò)誤，以及spa頁(yè)面不呈現(xiàn)等

我知道您要檢測(cè)的是所有白屏狀態(tài)。然后通過(guò)第一次有意義的繪制來(lái)確定白屏的加載時(shí)間。如果您想看到頁(yè)面崩潰或意外的白色屏幕。

Mutationobserver@dickeylth提到，確實(shí)可以通過(guò)此API獲得頁(yè)面狀態(tài)更改，但頻繁遍歷頁(yè)面節(jié)點(diǎn)狀態(tài)更改是愚蠢的。在這里，我將添加前面的共享中提到的遍歷優(yōu)化方法。

獲得白色屏幕和頁(yè)面的第一個(gè)屏幕很有幫助。原來(lái)不是我，而是GMTC阿里云前端監(jiān)控團(tuán)隊(duì)的前端技術(shù)專家彭偉春。

[第1316期]大前端時(shí)代前端監(jiān)控的最佳實(shí)踐

讓我來(lái)截圖一下這部分的實(shí)現(xiàn)。Ppt說(shuō)得很清楚。

根據(jù)這個(gè)想法，我們可以考慮如何判斷和檢測(cè)白屏。