❶ 前端开发，页面优化，性能优化有哪些方面
常用的优化有两部分
第一：面向内容的优化
1. 减少 HTTP 请求
2. 减少 DNS 查找
3. 避免重定向
4. 使用 Ajax 缓存
5. 延迟载入组件
6. 预先载入组件
7. 减少 DOM 元素数量
8. 切分组件到多个域
9. 最小化 iframe 的数量
10. 不要出现http 404 错误
第二：面向 Server
1. 缩小 Cookie
2. 针对 Web 组件使用域名无关性的
❷ 前端性能优化的具体方法有哪些
解决办法一：
减少http请求次数：CSS Sprites, JS、CSS源码压缩、图片大小控制合适；网页Gzip，CDN托管，data缓存 ，图片服务器。
前端模板 JS+数据，减少由于HTML标签导致的带宽浪费，前端用变量保存AJAX请求结果，每次操作本地变量，不用请求，减少请求次数
用innerHTML代替DOM操作，减少DOM操作次数，优化javascript性能。
当需要设置的样式很多时设置className而不是直接操作style。
少用全局变量、缓存DOM节点查找的结果。减少IO读取操作。
避免使用CSS Expression（css表达式)又称Dynamic properties(动态属性)。
图片预加载，将样式表放在顶部，将脚本放在底部 加上时间戳。
解决办法二：
减少HTTP请求次数
使用CDN：CDN在前端开发的作用
避免空的src和href
为文件头指定Expires
使用gzip压缩内容
把CSS放到顶部
把JS放到底部
避 免使用CSS表达式
将CSS和JS放到外部文件中
避免跳转
可缓存的AJAX
使用GET来完成AJAX请求
❸ 如何进行前端优化
1.减少 HTTP 请求....
2.使用 HTTP2
3.使用服务端渲染
4.静态资源使用 CDN
5.将 CSS 放在文件头部，JavaScript 文件放 ...
6.使用字体图标 iconfont 代替图片图标
7.善用缓存，不重复加载相同的资源
8.压缩文件
9.图片优化
(1).图片延迟加载
(2). 响应式图片
(3). 调整图片大小
(4). 降低图片质量
(5). 尽可能利用 CSS3 效果代替图片
(6). 使用 webp 格式的图片
10. 通过 webpack 按需加载代码，提取第三库代码，减少 ES6 转为 ES5 的冗余代码
11. 减少重绘重排
12. 使用事件委托
13. 注意程序的局部性
14. if-else 对比 switch
15. 查找表
16. 避免页面卡顿
17. 使用 requestAnimationFrame 来实现视觉变化
18. 使用 Web Workers
19. 使用位操作
20. 不要覆盖原生方法
21. 降低 CSS 选择器的复杂性
(1). 浏览器读取选择器，遵循的原则是从选择器的右边到左边读取。
(2). CSS 选择器优先级
22. 使用 flexbox 而不是较早的布局模型
23. 使用 transform 和 opacity 属性更改来实现动画
24. 合理使用规则，避免过度优化
性能优化主要分为两类：
加载时优化
运行时优化
❹ 常见的前端性能优化手段都有哪些都有多大收益
前端是庞大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各种各样的资源。前端优化是复杂的，针对方方面面的资源都有不同的方式。那么，前端优化的目的是什么 ?
1. 从用户角度而言，优化能够让页面加载得更快、对用户的操作响应得更及时，能够给用户提供更为友好的体验。
2. 从服务商角度而言，优化能够减少页面请求数、或者减小请求所占带宽，能够节省可观的资源。
总之，恰当的优化不仅能够改善站点的用户体验并且能够节省相当的资源利用。
前端优化的途径有很多，按粒度大致可以分为两类，第一类是页面级别的优化，例如 HTTP请求数、脚本的无阻塞加载、内联脚本的位置优化等 ;第二类则是代码级别的优化，例如 Javascript中的DOM 操作优化、CSS选择符优化、图片优化以及 HTML结构优化等等。另外，本着提高投入产出比的目的，后文提到的各种优化策略大致按照投入产出比从大到小的顺序排列。
一、页面级优化
1. 减少 HTTP请求数
这条策略基本上所有前端人都知道，而且也是最重要最有效的。都说要减少 HTTP请求，那请求多了到底会怎么样呢 ?首先，每个请求都是有成本的，既包含时间成本也包含资源成本。一个完整的请求都需要经过 DNS寻址、与服务器建立连接、发送数据、等待服务器响应、接收数据这样一个 “漫长” 而复杂的过程。时间成本就是用户需要看到或者 “感受” 到这个资源是必须要等待这个过程结束的，资源上由于每个请求都需要携带数据，因此每个请求都需要占用带宽。另外，由于浏览器进行并发请求的请求数是有上限的 (具体参见此处 )，因此请求数多了以后，浏览器需要分批进行请求，因此会增加用户的等待时间，会给用户造成站点速度慢这样一个印象，即使可能用户能看到的第一屏的资源都已经请求完了，但是浏览器的进度条会一直存在。
减少 HTTP请求数的主要途径包括：
(1). 从设计实现层面简化页面
如果你的页面像网络首页一样简单，那么接下来的规则基本上都用不着了。保持页面简洁、减少资源的使用时最直接的。如果不是这样，你的页面需要华丽的皮肤，则继续阅读下面的内容。
(2). 合理设置 HTTP缓存
缓存的力量是强大的，恰当的缓存设置可以大大的减少 HTTP请求。以有啊首页为例，当浏览器没有缓存的时候访问一共会发出 78个请求，共 600多 K数据 (如图 1.1)，而当第二次访问即浏览器已缓存之后访问则仅有 10个请求，共 20多 K数据 (如图 1.2)。 (这里需要说明的是，如果直接 F5刷新页面的话效果是不一样的，这种情况下请求数还是一样，不过被缓存资源的请求服务器是 304响应，只有 Header没有Body ，可以节省带宽 )
怎样才算合理设置 ?原则很简单，能缓存越多越好，能缓存越久越好。例如，很少变化的图片资源可以直接通过 HTTP Header中的Expires设置一个很长的过期头 ;变化不频繁而又可能会变的资源可以使用 Last-Modifed来做请求验证。尽可能的让资源能够在缓存中待得更久。关于 HTTP缓存的具体设置和原理此处就不再详述了，有兴趣的可以参考下列文章：
HTTP1.1协议中关于缓存策略的描述
Fiddler HTTP Performance中关于缓存的介绍
(3). 资源合并与压缩
如果可以的话，尽可能的将外部的脚本、样式进行合并，多个合为一个。另外， CSS、 Javascript、Image 都可以用相应的工具进行压缩，压缩后往往能省下不少空间。
(4). CSS Sprites
合并 CSS图片，减少请求数的又一个好办法。
(5). Inline Images
使用 data: URL scheme的方式将图片嵌入到页面或 CSS中，如果不考虑资源管理上的问题的话，不失为一个好办法。如果是嵌入页面的话换来的是增大了页面的体积，而且无法利用浏览器缓存。使用在 CSS中的图片则更为理想一些。
(6). Lazy Load Images（自己对这一块的内容还是不了解）
这条策略实际上并不一定能减少 HTTP请求数，但是却能在某些条件下或者页面刚加载时减少 HTTP请求数。对于图片而言，在页面刚加载的时候可以只加载第一屏，当用户继续往后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。 有啊首页 曾经的做法是在加载的时候把第一屏之后的图片地址缓存在 Textarea标签中，待用户往下滚屏的时候才 “惰性” 加载。
2. 将外部脚本置底（将脚本内容在页面信息内容加载后再加载）
前文有谈到，浏览器是可以并发请求的，这一特点使得其能够更快的加载资源，然而外链脚本在加载时却会阻塞其他资源，例如在脚本加载完成之前，它后面的图片、样式以及其他脚本都处于阻塞状态，直到脚本加载完成后才会开始加载。如果将脚本放在比较靠前的位置，则会影响整个页面的加载速度从而影响用户体验。解决这一问题的方法有很多，在 这里有比较详细的介绍 (这里是译文和 更详细的例子 )，而最简单可依赖的方法就是将脚本尽可能的往后挪，减少对并发下载的影响。
3. 异步执行 inline脚本(其实原理和上面是一样，保证脚本在页面内容后面加载。)
inline脚本对性能的影响与外部脚本相比，是有过之而无不及。首页，与外部脚本一样， inline脚本在执行的时候一样会阻塞并发请求，除此之外，由于浏览器在页面处理方面是单线程的，当 inline脚本在页面渲染之前执行时，页面的渲染工作则会被推迟。简而言之， inline脚本在执行的时候，页面处于空白状态。鉴于以上两点原因，建议将执行时间较长的 inline脚本异步执行，异步的方式有很多种，例如使用 script元素的defer 属性(存在兼容性问题和其他一些问题，例如不能使用 document.write)、使用setTimeout ，此外，在HTML5中引入了 Web Workers的机制，恰恰可以解决此类问题。
4. Lazy Load Javascript（只有在需要加载的时候加载，在一般情况下并不加载信息内容。）
随着 Javascript框架的流行，越来越多的站点也使用起了框架。不过，一个框架往往包括了很多的功能实现，这些功能并不是每一个页面都需要的，如果下载了不需要的脚本则算得上是一种资源浪费 -既浪费了带宽又浪费了执行花费的时间。目前的做法大概有两种，一种是为那些流量特别大的页面专门定制一个专用的 mini版框架，另一种则是 Lazy Load。YUI 则使用了第二种方式，在 YUI的实现中，最初只加载核心模块，其他模块可以等到需要使用的时候才加载。
5. 将 CSS放在 HEAD中
如果将 CSS放在其他地方比如 BODY中，则浏览器有可能还未下载和解析到 CSS就已经开始渲染页面了，这就导致页面由无 CSS状态跳转到 CSS状态，用户体验比较糟糕。除此之外，有些浏览器会在 CSS下载完成后才开始渲染页面，如果 CSS放在靠下的位置则会导致浏览器将渲染时间推迟。
6. 异步请求 Callback（就是将一些行为样式提取出来，慢慢的加载信息的内容）
在某些页面中可能存在这样一种需求，需要使用 script标签来异步的请求数据。类似：
Javascript:
function myCallback(info){
//do something here
}
HTML:
cb返回的内容 :
myCallback('Hello world!');
像以上这种方式直接在页面上写 <script>对页面的性能也是有影响的，即增加了页面首次加载的负担，推迟了 DOMLoaded和window.onload 事件的触发时机。如果时效性允许的话，可以考虑在 DOMLoaded事件触发的时候加载，或者使用 setTimeout方式来灵活的控制加载的时机。
7. 减少不必要的 HTTP跳转
对于以目录形式访问的 HTTP链接，很多人都会忽略链接最后是否带 ’/'，假如你的服务器对此是区别对待的话，那么你也需要注意，这其中很可能隐藏了 301跳转，增加了多余请求。具体参见下图，其中第一个链接是以无 ’/'结尾的方式访问的，于是服务器有了一次跳转。
8. 避免重复的资源请求
这种情况主要是由于疏忽或页面由多个模块拼接而成，然后每个模块中请求了同样的资源时，会导致资源的重复请求
二、代码级优化
1. Javascript
(1). DOM
DOM操作应该是脚本中最耗性能的一类操作，例如增加、修改、删除 DOM元素或者对 DOM集合进行操作。如果脚本中包含了大量的 DOM操作则需要注意以下几点：
a. HTML Collection（HTML收集器，返回的是一个数组内容信息）
在脚本中 document.images、document.forms 、getElementsByTagName()返回的都是 HTMLCollection类型的集合，在平时使用的时候大多将它作为数组来使用，因为它有 length属性，也可以使用索引访问每一个元素。不过在访问性能上则比数组要差很多，原因是这个集合并不是一个静态的结果，它表示的仅仅是一个特定的查询，每次访问该集合时都会重新执行这个查询从而更新查询结果。所谓的 “访问集合” 包括读取集合的 length属性、访问集合中的元素。
因此，当你需要遍历 HTML Collection的时候，尽量将它转为数组后再访问，以提高性能。即使不转换为数组，也请尽可能少的访问它，例如在遍历的时候可以将 length属性、成员保存到局部变量后再使用局部变量。
b. Reflow & Repaint
除了上面一点之外， DOM操作还需要考虑浏览器的 Reflow和Repaint ，因为这些都是需要消耗资源的，具体的可以参加以下文章：
如何减少浏览器的repaint和reflow?
Understanding Internet Explorer Rendering Behaviour
Notes on HTML Reflow
(2). 慎用 with
with(obj){ p = 1}; 代码块的行为实际上是修改了代码块中的 执行环境 ，将obj放在了其作用域链的最前端，在 with代码块中访问非局部变量是都是先从 obj上开始查找，如果没有再依次按作用域链向上查找，因此使用 with相当于增加了作用域链长度。而每次查找作用域链都是要消耗时间的，过长的作用域链会导致查找性能下降。
因此，除非你能肯定在 with代码中只访问 obj中的属性，否则慎用 with，替代的可以使用局部变量缓存需要访问的属性。
(3). 避免使用 eval和 Function
每次 eval 或 Function 构造函数作用于字符串表示的源代码时，脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢 100倍以上。
eval 函数效率特别低，由于事先无法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器无法优化上下文，因此只能有浏览器在运行时解释代码。这对性能影响很大。
Function 构造函数比 eval略好，因为使用此代码不会影响周围代码 ;但其速度仍很慢。
此外，使用 eval和 Function也不利于Javascript 压缩工具执行压缩。
(4). 减少作用域链查找（这方面设计到一些内容的相关问题）
前文谈到了作用域链查找问题，这一点在循环中是尤其需要注意的问题。如果在循环中需要访问非本作用域下的变量时请在遍历之前用局部变量缓存该变量，并在遍历结束后再重写那个变量，这一点对全局变量尤其重要，因为全局变量处于作用域链的最顶端，访问时的查找次数是最多的。
低效率的写法：
// 全局变量
var globalVar = 1;
function myCallback(info){
for( var i = 100000; i--;){
//每次访问 globalVar 都需要查找到作用域链最顶端，本例中需要访问 100000 次
globalVar += i;
}
}
更高效的写法：
// 全局变量
var globalVar = 1;
function myCallback(info){
//局部变量缓存全局变量
var localVar = globalVar;
for( var i = 100000; i--;){
//访问局部变量是最快的
localVar += i;
}
//本例中只需要访问 2次全局变量
在函数中只需要将 globalVar中内容的值赋给localVar 中区
globalVar = localVar;
}
此外，要减少作用域链查找还应该减少闭包的使用。
(5). 数据访问
Javascript中的数据访问包括直接量 (字符串、正则表达式 )、变量、对象属性以及数组，其中对直接量和局部变量的访问是最快的，对对象属性以及数组的访问需要更大的开销。当出现以下情况时，建议将数据放入局部变量：
a. 对任何对象属性的访问超过 1次
b. 对任何数组成员的访问次数超过 1次
另外，还应当尽可能的减少对对象以及数组深度查找。
(6). 字符串拼接
在 Javascript中使用"+" 号来拼接字符串效率是比较低的，因为每次运行都会开辟新的内存并生成新的字符串变量，然后将拼接结果赋值给新变量。与之相比更为高效的做法是使用数组的 join方法，即将需要拼接的字符串放在数组中最后调用其 join方法得到结果。不过由于使用数组也有一定的开销，因此当需要拼接的字符串较多的时候可以考虑用此方法。
关于 Javascript优化的更详细介绍请参考：
Write Efficient Javascript(PPT)
Efficient JavaScript
2. CSS选择符
在大多数人的观念中，都觉得浏览器对 CSS选择符的解析式从左往右进行的，例如
#toc A { color: #444; }
这样一个选择符，如果是从右往左解析则效率会很高，因为第一个 ID选择基本上就把查找的范围限定了，但实际上浏览器对选择符的解析是从右往左进行的。如上面的选择符，浏览器必须遍历查找每一个 A标签的祖先节点，效率并不像之前想象的那样高。根据浏览器的这一行为特点，在写选择符的时候需要注意很多事项，有人已经一一列举了， 详情参考此处。
3. HTML
对 HTML本身的优化现如今也越来越多的受人关注了，详情可以参见这篇 总结性文章 。
4. Image压缩
图片压缩是个技术活，不过现如今这方面的工具也非常多，压缩之后往往能带来不错的效果，具体的压缩原理以及方法在《 Even Faster Web Sites》第10 章有很详细的介绍，有兴趣的可以去看看。
总结
本文从页面级以及代码级两个粒度对前端优化的各种方式做了一个总结，这些方法基本上都是前端开发人员在开发的过程中可以借鉴和实践的，除此之外，完整的前端优化还应该包括很多其他的途径，例如 CDN、 Gzip、多域名、无 Cookie服务器等等，由于对于开发人员的可操作性并不强大，在此也就不多叙述了，详细的可以参考 Yahoo和Google 的这些“金科玉律。
❺ 前端如何做好网站性能优化
前端开发需要做的就是网站搭建。网站搭建有2个细节需要注意，一是排版，二是链接，排版是为了不让出现乱码而做细节优化，链接是为了优化网页之间的关系，就好比城镇建设，每一座城市都要搭建的好，城与城之间的交通也要完善，这样才有利于城区发展，网站也是一样，每个网页的内容和网页之间的链接做好，网站优化也就好做了。
❻ 前端性能优化什么意思
如果前端优化得好，他不仅可以为企业节约成本，他还能给用户带来更多的用户，因为增强的用户体验。说了这么多，那么我们应该如何对我们前端的页面进行性能优化呢？一般说来，web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN服务等，主要优化手段有浏览器访问、使用反向代理才、CDN等。
❼ 前端性能优化有哪些方法
图片雪花、懒加载、减少iframe的使用、js文件尽量放到最后加载
❽ 简单谈谈前端性能优化
这个话题，贼大。
个人认为：核心在于，HTTP 请求的减少和请求包大小的减少再加上对代码的重构。
HTTP 请求的减少，瞧瞧现在的前端工程化，工程化的作用之一正是将那些散乱的 js 、css 库全部都集成起来，压缩成一个文件，这么多文件压缩成一个，这请求不就减少了么~还有一个就是”精灵图技术“也是优化的体现，就不展开了。
请求包大小的减少，这个简直是能减就减啊，比如以前的时候，我们需要将图片直接发送到浏览器上是吧，现在可以不用！如果只是发生一段代码到客户的浏览器上，然后客户用自己的机器生成图片，这得有多快啊，毕竟一段代码大还是一张图片大还是很容易分清的，特别的是 GIF 图！这时候用上 svg 或是 canvas 技术，就不需要发送巨大的 GIF 图片了，只需要调用浏览器的资源生成图像即可。
重构，反正不满意重构就是了，满意了加功能然后继续重构就是了。
但这都是还只是皮毛啊这是，如果用到框架，那还要讲到框架的优化，因为前端框架的优化同样是性能优化，那都能写几十页了都......
如果再深入讲到浏览器自身......啊，要死了死了，技术是无穷的，命是有限的！
❾ 如何对前端性能进行优化
前端开发代码优化、可维护性、浏览器兼容性是非常重要的课题。从实际的工程应用角度出发，最常遇见的前端优化问题。前端性能进行优化规则，基本可以涵盖现在前端大部分的性能优化原则了，很多更加geek和精细优化方法都是从这些原则里面延伸出来的。
前端性能进行优化都有哪些规则
减少HTTP请求次数
尽量合并图片、CSS、JS。比如加载一个页面有5个css文件的话，把这个5个文件合成一个的话，就只需要发出一次http请求，节省网络请求时间，加快页面的加载。
2. 使用CDN
网站上静态资源即css、js全都使用cdn分发，包括图片
3. 避免空的src和href
当link标签的href属性为空、script标签的src属性为空的时候，浏览器渲染的时候会把当前页面的URL作为它们的属性值，从而把页面的内容加载进来作为它们的值。所以要避免犯这样的疏忽。
4. 为文件头指定Expires
Exipres是用来设置文件的过期时间的，一般对css、js、图片资源有效。 他可以使内容具有缓存性，这样下回再访问同样的资源时就通过浏览器缓存区读取，不需要再发出http请求。如下例子：
新浪微博的这个css文件的Expires时间是2016-5-04 09:14:14.
5. 使用gzip压缩内容
gzip能够压缩任何一个文本类型的响应，包括html，xml，json。大大缩小请求返回的数据量。
6. 把CSS放到顶部
网页上的资源加载时从上网下顺序加载的，所以css放在页面的顶部能够优先渲染页面，让用户感觉页面加载很快。
7. 把JS放到底部
加载js时会对后续的资源造成阻塞，必须得等js加载完才去加载后续的文件 ，所以就把js放在页面底部最后加载。
8. 避免使用CSS表达式
举个css表达式的例子
font-color: expression( (new Date()).getHours()%3 ? “#FFFFFF" : “#AAAAAA" );
这个表达式会持续的在页面上计算样式，影响页面的性能。并且css表达式只被IE支持。
9. 将CSS和JS放到外部文件中
目的是缓存文件，可以参考原则4。 但有时候为了减少请求，也会直接写到页面里，需根据PV和IP的比例权衡。
10. 权衡DNS查找次数
减少主机名可以节省响应时间。但同时，需要注意，减少主机会减少页面中并行下载的数量。
IE浏览器在同一时刻只能从同一域名下载两个文件。当在一个页面显示多张图片时，IE 用户的图片下载速度就会受到影响。所以新浪会搞N个二级域名来放图片。
下面是新浪微博的图片域名，我们可以看到他有多个域名，这样可以保证这些不同域名能够同时去下载图片，而不用排队。不过如果当使用的域名过多时，响应时间就会慢，因为不用响应域名时间不一致。
11. 精简CSS和JS
这里就涉及到css和js的压缩了。比如下面的新浪的一个css文件，把空格回车全部去掉，减少文件的大小。现在的压缩工具有很多，基本主流的前端构建工具都能进行css和js文件的压缩，如grunt，glup等。
12. 避免跳转
有种现象会比较坑爹，看起来没什么差别，其实多次了一次页面跳转。比如当URL本该有斜杠（/）却被忽略掉时。例如，当我们要访问http:// .com时，实际上返回的是一个包含301代码的跳转，它指向的是http:// .com/（注意末尾的斜杠）。在nginx服务器可以使用rewrite；Apache服务器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash来避免。
另一种是不用域名之间的跳转， 比如访问http:// .com/bbs跳转到http:// bbs..com/。那么可以通过使用Alias或者mod_rewirte建立CNAME（保存一个域名和另外一个域名之间关系的DNS记录）来替代。
13. 删除重复的JS和CSS
重复调用脚本，除了增加额外的HTTP请求外，多次运算也会浪费时间。在IE和Firefox中不管脚本是否可缓存，它们都存在重复运算JavaScript的问题。
14. 配置ETags
它用来判断浏览器缓存里的元素是否和原来服务器上的一致。比last-modified date更具有弹性，例如某个文件在1秒内修改了10次，Etag可以综合Inode(文件的索引节点(inode)数)，MTime(修改时间)和Size来精准的进行判断，避开UNIX记录MTime只能精确到秒的问题。 服务器集群使用，可取后两个参数。使用ETags减少Web应用带宽和负载
15. 可缓存的AJAX
异步请求同样的造成用户等待，所以使用ajax请求时，要主动告诉浏览器如果该请求有缓存就去请求缓存内容。如下代码片段, cache:true就是显式的要求如果当前请求有缓存的话，直接使用缓存
$.ajax({ url : 'url', dataType : "json", cache: true, success : function(son, status){ }
16. 使用GET来完成AJAX请求
当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，然后才发送数据。因此使用GET获取数据时更加有意义。
17. 减少DOM元素数量
这是一门大学问，这里可以引申出一堆优化的细节。想要具体研究的可以看后面推荐书籍。总之大原则减少DOM数量，就会减少浏览器的解析负担。
18. 避免404
比如外链的css、js文件出现问题返回404时，会破坏浏览器的并行加载。
19. 减少Cookie的大小
Cookie里面别塞那么多东西，因为每个请求都得带着他跑。
20. 使用无cookie的域
比如CSS、js、图片等，客户端请求静态文件的时候，减少了 Cookie 的反复传输对主域名的影响。
21. 不要使用滤镜
IE独有属性AlphaImageLoader用于修正7.0以下版本中显示PNG图片的半透明效果。这个滤镜的问题在于浏览器加载图片时它会终止内容的呈现并且冻结浏览器。在每一个元素（不仅仅是图片）它都会运算一次，增加了内存开支，因此它的问题是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式来代替，这种格式能在IE中很好地工作。如果你确实需要使用AlphaImageLoader，请使用下划线_filter又使之对IE7以上版本的用户无效。
22. 不要在HTML中缩放图片
比如你需要的图片尺寸是50* 50
那就不用用一张500*500的大尺寸图片，影响加载
23. 缩小favicon.ico并缓存