[TOC] ## 突破单线程解析渲染阻塞限制 浏览器是一个单线程解析模式去解析渲染从服务器端拿到的html文本，css加载的过程中会对后续的脚本资源加载造成阻塞，脚本的加载也会阻塞后续DOM结构的解析造成页面的留白时间增长，雅虎的35条军规中有一条就是样式文件放在头部，脚本文件放在DOM节点最末尾，减少阻塞。 这里还有几个针对脚本文件的优化： * 针对不需要DOM操作（主要考虑是需要操作DOM的脚本往往需要获取一些样式信息）的Js脚本可以采用动态创建script的方式载入，动态载入的脚本不阻塞后续资源的加载。 * 脚本文件加载可以加上defer或者async属性标识防止阻塞 ## 避开Cookie性能bug Cookie是前端作为前后台登录态校验最通常用的缓存方案，但鉴于浏览器在每次都会往同域的任何资源的http请求中自动带上cookie信息的情况，这里有必要进行优化一下，因为像css、js、image这些资源请求是不需要cookie信息的，会无端造成请求带宽的浪费（想象一下我们的cookie大小假设为10K，100个请求就是近1M的大小，高并发下以我们现行网络带宽也是蛮大的一笔负担了）。Cookie free性能优化方案的处理方式是CDN异域静态资源服务器部署我们的前端css、js、image资源。 以香港跨境汇款为例  页面路径下的资源的请求：  CDN资源加载的请求：  ## 突破浏览器并发连接限制 浏览器针对domain,而非页面page做并发连接限制的特性，domain hash的技术优化方案的处理方式是将资源划分域分开部署，但因为过多的域划分会增加多余的DNS开销，这里通行的数量是3个以内。 ## 缓存 我们都知道，浏览器在向服务器发起请求前，会先查询本地是否有相同的文件，如果有，就会直接拉取本地缓存，这和我们在后台部属的Redis、Memcache类似，都是起到了中间缓冲的作用，我们先看看浏览器处理缓存的策略：  这里我们可以使用chrome devtools里的network面板查看网络传输的相关信息： （这里需要特别注意，在我们进行缓存调试时，需要去除network面板顶部的Disable cache 勾选项，否则浏览器将始终不会从缓存中拉取数据） 浏览器默认的缓存是放在内存内的，但我们知道，内存里的缓存会因为进程的结束或者说浏览器的关闭而被清除，而存在硬盘里的缓存才能够被长期保留下去。很多时候，我们在network面板中各请求的size项里，会看到两种不同的状态：from memory cache 和 from disk cache，前者指缓存来自内存，后者指缓存来自硬盘。而控制缓存存放位置的，不是别人，就是我们在服务器上设置的Etag字段。在浏览器接收到服务器响应后，会检测响应头部（Header），如果有Etag字段，那么浏览器就会将本次缓存写入硬盘中。 之所以拉取缓存会出现200、304两种不同的状态码，取决于浏览器是否有向服务器发起验证请求。 只有向服务器发起验证请求并确认缓存未被更新，才会返回304状态码。 首先，我们先进入nginx的配置文档 ~~~ $ vim nginxPath/conf/nginx.conf ~~~ 在配置文档内插入如下两项： ~~~ etag on; //开启etag验证 expires 7d; //设置缓存过期时间为7天 ~~~ 打开我们的网站，在chrome devtools的network面板中观察我们的请求资源，如果在响应头部看见Etag和Expires字段，就说明我们的缓存配置成功了。  > 在我们配置缓存时一定要切记，浏览器在处理用户请求时，如果命中强缓存，浏览器会直接拉取本地缓存，不会与服务器发生任何通信，也就是说，如果我们在服务器端更新了文件，并不会被浏览器得知，就无法替换失效的缓存。所以我们在构建阶段，需要为我们的静态资源添加md5 hash后缀，避免资源更新而引起的前后端文件无法同步的问题。 参考资料 [鸟瞰前端 , 再论性能优化](https://juejin.im/post/59c2109cf265da066875eff5#comment) [网站性能优化实战——从12.67s到1.06s的故事](https://zhuanlan.zhihu.com/p/35224473)