就像知乎/quora等网站，当阅读用户的回答或者文章的时候，可以采用read more或者modal阅读整篇文章。
现在有一个相似的业务场景，每次前端向后端请求15篇文章，但是我的问题的是有些文章可能字数有好几万字，这样的话restful-api返回的数据量是否过大。
由于题主对网络数据传输之类的概念理解不是很深，请问一次性返回将近10万字的数据对网络延迟是否有很多的影响？或者说每次我只返回文章前多少个字，当用户点击read more的时候前端再向后端发起请求。
忽略网络因素，这个场景需要考虑两个点1.服务端压缩算法性能2.服务端压缩算法压缩率通常，算法的性能和压缩率是成反比的。最极端情况，服务端不进行压缩，这样压缩率100%，cpu开销0%；相反的压缩率达到0.1%，cpu开销100%。目前服务器都会开启gzip压缩，针对文本压缩率能够达到15%左右，当然跟文本内容也有关系，例如：排序后的文本压缩率会更高。从题主描述的业务场景来看，类似预加载15篇文章，可以适当取舍，毕竟要兼顾产品体验，也要考虑用户的流量。
那么问题来了，当你是服务端渲染页面的时候，你请求好几万字的文章，数据量不是更大了？十几万字，一个中文字是2字节十几万字才几百KB= =能有多大
忽略网络因素，这个场景需要考虑两个点
1.服务端压缩算法性能
2.服务端压缩算法压缩率
通常，算法的性能和压缩率是成反比的。最极端情况，服务端不进行压缩，这样压缩率100%，cpu开销0%；相反的压缩率达到0.1%，cpu开销100%。
目前服务器都会开启gzip压缩，针对文本压缩率能够达到15%左右，当然跟文本内容也有关系，例如：排序后的文本压缩率会更高。
从题主描述的业务场景来看，类似预加载15篇文章，可以适当取舍，毕竟要兼顾产品体验，也要考虑用户的流量。
那么问题来了，当你是服务端渲染页面的时候，你请求好几万字的文章，数据量不是更大了？十几万字，一个中文字是2字节十几万字才几百KB= =能有多大