转:名站技术分析 — facebook奇特的页面加载技术
来自:http://www.cnblogs.com/BearsTaR/archive/2010/06/18/facebook_html_chunk.html
没事使用代理上了下facebook,注册进入个人首页后,习惯性的查看源代码,发现了1个很有意思的现象,首页内容不少,但源代码中HTML的代码却很少,但去多出了很多段的javascript代码,这些js代码都是用于动态生成html的,facebook为什么需要这样做了?出于职业习惯,研究研究:
一、html代码。
先看看首页查看的源代码,因为源代码比较大,所以把图片压缩了下,可能看不太清楚,只需要注意图中红色是html代码,其余黑压压一片的就全部是JS代码:
二、JS代码
看到黑压压的JS代码是不是被吓一跳,下面就截取一段JS来分析(其余段的JS都是类似的),facebook源代码中充斥了类似于下面的JS代码:
01 | <script> |
02 | big_pipe.onPageletArrive({ |
03 | "id" : "pagelet_welcome_box" , "phase" :1, "is_last" : false , "append" : false , "bootloadable" :[], |
04 | "css" :[ "lDRwi" , "eon+N" ], |
05 | "js" :[ "F+B8D" , "IdQlc" ], |
06 | "resource_map" :[], "requires" :[], "provides" :[], |
07 | "onload" :[ "window.__UIControllerRegistry[\"c4c13a3ed2dd1e0e349b72\"] = new UIPagelet(\"c4c13a3ed2dd1e0e349b72\", \"\\\/pagelet\\\/generic.php\\\/WelcomeBoxPagelet\\\/\", {}, {});; ;" ], |
08 | "onafterload" :[], "onpagecache" :[], "onafterpagecache" :[], "refresh_pagelets" :[], "invalidate_cache" :[], |
09 | "content" :{ |
10 | "pagelet_welcome_box" : "<div id=\"c4c13a3ed2dd1e0e349b72\"><div class=\"UIImageBlock clearfix fbxWelcomeBox\"> ...这里省略N多HTML" |
11 | }, |
12 | "page_cache" : true |
13 | }); |
14 | </script> |
让我们再看看big_pipe.onPageletArrive函数到底做了什么了?我们只关注参数中的id,js,css,content4个参数,可以看出js和css都是进行过编码,下面是解码后我们关注的代码:
01 | <script> |
02 | big_pipe.onPageletArrive({ |
03 | "id" : "pagelet_welcome_box" , |
04 | "css" :{ |
05 | name: "css/c5mv8gd5gwoc4kk0.pkg.css" |
06 | permanent: true |
08 | type: "css" |
09 | }, |
10 | "js" :{ |
11 | name: "js/19khsprwvtvokwow.pkg.js" |
12 | permanent: false |
14 | type: "js" |
15 | }, |
16 | "content" :{ |
17 | "pagelet_welcome_box" : "<div id=\"c4c13a3ed2dd1e0e349b72\"><div class=\"UIImageBlock clearfix fbxWelcomeBox\"> ...这里省略N多HTML" |
18 | } |
19 | }); |
20 | </script> |
看到还原后的JS,你应该猜出onPageletArrive函数是干嘛的吧,其实onPageletArrive最主要实现就是把"content"中的html内容插入到对应id(上面的"pagelet_welcome_box")的html元素中,并下载对应的css和JS。
三、chunk、flush
看到上面的分析后,大家一定奇怪,facebook为什么要生成那么多段JS,再用js去动态插入html代码,这不是脱了裤子放屁,多此一举吗?还不如直接生成html代码了。facebook当然不会那么笨了,让我们先监控下facebook的http请求,监控图如下:
注意上图中红色部分,原来facebook使用了chunk对页面进行分块输出。这就比较容易理解了,facebook首页的js代码段不是1次就全部输出的,而是一段一段进行输出的。
什么是chunk和如何使用chunk,请参考我的另1篇博文:flush让页面分块,逐步呈现
总结
facebook使用chunk技术让页面分块输出成很多JS段,这样做的好处就是服务器和客户端可以并行进行处理,不用等服务器全部处理完毕,客户端才进行处理。
举个博客园首页的列子,博客园首页分为下面几块("推荐博客排行","首页随笔列表","最新新闻"...),
我们一般对该http请求处理如下:
1. 浏览器发送http请求
2. 服务器处理请求(从缓存读取前50个推荐博客,从数据库读取"首页随笔列表",从数据库读取"最新新闻"),生成首页的html代码。
3. 服务器发送html代码给客户端
4、浏览器接收到响应,处理html(下载css,js,image,执行js等等)
可以看出传统的http请求4个过程中,每个过程都必须等待前1个过程完成后才能执行,这样就存在很大的资源浪费。
facebook的对该http请求的处理如下:
1. 浏览器发送http请求
2. 服务器处理请求(从缓存读取前50个推荐博客,生成"推荐博客"的js代码段,flush输出该代码段,
服务器继续读取"首页随笔列表",并生成输入js代码段。
服务器继续读取"最新新闻",并生成输入js代码段。
3. 浏览器接收到js代码段,下载该代码段所需的js和css。插入html代码。
在这个处理流程中,最大的特点就是2,3是并行进行处理的,服务器处理完一部分数据就把已经处理好的数据交给浏览器进行呈现处理,自己再继续处理其他的数据。
PS:文章看完了,有些同学可能会想,为什么不像博客园一样,前台全部用ajax来异步读取"推荐博客" ,“最新新闻”的数据了,这样做就不会出现因为要处理太多数据而让客户端等待太久的问题了。我觉得对于facebook这种并发量巨大的网站,使用这种方法无疑会产生太多的请求,比如facebook首页用了14个chunk,如果使用ajax,则需要多14个request请求,这将增加不少服务器的压力吧。