web前端性能
由于web前端性能测试包含的知识点很多：浏览器工作原理、浏览器缓存、相关的http头信息、http状态码、完整的一个http请求及响应过程、响应时间、web前端性能测试工具以及优化方法等等，所以决定分两篇文章来总结，这一篇主要介绍一些跟web前端性能有关的一些概念，最近也在收集阅读相关文档，一边学习一边理解消化一边总结，有什么不对
的希望指出。
浏览器的主要构成：
1>.用户界面－包括地址栏、后退/前进按钮、书签目录等，也就是你所看到的除了用来
显示你所请求页面的主窗口之外的其他部分。2>.浏览器引擎－用来查询及操作渲染引擎的接口。
3>.渲染引擎－用来显示请求的内容，例如，如果请求内容为html，它负责解析html
及css，并将解析后的结果显示出来。
4>.网络－用来完成网络调用，例如http请求，它具有平台无关的接口，可以在不同
平台上工作。
5>.UI后端－用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台
的通用接口，底层使用操作系统的用户接口。
6>.JS解释器－用来解释执行JS代码。
7>.数据存储－属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了webdatabase技术，这是一种轻量级完整的客户端存储技术
虽然不同浏览器的工作方式不完全一样，但是基本上都包括以上各组件，浏览器的核心是浏览器引擎（BrowserEngine），目前市场占有率最高的几种浏览器几乎使用了不同的浏览器引擎：IE使用的是Trident，Firefox使用的是Gecko，Safari和Chrome使用的是Webkit。
一个完整的页面请求及响应过程：
1、浏览器的url请求2、递归寻找DNS服务器3、连接目标IP并建立TCP连接4、向目标服务器发送http请求
5、web服务器接收请求后处理
6、web服务器返回相应的结果【无效、重定向、正确页面等】7、浏览器接收返回的http内容
=========================================前端解析分割线==============================================8、开始解析html文件，当然是自上而下，先是头部，后是body
9、当解析到头部css外部链接时，同步去下载，如果遇到外部js链接也是下载【不过js链接不建议放在头部，因为耽误页面第一展现时间】
10、接着解析body部分，边解析边开始生成对应的DOM树，同时等待css文件下载11、一旦css文件下载完毕，那么就同步去用已经生成的DOM节点+CSS去生成渲染树12、渲染树一旦有结构模型了，接着就会同步去计算渲染树节点的布局位置13、一旦计算出来渲染的坐标后，又同步去开始渲染
14、10-13步进行过程中如果遇到图片则跳过去渲染下面内容，等待图片下载成功后会返回来在渲染原来图片的位置
15、同14步，如果渲染过程中出现js代码调整DOM树机构的情况，也会再次重新来过，从修改DOM那步开始
16、最终所有节点和资源都会渲染完成
=========================================分析结束分割线==============================================17、渲染完成后开始page的onload事件18、整个页面load完成
整个过程中会有很多的分别请求，所以TCP连接会很多，并且每一个用完都会自己关了，除非是keep-live类型的可以请求多次才关闭。对web应用前端性能的研究并不是为了准确的得到一个响应时间数据，实际上，web性能一部分取决于web服务器和应用服务器（建立连接、下载资源文件），另一部分取决于浏览器的实现机制、web页面上的js文件的执行等（分割线以内的步骤过程），我们并不仅仅关注页面资源的解析和展示响应时间，而是要关注总时间；我们进行web前端性能测试的目的是计算出包含页面渲染、网络传输以及
服务器端解析等综合因素在内的加载时间等指标，对该页面性能进行评估分析，找出影响性能的主要因素和瓶颈，并在此结果的基础上，给出一定的优化建议和解决方案，从而提升用
户体验。
Web前端响应时间与缓存有很大关联，而缓存也取决于http请求和响应头的某些信息。下面介绍下与前端性能相关的http头信息：先来说说为什么要缓存：1>减少网络带宽消耗2>降低服务器压力
3>减少网络延迟，加快页面加载
Web缓存的工作原理是基于一套规则（http协议头定义或HTML页面的Meta标签中定义）来帮助他们决定什么时候使用缓存中的保存的副本提高服务。分别从新鲜度和校验值两个维度来决定是使用缓存中的副本还是直接去源服务器中获取资源。
新鲜度（过期机制）：也就是缓存副本有效期。一个缓存副本必须满足以下条件，浏览器会
认为它是有效的，足够新的：
1.含有完整的过期时间控制头信息（HTTP协议报头），并且仍在有效期内；2.浏览器已经使用过这个缓存副本，并且在一个会话中已经检查过新鲜度；
满足以上两个情况的一种，浏览器会直接从缓存中获取副本并渲染。
校验值（验证机制）：服务器返回资源的时候有时在控制头信息带上这个资源的实体标签Etag（EntityTag），它可以用来作为浏览器再次请求过程的校验标识。如过发现校验标识
不匹配，说明资源已经被修改或过期，浏览器需求重新获取资源内容。
看看浏览器的一些工作原理：
在先前至少有过一次有效访问后，在以后对同一URI资源的请求中，浏览器只进行两种动
作：
(1)直接在缓存中去获取内容。如果先前有效访问的响应头包含Expires,max-age的话，“打开新窗口”、“输入URI回车”、“前一页”、“后一页”这些浏览器行为不会使浏览器在Expires,
max-age设置的有效期时间内去访问服务器，而是在缓存中去获取内容，但是""刷新""或"
重载"例外。
(2)访问服务器，根据服务器响应来获取内容。这种情况发生在设置no-cache等头标要求不
缓存，或者是设置了Expires,max-age但浏览器行为是“刷新”或“重载”时候。"Last-Modified"、"ETag"、"must-revalidate"等有些特殊，不直接受浏览器行为影响，它们必须访问服务器后，再由服务器判断是直接发送新的资源，还是发送一个304NotModfied
让浏览器使用缓存中的资源。用户操作的行为也会影响缓存的使用。
需要注意的一点是浏览器的缓存是根据URI进行的，当浏览器需要从某个URI获取资源时，会首先查看缓存中是否存在针对该URI的缓存内容，判断是直接使用还是去数据库重新去资源，因此需要改变web上显示的资源时，只需要在发布时使用一个与以前不同的URI即
可。
关于浏览器并发数：
浏览器默认对同一域下的资源，只保持一定的连接数，会阻塞过多的连接，即规定了每个客户端只能与每个服务器建立的连接数。rfc2616建议不超过2个，但是随着家庭带宽和网速的增加，各个浏览器并没有保持rfc建议的2个连接数，不同浏览器的默认值是不一样的，
对于不同的HTTP协议，其值也是不一样的，下面的表格是早期统计的一些值：
浏览器HTTP1.1HTTP1.0IE6,724IE866Firefox228Firefox366Safari3,444Chrome1,26?
浏览器HTTP1.1HTTP1.0Chrome344Opera9.644总的来看，HTTP1.0下允许的连接数普遍大于HTTP1.1协议下的，是因为HTTP1.1是保持连接的，本身对同域下资源的获取就是优化的，且对资源的消耗要大于HTTP1.0。在rfc2616中说到，限制连接数的目的在于提高响应速度和避免拥塞。当然对于浏览器的连接数也是可以修改的。使用httpwatch时页面响应时间划分中的Block这个时间段主要就是浏览器并发
数限制影响的。
HTTP状态码（HTTPStatusCode）是由RFC2616规范定义，用于表示Web服务器HTTP
响应状态的3位数字代码。
所有状态码的第一个数字代表了响应的5种状态之一，这5种状态分别如下。
1xx消息：这一类型的状态码，代表请求已被接受，需要继续处理。2xx成功：这一类型的状态码，代表请求已成功被服务器接收、理解并接收。3xx重定向：这类状态码代表需要客户端采取进一步的操作才能完成请求。
4xx请求错误：这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。
5xx服务器错误：这类状态码代表了服务器在处理请求的过程中有错误或者异常状态如使用httpwatch录制一个http请求，会返回200http状态码，表示请求已成功，请求所希望的响应头或数据体将随此响应返回；返回302表示请求的资源现在临时从不同的URI响应请求，由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。
只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存
的。；返回304时需要与其他头信息综合查看。
其它的头信息：1>1.Accept-Encoding
Accept-Encoding是浏览器发出的请求头中包含的头信息域之一，用于告诉服务器所接受
的页面文件的编码方式
比如：Accept-Encoding:gzip,deflate就是告诉服务器，浏览器能够接受不压缩和使用gzip压缩两种方式的页面内容。页面压缩和不压缩之间的下载时间相差很大，直接影响web前端相应时间。对比以下两张图（使用的是ApacheHTTPServer自带的ab加压工具，测
试对象是我实际测试项目）
2>2.2.Connection
http协议是一种非面向连接的、无状态的协议。每一个http请求与其他http请求都是完全独立的。从理论上讲，每个一个http请求都会经历一个“建立连接-请求页面或资源-获得页面或资源-断开连接”的过程。但是建立和断开连接需要一定的时间和资源开销，对于非常小的页面和资源文件来说，很可能建立连接所消耗的时间甚至大于页面或资源的处理时间。为了让响应时间尽可能缩短，http协议引入了持久连接。用于控制持久连接的http请求头就是Connection.当Connection的值设为keep-live时，浏览器与服务器之间约定使用持久连接。Httpwatch工具下Headers下headersents中可以查看Connection的Value。
扩展阅读：Web前端性能优化全攻略
网页制作Webjx文章简介：Web前端性能优化是个大话题，是个值得运维人员持续跟踪的话题，是被很多网站无情忽视的技术。
Web前端性能优化是个大话题，是个值得运维人员持续跟踪的话题，是被很多网站无情忽视的技术。
Web前端优化最佳实践之内容篇Web前端优化最佳实践之Server篇Web前端优化最佳实践之Cookie篇Web前端优化最佳实践之CSS篇
Web前端优化最佳实践之JavaScript篇Web前端优化最佳实践之图象篇
Web前端优化最佳实践之Mobile(iPhone)篇
Yahoo!的ExceptionalPerformanceteam在Web前端方面作出了卓越的贡献。广为人知的优化规则也由13条到14条，再到20条，乃至现在的34条--真是与时俱进啊。最新的34条也针对不同的角度做了分类。面向内容的优化规则目前有10条。
1.尽量减少HTTP请求(MakeFewerHTTPRequests)
作为第一条，可能也是最重要的一条。根据Yahoo!研究团队的数据分析，有很大一部分用户访问会因为这一条而取得最大受益。有几种常见的方法能切实减少HTTP请求：
1)合并文件，比如把多个CSS文件合成一个；
2)CSSSprites利用CSSbackground相关元素进行背景图绝对定位；参见：CSSSprites:ImageSlicing"sKissofDeath3)图像地图
4)内联图象使用data:URLscheme在实际的页面嵌入图像数据.
2.减少DNS查找(ReduceDNSLookups)
必须明确的一点，DNS查找的开销是很大的。另外，我倒是觉得这是Yahoo!所有站点的通病，Yahoo！主站点可能还不够明显，一些分站点，存在明显的类似问题。对于国内站点来说，如果过多的使用了站外的Widget，也很容易引起过多的DNS查找问题。
3.避免重定向(AvoidRedirects)
不是绝对的避免，尽量减少。另外，应该注意一些不必要的重定向。比如对Web站点子目录的后面添加个/(Slash)，就能有效避免一次重定向。
与二者之间是有差异的。如果是Apache服务器，通过配置Alias或mod_rewrite或是DirectorySlash能够消除这个问题。
4.使得Ajax可缓存(MakeAjaxCacheable)
响应时间对Ajax来说至关重要，否则用户体验绝对好不到哪里去。提高响应时间的有效手段就是Cache。其它的一些优化规则对这一条也是有效的。5.延迟载入组件(Post-loadComponents)6.预载入组件(PreloadComponents)
上面两条严格说来，都是属于异步这个思想灵活运用的事儿。7.减少DOM元素数量(ReducetheNumberofDOMElements)8.切分组件到多个域(SplitComponentsAcrossDomains)
主要的目的是提高页面组件并行下载能力。但不要跨太多域名，否则就和第二条有些冲突了。
9.最小化iframe的数量(MinimizetheNumberofiframes)
熟悉SEO的朋友知道iframe是SEO的大忌。针对前端优化来说iframe有其好处，也有其弊端，一分为二看问题吧。10.杜绝http404错误(No404s)
对页面链接的充分测试加上对Web服务器error日志的不断跟踪能有效减少404错误，亦能提升用户体验。值得一提的是，CSS与JavaScript引起的404错误因为定位稍稍"难"一点而往往容易被忽略。
这是内容篇的10条。应该说具体引导性的内容还不够详细。逐渐会根据自己的理解补充上来
Web前端优化最佳实践第二部分面向Server。目前共计有6条实践规则。【注，这最多算技术笔记，查看最原始内容，还请访问：ExceptionalPerformance:BestPracticesforSpeedingUpYourWebSite】1.使用CDN(UseaContentDeliveryNetwork)
国内CDN的普及还不够。不过我们有独特的电信、网通之间的问题，如果针对这个作优化，基本上也算能收到CDN或类似的效果吧(假装如此)。【Tin说国内CDN用的挺多，看看CDN厂商的市场就知道了，还没走入寻常百姓家】2.添加Expires或Cache-Control信息头(AddanExpiresoraCache-ControlHeader)
各个浏览器都有针对的方案,Apache例子【注意：下面的说明例子还不够精细，具体的环境上还要加一些调整】:
ExpiresActiveOn
ExpiresByTypeimage/gif"modificationplus1weeks"Lighttpd启用mod_expire模块后：
$HTTP["url"]=~"\\.(jpg|gif|png)___FCKpd___1quot;{expire.url=(""=>"access1years")}
Nginx例子参考:
location~*\\.(jpg|gif|png)${if(-f$request_filename){expiresmax;break;}}
3.压缩内容(GzipComponents)
对于绝大多数站点，这都是必要的一步，能有效减轻网络流量压力。或许有人担心对CPU压缩对于CPU的影响，放心大胆的整吧，没事儿。Nginx例子：gzipon;
gzip_typestext/plaintext/htmltext/cssext/javascript;另外参见：
IIS如何启用Gzip压缩?4.设置Etags(ConfigureETags)
对于Etag，可能是多数网站维护者都会忽略的地方。在这一系列优化规则出现之前，可能互联网上绝大多数站点都对这个问题忽略了。当然，Etag对多数站点性能的影响并不是很大。除非是面向RSS的网站。【看到有朋友批评说写的简略，并且说IE不支持ETag。明确说一下：IE支持ETag，倒是使用IIS要注意相关EtagBug。】
补充：我的意思是"很多网站在不注意的情况下都是打开Etag的，而没有网站关心如何用，消耗资源而不知。并不是说Etag不好，合理利用Etag，绝对能取得很好的收益.
5.尽早刷新Buffer(FlushtheBufferEarly)
对这一条，琢磨了半天，貌似还是异步的思路。能更好的提升用户体验?6.对AJAX请求使用GET方法(UseGETforAJAXRequests)
XMLHttpRequestPOST要两步，而GET只需要一步。但要注意的是在IE上GET最大能处理的URL长度是2K。
Web前端优化最佳实践第三部分面向Cookie。目前只有2条实践规则。1.缩小Cookie(ReduceCookieSize)
Cookie是个很有趣的话题。根据RFC2109的描述，每个客户端最多保持300个Cookie，针对每个域名最多20个Cookie(实际上多数浏览器现在都比这个多，比如Firefox是50个)，每个Cookie最多4K，注意这里的4K根据不同的浏览器可能不是严格的4096。别扯远了，对于Cookie最重要的就是，尽量控制Cookie的大小，不要塞入一些无用的信息。
2.针对Web组件使用域名无关性的Cookie(UseCookie-freeDomainsforComponents)
这个话题在此前针对Web图片服务器的讨论中曾经提及。这里说的Web组件(Component)，多指静态文件，比如图片CSS等，Yahoo!的静态文件都在yimg.com上，客户端请求静态文件的时候，减少了Cookie的反复传输对主域名(yahoo.com)的影响。
从这篇WhentheCookieCrumbles能看出，MySpace和eBay的Cookie都不小的，想必是对用户行为比较关心。eBay前不久构造了PersonalizationPlatform，就是从Cookie的限制中跳出来。
Web前端优化最佳实践第四部分面向CSS。目前共计有6条实践规则。另请参见Mozilla开发者中心的文章：WritingEfficientCSS1.把CSS放到代码页上端(PutStylesheetsattheTop)
官方的解释我觉得多少有点语焉不详。这一条其实和用户访问期望有关。CSS放到最顶部，浏览器能够有针对性的对HTML页面从顶到下进行解析和渲染。没有人喜欢等待，而浏览器已经考虑到了这一点。2.避免CSS表达式(AvoidCSSExpressions)
个人认为通过CSS表达式能做到的事情，通过其它手段也同样能做到而且风险更小一些。
3.从页面中剥离JavaScript与CSS(MakeJavaScriptandCSSExternal)剥离后，能够有针对性的对其进行单独的处理策略，比如压缩或者缓存策略。4.精简JavaScript与CSS(MinifyJavaScriptandCSS)
如果没有JavaScript与CSS可能更好。但，这是不可能的，SO，尽量小点吧。语法能简写的简写。
5.使用而不是@importChooseover@import
在IE中@import指令等同于把link标记写在HTML的底部。而这与第一条相违背。
6.避免使用Filter(AvoidFilters)
Web前端优化最佳实践之JavaScript篇，这部分有6条规则，和CSS篇重复的有几条。前端优化最佳实践，最重要的还是"实践"，要理解这东西容易得很，关键是要去"实践"，去"执行"，去"反馈"，去获取受益。1.脚本放到HTML代码页底部(PutScriptsattheBottom)
当一个脚本在下载的时候，浏览器干不了其它的事儿(串行了)。所以，把它扔到最后面去处理。对于一些功能性的脚本，可能实现起来有些两难。不过对于国内网站来说，有很多使用GoogleAnalytics服务进行网站数据分析的。这这一点来说，绝对可行的建议，放到页面最底下。2.MakeJavaScriptandCSSExternal参见CSS篇的描述
3.精简JavaScript与CSS(MinifyJavaScriptandCSS)参见CSS篇的描述
4.移除重复脚本(RemoveDuplicateScripts)
对于一些历史遗留站点或是论坛类的网站来说，这倒是比较常见的。接手维护人前后变化过多，每个人都有自己的一套。这就会带来一些潜在的麻烦。5.减少DOM访问(MinimizeDOMAccess)有三条指导建议:
缓存已经访问过的元素(Cachereferencestoaccessedelements)"离线"更新节点,再将它们添加到树中(Updatenodes"offline"andthenaddthemtothetree)
避免使用JavaScript输出页面布局--应该是CSS的事儿(AvoidfixinglayoutwithJavaScript)
6.DevelopSmartEventHandlers
除了英文解释外，这里也提醒一下注意关于JavaScript内存泄漏的问题。另外推荐一篇《如何优化JavaScript脚本的性能》，关于Ajax优化指导原则，可以参见提高Ajax应用程序性能，避开Web服务漏洞。
后记1)：整理得差不多之后，发现网络上已经有一篇《Yahoo!网站性能最佳体验的34条黄金守则》，是翻译稿。看来我做了一部分重复劳动。
后记2)：CSS/JavaScript都有优化规则。但似乎缺少了对Flash的优化实践。
Web前端优化最佳实践第六部分面向图片(Image)，这部分目前有4条规则。在最近的Velocity201*技术大会上，Yahoo!的StoyanStefanov做的ImageOptimization:HowManyofThese7MistakesAreYouMaking也非常有参考价值。结合一起说一下。1.优化图片(OptimizeImages)
使用GIF、JPG还是PNG格式的图片?尽可能的使用PNG格式的图片，更多的功能，更小的尺寸(与GIF相比)。
对于PNG图片，考虑用Pngcrush或类似的工具进行优化。常见的工具如下表:pngcrush
pngrewrite~jason1/pngrewrite/
OptiPNG~cosmin/pngtech/optipng/(refer:教程)
PNGOut
另请参见:FiveTipsFortheEffectiveUseofPNGImages对JPEG图片的优化工具：
jpegtran()必需要强调的是，图片设计的同学啊，请考虑设计面向Web的图片，不要动不动就设计超过可接受尺寸之外大家伙，这应该是一种习惯，而不是什么高超的技能，只需要记住就成了。
2.使用CSSSprites技巧对图片优化(OptimizeCSSSprites)
之前提到过，简单的说就是"利用CSSbackground相关元素进行背景图绝对定位"，把多次HTTP调用变为一次调用，更多参考：CSSSprites:ImageSlicing"sKissofDeath
补充一下：对于这个技巧我曾经见到有人滥用的。把多个背景图片揉成一个，减少HTTP调用，这是一个很好的思路。但一定要记住这个大图片不能太"重"，我看到过100多K的背景图。一个图片就把整个网站拖得很慢。比较好的例子可以参考雅虎关系的这个图.
更新：使用CSSSprites的一个潜在的副作用是客户端将消耗更多内存(参考)。3.不要在HTML中使用缩放图片(Don"tScaleImagesinHTML)
更多的时候，可能是因为偷懒而没有制作合适大小的图片，如果是批量处理图片的话，可能一条ImageMagic命令（convert）就能搞定。必须提及的是，看到太多的对图片拉伸很难看的页面，救救这些页面!
4.用更小的并且可缓存的favicon.ico(Makefavicon.icoSmallandCacheable)
更小，可缓存，这两条可能都不是问题。问题是，太多站点根本没有
favicon.ico。有的时候，判断独立域名的Blog是否专业，基本看一下是否有favicon.ico就差不多了。--EOF--
补充：视觉设计者应该尽量考虑控制图片大小，推荐在200K以下。这不是胡说的，参考页面。
Web前端优化最佳实践最后一部分是针对移动应用的，其实只是针对iPhone的，目前只有两条规则。
1.单个数据对象小于25K(KeepComponentsunder25K)
这个似乎只是针对iPhone研究的。建议保持单个Web数据对象在25K以下。为什么是25K?Apple官方信息指出可缓存到内存中的Web对象最大支持到10M，但经过测试，发现也就是25K左右。
iPhone在市场上的优异表现，让Web人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。2.PackComponentsintoaMultipartDocument
把Web页面组件打包成一个多部分组成的文档。其目的是减少HTTP请求。对这部分语焉不详，等待后续更新吧。
友情提示：本文中关于《web前端性能》给出的范例仅供您参考拓展思维使用，web前端性能：该篇文章建议您自主创作。
来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。
公文素材库友情提示：本网站所有内容为共享上传提供，不涉及任何商业利益，本站对此不承担任何保证责任！
Copyright © www.bsmz.net Corporation, All Rights Reserved 共享时代 共享你我他 版权所有