前段时间(似乎目前也有)Twitter 的网站不是非常的稳定,虽然是 服务器方面的问题 ,而本人职业倾向,于是就看了下 Twitter 的前端代码,下面我说下我的个人观点。

按照期前所说的 评定标准 ,我们来对比下 Twitter 做得如何。

减少 HTTP 请求数,以及使用 CDN、加 Expires 头等

https://friable.rocks/_/2009_11_05/058855b87c6a.jpg

这是本人的 Twitter 主页的请求数统计( 大图 ),看得出在页面不大(150K)的情况下,请求数竟然达到了 60 个居多。

其中,大部分的请求数是图片等,主要的内容是用户的头像。其中,大部分的图像资源来自 s3.amazonaws.com 这个站点,而同时多达 60 多的并发请求数,还是让人对效率方面堪忧。

https://friable.rocks/_/2009_11_05/648315b87e99.jpg

上图是 Twitter 返回的 HTTP 头信息,看得出虽然设置了 Expires 头等信息,但是似乎缓存并没有发挥实际的功效(谁能告诉我原因?)。

Javascript 和 CSS 方面

Twitter 的 CSS 文件仅为一个,并且在页面的头部就已经载入。在这里我无法理解的就是为什么它们没有把样式给压缩,甚至连注释都存在。

https://friable.rocks/_/2009_11_05/345865b87c66.jpg

特别是针对 Twitter 这样突发流量非常大的站点,相信压缩过以后效率会更理想些。

https://friable.rocks/_/2009_11_05/024525b87c64.jpg

Javascript 方面的问题除了说了上述的 CSS 一样未被压缩过以外,它们还分别载入了两套不同的 Javascript 框架,分别是 Prototype 和 jQuery

相信 Javascript 运行开销会比较大的还有 urchin.js 这个文件,它是 Google 的统计埋点(Twitter 没有自己的统计系统?)。

Twitter 的页面虽然简单,但是如此安排前端脚本,在庞大的流量基数面前,个人认为不应该抱乐观的态度。

其他

Twitter 的 HTML 结构发现,有很多的结构都是被简化了的(可能这是处于针对移动设备的考虑)。

https://friable.rocks/_/2009_11_05/939665b87c68.jpg

有趣的一点就是他们会将很多事情交给 Javascript 去做,比如是否出现「On a mobile phone」的提示。

个人认为针对「无障碍」的 HTML 结构而言,固然是可以这样做(给用户更多的提示信息)。

但对于桌面用户而言,毕竟这是属于多余的结构,所以此类的提示信息应该放在服务器上面判断。当然,反驳本热观点的最好理由就是:其一,坚持「无障碍」的 HTML(结构);其二,减少服务器的运行开支。

--Split--

本人的水平有限,此文希望能起到抛砖引玉的效果。PS:大家想听我发牢骚,可以 去我的页面看看