前端工程打开速度优化的循序渐进总结
更新时间：2024-05-25 10:22:01 阅读量： 综合文库 文档下载
前端工程打开速度优化的循序渐进总结
创建人：@郑昀
优化的重要指标：
?
页面打开速度（Fully Loaded）
?
网站首页（或列表页）之 First View ：打开速度应在 3秒+0.5秒 内；
? 对 Repeat View 时的各项指标暂不作要求；
? 首屏打开时间（Start Render）
?
网站首页（或列表页） 之 First View ：首屏渲染速度应在 1秒+0.5秒 内；
? 文档解析完毕时间（Document Complete）：
?
对此指标暂不作要求。
指标测试方法参考附录A。
提纲：
1. 遵循常规优化建议
2. 外联内联js/css的位置摆放建议
3. combo handler的引入
4. 图片无损压缩的优化
5. 减少 dom elements 的数量
6. 引入 textarea/script 元素做延迟解析异步渲染
优化第一阶段：遵循常规优化建议 本阶段所使用工具参考附录B。 常规优化建议： 1. javascript 外联文件引用放在 html 文档底部：具体如何摆放内联JS/CSS和外联JS/CSS，请参考 优化第二阶段； 2. css 外联文件引用在 html 文档头部：位于 header 内； 3. http 静态资源尽量用多个子域名：充分利用现代浏览器的多线程并发下载能力。浏览器的多线程下载能力，参考 附录C； ? 具体建议： ? JS、CSS、CSS背景图片、CSSSprite图片分散在 s0～s2.55tuanimg.com 下；
? 业务类图片分散在 p0～p3.55tuanimg.com 下；
4. 服务器端提供 html 文档和 http 静态资源时，尽量开启 gzip 压缩；
?
json/xml 等格式的文本响应，也建议开启 gzip ；
? jepg/png 等图片，可以选择不开启 gzip，因为可能服务器端图片无损压缩算法已经很强悍了，不需要依赖于 gzip；
5. 在 js、css、image 等资源响应的 http headers 里，设置 expires、last-modified；
?
含义参考 附录D；
? 郑昀实例示范：
? Nginx设置示范：
?
location ~ .*\\.(js|css)${ expires 30d; } location ~ .*\\.(gif|jpg|jpeg|png|bmp)${ expires 1M; } 6. 尽量减少 HTTP Requests 的数量； ? 通过 combo handler 合并 js 和 css 的下载，参考 优化第三阶段； ? 本阶段请尽量减少外联 js/css 文件数，尽量减少 ajax 调用； 7. js/css 的 minify：可统一通过 combo handler 做到压缩加合并；
8. 减少不必要的 301/302 跳转：别让页面打开时间浪费在302多次跳转上（每次可能几十
毫秒）；
9. 请大量使用 CSS Sprites：这样做可以大大地减少CSS背景图片的HTTP请求次数； 10. 首屏不需要展示的较大尺寸图片，请使用 LazyLoad ；
11. 避免404错误：请求一个外联 js 失败时获得的404错误，不但会堵塞并行的下载，而且
浏览器会尝试分析404响应的内容，来辨识它是否是有用的Javascript代码；
12. 减少 cookies 的大小：尽量减少 cookies 的体积对减少用户获得响应的时间十分重要；
?
去除不必要的 cookie ；
? 尽量减少 cookie 的大小；
? 留心将 cookie 设置在适当的域名下，避免影响到其他网站；
? 设置适当的过期时间。一个较早的过期时间或者不设置过期时间会更快地删除 cookie，从而减少响应时间。
13. 使用无 cookies 的域：
?
当浏览其请求一个静态图片并一同发送 cookie 时，服务器并不需要这些 cookies 。这样只是毫无益处地创建了多余的网络流量。应当保证静态资源在请求时没有携带 cookies，所以需要把你的静态资源放在另一个子域名下。
? 如果你的域名是 www.example.org，你可以将你的静态资源放在 static.example.org 中。如果你把 cookie 设置在顶级域名 example.org 上而不是 www.example.org，那么所有发送至 static.example.org 的请求会包括那些 cookies。在 这种情况下，你可以用一个全新的没有 cookie 的域名来放置你的静态资源。
14. 避免使用 javascript 来定位布局；
优化第二阶段：外联内联js/css的位置摆放建议
玉伯定义的加载和阻塞三定律如下：
?
定律一：资源是否下载依赖 JS 执行结果——JS 有可能会修改 DOM。典型的，可能会有 document.write。这意味着，在当前 JS 加载和执行完成前，后续所有资源的下载有可能是没必要的。这是 JS 阻塞后续资源下载的根本原因。
? 定律二：JS 执行依赖 CSS 最新渲染——JS 的执行有可能依赖最新样式。比如，可能会有 var width = $('#id').width(). 这意味着，JS 代码在执行前，浏览
器必须保证在此 JS 之前的所有 css（无论外链还是内嵌）都已下载和解析完成。这是 CSS 阻塞后续 JS 执行的根本原因。
?
定律三：现代浏览器存在 prefetch 优化—— 现代浏览器在竞争中，在 UI update 线程之外，还会开启另一个线程，对后续 JS 和 CSS 提前下载（注意，仅提前下载，并不执行）。有了 prefetch 优化，这意味着，在不存在任何阻塞的情况下，理论上 JS 和 CSS 的下载时机都非常优先，和位置无关。
根据三定律，郑昀认为：
一，如果真的需要把外联js和css放在head里，那也需要从下面这种排序 1. 外联js 2. 外联css 3. 外联js 统一为： 1. 外联css 2. 外联js 3. 外联js
不要script和css交替混编。
原因是，据有人称：『
从Firefox 4+开始，对prefetch的策略有些许调整，调整在于 head 中 css 与 js 的位置。 css 在外联 js 后面时，可能会在 script 后面的 css 加载好之前，提前进行首次渲染。 然后等后面的 css 加载好后，再次更新 Render Tree 并进行渲染，造成页面闪烁现象。 即，各种优化策略，似乎随着浏览器版本不同，头可能发生细微差异。 』
所以郑昀认为，保守做法是，js 和 css 不要在 head 里交替混编，统一为先外联css再外联js！ 二，但只有万不得已时，才会在 head 里放外联js，否则请把外联js放置到