性能黄金法则：

 

只有10%~20%的最终用户响应时间花在了下载HTML文档上。其余的80%~90%时间花在了下载页面中的所有组件上。

 

提升加载速度的方式：
 

 

(1).合并脚本 和样式表

 

将多个样式表或者脚本文件合并到一个文件中，可以减少HTTP请求的数量从而缩短效应时间。 不过：合并所有的样式文件或者脚本文件可能会导致在一个页面加载时加载了多于自己所需要的样式或者脚本，对于只访问该网站一个页面的人来说反而增加了下载量，所以大家应该自己权衡利弊。

 

(2).字体图标

 

(3).雪碧图

 

(4).图片地图

 

知识点链接：www.laiyongfei.com，将所有点击提交到同一个url，同时提交用户点击的x、y坐标，服务器端根据坐标映射响应

 

 CDN（内容发布网络）是一组分布在多个不同地理位置的Web服务器，如果应用程序web服务器离用户更近，那么HTTP请求的响应时间将缩短。

 

浏览器在第一次访问页面时加载的资源会缓存起来，第二次访问判断在缓存中是否已有该资源并且有没有更新过，如果已有该资源且没有更新过，则去缓存去取，这样减少了下载资源的时间。原理上是通过HTTP Rquest Header中的 if-modified-since 和Response Headers中的last-modified来实现，HTTP请求把if-modified-sincede 时间传给服务端，服务端把last-modified时间与之对比，如果相同，则意味着文件没有改动，则返回304，浏览器则从缓存中获取资源，无需下载。虽然这种方法减少了已缓存资源的下载时间，但是仍然发起了一次http请求。

而HTTP的Expires和Cache-Control就是来免去该资源的http请求。

Cache-Control在服务端配置文件缓存有效期（3个月，1年...），有效期内读缓存数据，不HTTP请求。

expires在服务端配置，添加的是该资源过期的日期，浏览器会根据该过期日期与客户端时间对比，到期 了再重新读取，expires时间可能存在客户端时间跟服务端时间不一致的问题，最好与Cache-Control结合使用。更多详细请参考：www.laiyongfei.com

 

在HTTP请求中，accept-encoding: gzip, deflate, sdch, br是指客户端浏览器（这里是我的chrome浏览器）支持的压缩方式。参考Yahoo！工程师的说法，支持gzip的浏览器范围最广，使用gzip的压缩效果最佳。客户端不用任何配置，在服务端配置即可，服务器不同，配置方法也不尽相同。

 

Accept-Encoding: gzip,deflate...如果Web服务器看到请求中有这个头，就会使用客户端列出来的方法中的一种来进行压缩。

 

 

代理缓存

 

放在头部对于实际页面加载的时间并不能造成太大影响，但可以减少页面首屏出现的时间，使页面内容逐步呈现，改善用户体验，防止“白屏”。

 

我们总是希望页面能够尽快显示内容，为用户提供可视化的回馈，这对网速慢的用户来说是很重要的。

 

将样式表放在文档底部会阻止浏览器中的内容逐步出现。为了避免当样式变化时重绘页面元素，浏览器会阻塞内容逐步呈现，造成“白屏”。这源自浏览器的行为：如果样式表仍在加载，构建呈现树就是一种浪费，因为所有样式表加载解析完毕之前不需绘制任何东西

 

与样式表相同，脚本放在底部对于实际页面加载的时间并不能造成太大影响，但是这会减少页面首屏出现的时间，使页面内容逐步呈现。

 

js的下载和执行会阻塞Dom树的构建（严谨地说是中断了Dom树的更新），所以script标签放在首屏范围内的HTML代码段里会截断首屏的内容。

 

因为脚本可能修改页面内容，因此浏览器会等待；另外，也是为了保证脚本能够按照正确的顺序执行，因为后面的脚本可能与前面的脚本存在依赖关系，不按照顺序执行可能会产生错误。

 

内联脚本或者样式可以减少HTTP请求，按理来说可以提高页面加载的速度。然而在实际情况中，当脚本或者样式是从外部引入的文件，浏览器就有可能缓存它们，从而在以后加载的时候能够直接使用缓存，而HTML文档的大小减小，从而提高加载速度。

 

这时候就要分情况来看，如果一个用户每个月只访问你的网站一两次，那么这种情况下内联将会更好。而如果该用户能够产生很多页面浏览量，那么缓存的样式和脚本将会极大减少下载的时间，提交页面加载速度。

 

当我们在浏览器的地址栏输入网址（譬如： www.laiyongfei.com） ，然后回车，回车这一瞬间到看到页面到底发生了什么呢？

 

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

 

域名解析是页面加载的第一步，那么域名是如何解析的呢？见文章：（后面补上，or自行百度）

 

DNS也是开销，通常浏览器查找一个给定域名的IP地址要花费20~120毫秒，在完成域名解析之前，浏览器不能从服务器加载到任何东西。那么如何减少域名解析时间，加快页面加载速度呢？

 

当客户端DNS缓存（浏览器和操作系统）缓存为空时，DNS查找的数量与要加载的Web页面中唯一主机名的数量相同，包括页面URL、脚本、样式表、图片、Flash对象等的主机名。减少主机名的 数量就可以减少DNS查找的数量。

 

而减少唯一主机名的数量会潜在减少页面中并行下载的数量，这样减少主机名和并行下载的方案会产生矛盾，需要大家自己权衡。建议将组件放到至少两个但不多于4个主机名下，减少DNS查找的同时也允许高度并行下载。

 

对于一些图片，费首屏的，后面scroll到的时候再加载

 

模块化开发，只需加载用到的资源

 

预加载是在浏览器空闲时请求将来可能