前端性能优化方案索引

前端性能优化方案索引

陆续整理和不断更新网络上给出的前端性能的优化方案。

这里只是作一个总归纳式的索引，每个方案都十分值得推敲和细说。

1 请求和响应

缓存控制

请求头里，能够发送 If-Modified-Since 以及 If-None-Match 等信息，来询问服务端请求内容是否有更新，若是没有更新，可返回304，告诉浏览器使用缓存，避免从新下载资源。Pragma 和 Cache-Control 等也能控制缓存。如告诉服务端不要缓存等。

响应头里，Expires 能够告诉浏览器过时时间，Last-Modified 最近更新时间，ETag 则可容许浏览器进行缓存验证（在 If-None-Match 请求信息中使用）。

复用TCP

请求头里，Connection 可控制 TCP 通道的使用，使用 keep-alive 能够复用上次打开的 TCP。

GZIP压缩

若是能够启用 gzip 压缩，将减小响应数据大小，加快响应。请求头里面可用 Accept-Encoding 告知浏览器支持的压缩方式，而服务端则用 Content-Encoding 做为回应。

Cookies

发送请求时，cookies 也在请求之中。所以，cookies 也能够做为减小请求的优化对象。如，根据同源限制策略，可使用多个域名加载资源，如加载静态资源，就不会发送多余的 cookies；同时，合理设置 cookies 的路径和域名，如在子站避免没必要要的来自父站的 cookies。

减小HTTP请求

有不少细节能够实现，好比CSS Sprites、Data URL等等，因为此部份内容和下述内容有所重复，故部分细节在下面会讲到。

多域名分发

同域下浏览器能并发的请求有限，而为了增长并发，尤为是一些静态资源上，可使用多个域名。但因为域名DNS解析自己也是耗时的，因此实践原则是2-4个为宜。

须要额外提醒的是，加载图像资源的时候，并发没有问题；但在加载 JavaScript 脚本的时候，仍是会暂停加载其余资源。

使用CDN

根据用户能访问的最快位置加速访问。

避免重定向和404

重定向和404将浪费加载请求。

favicon.ico

浏览器默认加载的资源，最好可以缓存之。

2 HTML

减小DOM

过多的DOM元素会影响渲染、加载、执行。除了精简页面结构外，还能够适时删除没必要要的DOM元素（页面内已经不会再访问的元素），又或者能够懒加载（不必定会使用到的元素，如登陆框）。

CSS 和 JavaScript 文件位置

CSS 放 head，JavaScript 放 body 闭标签前。乃是由于：

• 样式表不参与 DOM 修改，因此不会为了解析样式中止文档解析

• 浏览器要避免重绘，在没有拿到所有样式前不会开始渲染

• 解析样式时，有的浏览器（FF）会中止脚本运行，而有的（Webkit）则会在脚本访问样式属性但可能受未加载样式影响时中止脚本运行

• 脚本解析中可能请求样式，若是样式还未解析完毕就会出错

• 脚本执行将暂停文档的解析和资源的下载

所以，将两者放在适当的位置，可以极大提升渲染效率。

脚本延迟加载

可将脚本添加 defer 和 async 属性。两个属性的共通点在于，脚本的加载和文档的解析是同步进行的，而区别在于：async 一旦加载完毕，当即中止文档解析并执行脚本；defer 等待文档解析完毕后再执行。

合理使用内联

脚本和样式，应按需选择内联或者外链。对于访问少、样式和脚本复用少的页面，能够考虑使用内联样式从而减小 HTTP 请求。但若是页面访问频繁，样式脚本在多个页面常常复用，使用外链则是最优选择。

不管如何，须要避免使用 @import 来导入样式。

而图像也是同样，高级浏览器支持将图像数据直接 base64 编码在 src 属性里，必要时可直接在 HTML 里输出图片数据。

减小iframe

iframe 自己有许多优势，好比能够并行下载脚本，适合加载慢内容（如广告），同时浏览器能够对其进行安全控制。

减小使用 iframe 的主要考虑是：iframe 会阻碍页面加载，同时也没有语义。

3 CSS

选择器

选择器效率排行以下：

1. ID选择器

2. 类选择器

3. 标签选择器

4. 相邻选择器

5. 子选择器

6. 后代选择器

7. 通配符选择器

8. 属性选择器

9. 伪类选择器

效率与优先级并非对等关系，优先级高的不必定效率高。如 #id.class 合用比 单个 #id 的优先级高，但效率却比值慢。

选择器书写建议是：

1. 避免使用通配符

2. 不使用标签名或类名修饰ID规则：若是规则使用ID选择器做为关键选择器，不要给规则添加标签名。由于ID自己就是惟一的，添加标签名会没必要要地下降匹配效率

3. 不使用标签名修饰类：相较于标签，类更具独特性

4. 尽可能选择最具体的方式：形成低效的最简单粗暴的缘由就是在标签上使用太多规则。给元素添加类能够更快细分到类方式，能够减小规则去匹配标签的时间

5. 关于后代选择器和子选择器：避免使用后代选择器，非要用的话建议用子选择器代替，但子选择器也要慎用，标签规则永远不要包含子选择器

6. 利用可继承性：不必在通常内容上声明样式

避免滤镜、表达式、Hack

效率低。

Sprites

合并图片可减小 HTTP 请求。其余建议有：

1. Sprite 中水平排列图片，垂直排列会增长文件大小

2. Sprite 中把颜色较近的组合在一块儿能够下降颜色数，理想情况是低于256色以便适用PNG8格式

3. 不要在Spirite的图像中间留有较大空隙。这虽然不大会增长文件大小,但对于用户代理来讲它须要更少的内存来把图片解压为像素地图。100×100的图片为1万像素，1000×1000就是100万像素

使用3D动画

使用 transform: translate3d 等可加速 GPU 渲染。

4 JavaScript

避免重排

渲染中可能存在的高成本操做：

1. 修改、增长、删除DOM节点

2. 移动DOM位置或者动画效果

3. CSS样式修改（重绘比重排好些）

4. 调整窗口大小，或者滚动时有绝对定位、fixed 背景以及动画

5. 修改页面默认字体

浏览器通常会缓存Render Tree的更新渲染，但如下状况除外：

1. 调整窗口大小和修改页面默认字体

2. client/offset/scroll

3. getComputedStyle() currentStyle

优化建议：

1. 修改 className 而非 style

2. 离线 DOM 后修改，如 documentFragment 或者 display:none 后再调整样式

3. 缓存属性值

4. 动画使用 absolute/fixed

5. 不使用 table 布局（牵一发动全身）

6. 修改层级比较低的 DOM

事件委托

将多个节点上的事件放到其父节点（经典案例：将 li 上的事件绑定到 ul 上）。

内存管理

合理释放和缓存内存。如缓存复用的属性，接触对象引用等。

5 资源

压缩大小

压缩样式、脚本、图像等资源的大小。

针对图像资源，可从预览小图、格式选择等多角度优化。

懒加载

如图像的懒加载（滚动到显示区域后才加载）等。

预加载

针对以后会用到的资源提早加载。

5 客户端

localStorage 缓存

相比 cookies，localStorage 存储容量更大。能够将一些静态资源（如 jQuery库）等缓存。