Web前端,高性能优化

高性能HTML

一、避免使用iframe
  iframe也叫内联frame,可将一个HTML文档嵌入另一个HTML文档中。
  iframe的好处是,嵌入的文档独立于父文档,通常也借此使浏览器模拟多线程。缺点是:

  ①虽然iframe能模拟多线程,但主流浏览器的同域名并行下载数是不变的,浏览器对同域名的链接总是共享浏览器级别的连接池,
     即使是不同窗口或标签页的同域名网页。
  ②在页面加载时,iframe会阻塞父文档onload事件的触发。并且有些浏览器需在触发onload事件后才能被触发onunload事件。
     故用户用onload事件长久未触发而离开页面时,不会触发onunload事件。
    ※不兼容IE6~8的解决方案:使用JavaScript动态加载iframe元素或动态设置其src属性。

<iframe id=ifr ></iframe>
document.getElementById( ‘ifr’ ).setAttribute( ‘src’ , ‘url ’ );

  ③iframe是文档内最消耗资源的元素之一,即使是空iframe的开销也是昂贵的。【通过Steve Souders测试】

二、避免空连接属性
  空连接指:img、link、script 和 iframe元素的src或href属性的值为空。(如src = ””)
  设置了空连接后浏览器依然会以默认规则发送请求:
  ①IE6~8中只有img元素会出问题:IE会将img的空地址解析为当前页面地址的目录地址并请求。
   如当前网页地址为http://aaa.com/bb/c.html,img的地址会被解析为http://aaa.com/bb
  ②早些版本的Webkit和Firefox会将空连接解析为当前页面的地址。在ios与android中此问题较严重。
   如果页面有多个空连接属性元素,会增加服务器的请求次数。
  ③幸运的是,主流浏览器对iframe的src属性值为空时,会解析为about:blank地址,而不发送额外请求。

三、避免节点深层级嵌套
  层级越深的节点在初始化构建时,所占内存越多。
  通过浏览器HTML解析器会将整个HTML文档的结构存储为DOM树结构。当节点嵌套层次越深,构建的DOM书层次也越深。

四、缩减HTML文档大小
  ①删除对执行结果无影响的空格空行和注释;
  ②避免table布局;
  ③使用HTML5;

五。显式指定文档字符集
  在HTML页面开时指定字符集有助于浏览器立即开始解析HTML代码。
  HTML文档通常被解析为一序列的带字符集编码信息的字符串,通过Internet传送。
  字符集编码在HTTP响应头中,或HTML标记中指定。浏览器通过指定的字符集,吧编码解析为可现实在屏幕上的字符。
  若浏览器无法获知页面的编码字符集,一般会在执行脚本和渲染页面之前,先将字节流缓存,再搜索可进行解析的字符集 或 以默认字符集来解析。

六、显示设置图片的宽高
  有时需要在页面加载完之前,就对页面布局进行定位。
  若页面中的图片没指定尺寸,或尺寸与实际图片大小不符,浏览器会在图片下载完成后再"回溯"该图片并重新显示,从而浪费时间。
  故最好为页面的图片设置指定尺寸(行内样式或CSS样式)。

<img src="hello.png" width="400" height="300">

七、避免 脚本阻塞加载
  浏览器在解析常规script标签时,会等待script下载完毕后,才解析执行,之后的HTML代码就只能等待。
  故应该将脚本放在文档的末尾:

 <script src="example.js" ></script>
 </body>

高性能CSS

一、避免使用@import
  CSS2.1加入的@import,会使页面在加载时添加额外延迟。
  由于浏览器不能并行下载样式,会导致页面增添额外的往返耗时。而使用<link>能并行下载样式,但任然是多次请求。

二、避免AlphaImageLoader滤镜
  此滤镜能解决IE6即一下版本显示PNG图片的半透明效果,但会在加载图片时终止内容的呈现,并冻结浏览器。
  在每个元素(不仅仅是图片)都会运算一次,添加内存开支。
  应使用PNG8格式来代替,或用下划线(_filter)只针对IE6。

三、避免CSS表达式
  CSS表达式是设置动态CSS属性的即强调又危险的方法。IE5开始支持,IE独有。

//实现每隔一小时切换一次背景颜色
background-color: expression((new Date()).getHours()%2?"#FFFFFF": "#000000" );

  CSS表达式的缺点是技术频率极大,在页面显示、缩放、滚动 或 移动鼠标,都会重新计算一次。移动随便会达到1w次以上的计算量。
  ①使用一次性的表达式能减少计算次数,在第一次运行时将结果赋给指定样式属性,并用该属性代替CSS表达式。
  ②如果样式属性必须在页面周期内动态地改变,使用时间句柄代替CSS表达式是一个可行的办法。

四、避免通配选择器
  优化选择器的原则是减少匹配时间。CSS选择器的匹配机制是:从右向左进行规制匹配的!
    #header > a { font-weight:blod; }
      上面这条规制实际是浏览器遍历页面所有a元素,并确定其父元素的id是否为header。
    #header  a {...}
      后代选择器开销更大,在遍历页面的所有a元素后,会需向上遍历直到根节点。

  由此可知,选择器最右边的规制 往往决定了向左移匹配的工作量。故最右边的选择规则 称之为关键选择器。
    .selected * {...}
      在匹配所有元素后,再分别向上匹配直至根节点。通常比开销最小的ID选择器高出·~3个数量级。

五、避免单规则的属性选择器
  .selected [href=‘#index‘] {...}
    浏览器先匹配所有的元素,检查其是否有href属性并且值为“#index”,再分别向上匹配class为selected的元素。
  故应该避免使用关键选择器是单规则属性选择器的规则。

六、避免正则的属性选择器
  CSS3添加了复杂的属性选择器,通过类正则表达式进行匹配。但这些类型的选择器会比基于类别的匹配慢很多。

七、移除无匹配的样式
  ①删除无用的样式,可缩减样式文件大小,加快加载速度。
  ②对于浏览器,所有样式规则都会被解析后索引起来,即使是当前页面无匹配的规则!故移除无匹配的规则,减少索引项,加快浏览器查找速度。

高性能JavaScript

一、使用事件代理
  当过多的时间句柄被频繁触发时,页面反应会迟钝。
  如一个div有10个按钮,只需给div附加一次事件句柄,而不必给每个按钮添加一个句柄。
    事件冒泡时刻捕捉到事件 并判断时那个事件发出的。【触发事件的元素 = ev.srcElement ? ev.srcElement : ev.target;】

二、缓存选择器查询结果
  减少选择器查询的次数,并尽可能缓存选中的结果,便于以后的重用。

jQuery(‘#top‘).find(‘p.classA‘);
...
jQuery(‘#top‘).find(‘p.classB‘);

//使用下面的方法 减少开销
var cached = jQuery(‘#top‘);
cached.find(‘p.classA‘);
...
cached.find(‘p.classB‘);

三、避免频繁的IO操作
  应减少对cookie或localstorage的操作,因为对它们进行操作的API是同步的,而它们是多个tab页面间共享的。
  多页面同时操作cookie和localstorage时,会存在同步加锁机制。

四、避免频繁的DOM操作
  JavaScript访问DOM元素缓慢,应做到:
  ①缓存已经查询过的元素;
  ②线下更新完节点之后,在将它们添加到文档树中;
  ③避免使用JavaScript来修改页面布局。

五、使用微类库
  尽量避免使用大而全的类库,而是按需使用微类库来辅助开发。

时间: 2024-11-03 05:44:19

Web前端,高性能优化的相关文章

web前端性能优化——干货

web前端性能优化 2017-05-23 服务器--分析工具:YSlow 1.多台服务器--服务器集群(应用服务器): 2.负载均衡 服务器:接受请求,分配服务器: 3.数据库(读:写=7:3),主服务器(读)<---->缓存服务器<---->从服务器(写)分离. 注:可以参考:李智慧的<大型网站架构演化发展历程> 网页前端--可以参考<高性能网站建设(进阶)指南> 1.减少HTTP请求,图片地图,合并脚本和样式表 2.使用内容发布网络--CDN.CDN:C

Web前端性能优化的9大问题

1.请减少HTTP请求基本原理: 在浏览器(客户端)和服务器发生通信时,就已经消耗了大量的时间,尤其是在网络情况比较糟糕的时候,这个问题尤其的突出. 一个正常HTTP请求的流程简述:如在浏览器中输入"www.xxxxxx.com"并按下回车,浏览器再与这个URL指向的服务器建立连接,然后浏览器才能向服务器发送请求信息,服务器在接受到请求的信息后再返回相应的信息,浏览器接收到来自服务器的应答信息后,对这些数据解释执行. 而当我们请求的网页文件中有很多图片.CSS.JS甚至音乐等信息时,将

WEB前端性能优化小结

1. 请减少HTTP请求 基本原理: 在浏览器(客户端)和服务器发生通信时,就已经消耗了大量的时间,尤其是在网络情况比较糟糕的时候,这个问题尤其的突出. 一个正常HTTP请求的流程简述:如在浏览器中输入"www.xxxxxx.com"并按下回车,浏览器再与这个URL指向的服务器建立连接,然后浏览器才能向服务器发送请求信息,服务器在接受到请求的信息后再返回相应的信息,浏览器接收到来自服务器的应答信息后,对这些数据解释执行. 而当我们请求的网页文件中有很多图片.CSS.JS甚至音乐等信息时

WEB前端性能优化常见方法

web前端是应用服务器处理之前的部分,前端主要包括:HTML,CSS,javascript,image等各种资源,针对不同的资源有不同的优化方式. 1. 内容优化 (1)减少HTTP请求数:这条策略是最重要最有效的,因为一个完整的请求要经过DNS寻址,与服务器建立连接,发送数据,等待服务器响应,接收数据这样一个消耗时间成本和资源成本的复杂的过程. 常见方法:合并多个CSS文件和js文件,利用CSS Sprites整合图像,Inline Images(使用 data:URL scheme在实际的页

Web 前端性能优化相关内容解析

Web 前端性能优化相关内容,来源于<Google官方网页载入速度检测工具PageSpeed Insights 使用教程>一文中PageSpeed Insights 的相关说明.大家可以对照着去优化自己的网站或者相关项目.本文由Jeff 整理. 0.提高服务器的响应速度 砸钱的东西,但却最根本:搞好这一项,甚比下面任何一项. 1.优化样式表和脚本的排列顺序 正确地排列外部样式表与外部和内嵌脚本的顺序,可增加下载时同时加载的数据量,并提高浏览器显示网页的速度. 将样式表放在顶部,将脚本放在底部

Web 前端性能优化【转】

Web 前端性能优化是个大话题,是个值得运维人员持续跟踪的话题,是被很多网站无情忽视的技术. Web 前端优化最佳实践之 内容篇Web 前端优化最佳实践之 Server 篇Web 前端优化最佳实践之 Cookie 篇Web 前端优化最佳实践之 CSS 篇Web 前端优化最佳实践之 JavaScript 篇Web 前端优化最佳实践之 图象篇Web 前端优化最佳实践之 Mobile(iPhone) 篇 Yahoo! 的 Exceptional Performance team 在 Web 前端方面作

Web前端性能优化全攻略[转载]

1. 尽量减少  ">HTTP 请求 (Make Fewer  ">HTTP Requests) 作为第一条,可能也是最重要的一条.根据 Yahoo! 研究团队的数据分析,有很大一部分用户访问会因为这一条而取得最大受益.有几种常见的方法能切实减少  ">HTTP 请求: 1) 合并文件,比如把多个  ">CSS 文件合成一个: 2)  ">CSS Sprites 利用  ">CSS background 相关元

Web前端性能优化全攻略

网页制作poluoluo文章简介:Web 前端性能优化是个大话题,是个值得运维人员持续跟踪的话题,是被很多网站无情忽视的技术. Web 前端性能优化是个大话题,是个值得运维人员持续跟踪的话题,是被很多网站无情忽视的技术. Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的贡献.广为人知的优化规则也由 13 条到 14 条,再到 20 条,乃至现在的 34 条--真是与时俱进啊.最新的 34 条也针对不同的角度做了分类. 面向内容的优化规则

阿里巴巴 web前端性能优化进阶路

Web前端性能优化WPO,相信大多数前端同学都不会陌生,在各自所负责的站点页面中,也都会或多或少的有过一定的技术实践.可以说,这个领域并不缺乏成熟技术理论和技术牛人:例如Yahoo的web站点性能优化黄金法则,以及大名鼎鼎的优化大师Steve Souders.本文并非一篇讨论性能优化技术方法的文章,而更多的是对中文站搜索List页面持续两年多的前端性能优化实践的思路总结.希望对正在从事这个领域研究的前端同学能有所帮助. 简单的说,我们的性能优化实践分为三个阶段:初探期.立规期.创新期, 每个阶段

Web 前端性能优化相关内容解析[转]

Web 前端性能优化相关内容,来源于<Google官方网页载入速度检测工具PageSpeed Insights 使用教程>一文中PageSpeed Insights 的相关说明.大家可以对照着去优化自己的网站或者相关项目.本文由Jeff 整理. 0.提高服务器的响应速度 砸钱的东西,但却最根本:搞好这一项,甚比下面任何一项. 1.优化样式表和脚本的排列顺序 正确地排列外部样式表与外部和内嵌脚本的顺序,可增加下载时同时加载的数据量,并提高浏览器显示网页的速度. 将样式表放在顶部,将脚本放在底部