规则1——减小HTTP请求javascript
只有10%到20%的最终用户响应时间花在接收请求的HTML文档上面。剩下80%到90%的 时间花在为HTML文档所引用的全部组件(图片,脚本,flash,样式表等)进行的HTTP请求上。所以改善响应的最简单途径就是减小组件数量,由此减小HTTP请求的数量。php
图片地图css
使用map标签进行坐标定位,减小图片数量。导航栏中使用了多个图片时候可使用。 html
缺点不少:手工方式很难完成坐标定位,且容易出错。除了矩形以外也难以定义其余形状,经过DHTML定义的图片IE中还没法工做。不建议使用。java
CSS Sprites (雪碧图/精灵图)web
经过把多个图片合并到一个图片,而后利用background-position进行定位,比使用分离图片快50%。图片地图中的图片必须是连续的,而CSS Sprites则没有这个限制。也有人认为合并后的图片比分离的图片总和还要大,合并后的图片包含附加的空白区域。实际是变小的,雪碧图下降了图片自身的开销。(颜色表,格式信息,等等) express
若是页面中背景,按钮,导航栏,连接须要使用不少图片,可使用。优势——干净的标签,不多的图片和很短的响应时间。gulp
缺点:后期修改麻烦,难以维护,牵一发动全身,没有以前改一个图片就行了容易浏览器
雪碧图制做方法:缓存
百度搜索CSS Sprites 可找到相应制做软件软件下载地址
gulp等自动化工具,自动合成
ps本身制做
内联图片
使用 data:URL的模式在WEB页面中包含图片,但无需任何额外的HTTP请求。咱们都熟悉http:模式的URL。其余相似模式包括ftp:,file:和maito:
data:url模式
在1995年提出来:容许将小数据块内联为当即数,数据就在url自身中。
什么是内联图片
内联图片是一种新型的图像格式(在我看来是这样不知道理解对否),官方称为:data URI scheme。一般咱们存储的图片在网页中须要写:
<img src="http://blog.xmaoseo.com/images/xmaoseo.jpg"/>
而内联图片写法会是
<img src="data:image/png;base64,iVAGRw0KGDCFGNSUhEUgACBBQAVGADCAIATYJ7ljmRGGAAGElEVQQIW2P4DwcMDAxAfBvMAhEQMYgcACEHG8ELxtbPACCCTElFTEVBQmGA"/>
内联图片语法
<img src="data:image/png;base64,iVBOR....>
data - 取得数据的协定名称
image/png - 数据类型名称
base64 - 数据的编码方法
iUANR.... - 编码后的数据
: , ; - data URI scheme 指定的分隔符号
这种图片格式无需额外的HTTP请求是不错,可是还有一个重要的一点,浏览器不会缓存这种图像。 data url 节省了HTTP请求,可是若是这个图像在网页多个地方显示会加大网页的内容,延长下载时间。还有一点 IE8 如下都不支持这种图像,因此仍是IE6的用户就比较悲催了。而且超过 100kb 图像使用base64编码也会增大图片大小。致使网页总体下载量增长。 (BASE64编码图片致使网站浏览缓慢崩溃http://blog.xmaoseo.com/125.html) 可是不少聪明人作法是把背景平铺类图片做为内联图片使用,这样效果很不错。也减小了HTTP请求加快了网站速度。那么你可能会问到如何获取图片的base64编码呢。网络上有不少免费的base编码和解码工具,可是有个最简单方法就是咱们写一个PHP文件。使用base64_encode()进行编码:好比:
echo base64_encode(file_get_contents('211-11.JPG'));
如何解决网页下载延迟问题。最简单一个方法就是用写成CSS里的背景去调用CLASS 类名就能够了。好比我们用上面的例子:
.blogxmao{background:url(data:image/png;base64,iVAGRw0KGDCFGNSUhEUgACBBQAVGADCAIATYJ7ljmRGGAAGElEVQQIW2P4DwcMDAxAfBvMAhEQMYgcACEHG8ELxtbPACCCTElFTEVBQmGA")}
<div>..内容...</div><div>..内容...</div>
合并脚本和样式表
根据模块化原则, 咱们应该将代码放到多个小文件中,可是这样会下降性能,由于每一个文件都会致使一个额外的http请求。理想状况,一个页面不该该使用多余一个的脚本和样式表。世界前十网站脚本和样式表通常不超过2个。
使用模块化工具,好比seajs,requirejs进行优化。否则随着文件的增多,手动合并将会很麻烦。
规则2——使用内容分发网络 CDN
内容分发网络(conten delivery network)是一组分布在多个不一样地理位置的Web服务器。可使用CDN服务提供商。
CDN优势:
缩短相应时间,备份扩展存储能力和进行缓存,缓和WEB流量峰值压力(获取天气,娱乐体育新闻等等)
CDN缺点:
你的响应时间会受到其余网站——甚至是竞争对手的流量的影响。没法控制组件服务器所带来的特殊麻烦。好比,修改HHTP表头必须由服务提供商来完成。
若是CDN服务性能降低了,你的工做也会受到影响。固然你可使用两个CDN服务提供商。
CDN用于发布静态图片(将全部静态组件转移到CDN),图片,脚本样式表,Flash,静态文件更易存储,有较少的依赖性。
规则3——添加Expires头
Web页面包含大量组件,首次访问时间并非惟一须要考虑的,页面的初访者会进行不少HTTP请求,可是可使用一个长久的Expires头,使得这些组件被缓存。
Expires头
长久的expires常常用于图片,然而能够用于全部组件,不少顶级网站并无作到这一点,由于添加长久的ecpires头会带来额外的开发成本。
Expires:Mon,15 Apr 2025 00:00:00 GMT
它会告诉浏览器该响应的有效性会持续到2025年。
Max-Age 和mod_expires
由于expires使用一个特定的时间,要求客户端和服务器端时钟严格同步,过时日期须要检查,还要配置新的日期,因此使用麻烦。HTTP1.1引入了Cache-Control头来克服它的限制。Cache-Control使用max-age指令来指定组件被缓存多久。以秒为单位定义了一个更 新窗。
对于不支持HTTP1.1的浏览器,你能够同时指定两个响应头——Expires和max-age.若是二者同时出现,后者将会重写前者。若是你很尽责,你仍然会担忧Expires过时问题以及时钟同步问题。
幸运的是,mod_expires使你经过ExpirsDefault指令以相对方式设置日期。
ExpirsDefault 'access plus 10 years'
时间能够设置为年月日时分秒。它同时向响应中发送Expires头和max-age头。实际过时日期根据什么时候获得请求而变,可是max-age有优先权。时钟同步问题和固定日期更新不用担忧了。
跨浏览器改善缓存最佳方案就是使用 ExpirsDefault设置的Expires.
空缓存vs完整缓存
用户第一次访问你的网站它不会对HTTP的请求的数量产生任何影响。此时浏览器的缓存是空的。性能改进取决因而否有完整缓存。
在那些每日一次一更新的网站,带有完整缓存的页面浏览百分比不多。
旅游网站,email网站中每一个用户会话可能产生屡次页面浏览,百分比就高。
只要用户每月至少访问一次,或者每次会话产生屡次页面浏览,完整缓存就颇有用,使用长久Expires就颇有必要。
不只仅是图片
脚本,样式表,flash均可以缓存,可是HTML文档不该该使用,由于包含动态内容,每次都要更新。
大型网站,图片,样式表,脚本大部分都要缓存30天以上。可是常常须要变化的新闻图片等等,不该该使用。咱们能够查看Last-Modifed中的值来看改变时间以及频率。
修订文件名
使用长久的Expires缺点是 :浏览器不会检查任何更新,直到过了过时日期。即便在服务器上更新了组件,浏览器由于缓存也不能得到最新组件。
为了确保用户能得到更新过的组件,须要在全部HTML页面中修改组件的文件名。
最有效的解决方案是修改其全部连接,这样。全新的请求将从原始服务器下载最新的内容。
使用php等动态语言生成HTML页将很简单,为全部组件的文件名使用变量,使用这种方法,在页面中更新文件名只须要简单地在某个地方修改变量。Yahoo常常将这一步做为生成过程的一部分——版本号嵌入在组件的文件名中(例如yahoo_2.0.6.js),并且在全局映射中修订过的文件名会自动更新。嵌入版本号不只能够改变文件名,还能在调试中更容易找到准确的源代码文件。
规则4——压缩组件
规则1--3都是限制没必要要的HTTP请求来减小响应时间,如今咱们经过减小响应大小来减小响应时间。
压缩是如何工做的
用于减少文件体积的文件压缩已经在email应用和ftp站点中使用了十年,一样的技术也能够用于向浏览器发布压缩的web页面。
从HTTP1.1开始,web客户端能够经过请求中的Accept-Encoding头来表示对文件压缩的支持。
————>
Accept-Encoding:gzip
若是web服务器看到请求中有这个头,就会使用客户端列出来的方法中的一种来压缩响应。并经过响应中的Content-Ecoding来通知客户端。
<————
Content-Ecoding:gzip
gzip是目前最有效,最流行的压缩方法,免费模式,并被标准化为RFC 1952.(90%使用)
压缩什么
不少网站会压缩HTML文档,压缩脚本和样式表也是很是值得的,还包括XML和JSON在内的任何文本响应。图片和PDF不该该解压缩,由于已经被压缩了。再压缩只会浪费CPU资源,还有可能会增长文件大小。
压缩的成本:服务器会花费额外的CPU周期来完成压缩,客户端要对压缩文件进行解压缩。要检测受益是否大于开销,须要考虑响应的大小,链接的带宽和和客户端服务器之间的Internet距离。
根据经验,一般对大于1KB或2KB的文件进行压缩。mod_gzip_minimum_file_size指令控制着但愿压缩文件的最小值,默认值是500B。
美国十大流行网站中9个压缩了html,七个压缩了大多数脚本和样式表,只要五个压缩了全部脚本和样式表。这能够将页面减小70%。
节省
压缩以后能将响应总体减小60%左右
配置
配置gzip时使用的模块取决于Apache(intert上最流行的web服务器,份额70%以上)的版本。Apache1.3使用mod_gzip,2.3使用mod_deflate.
具体配置详情如何压缩,压缩哪些文件,压缩程度,类型(可以使用正则匹配)可搜索mod_gzip的网站参考。
规则5——将样式表放在顶部
使用link标签将样式表放在文档head中
白屏
将css放在底部的时候(有观点以为DHTML特性东西在最后展示,因此会把css放在底部以为更优化。)实则否则,这样容易发生白屏和无样式内容的闪烁。
DHTML不是 W3C 标准
DHTML 指动态 HTML(Dynamic HTML)。
DHTML 是一个营销术语 - 被网景公司(Netscape)和微软公司用来描述 4.x 代浏览器应当支持的新技术。
DHTML 是一种用来建立动态站点的技术组合物。
对大多数人来讲,DHTML 意味着 HTML 4.0、样式表以及 JavaScript 的结合物。
W3C 曾讲过:“动态HTML是一个被某些厂商用来描述可以使文档动态性更强的HTML、样式表以及脚本的结合物的术语。”
好比一些打字机效果文字,闪烁文字,遮罩滤镜等等。
白屏容易产生的地方,特别是在IE中:
新窗口中打开时
从新加载时
做为主页(打开新的浏览器窗口)
无样式内容的闪烁FOUC
FOUC flash of unstyles content 产生缘由是没有吧样式表放在head顶部,或者使用了@import导入(即使放在前面了,样式表仍是会最后下载)
因此避免无样式内容闪烁最好方法就是使用link标签将其放在head顶部
规则6——将脚本放在底部
脚本放在顶部会阻塞后面内容的呈现和组件的下载。进而产生白屏现象。
放在底部将会产生最小影响和最佳效应。
规则7——避免css表达式
css表达式 expression方法被其余浏览器忽略,IE支持,这种方法虽然强大可是很是危险。
表达式求之的频率远高于人们的指望,不只在页面呈现和大小改变时求值,鼠标拖拽,页面滚动时候都会求值。因此要避开css表达式,用事件处理器来为特定的事件提供所指望的动态行为。
规则8—— 使用外部的js和css
**内联VS外置**
单纯比较而言,内联在第一次加载时要快一点,由于内联只有一个http请求。
可是多方面考虑仍是要用外置。
内联没法缓存,外置能够缓存,并且当你页面使用了相同的js和css时候,能够组件重用,缓存优点更明显。
最重要的是,外置能够下降耦合度,调试更加方便~~~
规则9——减小DNS查找
Internet经过IP地址查找服务器,浏览器查找一个给定主机名的IP地址要花费20—120毫秒,也是有开销的,充当这个角色的就是DNS(domain name system)
如何减小DNS查找
使用较少的域名,谷歌只有一个,由于只有两个组件,能够一次并行下载完,两个主机是最好的,平衡并行下载和DNS查询。
在HTTP请求中使用 Connection:keep-alive 来保持持久链接。早期HTTP请求中。每一个请求都要打开一个socket链接,由于页面中不少请求收拾指向同一个服务器,因此这样效率很低。持久链接的引入使得浏览器能够在一个单独的链接上进行多个请求。
HTTP1.1中定义的管道能够在一个单独的socket上发送多个请求而无需等待响应,并且性能优于持久链接。
规则10——精简javascript
精简
精简是从代码中移除没必要要的字符以减少其大小。进而改善加载时间的实践。
代码精简以后全部的注释以及没必要要的空白字符(空格,换行,制表符),能够减少20%。
混淆
混淆是能够应用在源代码上的另一种优化方式,和精简同样,也会移除注释和空白,做为改写的一部分,函数和变量的名字将被转换为更短的字符串。
这样的代码更加精炼,可是更难阅读。一般这样作是为了增长对代码进行反向工程的难度,但对提升性能也有帮助。
混淆js的三个缺点
缺陷:混淆更加复杂,混淆过程自己颇有可能引入错误。
维护: 因为混淆会改变js符号,所以须要对任何不能改变的符号(例如API函数)进行标记,防止混淆修改他们。
调试:很难阅读,调试更加困难。
精简历来不会带来问题,可是混淆会带来不少问题和缺陷。维护庞大的js建议使用精简而不是混淆。
实际通过gzip压缩以后,精简和混淆差异很小。
精简css
精简css带来的节省一般小于js,由于注释和空白比较少。最大的潜在节省来自于优化css——合并相同的类,移除不使用的类等。css依赖顺序的本质(成为层叠样式表的缘由)决定了这是一个复杂的问题。这个领域还须要进一步的研究和工具开发。
一般解决方案有使用颜色缩写,用0代替0px。
规则11——避免重定向