和浏览器并发请求数有关的一些前端技术

节选自 http://www.zhihu.com/question/20474326

前端技术的逐渐成熟,衍生了domain hash, cookie free, css sprites, js/css combine, max expires time, loading images on demand等技术。这些技术的出现和大量使用都和并发资源数有关。

1、按照普通设计,当网站cookie信息有1 KB、网站首页共150个资源时,用户在请求过程中需要发送150 KB的cookie信息,在512 Kbps的常见上行带宽下,需要长达3秒左右才能全部发送完毕。 尽管这个过程可以和页面下载不同资源的时间并发,但毕竟对速度造成了影响。 而且这些信息在js/css/images/flash等静态资源上,几乎是没有任何必要的。 解决方案是启用和主站不同的域名来放置静态资源,也就是cookie free。

2、将css放置在页面最上方应该是很自然的习惯,但第一个css内引入的图片下载是有可能堵塞后续的其他js的下载的。而在目前普遍过百的整页请求数的前提下,浏览器提供的仅仅数个并发,对于进行了良好优化甚至是前面有CDN的系统而言,是极大的性能瓶颈。 这也就衍生了domain hash技术来使用多个域名加大并发量(因为浏览器是基于domain的并发控制,而不是page),不过过多的散布会导致DNS解析上付出额外的代价,所以一般也是控制在2-4之间。 这里常见的一个性能小坑是没有机制去确保URL的哈希一致性(即同一个静态资源应该被哈希到同一个域名下),而导致资源被多次下载。

3、再怎么提速,页面上过百的总资源数也仍然是很可观的,如果能将其中一些很多页面都用到的元素如常用元素如按钮、导航、Tab等的背景图,指示图标等等合并为一张大图,并利用css background的定位来使多个样式引用同一张图片,那也就可以大大的减少总请求数了,这就是css sprites的由来。

4、全站的js/css原本并不多,其合并技术的产生却是有着和图片不同的考虑。 由于cs/js通常可能对dom布局甚至是内容造成影响,在浏览器解析上,不连贯的载入是会造成多次重新渲染的。因此,在网站变大需要保持模块化来提高可维护性的前提下,js/css combine也就自然衍生了,同时也是minify、compress等对内容进行多余空格、空行、注释的整理和压缩的技术出现的原因。

5、随着cookie free和domain hash的引入,网站整体的打开速度将会大大的上一个台阶。 这时我们通常看到的问题是大量的请求由于全站公有header/footer/nav等关系,其对应文件早已在本地缓存里存在了,但为了确保这个内容没有发生修改,浏览器还是需要请求一次服务器,拿到一个304 Not Modified才能放心。 一些比较大型的网站在建立了比较规范的发布制度后,会将大部分静态资源的有效期设置为最长,也就是Cache-Control max-age为10年。 这样设置后,浏览器就再也不会在有缓存的前提下去确认文件是否有修改了。 超长的有效期可以让用户在访问曾访问过的网站或网页时,获得最佳的体验。 带来的复杂性则体现在每次对静态资源进行更新时,必须发布为不同的URL来确保用户重新加载变动的资源。

6、即使是这样做完,仍然还存在着一个很大的优化空间,那就是很多页面浏览量很大,但其实用户很大比例是直接就跳走了,第一屏以下的内容用户根本就不感兴趣。 对于超大流量的网站如淘宝、新浪等,这个问题尤其重要。 这个时候一般是通过将图片的src标签设置为一个loading或空白的样式,在用户翻页将图片放入可见区或即将放入可见区时再去载入。 不过这个优化其实和并发资源数的关系就比较小了,只是对一些散布不合理,或第一页底部的资源会有一定的帮助。 主要意图还是降低带宽费用。

总的来说,各类技术都是为了能让用户更快的看到页面进行下一步操作,但却不必将宝贵的资源浪费在没有必要的重复请求、不看的内容上。

时间: 2024-08-29 23:18:35

和浏览器并发请求数有关的一些前端技术的相关文章

关于浏览器并发请求数的研究及优化

下面先看一下各个浏览器的并发请求数限制: 通过并发数的限制衍生了domain hash, cookie free. 按照普通设计,当网站cookie信息有1 KB.网站首页共150个资源时,用户在请求过程中需要发送150 KB的cookie信息,在512 Kbps的常见上行带宽下,需要长达3秒左右才能全部发送完毕. 尽管这个过程可以和页面下载不同资源的时间并发,但毕竟对速度造成了影响. 而且这些信息在js/css/images/flash等静态资源上,几乎是没有任何必要的. 解决方案是启用和主站

查看 并发请求数及其TCP连接状态

服务器上的一些统计数据: 1)统计80端口连接数netstat -nat|grep -i "80"|wc -l 2)统计httpd协议连接数ps -ef|grep httpd|wc -l 3).统计已连接上的,状态为"establishednetstat -na|grep ESTABLISHED|wc -l 4).查出哪个IP地址连接最多,将其封了.netstat -na|grep ESTABLISHED|awk {print $5}|awk -F: {print $1}|s

探知 浏览器并发请求个数

起因:在工作中经常会发现浏览器请求过多,会很慢很卡,但我并不知道并发请求个数, 于是就写个例子,探知浏览器并发请求的个数. 思路:1.新建网站. 2.添加两个按钮,分别添加点击事件,请求不同接口. 3.服务端添加内容,打印当前时间的日志,并使进程sleep 10秒. 4.分别点击按钮,查看日志时间连续记录有几条,即为并发请求个数,间隔时间长的打印,即为下次排队执行的请求. html部分: 添加两个 <body> <input id="Button1" type=&qu

查看Apache当前的并发请求数

我们调优常常要查看httpd进程数(即prefork模式下Apache能够处理的并发请求数): Linux命令: ps -ef | grep httpd | wc -l 出现的结果,就是当前Apache能够处理的多少个并发请求,这个值Apache将根据负载情况自动调节 #  ps -ef | grep httpd | wc -l27 ps -ef是查看所有的进程,然后通过grep筛选出你要的进程信息 参数说明:-e 显示所有进程,-f 全格式. #  ps -ef | grep httpd 参数

查看http的并发请求数及其TCP连接状态

统计80端口的连接数据 netstat -nat | grep -i "80" | wc -l 统计httpd协议连接数 ps -ef | grep httpd | wc -l 统计已连接的,状态为establish的 netstat -na | greo ESTABLISH | wc -l 查出那个IP连接最多,并将其封掉 netstat -na | grep ESTABLISH | awk {print $5} | awk -F:{print $1}| sort | uniq -c

查看并发请求数及其TCP连接状态

服务器上的一些统计数据: 1)统计80端口连接数 netstat -nat|grep -i "80"|wc -l 2)统计httpd协议连接数 ps -ef|grep httpd|wc -l 3).统计已连接上的,状态为"established netstat -na|grep ESTABLISHED|wc -l 4).查出哪个IP地址连接最多,将其封了. netstat -na|grep ESTABLISHED|awk {print $5}|awk -F: {print $

通过实验,整理了部分主流手机浏览器的并发请求数

网上未见针对移动端的浏览器并发数统计,可见的帖子数据全部来自于 StackOverflow 关于主机浏览器的一篇描述.所以,设计了实验,探测了部分手机浏览器,对同域的并发访问量.以下是实验程序服务端(Java) static private final AtomicLong SEQ = new AtomicLong(0); @RequestMapping(value = "sleep/{s}", method = GET) public Result<Long> sleep

Apache的工作模式和最大并发请求数设置

http://blog.csdn.net/hxsstar/article/details/18699045 什么是apache的工作模式? 个人理解:apache的工作模式就是apache在运行时候的内存分配,进程和线程的使用方式.举个例子:一台apache正在运行的服务器,如果有个用户访问这个apache,那么apache是启用一个进程来处理用户的请求呢?还是在已有的进程中启用一个线程来处理该用户的请求?这个选择就是 apache的工作模式来确定的.如果指定了某个工作模式比如prefork模式

查看http的并发请求数与其TCP连接状态

[[email protected] ~ 17:39:55]#netstat -na | awk '/^tcp/ {++S[$NF]} END {for(i in S) print i, S[i]}' TIME_WAIT 3460 FIN_WAIT1 17 FIN_WAIT2 6 ESTABLISHED 430 LAST_ACK 24 LISTEN 18