HTTP请求成本与页面大小成本？

Question

我知道最好尽量减少每个页面需要的请求数量.例如,组合javascript文件和使用css sprites将大大减少呈现页面所需的请求数.

我见过的另一种方法是将javascript嵌入页面本身,特别是对于特定于该页面的javascript,而不是真正在其他页面上共享.

但我的问题是:

在什么时候我的javascript变得太大,以至于将脚本拉入单独的文件并允许对单独的js文件的额外请求变得更有效？

换句话说,我如何测量多少字节等于一个请求的成本？

由于连续请求被缓存,因此调用相同js文件的唯一成本是请求的成本.将js保留在页面中将始终产生额外页面大小的成本,但不会产生额外请求的成本.

当然,我知道有几个因素:客户端的速度,带宽速度,延迟.但是必须有一个转折点,一个人做另一个更有意义.

或者,带宽如此便宜(速度,而不是金钱)这些天它需要比以往更多的字节,以超过请求的成本？似乎是一种趋势,页面大小变得不那么重要,而请求的成本已经趋于稳定.

思考？

Answer 1

如果您只是查看数字并假设平均往返时间为100毫秒,平均连接速度为5 Mbps,您可以得到一个数字,表示最多可以将62.5 KB添加到页面之前将其分解为单独的文件变得值得.假设您的服务器上启用了gzip压缩,那么您可以添加的实际JavaScript数量甚至更大.

但是,这个数字忽略了许多重要的考虑因素.例如,如果您将JavaScript移动到单独的文件中,则用户的浏览器可以更有效地缓存它,以便触摸您的页面100次的用户可能只下载一次JavaScript文件.如果您不这样做,并假设您的网页有任何动态内容,那么同一个用户每次都必须下载整个脚本.

另一个需要考虑的问题是页面的可维护性.作为一般规则,您添加的JavaScript越多,维护页面并进行更改和更新就越困难,而不会引入错误和其他问题.因此,即使你没有相当于62.5 KB的JavaScript,即使你不关心缓存方面的事情,你也要问问自己是否有一个单独的JavaScript文件可以提高可维护性,如果是的话,是否是值得牺牲可维护性以加快页面加载速度.

所以这里确实没有确切的答案,但作为一般规则,我认为如果JavaScript是页面真正固有的东西(onclick处理程序,效果/动画,其他与页面上的元素直接相关的东西)然后它属于页面.但是如果你有一堆其他代码,你的处理程序,效果和其他东西更像是一个库/辅助工具,那么该代码可以移动到一个单独的文件中.支持代码在页面大小和加载时间方面的可维护性.无论如何,这是我的建议.

Answer 2

如果设置了正确的标头(远期标题见:1),将js拉入单独的文件几乎总是最好的选择,因为对页面的所有后续请求都不会对js文件进行任何请求或连接.

此规则唯一的例外是静态网站,在实际的html页面本身上使用远期标头是安全的,因此可以无限期地缓存它.

至于什么字节大小等于http连接的成本,这很难确定,因为你提到的变量以及许多其他变量.HTTP资源请求可以在一直到用户的节点上缓存,它们可以在很多情况下并行,并且单个连接可以重复用于多个请求(参见:2).

网页大小在网络上仍然非常重要.移动浏览器变得越来越流行,并且通过移动提供商的连接也变得越来越流行.尝试并保持较小的文件大小.

1. http://developer.yahoo.com/performance/rules.html
2. http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Persistent_connections

另外:值得注意的是,通过minification和gzip可以实现主要页面大小的成就,这些成就分别通过良好的构建工具和Web服务器实现.

Answer 3

这是一个很大的话题 - 你间接询问网络性能的许多不同方面,所以有一些技巧,其中一些是wevals提到的.

根据我自己的经验,我认为它部分地归结为模块化和权衡.例如,将整个网站中常见的javascript打包在一起是有意义的.如果您从CDN提供资产并设置正确的HTTP标头(Cache-Control,Etag,Expires),您可以获得巨大的性能提升.

确实,您将承担浏览器发出请求并从服务器接收304 Not Modified的成本,但该响应至少会快速通过网络.但是,您(通常)仍将承担处理您的请求的服务器的成本并决定资产不变.这就是像Squid,Varnish和CDN这样的网络代理一般闪耀的地方.

关于CDN的主题,特别是关于JavaScript,将jQuery之类的库从公共CDN中拉出来是有意义的.例如,Google通过其CDN提供了许多最受欢迎的库,这几乎总是比从您自己的服务器上提供的库更快.

我同意wevals页面大小仍然非常重要,特别是对于国际网站.在许多国家/地区,您需要根据自己下载的数据收费,因此,如果您的网站数量巨大,那么当您为小访问者提供服务时,访问者会获得真正的好处.

但是,要真正归结起来,我不会过分担心"请求的字节成本"与"以字节为单位的总下载大小" - 您必须运行一个真正高流量的网站来担心这些问题.而且这通常不是一个问题,因为一旦你达到某个水平,你真的无法在你面前没有CDN或其他缓存层的情况下维持任何数量的流量.

这很有趣,但我注意到有很多性能问题,如果你以合理和模块化的方式设计代码,你会更容易找到自然的分离.因此,将有意义的事物捆绑在一起,并在写作时自己保持一次性.

希望这可以帮助.