《前端工程打开速度优化的循序渐进总结》由会员分享，可在线阅读，更多相关《前端工程打开速度优化的循序渐进总结（18页珍藏版）》请在金锄头文库上搜索。
1、前端工程打开速度优化的循序渐进总结创建人：郑昀优化的重要指标： 页面打开速度（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. 图片无损压缩
2、的优化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图片分散在 下；
3、业务类图片分散在 下；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
4、|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. 首屏不需要展示的较大尺寸图片，请使用 Lazy
5、Load；11. 避免404错误：请求一个外联 js 失败时获得的404错误，不但会堵塞并行的下载，而且浏览器会尝试分析404响应的内容，来辨识它是否是有用的Javascript代码；12. 减少 cookies 的大小：尽量减少 cookies 的体积对减少用户获得响应的时间十分重要； 去除不必要的 cookie； 尽量减少 cookie 的大小； 留心将 cookie 设置在适当的域名下，避免影响到其他网站； 设置适当的过期时间。一个较早的过期时间或者不设置过期时间会更快地删除 cookie，从而减少响应时间。13. 使用无 cookies 的域： 当浏览其请求一个静态图片并一同发送 co
6、okie 时，服务器并不需要这些 cookies 。这样只是毫无益处地创建了多余的网络流量。应当保证静态资源在请求时没有携带 cookies，所以需要把你的静态资源放在另一个子域名下。 如果你的域名是 www.example.org，你可以将你的静态资源放在 static.example.org 中。如果你把 cookie 设置在顶级域名 example.org 上而不是 www.example.org，那么所有发送至 static.example.org 的请求会包括那些 cookies。在 这种情况下，你可以用一个全新的没有 cookie 的域名来放置你的静态资源。14. 避免使用 jav
7、ascript 来定位布局；优化第二阶段：外联内联js/css的位置摆放建议玉伯定义的加载和阻塞三定律如下： 定律一：资源是否下载依赖 JS 执行结果JS 有可能会修改 DOM。典型的，可能会有document.write。这意味着，在当前 JS 加载和执行完成前，后续所有资源的下载有可能是没必要的。这是 JS 阻塞后续资源下载的根本原因。 定律二：JS 执行依赖 CSS 最新渲染JS 的执行有可能依赖最新样式。比如，可能会有var width = $(#id).width(). 这意味着，JS 代码在执行前，浏览器必须保证在此 JS 之前的所有 css（无论外链还是内嵌）都已下载和解析完成。
8、这是 CSS 阻塞后续 JS 执行的根本原因。 定律三：现代浏览器存在 prefetch 优化现代浏览器在竞争中，在 UI update 线程之外，还会开启另一个线程，对后续 JS 和 CSS 提前下载（注意，仅提前下载，并不执行）。有了 prefetch 优化，这意味着，在不存在任何阻塞的情况下，理论上 JS 和 CSS 的下载时机都非常优先，和位置无关。根据三定律，郑昀认为：一，如果真的需要把外联js和css放在head里，那也需要从下面这种排序1.外联js2.外联css3.外联js统一为：1.外联css2.外联js3.外联js不要script和css交替混编。原因是，据有人称：从Fire
9、fox 4+开始，对prefetch的策略有些许调整，调整在于head中css与js的位置。css在外联js后面时，可能会在script后面的css加载好之前，提前进行首次渲染。然后等后面的css加载好后，再次更新Render Tree并进行渲染，造成页面闪烁现象。即，各种优化策略，似乎随着浏览器版本不同，头可能发生细微差异。所以郑昀认为，保守做法是，js和css不要在head里交替混编，统一为先外联css再外联js！二，但只有万不得已时，才会在 head 里放外联js，否则请把外联js放置到前。原因是张克军的js和css的顺序关系指出： 只要 head 里出现外联js，无论如何放，css文件
10、都不能和body里的请求并行。 body 里 dom 渲染取决于 head 里的js执行完。外联js放在页面最后，高级浏览器会自动做优化（prefetch），你不用担心，它也可能会提前下载。优化第三阶段：combo handler 的引入背景Combo Handler 是 Yahoo! 开发的一个 Apache 模块，它实现了开发人员简单方便地通过URL来合并JavaScript和CSS文件，从而大大减少文件请求数。目的它满足 Yahoo! 前端优化第一条原则：Minimize HTTP Requests，来减少三路握手和HTTP请求的发送次数。国内实例淘宝网首页meta里多个js合并的声明：
11、js之间用英文逗号或&符号分隔。此src的Response是多个js文件的内容拼装。国内的 Combo Script 支持淘宝李晶-拔赤在 https:/ 下发布了combo.php和minfy.php，能够做到合并文件(不压缩)，以及合并且压缩。文件列表： - combo.php 合并文件，不压缩 - minify.php 合并压缩文件 - cssmin.php 压缩css - jsmin.php 压缩js - cb.php 淘宝CDN合并文件策略的模拟脚本使用: - 要求php5及以上版本 - 程序在找不到本地文件的情况下，会去指定的cdn上找同名文件 - 程序会自动转义-min文件为源文
12、件，因此要约定-min文件和原文件要成对出现 - 需要定义combo.php和minify.php中的$YOUR_CDN变量 - 如果只是合并压缩local文件，则不必重置$YOUR_CDN变量 - 这里提供cb.php，用来实现tbcdn的开发环境的模拟,apache的配置在cb.php中CDN上的 Combo Handler支持1）2008年7月YUI Team宣布在YAHOO! CDN上对YUI JavaScript组件提供Combo Handler服务。2）淘宝CDN支持Combo Handler，用逗号分隔js/css，用两个问号来触发combo特性：- http:/ http:/
13、http:/ CDN 缓存错误的版本，combo上线的访问策略是：1）静态文件传到服务器端；2）部署人员使用线上静态文件服务器的IP地址直接请求combo服务，挨个儿combo请求一次；3）部署人员确认上面的请求都成功、内容无误后，再换成CDN地址再次请求，确保CDN缓存正确的文件内容。优化第四阶段：图片无损压缩的优化页面上的各种图片是否有优化的余地，推荐使用PageSpeed检测一下。下面的建议来自于冯凯。由于专卖店等各种业务上传的图片有 jpeg、png 和 gif 等格式，因此三种格式都需要优化：1）jpegtran和jpegoptim的压缩效果几乎完全相同。但jpegtran有progressive编码（渐进式的展示，先显示模糊的，再逐步清晰），而且通常（84%的概率）对于大图片（10k+）压缩比更高。虽然我们的大部分页面已经改成延迟加载了，但对于非延迟加载的页面，效果明显更好。经测试，pagespeed 并没有按照 progressive 方式提供建议。2）测试了png的几种压缩方式，压缩效果各异。测试的一张图片 optipng 只压缩了约5%，但其他几种达到了20%+经测试，pagespeed上给出的可压缩比例是按照optipng给出的。
