从新浪微博改版谈网页重构——bigpipe中的页面构建优化.docxVIP

从微博的改版谈网页重构——bigpipe中的页面构建优化 题记：搞互联网的同学也许都知道一个数字——4秒，有研究表明，如果一个网站没有在4秒之内加载完成，用户就会感到焦躁不愉快，并离开这个网站（数据来自性能测试网站 HYPERLINK / \t _blank /）。网站的内容、SEO优化、用户体验？哪个更重要呢？在速度面前，也许这些都相对更次要。所以提高网页效率，是我们在新版微博的第一目标。从四个方面来浅谈我们新版微博的优化。 一、HTTP请求数的权衡 1、为什么要关心http请求？当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息。在用户打开一个页面的初初，包括等待时间、请求时间、建立响应时间、渲染时间……，都是消耗在前端的。比如下载图片、下载样式表、JavaScript脚本、flash等文件。大家应该都经历过那个“多图杀猫”的时代，加载那样一个网页会花费大量的时间。减少这些资源文件的请求数将是提高网页显示效率的重点。假设用户家的网速是10Mbps，10Mbps=10/8=1.25MB/s，那么他打开一个网页时，如果网页文件小于1.25MB，理论上他可以在一秒之内打开网页。下载网页的快慢在显示速度上占了很大比重，所以，网页本身体积越小，浏览速度就会越快。这就需要产品、交互、设计，从最初就遵循尽量精简的原则。现在，就揭开新版微博的面纱，看看微博3.0和新版微博的区别吧。 微博3.0截图 新版微博截图 微博3.0是大家熟悉的两栏结构，总宽为800px，有一级导航和二级导航、发布框、feed区、个人简介区。新版微博是现在最流行的三栏式布局，总宽950px，除以前的内容一个都不少之外，还整合出了左侧导航和右侧各种引导和公告。所以从理论上讲，虽然内容更丰富了，但新版微博着实比微博3.0的页面体积大了很多。2、什么是bigpipe？网上有个例子举得好：在饭馆点菜吃的时候，如果点了四个菜，厨师没有必要把四个菜一起炒好再上来。微博3.0就是这种把所有菜都炒好再上桌的网页加载模式。所以用户吃上菜的时候，已经是第5秒了。现在新版微博的bigpipe网页加载模式，是炒好一个菜先一个菜，用户可以先吃着，厨师再炒第二个菜。甚至可以几个菜并发同时炒。所以用户吃上第一口菜的时间可能是第1秒，比之前提前了很多。 bigpipe模式示意图 JS工程师把页面分割成若干个小块（pagelet），模块彼此独立，把html语言转变为JS语言，再把CSS通过style的方式加载进这段代码，而不需要用以往的头部link css地址的方式取样式。每个模块有自己对应的html、CSS、JS，一旦开始运行模块，就会寻找到对应的CSS，并显示对应innerHTML内容插入到对应的html元素中，同时渲染出本模块效果。比如执行到feed区域的 id=pl_content_homeFeed时，样式表只调用了feed.css。3、为什么新版微博 CSS的HTTP请求数不降反增？通过上面说的这种模式，css被全部link到头部，是为了给后台代码提供出pagelet所需要的样式列表。以前微博3.0头部只link了3个CSS，新版微博首页头部却需要link10多个css。虽然加载文件多了，新版微博CSS加载请求数反而高于v3，看似yslow降级了（这个数据已经不能说明任何问题了）。但实际上新版微博CSS没有像以往一样合并起来，而是用一个加载一个，CSS和JS被分配到不同流水线中，模块的加载变成并行的，先执行完的模块先显示出来。所以新版微博CSS渲染的总时间并不超过V3CSS渲染的总时间，速度反而快了很多，减少了视觉等待。 请求数总大小 加载时间 V3CSS3个请求76.3kb8.53sV4CSS24个请求50.2kb6.08s上面这张表格，来自yslow的分析。我们通过把页面切成细小模块写样式的做法，虽然请求数比以前大了8倍，但总大小上直降20K。将多个CSS合并的做法固然可以减少请求，但对上亿用户的微博页面来说，完成合并也许会带来5%速度的提升。但是如果按bigpipe模式，即使http请求数提高了，但是整体的速度也许是之前的50%。 二、对CSS的处理优化1、提取公用模块或公用元素，并反复调用如果用户每次访问微博首页时，就重新下载读取CSS文件。这就会造成给服务器带来额外压力且用户重复读取耗时。新版微博的做法是，把模块分为全局级模块和页面级模块，首页是全站的核心，所有模块都是重要且重复性高的，所以首页的所以模块都是全局级模块。首页所需要的CSS被整理成一个pl列表反馈给工程师，等待处理。而一些非公共的css模块样式被单独写在属于本页面的文件里，这样就最大化的节省了文件大小及利用率。