前端性能优化——个人搜集总结

供自己深思熟虑~

1. 查询Cache：读取Cache 或者发送304请求——浏览器预处理

查询DNS：减少DNS查找，DNS缓存 浏览器DNS缓存 计算机DNS缓存 服务器DNS缓存（TTL） 使用Keep-Alive特性 减少DNS查找 当客户端的DNS缓存为空时，DNS查找的数量与Web页面中唯一主机名的数量相等。减少唯一主机名的数量就可以减少DNS查找的数量。较少的域名来减少DNS查找（2-4个主机）

页面静态化,动态网站的话考虑才去伪静态处理；

减少HTTP请求——使用css sprite（雪碧图）【图片整合/压缩】，减少加载图片时发出的HTTP请求，js文件（不超过7个），数据文件js（1-2个），频道公用js(1个）和页面私有js（1-2个），css文件不超过4个，各频道首页和全站首页不超过3个。

避免无效链接

避免在页面加载的时候，使用js进行也难元素的改动，因为这样的话再渲染页面完毕后，接着js执行，会再次渲染HTML页面；

禁止使用iframe引入外部资源，不包括allyes广告，不包括about:blank的空页面。。搜索引擎不友好、 即时内容为空，加载也需要时间、会阻止页面加载。

<iframe>

的缺点：即时内容为空，加载也需要时间 .会阻止页面加载

没有语意

避免重定向，在重定向完毕并且HTML下载完毕之前，是没有任何东西显示给用户的

精简js以及css，从代码中移除不必要的字符以减少其大小，减少加载时间。

尽量缩减页面大小

使用外部的Js和Css文件，比如百度的CDN加速等

将样式表放在顶部

建议将脚本放在底部

移除重复脚本

避免CSS表达式，发生计算时，会影响页面渲染速度

优化图像，尽量使用GIF和PNG，png的图片优先，但是必须注意如要兼容IE6，则png使用一定要注意透明问题。

可缓存的AJAX

推迟加载内容，拿瀑布流【延迟加载/懒加载】来举栗子~首先显示一部分内容，当用户需要更多的数据时，鼠标滚轮向下滚动，继续加载一部分页面。不需要的内容不用展示，需要时在进行加载

预加载 ，预加载是在浏览器空闲时请求将来可能会用到的页面内容（如图像、样式表和脚本）。几种加载的方式：

1. 无条件的加载
2. 有条件加载
3. 有预期的加载

减少DOM元素数量

个复杂的页面意味着需要下载更多数据，同时也意味着JavaScript遍历DOM的效率越慢。

根据域名划分页面内容,把页面内容划分成若干部分可以使你最大限度地实现平行下载。由于DNS查找带来的影响你首先要确保你使用的域名数量在2个到4个之间。

不要出现404错误

*为文件头指定Expires或Cache-Control ,对于静态内容：设置文件头过期时间Expires的值为“Never expire”（永不过期）

对于动态内容：使用恰当的Cache-Control文件头来帮助浏览器进行有条件的请求*

配置ETagEntity tags（ETags）（实体标签）是web服务器和浏览器用于判断浏览器缓存中的内容和服务器中的原始内容是否匹配的一种机制（“实体”就是所说的“内容”，包括图片、脚本、样式表等）。增加ETag为实体的验证提供了一个比使用“last-modified date（上次编辑时间）”更加灵活的机制。Etag是一个识别内容版本号的唯一字符串。唯一的格式限制就是它必须包含在双引号内。原始服务器通过含有ETag文件头的响应指定页面内容的ETag。

使用GET来完成AJAX请求

使用外部JavaScript和CSS

用

<link>

代替@import

避免使用滤镜

把脚本置于页面底部

减小Cookie体积

对于页面内容使用无coockie域名

当浏览器在请求中同时请求一张静态的图片和发送coockie时，服务器对于这些coockie不会做任何地使用。因此他们只是因为某些负面因素而创建的网络传输。所有你应该确定对于静态内容的请求是无coockie的请求。创建一个子域名并用他来存放所有静态内容。

不要在HTML中缩放图像

不要为了在HTML中设置长宽而使用比实际需要大的图片。如果你需要：

<img width="100" height="100" src="mycat.jpg" alt="My Cat" />

那么你的图片（mycat.jpg）就应该是100x100像素而不是把一个500x500像素的图片缩小使用。

favicon.ico要小而且可缓存

保持单个内容小于25K

这条限制主要是因为iPhone不能缓存大于25K的文件。注意这里指的是解压缩后的大小。由于单纯gizp压缩可能达不要求，因此精简文件就显得十分重要。

打包组件成复合文本

避免使用 eval和 Function，每次 eval 或 Function 构造函数作用于字符串表示的源代码时，脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢 100倍以上。val 函数效率特别低，由于事先无法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器无法优化上下文，因此只能有浏览器在运行时解释代码。这对性能影响很大。Function 构造函数比 eval略好，因为使用此代码不会影响周围代码 ;但其速度仍很慢。

慎用 with

慎用字符串拼接

base64 url技术

CSS3 font-face技术 – 纯色图标大小以及颜色可以随意控制，增强复用

localStorage本地存储与优化。

图片/广告位的显屏加载，也就是滚动显示加载

无关紧要资源避开加载渲染高峰显示，例如外站iframe等载入完毕后1秒再DOM创建载入处理（例如嵌入的新浪微博）。