切图崽的自我修养－提高项目加载速度

前言

我的项目没问题，是用户的网络环境不够好

前端作为一个最贴近用户的技术工种，毫无疑问应该把户体验放在第一位. 而用户体验，基本正比于页面的打开速度，特别是做移动端的同学，所以如何优化自己的项目，提高页面的加载速度成为重中之重.

---

资源的下载及解析

对前端同学来说，弄清楚页面上资源的下载和解析顺序是及其重要的，知道了它们的加载顺序，就知道对于特定的场景，应该如何去优化. 一般来说，页面上的资源无非这么几种:

• Html

• Css

• Js

• Img

---

资源加载的特性

• Html: 边下载边解析，最终形成DOM树

• Css: 边下载边解析，解析成css树，并且每加载一个新的css文件，都会重新整合之前下载的css生成新Css树，最终构建完的css树会和DOM树结合成Render树，并被浏览器渲染

• JS: 下载完再立即逐行解析执行

• Img: 当HTML解析到<img>等标签的时候会像服务器发起下载对应img的请求，下载是并行的

---

资源加载的相互影响

那么各资源的下载和解析对其他的资源的下载和解析是否存在影响呢？

• Html: Html不管是下载还是解析都不会影响后续资源的下载和解析，当自身解析到link标签时，会并行下载css资源. 解析到img标签时，会并行下载img资源

• Css: Css的下载不会影响后续资源的下载和解析，Css的解析虽然不会影响到后续资源的下载，但会影响到后续资源的解析

• Js: Js无论是下载还是解析都会阻塞后续资源的下载及解析

• Img: Img的下载和呈现对后续资源的下载和解析无影响

( 特别注意，是"后续资源" )

---

罪魁祸首

从上我们可以知道，资源的相互阻塞主要来自于css和js

• 首先是js, 只要html解析到了script标签，就开始下载js，这个标签后的所有资源的下载和解析全部停滞. js下载完成之后，会立刻执行，执行的时候，同样会堵塞后续资源的下载和执行.直到该js执行完成 (原因在于js可能会改变dom结构和css属性导致重绘，所以在js下载和执行的时候对对后续的dom的建立显得很没必要)

• 然后是css, css解析的时候，会阻碍后续所有资源的解析.特别是js, js虽然是下载完就立刻执行，但其实它必须要等到它之前的css全部解析完毕之后才能解析.

所以我们可以看出来，Css和Js都会影响到后续文件的下载和解析

---

优化目标

当用户能够在1-2秒内打开页面，看到信息的展示，或者能够开始进行下一步的操作，用户会感觉速度还好，可以接受. 而页面如果在2-5秒后才进入可用的状态，用户的耐心会逐渐丧失. 而如果一个界面超过5秒甚至更久才能显示出来，这对用户来说基本是无法忍受的，也许有一部分用户会退出重新进入，但更多的用户会直接放弃使用。

对于页面呈现来说，不管是pc端还是移动端，最最重要一点是能让用户尽可能快的看到尽可能多的样式和内容. 所以业界有了所谓1秒钟法则:

2g网络：1秒内完成dns查询、和后台服务器建立连接
3g网络：1秒内完成首字显示（首字时间）
wifi网络：1秒内完成首屏显示（首屏时间）

---

优化措施

我们想让用户尽快地看到尽可能多的内容和样式，除了保证各加载资源在满足需求的情况下体积尽可能的小，还要保证各资源正确的加载顺序，防止资源的相互阻塞:

1. 减少html中不必要的标签(比如div, 加快dom树的生成)

2. 把css放在头部(以便能够更快的生成css树，从而尽快地dom树结合成render树，从而能够以最快的速度被浏览器渲染出来)

3. js放在尾部(或者用 window.onload 等到页面完全加载完成之后再执行)

4. 减少资源文件大小(压缩img,css,js)

5. 将大img切成多份小img加快加载速度(由于img是并行加载)

同时，由于在http请求的发送和回应上会消耗很大一部分时间，所以如何尽量减少 http请求也是优化的大头:

1. 合并css文件

2. 打包合并js文件

3. 采用sprite合成img

---

结语

总之，优化是一个很好的习惯. 但是，从工程的角度来讲，过度优化有时会造成很高昂的代价. 所以，一个好的工程师，不仅仅知道该怎么优化，更重要的是知道这里该不该优化.

以上是从一些很通用且浅显的角度来分析如何优化自己的项目.后续会慢慢讲到更多的优化技巧，比如js的延迟加载，按需加载等等，敬请期待