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

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

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

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

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

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

Javascript 和 CSS 方面

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

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

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

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

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

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

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

个人认为针对“无障碍”的 HTML 结构而言，固然是可以这样做（给用户更多的提示信息）。

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

--Split--

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