問題描述

就像知乎/quora等網(wǎng)站，當(dāng)閱讀用戶的回答或者文章的時候，可以采用read more或者modal閱讀整篇文章。

現(xiàn)在有一個相似的業(yè)務(wù)場景，每次前端向后端請求15篇文章，但是我的問題的是有些文章可能字?jǐn)?shù)有好幾萬字，這樣的話restful-api返回的數(shù)據(jù)量是否過大。

由于題主對網(wǎng)絡(luò)數(shù)據(jù)傳輸之類的概念理解不是很深，請問一次性返回將近10萬字的數(shù)據(jù)對網(wǎng)絡(luò)延遲是否有很多的影響？或者說每次我只返回文章前多少個字，當(dāng)用戶點擊read more的時候前端再向后端發(fā)起請求。

問題解答

忽略網(wǎng)絡(luò)因素，這個場景需要考慮兩個點1.服務(wù)端壓縮算法性能2.服務(wù)端壓縮算法壓縮率通常，算法的性能和壓縮率是成反比的。最極端情況，服務(wù)端不進(jìn)行壓縮，這樣壓縮率100%，cpu開銷0%；相反的壓縮率達(dá)到0.1%，cpu開銷100%。目前服務(wù)器都會開啟gzip壓縮，針對文本壓縮率能夠達(dá)到15%左右，當(dāng)然跟文本內(nèi)容也有關(guān)系，例如：排序后的文本壓縮率會更高。從題主描述的業(yè)務(wù)場景來看，類似預(yù)加載15篇文章，可以適當(dāng)取舍，畢竟要兼顧產(chǎn)品體驗，也要考慮用戶的流量。

那么問題來了，當(dāng)你是服務(wù)端渲染頁面的時候，你請求好幾萬字的文章，數(shù)據(jù)量不是更大了？十幾萬字，一個中文字是2字節(jié)十幾萬字才幾百KB= =能有多大