前言

最后更新于:2022-04-02 01:03:35

> 原文:[公众号coding.js](http://mp.weixin.qq.com/s?__biz=MjM5Mzc0MDAwNw==&mid=212340809&idx=1&sn=6d1b294f7f3c03907e68227d05920416#wechat_redirect) ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-10-27_562ee2c86dc90.jpg) 如今,互联网上的内容越来越丰富,过去几年时间,一个页面产生请求和整个大小都一直增长,这个趋势还会一直保持,对页面性能优化也要马不停蹄。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-10-27_562ee2c887ded.jpg) 一个页面,会经历过加载资源,执行脚本,渲染界面的过程。我们知道,100ms对于计算机来说,可以干很多事情了,但是对于网络请求,可能一次RTT就没了。因此,页面加载对于Web性能是重中之重。 加载的快慢可以总结成受两个因素影响:**阻塞**与**延迟**。 **1、阻塞。**浏览器在解析到脚本时,会阻塞页面,等到脚本下载执行完才继续解析文档。此外,浏览器还会限制同域下的并行请求数,超过这个限制后的请求就会被阻塞住。 **2、延迟。**网络请求都不可避免会有延迟,网页上的延迟有两种,一是DNS查询,二是TCP连接。 克服这些缺点,我们有一些约定俗成的方案: * 静态资源要支持304,开启HTTP缓存控制 * 开启gzip,压缩HTTP body * css放在html的head里,js在body底部 * 合并请求 * 使用雪碧图 * 域名分区(突破并行限制,也避免传输过多cookie) * 使用cdn 这些方案基本都能立竿见影。但是,对于追求极致(KPI)的我们,这些还是远远不够的。我们从页面开始加载时说起。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-10-27_562ee2c89313d.jpg)
';