高性能网站建设指南 学习笔记原创.docx
- 文档编号:6540330
- 上传时间:2023-01-07
- 格式:DOCX
- 页数:25
- 大小:784.76KB
高性能网站建设指南 学习笔记原创.docx
《高性能网站建设指南 学习笔记原创.docx》由会员分享,可在线阅读,更多相关《高性能网站建设指南 学习笔记原创.docx(25页珍藏版)》请在冰豆网上搜索。
高性能网站建设指南学习笔记原创
序言:
可能很多人跟我一样,一直以为性能主要是后端问题。
但是这本书中的实例表明,前端问题可能消耗掉整体时间的80%到90%,而只有10%到20%的时间花在了下载HTML文档上。
一般我们认为前端性能无非就是坚持使用外部的CSS和JS,尽量减少CSS和JS引用的数量,还有对JS的压缩。
但是这本书告诉我们,我们要做的工作远不止这些。
本书按照优先级顺序介绍了14个性能规则。
但是并非每个规则都要应用于每个网站,也不是每个网站都应该按照同一种方式运用一个规则,但是每个规则都值得考虑。
我自己做了下实验:
XX:
0.013/0.075=17%0.014/0.040=35%
pagespeed评分:
99
我们的问题大概在一下这几个方面:
启用Keep-Alive
由同一网址提供资源
将图片组合为CSS贴图定位
优化图片
我们做到了:
暂缓JavaScript解析
压缩JavaScript
压缩CSS
压缩HTML
指定图片大小
将查询字符串从静态资源中删除
优化样式表和脚本的排列顺序
使用浏览器缓存
使目标网页重定向可缓存
内嵌小型CSS
内嵌小型JavaScript
启用压缩
将CSS放在文档标头处
将图片组合为CSS贴图定位
尽量减少请求的数据量
尽量减少重定向
指定字符集
请指定一个“Vary:
Accept-Encoding”标头
请指定缓存验证工具
避免出现错误的请求
避免在CSS中使用@import
首选异步资源
下面是对以上提到的14条规则的具体介绍:
规则1-减少HTTP请求
既然有80%-90%的时间花在为HTML文档所引用的所有组建(图片,脚本,样式表,Flash等)进行的HTTP请求上,因此改善响应时间的最简单途径就是减少组件的数量,并由此减少HTTP请求数量。
这是最重要的原则,如果14条规则里只能选一条,那就是它了.
图片地图:
如果用图片做导航链接,我们可以将多个图片完成的功能,使用一个图片,根据的不同区域来响应不应的请求。
因为一个图片只有一次HTTP请求,而多个图片需要有多次请求。
--注意imgusemap的内容要和mapname一致-->
使用:
未使用:
CSSSprites
原理同上,但比上面的更灵活
CSSSprites方式处理例子:
.home{background-position:
00;margin-right:
4px;margin-lift:
4px;}
书中的示例:
内联图片是将简单图片的编码数据直接保存在URL自身之中。
(需要内联编码技术)
例如:
image/gif;base64,FNMSDAAAAA......" 合并脚本和样式表: 每个文件都会导致一个HTP请求,尽量将css和js合并到一个文件中; 单独脚本: 联合脚本: 把原有的多个样式表文件合成一个,可以使用户在浏览网页时只需下载一个CSS文件。 这样减少了HTTP请求,速度自然就快了些。 Javascript文件也一样。 不过这样做似乎不符合模块化的开发原则。 本书作者提出的建议是: 开发时仍用多个文件,部署时再把它们合并在一起。 小结: 前三种方法的起到的效果差不多,根据书中提供的例子,理论上都能节约将近一半的时间。 但是图片地图中的图片必须是连续的,在定义区域坐标时,如果采取手工的方式则很难而且容易出错,而且除了举行之外几乎无法完成其它形状,通过DHTML创建的图片地图IE不支持。 CSS精灵没有图片连续的限制,非常灵活,而且它还有个额外的优点,合并后的图片会比分离的图片的总和要小。 这是因为它降低了图片自身的开销(颜色表,格式信息等)。 内联图片的缺点是IE不支持,而且对图片的大小也有限制。 所以CSS精灵是最佳选择,我们网站用的也是这个。 合并脚本和样式表,当初改版的时候我们也是做了要求的,我们要求不超过三个,包括头部一个,框架一个,页面里只能用一个了。 规则2-使用内容发布网络 内容发布网络(CDN): 是一组分布在多个不同地理位置的Web服务器,用来存储静态文件(多数情况)以保证响应速度的提高。 CDN还有些额外的好处: 它可以提供的服务包括备份,扩展存储能力和缓存。 一些大型的公司有自己的CDN,但是大部分还是租的,如果是租的就会带来风险,因为竞争对手可能用的也是这家公司的CDN,这样的话竞争随手的流量就会影响你(但是,运营商通常会说尽量各个网站不受影响,相当于各自配置流量),另一个缺点是修改http响应头必须通过服务提供商,而不是自己的团队,如果CDN的性能下降,整体的性能就会受影响。 如果CDN是自己搭建的,唯一的缺点就是非常贵。 CDN特点 1、本地Cache加速提高了站点(尤其含有大量图片和静态页面站点)的访问速度。 2、消除了不同运营商之间互联的瓶颈造成的影响,实现了跨运营商的网络加速,保证不同网络中的用户都能得到良好的访问质量。 3、自动生成服务器的远程Mirror(镜像)cache服务器,远程用户访问时从cache服务器上读取数据,减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。 使用CDN: 未使用CDN: 这个我就不做测试了,因为这两个url请求的服务器都在美国,而CDN运行测试的地理位置对结果有重要的影响。 小结: 咱们网站使用了CDN,但是CDN的备份,扩展存储能力和缓存是如何实现的,我没有找到相关的资料。 规则3-添加Expires头 使用Expires来设置浏览器缓存,就是到指定的时间为止一直访问缓存中的内容。 另外在http1.1中引入了cache-control头来克服Expires头的限制,因为Expires头使用一个特定时间,它要求服务器和客户端的时钟严格同步,过期时间需要经常检查,并且一旦未来这一天到了,还需要在服务器配置中提供一个新的日期。 Cache-control使用max-age指定指定组件被缓存多久,它以秒为单位定义了一个更新窗。 如果从组件被请求开始过去的秒数少于max-age,浏览器就使用缓存版本。 如果你同时指定了Expires和cache-control头,max-age指令将重写Expires头。 可以在页面上设置(只适用于html等页面,不适用于组件): --expires表示网页在浏览者计算机缓存中的过期时间--> 21: 57GMT"> --使用带有max-age的cache-control指定组件被缓存多久--> 可以通过iis设置: 必须是本地计算机上Administrators组的成员或者必须被委派了相应的权限,才能执行下列步骤。 作为安全性的最佳操作,最好使用不属于Administrators组的帐户登录计算机,然后使用运行方式命令以管理员身份运行IIS管理器 在命令提示符下,键入runas/user: administrative_accountname“mmc%systemroot%\system32\inetsrv\iis.msc”。 IIS为不同的文件设置不同的过期头 为静态文件(js,css,image)设置客户端缓存是前端优化的重要法则之一,通过IIS为静态文件设置过期头(Expiresheaders)很方便, 1.打开IIS管理器; 2.点击要设置的站点,在功能视图中双击HTTP响应标头 , 3.然后点击 ,打开对话框 但是这样操作,web的整个站的所有的静态文件的缓存时间都一样,如果我们希望为不同的静态文件添加不同的缓存时间,比如有些文件很久不改变希望缓存时间长些,有些希望缓存时间短些。 操作起来还是很简单,下面以添加某一个JS文件的缓存时间为例: 1.在IIS管理器下点击该文件的文件夹并切换到内容视图 2.选中要设置的js文件,如上图的jquery-1.3.2.js,右键切换到功能视图,这时看到的IIS管理台内容是 双击上图的HTTP响应标头就可以像为整个站点设置过期时间一样的操作。 上面的操作最终还是生成web.config的配置,经过上面的设置你会发现在Script文件夹下生成了一个web.config配置文件,打开发现内容如下 这样就明白了通过上面在IIS管理器的“繁琐”的界面操作可以通过简单的web.config中配置即可,比如我要我整个Script文件夹设置统一的过期日期,只用添加一个location节即可 注意: 1.Cache-Control具有优先权于Expires 2.为了确保更新的组件在用户的浏览器中也更新(而不是使用缓存中的),解决方案是: 将所有需要更新的组件更改文件名。 我们网站没有在页面和iis设置,我们的资源文件使用的是CDN缓存,数据使用的是memcached缓存。 规则4-压缩组件 1.什么东西应该压缩? a.图片、PDF等二进制文件不应该压缩,因为它们已经压缩过了 b.太小的文件不应压缩。 为小文件压缩而耗费一些CPU时间不太值得。 一般来说,应该只对1KB或2KB以上的文件进行压缩。 2.浏览器端的支持 支持HTTP1.1的浏览器才能展现压缩过的内容。 如果你用的是APACHE服务器,则可以设置“浏览器白名单”,只对名单里的客户端传输压缩过的内容。 IIS 服务器我没查到相关的配置。 4.HTTP压缩工作原理 Web服务器处理HTTP压缩的工作原理如下: Web服务器接收到浏览器的HTTP请求后,检查浏览器是否支持HTTP压缩; 如果浏览器支持HTTP压缩,Web服务器检查请求文件的后缀名; 如果请求文件是HTML、CSS等静态文件,Web服务器到压缩缓冲目录中检查是否已经存在请求文件的最新压缩文件; 如果请求文件的压缩文件不存在,Web服务器向浏览器返回未压缩的请求文件,并在压缩缓冲目录中存放请求文件的压缩文件; 如果请求文件的最新压缩文件已经存在,则直接返回请求文件的压缩文件; 如果请求文件是ASPX等动态文件,Web服务器动态压缩内容并返回浏览器,压缩内容不存放到压缩缓存目录中。 5.IIS6.0中配置HTTPGzip压缩的步骤: (本文以windowsserver2003操作系统和IIS6.0服务器为例).win7不行 1、双击IIS服务器,右键点击网站,点击属性,然后点击服务,我们看到HTTP压缩,然后在压缩应用程序文件,压缩静态文件中打钩,然后点击确定,第一步就完成了 2、然后我们右键点击web服务扩展,点击添加一个新的web服务扩展,输入扩展名,为了便于我们识别,我们可以起名为gzip(关于起名应该是随意吧,小编没有测试过),然后点击添加,选择C: \WINDOWS\system32\inetsrv\gzip.dll,然后点击确定,扩展状态为允许,否则gzip不能生效,一切完成,我们就可以点击确定了. 3、接下来也是最重要的一步了,编辑IIS配置数据库配置文件,在此操作之前,我们应该关闭IIS服务器才能进行接下来的操作,当然我们也可以不关闭IIS服务器,我们双击IIS服务器,右键点击本地计算机,点击属性,在允许直接编辑配置数据库上打钩,那么我们不用关闭IIS就能直接配置服务器配置数据库配置文件了 4、我们找到C: \WINDOWS\system32\inetsrv下的MetaBase.xml文件,操作这个文件之前应该先复制一份,以免出现意外的情况.打开此文件,搜索deflate,找到HcDoStaticCompression原来为false改为true,HcDynamicCompressionLevel原来为0,改为9,HcFileExtensions里面就可以添加我们需要压缩的后缀,这里添加的是静态文件,一般压缩html,js,css图片不列为压缩之列.动态的文件可不可以压缩呢,当然可以HcScriptFileExtensions里面就是填写要压缩的动态文件.配置完这个,我们要来配置下面的gzip,他们两个紧挨着的,配置方法相同. 5、一切步骤都就绪了,我们看看是否开启成功了呢,那么怎样查看呢,方法有两种,可以使用火狐的firebug,还可以使用站长工具查看 注意事项: 配置数据库配置文件之前应该关闭IIS,或者启用允许直接编辑数据库 在操作MetaBase.xml文件之前应该先备份一下,防止意外情况发生. 6、代理缓存 第一次,无缓存 未压缩,缓存 第二次,有缓存 未压缩 解决办法: 2个版本的缓存 Vary: Accept-Encoding 各取所需 7、边缘情形: 正常情况下,当浏览器直接与服务器通信时我只要按常规的配置即可。 但是当浏览器通过代理来发送请求的时候就变得非常复杂。 可能会产生边缘情形(发送压缩内容到不支持它的客户端,忘记将压缩内容生命为已经进行了gzip压缩编码等)这就需要考虑压缩和缓存之间的平衡。 我们采用了gzip压缩,但是我不知道有没有禁用了代理,我们是怎么平衡的。 规则5-将样式放在顶部 首先书中提到了可视化反馈的重要性,一个很常见的例子就是进度指示器: 在我们这里,HTML页面就相当于进度指示器,当浏览器逐步的加载页面时,页头,导航栏等,所有这些为等待页面的用户提供视觉反馈。 按照作者的意思: 在IE中将样式表放在底部,可能会导致白屏或者是无样式内容的闪烁。 白屏是由于浏览器要等待css下载完再显示页面的组件,所以在等待css下载的时候页面就是白屏。 无样式的闪烁是由于先下载页面的组件比如文字图片,并逐步显示,等css下载完则需要应用新的css样式渲染,就产生了这种无样式的闪烁现象。 Css在底部: Css在顶部: 用@import方式: 无样式内容的闪烁: 但按我的测试,虽然说白屏现象只有在ie下页面加载时偶尔才会出现,但是前两个我测试不出他说的这种情况。 这条规则的说服力对我来说不是很大。 后两个效果还是很明显的。 需要说明的一点是,不管样式放在那里并不会影响加载页面的时间,而影响的是浏览器对这些组件顺序的反应,如下图: 有些用户感觉缓慢的页面反而加载的更快,这就是视觉化反馈的重要性。 如果真的产生了白屏,用户就会因为不知道发生了什么而离开,去投奔竞争对手。 还有,根据上面第三个连接,作者提出: 1.使用@import方法必须放在