web前端性能优化解决方案_第1页
web前端性能优化解决方案_第2页
web前端性能优化解决方案_第3页
web前端性能优化解决方案_第4页
web前端性能优化解决方案_第5页
已阅读5页,还剩7页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

web前端性能优化解决方案

0web前端性能优化加载时间极大地影响了用户体验和网站竞争力。据美国网上媒体报道,Google检索到的网页的加载速度平均为2.45秒,而购物网站的平均网页加载速度为7.25秒。美国研究生项目资讯网站的调查结果表明,网页加载时间超过4秒,约有四分之一的人会放弃打开该网页。调查机构KissMitrics研究发现:网页加载速度影响用户消费,如果电子商务每天收入为10万美元,那么1秒的延迟就会让该网站每年损失250万美元。截止至2013年4月,互联网站总数近10亿,每秒新增7.9个新网民。如此高速发展的Web,却普遍存在前端性能低下的问题。例如:2011年百度年会推出的百度新首页,后端的平均时间为60ms,而前端的平均时间却为1.3秒。与此同时,国内的网速普遍比发达国家慢很多,中国大陆网速排在世界第71名,平均网速为1.774Mbps,远低于世界平均水平。在网速低下的环境下,对Web进行前端性能优化显得尤为重要。如今,Web的高速发展,以往的以文档为核心的HTML和XHTML标准已经无法满足Web发展的需要。新一代的HTML5应用旨在改变这一切,其拥有很多强大的用于交互、多媒体和本地化等各个方面的标签以及应用编程接口。但这些的实现意味着需要更好前端性能,特别是在移动端网速普遍较慢的环境下。早在21世纪初,雅虎、谷歌等知名互联网公司已经开始重视前端性能优化,并提出了很多解决方案以及相关的工具。比如谷歌的PageSpeed、SpeedTracer、雅虎的首席性能工程师SteveSouders根据性能优化的经验编写了《HighPerformanceWebSites》以及他与另外8位Web前端专家级特约作者编写的《EvenFasterWebSites》提供了提升网站性能的最佳实践和实用建议。国内2010年,张紫微等人通过对影响Web前端性能的各种因素,包括HTTP协议、浏览器工作方式、缓存机制、页面大小、页面结构以及Ajax等前端相关理论的分析,有针对性地提出了前端优化的多种技术开展方法,设计并实现了一个基于等待时间提升优先级的优先级请求队列,使所有的异步请求都放入优先级队列,由该队列管理请求和发送请求,解决了Ajax浏览器的2连接请求问题。高洁璇采用Ajax技术建立了Ajax化页面模型,从传统的缓存思想出发,针对热点页面建立了页面缓存模型,使请求冗余进一步减少,降低了服务器负载,利用并行思想,设计了适用于信息复杂、可模块化的页面并行加载模型,降低请求响应过程中的冗余,提高了服务器响应速度,并缩短用户等待时间,获得了更好的用户体验。在性能诊断与优化处理工具方面,周鹏等提出了基于Spirent的Web应用性能评测。聂应高以湖北省高校数字图书馆门户为例,进行了基于PageSpeed的网站前端性能优化分析和实践。连志刚认为Web性能测试难度大、周期长、要求高是一直困扰测试人员的主要问题,研究了基于RBI的马尔科夫Web系统性能测试过程模型。赵佳佳运用性能测试工具LoadRunner等建立场景并从全面分析研究,尽可能真实地模拟大量用户的并发操作等行为,并对测试结果进行完善,利用单因素隔离与对比等方法分析影响Web性能的瓶颈。但这些方案往往比较宽泛零散,缺乏系统性,实践对比不足,与项目挂钩太紧密,缺乏通用性性能测试,没形成一个完整的解决方案。据此,通过分析归纳Web中从后端到前端的B/S架构原理、浏览器缓存、浏览器的加载方式、服务器关于HTTP相关的配置等过程中一些影响前端性能优化的因素,系统地提出了一个旨在提高网页加载速度、呈现速度和用户体验,整体性、通用性强的完整Web前端性能优化解决方案,包括服务器端优化、HTML优化、JavaScript优化、CSS优化、图片优化,过程尽量避免项目的特殊性,强调实践的可行性以及通用性。针对一个基于HTML5技术的Web移动应用“指尖点餐系统”选用适当的性能检测工具搭建测试环境,寻找该系统前端性能优化上的瓶颈,并结合该项目特点,根据所提出的Web前端性能优化解决方案对其进行优化实践,对比优化前后的性能。1web性能优化方案1.1http协议的实现(1)B/S架构从浏览器对服务器进行页面请求的过程如下所示:(1)首先用户在浏览器输入网址或者通过其它应用程序请求url。(2)DNS解析域名,返回该域名所指向的网站ip地址。(4)服务器接收到浏览器的发送的HTTP请求。(5)服务器解悉浏览器请求的URL,根据URL确定请求的目标资源文件。这个资源文件通常是一个动态页面(如ASP,PHP,JSP等文件)的网络地址(MVC结构的程序例外)。Web服务器根据动态页面文件的内容和URL中的参数,调用相应的资源(通过数据库或文件)组织数据,生成HTML页面。(注意这里生成的是一个HTML文档,里面可能包含JavaScript代码等,这里在服务器端不管HTML文档里的具体内容)(6)生成HTML文档以后,服务器响应浏览器的HTTP请求,将生成的HTML文档发送给浏览器。(7)浏览器接收请求得来的HTML文档。(8)浏览器对HTML文档进行解悉,并请求HTML中链接的资源文件(如JavaScript,CSS,多媒体资源,内嵌网页)等。(9)服务器接到浏览器对资源文件的HTTP请求以后,将相应的资源文件发送给浏览器。(10)浏览器接收到请求来的资源文件,整理并呈现到页面中(浏览器将进行重排、重绘)。在进行页面呈现的时候,浏览器会从上到下执行HTML文档,当遇到相应的页面脚本的时候,会对脚本进行分析,并解释执行相应的脚本代码。当执行脚本时,将阻塞之后的链接文件的加载。在此过程中,JavaScript的加载会影响其他资源的加载。CSS的加载虽然不会影响其他资源的加载,但是由于其与浏览器的渲染有关,因此加载会影响浏览器呈现和用户体验。资源加载方面,浏览器还会限制资源加载的并行连接数和最大连接数。(2)HTTP协议客户机与服务器信息交互浏览器与服务器之间的HTTP通信协议对浏览器缓存机制进行了一系列规定,使得非首次访问不用重复加载加载过的资源,提高了资源的利用率,避免了重复加载的浪费。在HTTP/1.0中提供了一种简单的缓存机制,通过客户端根据获取文件中的日期和时间与在硬盘上缓存的文件进行对比。如果要获取的文件存在客户端缓存中,则客户端发送带有If-Modifined-Since字段的头部信息的HTTP请求。服务器程序若发现该文档没有发生改变,则返回304响应,不发生请求文件,此时客户端接收304响应后直接使用缓存中的文件。在这期间,浏览器就向服务器发送HTTP的请求及服务器接收到浏览器的发送的HTTP请求无可厚非是一个非常重要的过程。超文本传输协议HTTP(HyperTextTransferProtocol)是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符来标识。HTTP协议有四个版本:HTTP0.9、HT-TP/1.0、HTTP/1.1及HTTPS,其中HTTP/1.1是当前最经常被使用的版本。它持久连接被默认采用,并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求,以便降低线路负载,提高传输速度。HTTP/1.1更改使用持续连接,不必为每个Web对象创建一个新的连接,一个连接可以传送多个对象。HTTP/1.1还进行了带宽优化,例如HTTP/1.1引入chunkedtransferencoding(分块传输编码)来允许stream化传输持续连接上发送的内容,取原先的buffer式传输。在HTTP/1.0协议中每个HTTP请求都需要建立一个单独的连接,每次连接只传输单独的资源。在客户端和服务器每次建立和关闭连接中需要一定的时间消耗和延迟,频繁的请求影响客户端和服务器的性能。为了克服这个缺陷,HTTP/1.1采用持久连接(也称作长连接),在同一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。HTTP1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间。基于HTTP1.1协议的客户机与服务器的信息交换过程如图1所示。此外,HTTP也有状态码和一些缓存的机制。HTTP缓存可以简单地理解为:当Web请求抵达缓存时,如果本地有“已缓存的”副本,就可以从本地存储设备而不是从原始服务器中提取这个文档。这样一来,就可以减少冗余的数据传输,减少了服务器的负担,大大提高了网站的性能,从而加快了客户端加载网页的速度。在HTTP/1.0中提供了一种简单的缓存机制,即客户端根据获取文件中的日期和时间与在硬盘上缓存的HTTP文件相对比。如果要获取的文件存在客户端缓存中,则客户端发送带有If-Modifined-Since字段的头部信息的HTTP请求。服务器程序若发现该文档没有发生改变,则返回304响应,不发生请求文件,此时客户端接收304响应后直接使用缓存中的文件。HTTP/1.1对缓存进行了加强,并使用了复杂的算法以及机制来实现缓存(过期验证模型和有效性确认模型),对与经常访问的客户端的请求响应产生的数据流量大大下降,降低服务器上拥塞的产生,同时大大缩短了响应时间,提高了服务器和Web前端的性能。在服务器响应请求发送的过程中,浏览器与服务器可以进行gzip等约定的双方的压缩协议。(3)浏览器方面在B/S结构结构中,Web浏览器作为客户端最主要的应用软件,客户端统一化,将系统功能实现的核心部分集中到服务器上,简化了系统的开发、维护和使用。Web浏览器可以对页面资源进行并行加载,但是对同一个域名下会有并行连接数的限制,同时对浏览器的总连接数也有所限制。不同的浏览器有着不同限制,图2是国外的社区驱动型项目Browserscope浏览器对比的结果。因此,应通过适当增加域名来提高同一页面的并行连接数、在域名解析、同一域下并行连接数和最大连接数之间适当的平衡。在浏览器对服务器进行页面请求的过程中,JavaScript的加载会影响其他资源的加载。CSS的加载虽然不会影响其他资源的加载,但是由于其与浏览器的渲染有关,因此加载会影响浏览器呈现和用户体验。资源加载方面,浏览器还会限制资源加载的并行连接数和最大连接数。1.2采用cache-控制和etag保证选择缓存数据(1)域名优化浏览器限制并行连接数使得在同一个域名下加载的资源数量及其有限。对于页面请求很多的页面来说,页面加载速度必然受到限制。采用多域名加载资源,可以提高同一时间内加载资源的数量,最大限度地利用有限的带宽。同时,采用多域名的另外一个好处在于,当HTML资源携带的Cookie过大时,将HTML规划到单独的域名,避免其他资源的请求来回传输很大的cookie,从而避免了HTTP请求大小,提高Web前端性能。局限性:采用多域名不得不面临的问题是域名查找DNS的开销,DNS解析可能需要几秒的时间,因此如何在域名解析时间消耗和多域名提高并行连接数折中,是采用多域名优化加载资源的考虑因素之一。(2)设置缓存浏览器使用缓存来减少HTTP请求的大小,避免重复加载资源,提高资源的利用率、减少服务器压力、提高前端性能。在服务器与Web浏览器之间可以设置Expires、Cache-Control(MaxAge)、mod_expires、Etag头部信息等方式进行缓存。设置Expires头部是最常用的方式之一,通过指定HTTP头部的Expires字段一个过期时间来验证是否使用缓存数据。其局限性在于,Expires头部指定的时间,需要服务器与浏览器进行时间同步。设置Cache-Control的max-age来进行缓存,可以避免与服务器进行实践同步。不过其只支持HTTP1.1。通过同时设置这两个字段,可以在HTTP1.1时使用Cache-Control,在其他使用Expires头部进行缓存。此外,ETag用于检测浏览器缓存中的组件是否与服务器上的组件一致。设置或移除ETag头部信息,可以有很大的作用,比如Etag对于CacheCGI页面很有用。特别是论坛,论坛有办法为每个帖子页面生成唯一的Etag,在帖子未改变时,查看话题属性比较Etag就能避免刷新帖子,减少CGI操作和网络传输,减少论坛负担。适时移除ETag将有利于提升性能,避免数据存在于缓存时进行不必要的和低效的下载。但它也有一定的局限性:ETag降低了代理缓存的效率,用户与代理之间的ETag经常不匹配。而通常Last-Modified与ETag是可以一起使用的,服务器会优先验证ETag,一致的情况下,才会继续比对Last-Modified,最后才决定是否返回304。且在一般情况下,Cache-Control/Expires会配合Last-Modified/ETag一起使用,因为即使服务器设置缓存时间,当用户点击“刷新”按钮时,浏览器会忽略缓存继续向服务器发送请求,这时Last-Modified/ETag将能够很好利用304,从而减少响应开销。(3)使用CDN静态内容(比如图片、CSS、JavaScript、以及其他cookie无关的网页内容)都应该放在一个不需要使用cookie的独立域名之上。因为域名之下如果有cookie,那么客户端向该域名发出的每次HTTP请求,都会附上cookie内容。这里的一个好方法就是使用“内容分发网络”(ContentDeliveryNetwork,CDN)。CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。CDN正是出于缩短资源服务器与用户之间的距离而出现的,提高了资源的加载速度。(4)启动Gzip压缩在发送文本内容之前可以对内容进行压缩,浏览器支持Gzip、Deflate等压缩技术,而HTTP协议上的GZIP编码是一种用来改进Web应用程序性能的技术。大流量的Web站点常常使用GZIP压缩技术来让用户感受更快的速度。Gzip开启以后会将输出到用户浏览器的数据进行压缩处理,因此通过在服务器压缩再发送给浏览器,可以减少文本资源的大小,提高响应速度和加载时间。表1为YSLow对测试有无Gzip的结果。局限性:一般对于HTML、CSS、JavaScript等文本内容为主的文件,Gzip算法的效率比较高,而图片、pdf等二进制文件使用Gzip的成效就不明显。而且Gzip压缩需要消耗服务器的资源,而解压缩需要消耗浏览器的资源,对于比较大的二进制文件具有非常大的性能消耗。过小的文件(通常小于150个字节)不宜进行Gzip压缩。1.3检测页面美国web内的添加量(1)减小HTML的大小HTML中存在着不少的空格字符,如果能去除这些空格字符,就可以减小HTML文件大小。HTML文件缩小的工具有HTMLTidy或者自己用动态语言去除多余空格、制表符、换行、注释,以达到压缩HTML文件的减少文件的大小,直接提高了网页的加载速度。减少HTML大小,可以通过代码级压缩,去除空格字符或注释等无关的字符。精简代码,减少HTML元素的数量,注重HTML语义化,避免嵌套多层,在减少HTML文件大小的同时,还提高了页面渲染速度,提高了网页性能。(2)检查不存在或链接不到的资源HTTP请求、响应都需要耗费浏览器、服务器的性能,发出不带任何益处的请求降低了网页的性能。如果请求一个不存在的JavaScript文件,并且请求的服务器返回一个错误页面而不是JavaScript文件,那么浏览器会等待错误页面的内容下载完毕后才继续对所在页面进行解析,这样的空链接使得情况更糟。(3)减小Cookie的大小浏览器对同域下的每个HTTP请求都会发送与该域有关的Cookie数据,因此在Cookie比较大时HTML页面采用独立域名有利于提高Web性能。表2为HTML页面Cookie对响应时间的影响的实验结果。从该表中可以看出:在慢网速下,一个3000byte的Cookie或者所有Cookie的容量为3000bytes将会增加近1s的延迟等待时间。这个结果进一步说明我们应该尽最大的可能减少Cookie的大小,从而较少其对页面响应时间的影响。1.4web应用程序加载技术(1)压缩JavaScript文件大小与压缩HTML文件类似,JavaScript通过去除所有的注释以及不必要的空白符达到精简,缩小JavaScript文件大小的目的。除此之外,JavaScript还可以通过混淆,改写代码,将函数和变量的名字转换成更短的字符串,增加了反向工程的难度,同时大大减小了代码的大小。精简和混淆可以使用JSmin工具。(2)将JavaScript置于底部JavaScript脚本会阻塞浏览器的并行下载(某些高级版本的浏览器会有所优化,不会造成该现象),阻塞后续组件的下载和对其后面内容的呈现。将脚本放在底部可以避免阻塞对页面的呈现和避免阻塞资源加载,提高网页响应速度和加载速度,并且可以让代码更加的干净,有利于蜘蛛的抓取。(3)采用无阻塞JavaScript使用Ajax加载脚本资源,加载完成后可以eval或者创建一个script的DOM元素,然后把响应的资源加入script元素内,然后嵌入head。通过JavaScript动态创建script的DOM元素,设置其src并附加到HTMLDOM树上。该方法优于上述方法,该方法可以跨域获取脚本。(4)最小化重排和重绘最小化重排和重绘可以通过合并dom操作和样式的修改:b:通过设置CSS属性display,隐藏元素,应用修改,然后重新显示c:使用代码片段(documentFragment)在当前DOM之外构建一个DOM子树,DOM操作完毕后,将其带回文档中。d:将元素用于DOM操作的元素拷贝到一个脱离文档的节点中,DOM操作完毕后,将其带回文档中。(5)取消依赖库和按需加载在开发项目当中,有时为了提高开发效率,引入了很多JavaScript类库,而项目中只使用了其中非常少的一部分。这造成过大的JavaScript下载,形成不必要的资源浪费。可以考虑使用精小的JavaScript库代替或者使用原生的JavaScript代替。JavaScript的加载会阻塞浏览器UI线程。如果将还未用到的JavaScript封装起来,但需要用到的时候再进行调用加载。或者进行预加载,有利于提高网页性能。1.5sql充放电技术(1)精简CSS解析CSS的过程中会忽略文件中空格、制表符、换行符、格式化、注释等字符。除此之外,对部分CSS(比如font、background、margin等)。同时在项目中经常会遇到写完CSS后没用到,造成不必要的CSS代码,这时可以通过Chrome的CollectCSSSelectorProfile进行检查,并在代码中去除。(2)CSS位置CSS应该避免行内样式,采用外部样式。外部样式有利于维护、组件重用以及缓存,同时缩减HTML文件大小,在不采用样式的情况下,加载速度更快。需将样式表放在HEAD标签中。浏览器是根据CSS结合DOMTree进行渲染的。CSS的加载影响网页渲染,置于HEAD开头有利于浏览器在解析BODY内容时,加载CSS以便达到逐渐呈现的效果,提高用户体验。(3)避免耗费性能的CSS写法在IE中使用CSS表达式,它可能会被执行成千上万次,导致页面变慢。在CSS的规范写法中,不同的选择器的解析性能是不一样的。样式系统从最右边的选择符开始向左边匹配规则。只要当前选择符的左边还有其他选择符,样式系统就会继续向左移动,直到找到和规则匹配的元素,或者因为不匹配而退出。根据这个匹配的规则。应该避免使用通配符、相邻兄弟选择符、子选择符、后代选择符和属性选择符等低效的选择区,更多考虑使用ID选择符、类选择符,规则越具体越好。1.6减少网页加载时间(1)减少小图片在导航栏或按钮中,常常关联多个带有超链接的图片,这时可以考虑使用ImageMap,而CSSSprites将一个页面涉及到的所有零星图片都包含到一张大图中去,当访问该页面时,载入的图片就不会像以前那样一幅一幅地慢慢显示出来了。对于当前网络流行的速度而言,不高于200KB的单张图片的所需载入时间基本是差不多的,所以无需顾忌这个问题。利用CSSSprites能很好地减少了网页的HTTP请求,从而大大的提高了页面的性能。而且CSSSprites能够使图片之间更加紧凑,减少图片字节。所以,对于小图片,可以通过ImageMap、CSSSprites、使用内联图片等方式合并多张小图片,来减少HTTP请求,减少网页加载时间,从而提高网页前端性能。(2)避免加载过大的图片在HTML中,如果需要加载的图片尺寸过大或者过小,都可以通过前端HTML对其进行缩放。如果图片过大,便造成了不必要的图片下载开销。其次,可以选择提前将图片进行压缩到同比例的大小(可以通过图片工具或者在服务器端利用后台代码),从而选用适当比例的图片,有利于节省流量、减少下载开销。另外,选用适当的图片格式有利于提高网页质量和前端性能。2web性能优化练习2.1web新技术,提高餐饮工作效率指尖点餐系统是信息化移动生活中,将智能平板联合HT-ML5技术的发展用到点餐流程中,节约了餐厅的人力,提高餐厅的工作效率、经营收益和顾客满意度。该点餐项目基于Web新技术HTML5搭建,取代本地应用,缩短开发周期,更新周期短,维护成本低,硬件配置低等优点。但其面临性能优化问题,在网速较慢的情况下,网页加载速度很慢,极大制约了该系统的使用和降低了顾客的满意度,这也是普遍HTML5应用相对于本地应用的弱势之一。2.2web应用性能测试1)网络层面上性能检测工具(1)采用各个浏览器的开发工具(如firebug)查看代码、元素、加载情况以及清除缓存等。(2)利用YSLow、pagespeed等工具查看网络层面上的性能缺陷。(3)利用Webkit浏览器内置开发工具查看网络network、Timeline。(4)利用Fidder2来限制网速,以及查看HTTP请求信息、请求汇总报告。2)浏览器层面上性能检测工具(1)利用Webkit浏览器内置开发工具的profiles监测cpu、页面渲染、JavaScript执行、CSS利用率等。(2)利用SpeedTracer浏览器性能监测工具来监测浏览器UI线程、渲染重排、布局板面以及JavaScript执行效率代码进行级别优化等。(3)使用Spirent测试工具,采用平均事务响应时间、待测系统资源利用率和每秒事务数作为主要测试指标,综合评测Web应用的软硬件性能,并快速定位Web应用系统的性能瓶颈。3)测试环境(1)清空浏览器缓存。(2)清空DNS缓存(ipconfig/flushdns)。(3)慢网速下测试(使用Fiddler工具设置512KB带宽),10M网速下测试UIThread。(4)关闭不相关网页,开启监测工具(SpeedTracer)。2.3测试场景设计(1)Web应用评测过程在Web应用评测中,每进行一轮测试时,需针对测试目标设计测试场景,通过Spirent实施一次负载测试,统计分析各项指标,生成测试报告,根据需要分析查找系统性能瓶颈,对相关瓶颈进行优化,如图3所示。根据需要和代价选择测试、优化的迭代次数,选择符合用户需求的最佳迭代方案。(2)测试场景设计和选择性能测试应该是一个全面的测试,测试目标系统各项能力、发现系统的问题、定位系统瓶颈。如何设计测试用例,实现以最少的测试用例,最大发现系统的性能瓶颈,为优化提供指导。因此,既要从事务中的选取具有业务代表性的事件进行单独测试,又要对综合业务进行测试,防止因综合业务间事务或数据的相关性发生读写锁等待,并且设计测试用例时应尽量减少用例间的重叠,同时又无遗漏。在指尖点餐系统中,最复杂的页面为点餐页面,该页面使用最频繁,结构最复杂,页面操作多,UI交互多等特点。因此对该页面进行优化实践,对该系统最具现实意义。图4为该点餐系统的点餐页面截图。(3)负载测试流程设计Spirent负载测试主要流程如图5所示,其核心是如何配置参数使测试能完成测试目标和对测试日志的分析,找出系统的瓶颈;负载由Spirent工具自动生成。2.4点餐的时间普通采用HTML5点餐应用项目中的点餐页面进行的测试,图6为点餐页面优化前首次加载的Timeline。图6为点餐页面采用Fiddler和SpeedTracer所检测到的Timeline和UIThread拼合的测试数据。从该图中可以看出的问题如表3所示。所以针对页面渲染采取一定的性能优化措施尤为重要。2.5系统的测试结果(1)服务器端优化设置缓存后的二次加载后的二次加载如图7所示。开启Gzip压缩后的首次加载Timeline如图8所示。开启Gzip后加载时间较少了约54%,总资源大小减少了约42%,HTML/JS/CSS等文件减少了70%左右。(2)JavaScript优化针对该项目进行的JavaScript优化,主要精简代码,去除jQuery依赖。使得JavaScript文件大小从82.9KB变到3.8KB。加载时间从22s提高到11s,减少了50%的加载时间;脚本的执行时间从296ms变为132ms,减少了54.5%。同时通过优化DOM操作使页面渲染Paint减少了34%(19ms),DOM事件响应时间减少了71.5%(10ms)。相应ParseHTML增加了12ms,这是由于采用innerHTML添加元素需要解析成DOM导致的。但是整体来说UI线程减少了20ms左右。图9为进行JavaScript优化后的测试结果图。(3)JavaScript、HTML、CSS组件优化从项目之前的Timeline可以看出CSS的三个文件大小都比较小,分别为1、1.4、2.6KB。因此考虑将三

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论