前端网页提速的具体方法
前端网页提速的具体方法
先说说目标,前端优化的目标是什么,一个字:快.两个字:更快.那么下面我们来看看慢的网页将会给我们带来什么:
1.慢的页面可能会网站失去更多的用户.
2.慢500ms意味着20%的用户将放弃访问(google)3.慢100ms意味着1%的用户将放弃交易(amazon)4.慢???ms意味着??%的用户将放弃xx(yoursite)
所以我们的目标很明确,就是要网页展现的速度更快.方法如下：
0.减少http请求
我把它排在了第一点,为啥要在第一点呢,很简单,因为它最重要.
如何做呢.一般来说,我们从变化性上把数据分成两种类型,变和不变.那么不变的数据可以缓存,变化的数据不能缓存,这是一个常识,也就是说要减少我们的http请求次数这个目标可以转换成把数据分为变化和不变化两个部分.不变化的数据不需要再次请求,这样http请求的次数就减少了,下面我们分点来描述将数据分类的途径.
1.合并脚本文件
包括脚本,样式和图片,可以有选择的把一些Js和css可以合并成一个文件,一些图片可以使用csssprites技术.这样做的原因是什么?做过web开发的人都知道,js和css基本是不变的,是静态文件,图片亦然.那么不变的文件如果适当的合并在一起,会有什么效果呢?请求的次数从多次变成了一次.这样http请求的次数就减少了.当时合并之后,文件体积变大了,会影响速度吗?答:肯定会啊,不过这里是需要权衡的,比如我100份静态文件,合并成10份还是合并成1份这就得看你得具体情况了.
2.指定Expires或者Cache-Control
对于静态内容：设置文件头过期时间Expires的值为“Neverexpire”（永不过期）动态页面,在代码中添加cache-control,表示多少时间之后过期,如:response.setHeader("Cache-Control","max-age=3600");
如果使用了Expires文件头，当页面内容改变时就必须改变内容的文件名。通常是在文件内容后加版本号
这一点在企业应用的系统中也时有发生.比如我们使用extjs作为前端的技术,400多k啊,每打开一个页面都导入,下载这个js,够无聊的.那么童子们可能就要问了,静态文件为啥不用apache,lighttpd等呢,答,用了又怎么样,不设expire或者max-age不是一样要下载,最好的方法是写一个filter,再filter中判断,如果url满足一定的条件(比如符合配置文件中的正则表达式),那么就设置一个max-age,这样就ok,太简单了,几行代码就可以搞定.快哉.
3.缓存Ajax请求
缓存的方法同动态页面,ajax请求需要使用get方式,url长度为2k(ie)限制(post请求有两个过程,1发送请求headers,2发送请求数据,根据http规范,get请求只会发送一个tcp包).--------这一段话来自yahoo,先不管其真假,我们从另外一个方面来考虑一下为什么最好使用get方式,之前有一个项目的ajax请求使用了post方式,后来发现经常出错,而且抛出了squid的错误,因为我们的网站使用了squid,问题就出在这里了,从http协议上可以了解到,method=post是指把数据提交到服务器上去,那么squid的一个特性是不会缓存post请求(事实上它确实不应该缓存,因为这样会违反http协议中的语义),把ajax请求改成get方式之后,一切恢复如常.
4.移除重复的js
重复的js导入也有可能导致ie重新加载该脚本.没啥好说的,照做.
5.避免重定向
有一种经常被网页开发者忽略却往往十分浪费响应时间的跳转现象。这种现象发生在当URL本该有斜杠（/）却被忽略掉时。这时候会返回一个301的状态码,然后浏览器重新发起一次请求.在企业应用里,重定向是我们在企业应用中常用的技术,不过用在网站项目上,您可要小心了,因为普通的重定向其实是server在responseheader中设置httpstatus=302,浏览器收到之后,判断出是302,会重新发送一个请求,目标地址是前一次返回中指定的地址.在网站项目中如果可以不用重定向就别用吧.如果您做企业应用项目,ok,关系不大,您就放心的”定”吧.
6.使用cdn
让内容更靠近用户,这有啥好说呢,原理很简单,就是根据用户浏览器所在机器的ip来判断哪些服务器离用户最近,浏览器会再次去请求这些最近的机器.一般的cdn服务商是通过开发自己的dnsserver来达到这个目的的.不过这个是通常情况哦,技术实力比较高,或者场景比较特殊的公司会开发自己的cdn.当然不管怎么说,使用cdn肯定可以使页面响应更快(也包括音频,视频,图片,文本文件,等等等等)
7.减小返回数据的体积(1)使用gzip压缩返回数据
Gzip压缩所有可能的文件类型是减少文件体积增加用户体验的简单方法。比如本来400k的文件,压缩一下之后只有50k-100k,那么网络的流量就立刻下来了,压缩的代价是服务器端要压缩文件,需要消耗cpu,浏览器需要解压文件,也需要消耗cpu,不过对于现代这么nb的pc,来说,浏览器解压一下数据带来的cpu消耗简直不值一提.所以您就压吧.不过压的时候要小心哦,有的浏览器在特定场景下会出去一些小bug,导致页面不正常.比如ie6在跨域的时候可能会有些小麻烦,把这部分数据的gzip去掉就可以了.(2)最小化js文件和css文件
压缩js可以使用JSMin或者YUICompressor,后者同时可以压缩css,这个也没啥好说的,照做吧.
(3)将css和js独立成外部文件
其实这一点也可以看成是区分不变数据和变化数据.很多人喜欢在页面商写很多很多的js和css,这些数据其实都是不会变化的数据,也就是说这些数据也是可以缓存在浏览器上的,通过把它们独立成外部文件,可以把这些数据缓存起来.这样做看上去是增加的请求的次数,但是由于第一次请求之后该部分数据已经被缓存,所以第二次就无需再请求后端,减少了网络带宽的开销.
8.优化Cookie(1)减小cookie体积
能不放就别放吧,为啥呀,cookie就象钥匙串,只有出门和回家得时候才用,但是一整天你都要带在身上,麻烦不.(2)合理设置Cookie域
由于二级域名可以拿到一级域名得cookie,那么如果,而二级域名之间确不能相互共享cookie,所以合理得设置cookie得域名也可以避免无必要得带宽浪费和响应速度得增加.(3)设置合理的cookie过期时间
该过期就过期,不要让不必要的数据一直带在身上走来走去.(4)使用域分离
为图片或者其他静态资源文件使用子域或者建立新的独立域名(申请新的域名),避免无必要的cookie传输,当然也是要在有必要得情况下,图片类网站肯定有必要,javaeye上得图片并没有使用域分离,所以我们得cookie其实会带到坛子得图片服务器上去,每次请求图片都是如此(不过还好,坛子里没有什么图片,所以这方面的浪费不大).(5)小结
其实cookie上得问题,单词请求看上去也不是什么大问题,好像是无所谓得事情,就那么几十个byte,至于吗,不过大家都听说过水滴石穿,绳锯木断的故事.所以该做的,我们还是要做,正所谓,勿以善小而不为,勿以恶小而为之.
9.优化浏览器加载(1)将css放在页面顶部加载
把样式表放在文档底部的问题是在包括InternetExplorer在内的很多浏览器中这会中止内容的有序呈现。浏览器中止呈现是为了避免样式改变引起的页面元素重绘。用户不得不面对一个空白页面。
HTML规范清楚指出样式表要放包含在页面的区域内：“和不同，只能出现在文档的区域内，尽管它可以多次使用它”。无论是引起白屏还是出现没有样式化的内容都不值得去尝试。最好的方案就是按照HTML规范在文档内加载你的样式表。
(2)将js放在页面底部加载
脚本带来的问题就是它阻止了页面的平行下载。HTTP/1.1规范建议，浏览器每个主机名的并行下载内容不超过两个。如果你的图片放在多个主机名上，你可以在每个并行下载中同时下载2个以上的文件。但是当下载脚本时，浏览器就不会同时下载其它文件了，即便是主机名不相同。
Js放在底部加载其实并不影响浏览器展示页面,除非用户会在js加载完成之前就调用某个js方法,比如说页面刚展现到一半,但是恰好这一半里有一部分是调用了还未下载的js,这个时候就会出问题了,如果童子们遇到这种情况,可以把这部分js先加载.
全文总结
以上这些优化点其实只是前端优化的部分内容,不过根据80/20原则,这些优化点已经覆盖了80%的情况了,同时前端优化其实也不是什么复杂的东西,原理上是很简单的,更多的是需要我们的实践,因为我们可能会碰到各种各样的问题,而很多的这些问题其实一般是预测不到的.只有遇到过才知道.
说的不对的地方请大家拍砖,或者童子们也可以把自己的经验在这里和大家分享一下.代表其他童子表示十分的感谢.
扩展阅读：网页加速的14条优化法则
网页加速的14条优化法则
关键字:网页加速,Web
优化,性能优化,YouMonitor.Us
译自：
最近，YouMonitor.Us在做Web应用性能优化，在网上发现了文章HighPerformanceWebSites:TheImportanceofFront-EndPerformance，感觉其
14条优化
法则很实用，操作性很强。因此翻译出来，供大家参考。
Web应用性能优化黄金法则：
先优化前端程序(front-end)的性能，因为这是80%或以上的最终用户响应时间的花费所在。
法则1.减少HTTP请求次数
80%的最终用户响应时间花在前端程序上，而其大部分时间则花在各种页面元素，如图像、样式表、脚本和Flash等的下载上。减少页面元素将会减少HTTP请求次数。这是快速显示页面的关键所在。
一种减少页面元素个数的方法是简化页面设计。但是否存在其他方式，能做到既有丰富内容，又能获得快速响应时间呢？以下是这样一些技术：
Imagemaps组合多个图片到一张图片中。总文件大小变化不大，但减少了
HTTP请求次数从而加快了页面显示速度。该方式只适合图片连续的情况；同时坐标的定义是烦人又容易出错的工作。
CSSSprites是更好的方法。它可以组合页面中的图片到单个文件中，并使用
CSS的background-image和background-position属性来现实所需的部分图片。
Inlineimages使用data:URLscheme来在页面中内嵌图片。这将增大HTML文件的大小。组合inlineimages到你的（缓存）样式表是既能较少HTTP请求，又能避免加大HTML文件大小的方法。Combinedfiles通过组合多个脚本文件到单一文件来减少HTTP请求次数。样式表也可采用类似方法处理。这个方法虽然简单，但没有得到大规模的使用。10大美国网站每页平均有7个脚本文件和2个样式表。当页面之间脚本和样式表变化很大时，该方式将遇到很大的挑战，但如果做到的话，将能加快响应时间。
减少HTTP请求次数是性能优化的起点。这最提高首次访问的效率起到很重要的作用。据TenniTheurer的文章BrowserCacheUsage-Exposed!描述，40-60%的日常访问是首次访问，因此为首次访问者加快页面访问速度是用户体验的关键。
法则2.使用CDN(ContentDeliveryNetwork,内容分发网络)
用户离webserver的远近对响应时间也有很大影响。从用户角度看，把内容部署到多个地理位置分散的服务器上将有效提高页面装载速度。但是该从哪里开始呢？
作为实现内容地理分布的第一步，不要试图重构web应用以适应分布架构。改变架构将导致多个周期性任务，如同步session状态，在多个server之间复制数据库交易。这样缩短用户与内容距离的尝试可能被应用架构改版所延迟，或阻止。
我们还记得80-90%的最终用户响应时间花在下载页面中的各种元素上，如图像文件、样式表、脚本和Flash等。与其花在重构系统这个困难的任务上，还不如先分布静态内容。这不仅能大大减少响应时间，而且由于CDN的存在，分布静态内容非常容易实现。
CDN是地理上分布的webserver的集合，用于更高效地发布内容。通常基于网络远近来选择给具体用户服务的webserver。
一些大型网站拥有自己的CDN，但是使用如AkamaiTechnologies,MirrorImageInternet,或LimelightNetworks等CDN服务提供商的服务将是划算的。在Yahoo!把静态内容分布到CDN减少了用户影响时间20%或更多。切换到CDN的代码修改工作是很容易的，但能达到提高网站的速度。
法则3.增加ExpiresHeader
网页内容正变得越来越丰富，这意味着更多的脚本文件、样式表、图像
文件和Flash。首次访问者将不得不面临多次HTTP请求，但通过使用Expiresheader，您可以在客户端缓存这些元素。这在后续访问中避免了不必要的HTTP请求。Expiresheader最常用于图像文件，但是它也应该用于脚本文件、样式表和Flash。
浏览器（和代理）使用缓存来减少HTTP请求的次数和大小，使得网页加速装载。Webserver通过Expiresheader告诉客户端一个元素可以缓存的时间长度。
如果服务器是Apache的话，您可以使用ExpiresDefault基于当期日期来设置过期日期，如：
ExpiresDefault“accessplus10years”设置过期时间为从请求时间开始计算的10年。
请记住，如果使用超长的过期时间，则当内容改变时，您必须修改文件名称。在Yahoo!我们经常把改名作为release的一个步骤：版本号内嵌在文件名中，如yahoo_2.0.6.js。
法则4.压缩页面元素
通过压缩HTTP响应内容可减少页面响应时间。从HTTP/1.1开始，web客户端在HTTP请求中通过Accept-Encoding头来表明支持的压缩类型，如：
Accept-Encoding:gzip,deflate.
如果Webserver检查到Accept-Encoding头，它会使用客户端支持的方法来压缩HTTP响应，会设置Content-Encoding头，如：Content-Encoding:gzip。Gzip是目前最流行及有效的压缩方法。其他的方式如deflate，但它效果较差，也不够流行。通过Gzip，内容一般可减少70%。如果是Apache，在1.3版本下需使用mod_gzip模块，而在2.x版本下，则需使用mod_deflate。
Webserver根据文件类型来决定是否压缩。大部分网站对HTML文件进行压缩。但对脚本文件和样式表进行压缩也是值得的。实际上，对包括XML和JSON在内的任务文本信息进行压缩都是值得的。图像文件和PDF文件不应该被压缩，因为它们本来就是压缩格式保存的。对它们进行压缩，不但浪费CPU，而且还可能增加文件的大小。
因此，对尽量多的文件类型进行压缩是一种减少页面大小和提高用户体验的简便方法。
法则5.把样式表放在头上
我们发现把样式表移到HEAD部分可以提高界面加载速度，因此这使得页面元素可以顺序显示。
在很多浏览器下，如IE，把样式表放在document的底部的问题在于它禁止了网页内容的顺序显示。浏览器阻止显示以免重画页面元素，那用户只能看到空白页了。Firefox不会阻止显示，但这意味着当样式表下载后，有些页面元素可能需要重画，这导致闪烁问题。
HTML规范明确要求样式表被定义在
HEAD中，因此，为避免空白屏幕或闪烁
问题，最好的办法是遵循HTML规范，把样式表放在HEAD中。
法则6.把脚本文件放在底部
与样式文件一样，我们需要注意脚本文件的位置。我们需尽量把它们放在页面的底部，这样一方面能顺序显示，另方面可达到最大的并行下载。
浏览器会阻塞显示直到样式表下载完毕，因此我们需要把样式表放在HEAD部分。而对于脚本来说，脚本后面内容的顺序显示将被阻塞，因此把脚本尽量放在底部意味着更多内容能被快速显示。脚本引起的第二个问题是它阻塞并行下载数量。HTTP/1.1规范建议浏览器每个主机的并行下载数不超过2个。因此如果您把图像文件分布到多台机器的话，您可以达到超过2个的并行下载。但是当脚本文件下载时，浏览器不会启动其他的并行下载，甚至其他主机的下载也不启动。
在某些情况下，不是很容易就能把脚本移到底部的。如，脚本使用document.write方法来插入页面内容。同时可能还存在域的问题。不过在很多情况下，还是有一些方法的。
一个备选方法是使用延迟脚本（deferredscript）。DEFER属性表明脚本未包含document.write，指示浏览器刻继续显示。不幸的是，Firefox不支持DEFER属性。在IE中，脚本可能被延迟执行，但不一定得到需要的长时间延迟。不过从另外角度来说，如果脚本能被延迟执行，那它就可以被放在底部了。
法则7.避免CSS表达式
CSS表达式是功能强大的(同时也是危险的)用于动态设置CSS属性的方式。IE，从版本5开始支持CSS表达式，如backgourd-color:
expression((newDate()).getHours()%2?”#B8D4FF”:”#F08A00”)，即背景色每个小时切换一次。
CSS表达式的问题是其执行次数超过大部分人的期望。不仅页面显示和resize时计算表达式，而且当页面滚屏，甚至当鼠标在页面上移动时都会重新计算表达式。
一种减少CSS表达式执行次数的方法是一次性表达式，即当第一次执行时就以明确的数值代替表达式。如果必须动态设置的话，可使用事件处理函数代替。如果您必须使用CSS表达式的话，请记住它们可能被执行上千次，从而影响页面性能。
法则8.把JavaScript和CSS放到外部文件中
上述很多性能优化法则都基于外部文件进行优化。现在，我们必须问一个问题：JavaScript和CSS应该包括在外部文件，还是在页面文件中？在现实世界中，使用外部文件会加快页面显示速度，因为外部文件会被浏览器缓存。如果内置JavaScript和CSS在页面中虽然会减少HTTP请求次数，但增大了页面的大小。另外一方面，使用外部文件，会被浏览器缓存，则页面大小会减小，同时又不增加HTTP请求次数。
因此，一般来说，外部文件是更可行的方式。唯一的例外是内嵌方式对主页更有效，如Yahoo!和MyYahoo!都使用内嵌方式。一般来说，在一个session中，主页访问此时较少，因此内嵌方式可以取得更快的用户响应时间。
法则9.减少DNS查询次数
DNS用于映射主机名和IP地址，一般一次解析需要20～120毫秒。为达到更高的性能，DNS解析通常被多级别地缓存，如由ISP或局域网维护的cachingserver，本地机器操作系统的缓存（如windows上的DNSClientService），浏览器。IE的缺省DNS缓存时间为30分钟，Firefox的缺省缓冲时间是1分钟。
减少主机名可减少DNS查询的次数，但可能造成并行下载数的减少。避免DNS查询可减少响应时间，而减少并行下载数可能增加响应时间。一个可行的折中是把内容分布到至少2个，最多4个不同的主机名上。
法则10.最小化JavaScript代码
最小化JavaScript代码指在JS代码中删除不必要的字符，从而降低下载时间。两个流行的工具是JSMin和YUICompressor。
混淆是最小化于源码的备选方式。象最小化一样，它通过删除注释和空格来减少源码大小，同时它还可以对代码进行混淆处理。作为混淆的一部分，函数名和变量名被替换成短的字符串，这使得代码更紧凑，同时也更难读，使得难于被反向工程。DojoCompressor(ShrinkSafe)是最常见的混淆工具。
最小化是安全的、直白的过程，而混淆则更复杂，而且容易产生问题。从对美国10大网站的调查来看，通过最小化，文件可减少21%，而混淆则可减少25%。除了最小化外部脚本文件外，内嵌的脚本代码也应该被最小化。即使脚本根据法则4被压缩后传输，最小化脚本刻减少文件大小5%或更高。
法则11.避免重定向
重定向功能是通过301和302这两个HTTP状态码完成的，如：HTTP/1.1301MovedPermanentlyLocation:Content-Type:text/html
浏览器自动重定向请求到Location指定的URL上，重定向的主要问题是降低了用户体验。
一种最耗费资源、经常发生而很容易被忽视的重定向是URL的最后缺少/，如访问将被重定向到
。在
Apache下，可以通过Alias，
mod_rewrite或DirectorySlash等方式来解决该问题。
法则12.删除重复的脚本文件
在一个页面中包含重复的JS脚本文件会影响性能，即它会建立不必要的HTTP请求和额外的JS执行。
不必要的HTTP请求发生在IE下，而Firefox不会产生多余的HTTP请求。额外的JS执行，不管在IE下，还是在Firefox下，都会发生。
一个避免重复的脚本文件的方式是使用模板系统来建立脚本管理模块。除了防止重复的脚本文件外，该模块还可以实现依赖性检查和增加版本号到脚本文件名中，从而实现超长的过期时间。法则13.配置ETags
ETags是用于确定浏览器缓存中元素是否与Webserver中的元素相匹配的机制，它是比last-modifieddate更灵活的元素验证机制。ETag是用于唯一表示元素版本的字符串，它需被包括在引号中。Webserver首先在response中指定ETag：
HTTP/1.1200OK10c24bc-4ab-457e1c1f"Content-Length:12195
后来，如果浏览器需要验证某元素，它使用If-None-Match头回传ETag给Webserver，如果ETag匹配，则服务器返回304代码，从而节省了下载时间：
GET/i/yahoo.gifHTTP/1.1Host:us.yimg.com10c24bc-4ab-457e1c1f"
HTTP/1.1304NotModified
ETags的问题在于它们是基于服务器唯一性的某些属性构造的，如Apache1.3和2.x，其格式是inode-size-timestamp，而在IIS5.0和6.0下，其格式是Filetimestamp:ChangeNumber。这样同一个元素在不同的webserver上，其ETag是不一样的。这样在多Webserver的环境下，浏览器先从server1请求某元素，后来向server2验证该元素，由于ETag不同，所以缓存失效，必须重新下载。
因此，如果您未用到ETags系统提供的灵活的验证机制，最好删除ETag。删除ETag会减少httpresponse及后续请求的HTTP头的大小。微软支持文章描述了如何删除ETags，而在Apache下，只要在配置文件中设置FileETagnone即可。法则14.缓存Ajax
性能优化法则同样适用于web2.0应用。提高Ajax的性能最重要的方式是使得其response可缓存，就象“法则3增加ExpiresHeader”讨论的那样。以下其他法则同样适用于Ajax，当然法则3是最有效的方式:
法则4.压缩页面元素
法则9.减少DNS查询次数
法则10.最小化脚本文件
法则11.避免重定向
法则13.配置ETags.
友情提示：本文中关于《前端网页提速的具体方法》给出的范例仅供您参考拓展思维使用，前端网页提速的具体方法：该篇文章建议您自主创作。
来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。
《前端网页提速的具体方法》
由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
http://m.bsmz.net/gongwen/713196.html
- 上一篇：实验2-Web开发
- 下一篇：前端网页设计代码大全