問題描述

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

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

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

問題解答

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

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