这两天一直在看首屏优化的文章,因此将其总结概括一下,方便之后使用。css
相对于移动端的首屏优化,PC在有些方面要苛刻得多,主要是由于PC端有太多的东西想要让用户看到,这就不免PC端的页面大而“重”,与咱们如今“富客户端”的概念想相呼应。html
本文目录前端
以800x600像素尺寸为标准,当浏览器加载页面后看到第一眼的显示内容为首屏。而从开始加载到浏览器页面显示高度达到600像素且此区域有内容显示的时间为首屏显示时间。jquery
以京东首页为例:json
当咱们打开京东时,第一眼看到的内容即为首屏内容,也就是如上图的内容。后端
一个页面的“总加载时间”要比“首屏时间”长,但对于最终用户体验而言,当内容充满首屏的区域时,用户就能够看到网站的主要内容并能够进行各自的选择了。首屏时间的快与慢,直接影响到了用户对网站的认知度。
因此首屏时间的长短对于用户的滞留时间的长短、用户转化率都尤其重要。浏览器
仍是首先以京东为例:缓存
当咱们打开京东的网站(不要滚动鼠标和键盘),右键查看源代码会发现京东首页的DOM树出奇的简单,页面DOM中多含有mod_lazyload的类性能优化
<div class="J_f J_lazyload J_f_lift mod_lazyload need_ani chn" id="portal_8" data-backup="basic_8" data-source="cms:basic_8" data-tpl="portal_tpl">
再看下 localstorage服务器
尤为是观察location下面的键值对,会发现它们的值中多存在一串完整的相似于html的内容(内容太多删除了值中的内容)
由上面的结构咱们可知jd.com已经将它们的页面结构放到了localstorage,不难想象这只是它页面中的其中一个模块的内容
分析到这里已经很明显了,经过前端缓存和异步加载jd已经完美的实现了首屏快速加载,在PC端达到了秒开的级别。
把须要请求的路径写在 dom 上(例如:data-tpl="elevator_tpl"),用户滚动时,一旦该模块进入了视窗,则请求 dom 上对应的 data-tpl 地址,拿到渲染这个模块所须要的脚本和数据,不过这中间还有一层本地缓存 localstorage,若是在本地缓存中匹配到了对应的 hash string 内容,则直接渲染,不然请求到数据以后更新本地缓存。localstorage中的 version 会在页面加载时候,与后端文件 hash相对比,hash不变直接取localstorage中的内容(固然也可使用cookie判断版本)。
这里其实存在两个请求,一个请求是加载数据和脚本,而这里的内容是:
为啥不在返回的内容中直接把脚本也输出出来?为了让数据充分缓存下了很多功夫。数据的变化频率比较高,若是数据和初始化脚本包装在一块儿,虽然节约了一个请求,但一旦数据变化,整个脚本都得从新加载,而将数据和脚本分离,脚本能够长期缓存在本地,单独请求数据,这个量会小不少。直接改变上面的 version 版本号即可以让浏览器从新请求最新脚本。
从上面能够看出,任何一个模块的改动,在前端只会引发一个较小的加载变化,加上 http 的缓存策略,服务器的压力也是很小的。
看了上面的内容相信你们对于京东关于首屏优化的方案有了一个大致的了解,下面咱们再整理一下关于首屏显示速度优化细节上的内容:
为了求快,首页是没有css外链的,这样会再发起屡次请求,相信对于咱们来讲,也是老生常谈的前端优化了。
那有人可能会问没有css外链,那若是一整个页面的css是否会增长页面的体积?其实上面就已经提到了,页面切分为模块化加载,对应模块下的css交给js或jsonp请求返回
京东采用请求的方式减小了与服务器交互的时间
<script src="//misc.360buyimg.com/??/jdf/lib/jquery-1.6.4.js,/jdf/2.0.0/ui/ui/1.0.0/ui.js,/mtd/pc/index/gb/lib.min.js,/mtd/pc/base/1.0.0/base.js,/mtd/pc/common/js/o2_ua.js,/mtd/pc/index/home/index.min.js,/mtd/pc/index/home/init.min.js"></script>
懒执行,有交互才执行,有兴趣的能够看看小胡子哥的淘宝首页性能优化实践这篇文章
图片在其余屏(非首屏)都采用懒加载的模式,这样既能节省流量,也能减小请求数或延迟请求数。
以上基本上即是最近整理的一些内容,还有不少咱们前端开发应该注意像script标签的位置啊,div的嵌套深度啊等咱们开发自己应该具有中的就很少说了。正所谓“一如前端深似海”。。。