个人大部分性能优化工做都集中在JavaScript和CSS上,从早期的Move Scripts to the Bottom和Put Stylesheets at the Top规则。为了强调这些规则的重要性,我甚至说过,“JS和CSS是页面上最重要的部分”。html
几个月后,我意识到这是错误的。图片才是页面上最重要的部分。git
我关注JS和CSS的重点也是如何可以更快地下载图片。图片是用户能够直观看到的。他们并不会关注JS和CSS。确实,JS和CSS会影响图片内容 的展现,尤为是会影响图片的展现方式(好比图片轮播,CSS背景图和媒体查询)。可是我认为JS和CSS只是展现图片的方式。在页面加载的过程当中,应当先 让图片和文字先展现,而不是试图保证JS和CSS更快下载完成。github
我优化JS和CSS的目的就是让页面尽快渲染。web
伴着关注渲染时间的念头,我查询了HTTP Archive来了解咱们的页面开始渲染的时间。下面是一些衡量的数值:浏览器
从世界最快的30万个地址的测量值中,我提取出其中的50%和90%部分。以下面展现的同样,在页面加载的前三分之一段时间内,没有任何渲染动做。性能优化
表格 1. 页面加载过程当中的各个时间点 | |||
TTFB | 开始渲染 | onload | |
---|---|---|---|
50th percentile | 610 ms | 2227 ms | 6229 ms |
90th percentile | 1780 ms | 5112 ms | 15969 ms |
页面等待渲染的时间是整个页面加载时间的三分之一,这个事实让人出乎意料。HTTP Archive上的数听说明,页面花费了32%到36%的时间来等待渲染开始。可是只须要10%的时间来获取第一个字节。所以,浏览器在22%到26%的 时间段内,虽然已经接受到了数据,可是却不作任何渲染。在这段时间内浏览器一般都是在下载解析脚本和样式—这二者都会阻碍页面的渲染。性能
曾经,浏览器在这个时间段内(从接受到第一个字节到渲染开始)是处于空闲状态的。这是由于旧的浏览器中,一个脚本的下载会阻塞其余全部的资源的下载,好比IE6&7。浏览器厂商意识到虽然浏览器须要等待脚本下载执行完成后才能构建DOM,可是没有理由阻塞页面其余资源的并行下载。在2009年的IE8以后,浏览器预加载其余资源的请求。研究代表,预加载让页面加载速度快了20%。今天,全部主流浏览器都支持预加载。在这些浏览器数据中,我展现了每一个主流浏览器最先支持预加载的版本。测试
(顺便说一句,我认为预加载是最有效的性能提高方式。设想如今的浏览器中脚本下载会阻塞其余资源,面对页面上如此庞大的脚本数量,页面的性能会糟糕到哪一个程度)优化
这时咱们又要回到 Jason Grigsby的一条tweet:网站
我不得不认可一点。我试图推动响应式图片,而且愈来愈倾向于鼓励开发者来使用JS阻止预加载。
Jason指的“响应式图片”是一项技术,使用脚原本生成图片。一般这个技术用于实现图片对分辨率的适应。一个例子是Picturefill。当你将“预加载”和“响应式图片”合起来思考——预加载会提早加载图片的SRC,可是响应式图片技术一般又没有SRC,或者只是有一个1x1的替代图片。这两项技术之间有冲突。下面有一些权衡:
接着Jason在后一条tweet中说:
让我以为不舒服的是,大部分结论都没有通过测试。只是一些理论,而不是数据。
我并无数据来比较这两个方式,可是HTTP Archive中开始渲染的时间占总加载时间的三分之一也说明了一些问题。彷佛渲染确实被脚本阻塞了,也就是说IMG标签尚未被建立。那么在1/3点后 的时间里,IMG标签会被解析,而后JS和CSS才会执行并开始下载须要的图片。
我认为,在页面加载过程当中初始化图片请求太晚了,而且相对使用预加载后的效果,页面的渲染时间确实被推迟了。再次声明,我没有数据来对比这两项技术。同时,我也不肯定在markup技术的响应式图片中使用预加载会有怎样的改观。(Jason有篇博客文章有相关的内容,The real conflict behind <picture> and @srcset)
理想状况下,咱们利用markup解决了预加载和响应式图片之间的冲突问题。直到那时,我依然担忧这样的技术在开发社区中大量使用会让响应式图片付出预加载失效的代价。我但愿浏览器能够加强预加载的效果,那么如今和将来里网站就可以充分利用预加载的功能。