搞前端的同学也许都知道一个数字——4秒，有研究表明，如果一个网站没有在4秒之内加载完成，用户就会感到焦躁不愉快，并离开这个网站。网站的内容、搜索引擎优化、用户体验？哪个更重要呢？在速度面前，也许这些都相对更次要。所以提高网页效率，是我们在新版微博的第一目标。从四个方面来浅谈我们新版微博的优化。

　　一、HTTP请求数的权衡

　　1、为什么要关心http请求？

　　当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息。在用户打开一个页面的初初，包括等待时间、请求时间、建立响应时间、渲染时间……，都是消耗在前端的。比如下载图片、下载样式表、JavaScript脚本、flash等文件。大家应该都经历过那个“多图杀猫”的时代，加载那样一个网页会花费大量的时间。减少这些资源文件的请求数将是提高网页显示效率的重点。

　　假设用户家的网速是1M/秒，那么他打开一个网页时，如果网页文件小于1M，理论上他可以在一秒之内打开网页。下载网页的快慢在显示速度上占了很大比重，所以，网页本身体积越小，浏览速度就会越快。这就需要产品、交互、设计，从最初就遵循尽量精简的原则。

　　现在，就揭开新版微博的面纱，看看微博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渲染的总时间并不超过V3 CSS渲染的总时间，速度反而快了很多，减少了视觉等待。

　　上面这张表格，来自yslow的分析。我们通过把页面切成细小模块写样式的做法，虽然请求数比以前大了8倍，但总大小上直降20K。

　　将多个CSS合并的做法固然可以减少请求，但对上亿用户的微博页面来说，完成合并也许会带来5%速度的提升。但是如果按bigpipe模式，即使http请求数提高了，但是整体的速度也许是之前的50%。

　　二、对CSS的优化处理

　　1、提取公用模块或公用元素，并反复调用

　　如果用户每次访问微博首页时，就重新下载读取CSS文件。这就会造成给服务器带来额外压力且用户重复读取耗时。新版微博的做法是，把模块分为全局级模块和页面级模块，首页是全站的核心，所有模块都是重要且重复性高的，所以首页的所有模块都是全局级模块。首页所需要的CSS被整理成一个pl列表反馈给工程师，等待处理。而一些非公共的css模块样式被单独写在属于本页面的文件里，这样就最大化的节省了文件大小及利用率。这么做还有一个好处，就是公共模块样式被调用过后，会在浏览器里留下缓存。调用最频繁的模块，反而样式被最快的加载进来。

　　举个简单的例子：

it知识库：从新浪微博的改版谈网页重构，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。