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

前言

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

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

---

资源的下载及解析

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

• 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的延迟加载，按需加载等等，敬请期待