关于大容量页面前端速度优化方案

        何为大容量页面，我的理解为页面html代码量超过500行，页面展示长度超过1屏的页面为大容量页面，同时，这些页面还可能充斥着各种js，广告代码，统计代码，前端优化得不好，对于机器不好的网友来说，打开这张页面就有一种想要关闭的感觉，对于网站来说，自然是一种损失，如何优化呢？ 


第一层优化： 依据y‘slow里面的规则，减少http请求，使用csssprite，合并js，减少dom数量，嵌套，增加缓存，过滤注释等，其他诸如后端的就不说了，这种网上已经有很多这样的说明了，就不多说了，不过这里会出现一个问题，就是大型网站的css，js应该如何布局，单个页面单个css和js的方案是否可行，对于全站的优化有何利弊，这个以后再讨论。根据第一层的优化，从数据来说，y’slow的分数一般可以提升一个到二个等级，但是从感官来说，似乎提升不大。


第二层优化：
 a.优化tab数据，越来越多的网站使用了tab这种流行的交互模式，但是带来的副作用就是页面代码量激增，一般的tab制作方式就2种，一种使用display:none/block来控制隐藏和显示，但是display:none的方式，浏览器还是要提前渲染隐藏的tab内容，里面如果有图片，浏览器一样需要去下载；另外一种使用ajax去读数据库，这使用起来不方便。 taobao这次改版使用了textarea的方法，把要隐藏的tab写在textarea中，这样隐藏的内容就不会被渲染，成了一段死的字符串，如果tab里面有大量的图片，速度的提升是明显的，只要js激活当前tab时把代码处理一下就可以了，相当灵活的方式。
b.第一屏以下图片的延迟展示，这种方式在图片量大的门户网站非常得有效，只在onscroll滚动的时候去加载第一屏以后的图片，这样整张页面的初始化需要下载的容量得到了有效地控制，感官上能明显得感觉到页面速度加快。


如果第一层，第二层优化都做了，那接下去就是整站级别的优化了，下次再说。。 

markup和真实内容的比例多少为好

随着css技术的发明，随着宽带时代的到来，这个时代的网页已经完全不是上个世纪末甚至这个世纪初的样子，标准化页面横行，随便找一个站，都是css-driven的布局，xhtml化的页面。而且越来越的内容被塞进页面。门户越做越大，页面越拉越长，真的这样好吗？新时代的前端，应该跟关注client side的性能和SEO，而且当新媒体流行的时代，javascript泛滥的时代，前端们更加应该关注性能。有时候写几千行代码，实际内容确只有几百行，实在是让人沮丧的一件事情。

最近，发现一个国外前端写了一个程序，来测试markup和网页实际内容的比率的程序，很简单，

1.添加到收藏夹

content/markup

2.浏览你想要测试的网站

3.等页面加载完成以后，点击那个收藏夹的链接

随便测试了一下，fair ratio是指把有用的alt，title等信息加进去的计算结果

淘宝首页：
total size : 152289 bytes
Content size: 14237 bytes
Content-to-markup ratio: 0.09
Fair ratio *: 0.10

百度有啊首页：
total size : 101186 bytes
Content size: 7312 bytes
Content-to-markup ratio: 0.07
Fair ratio *: 0.10

新浪新闻：
total size : 606553 bytes
Content size: 41095 bytes
Content-to-markup ratio: 0.07
Fair ratio *: 0.08

PChome首页：
total size : 156468 bytes
Content size: 26639 bytes
Content-to-markup ratio: 0.17
Fair ratio *: 0.22

国内的网站似乎都不是很高，看看国外网站的结果：

http://www.cnn.com:
Total size: 92004 bytes
Content size: 11475 bytes
Content-to-markup ratio: 0.12
Fair ratio * : 0.16

http://www.sitepoint.com
Total size: 65989 bytes
Content size: 16199 bytes
Content-to-markup ratio: 0.25
Fair ratio * : 0.60

Article on http://en.wikipedia.org:
Total size: 21648 bytes
Content size: 3315 bytes
Content-to-markup ratio: 0.15
Fair ratio * : 0.35

http://www.phpied.com
Total size: 31899 bytes
Content size: 7933 bytes
Content-to-markup ratio: 0.25
Fair ratio * : 0.48

http://www.google.com SERP
Total size: 29963 bytes
Content size: 3351 bytes
Content-to-markup ratio: 0.11
Fair ratio * : 0.14

这个值和网页的规划，设计有很大的关系，不过前端们应该在尽可能的情况下提高这个值，对页面的性能和SEO都有好处的

40种布局代码看2.0时代前端代码的规划

40种相同代码的不同布局

我没有测试是否有bug，不过对于学习布局，非常有好处，特别是margin负值的应用。

当年学习标准化页面制作，完全是出于偶然，应为有一种习惯是学一门知识，就喜欢去买本书看看，所以买了一本叫做《网站重构》的书，因为当时觉得很好奇，原来不用表格能实现那么复杂的效果，真的不错，这本书本身翻译得不怎么样，不过算是带我入门了。书的英文作者叫：zeldman。他有一个网站叫禅意花园，里面有各种各样的标准化爱好者为网站定制的css。使用的都是同一种代码，超过200个css让人体会到了css的强大之处。

但是，对于消费类网站应用，和越来越多的2.0 web应用程序，css这种特性确使用的人非常非常地少，我相信很少有人对于网站的改版只需要改动css就可以成功的，因为很多的未来是不可以被遇见的。

难道2.0时代，前端能做的只是一遍又一遍的重复劳动吗？当然不是！

1. 前期做好整个系统的预估，对于未来的扩展心里有数，很多人喜欢用很少的代码来实现效果，如果只是一张静态页面，我赞成你这么做，如果对于某一个系统，我还是比较喜欢做一些结构性的牺牲的
2. 充分理解class和id的作用，这个比较像面对对象便成里面的类和对象的关系
3. 不要有奇怪的命名，这个老生长谈了，经验积累
4. 建立自己的代码库，方便自己使用
5. 欢迎补充

前端应该思考什么

最近很多blog都在讨论div+css的是与非或者是用strong标签好，还是em标签好。这真的是没什么问题，说明大家已经从2000年刚开始的盲目追求标准化的情绪中摆脱出来，继而追求一种更高的境界了。

叫div+css也好，叫xhtml+css也好，甚至叫xml+css也罢，对于一个优秀的前端来说，真的无所谓，不可能因为标准化被叫做div+css，在写代码的时候只用div标签，退一万步来说，即使整张页面只用div+css来制作，也没有什么不可以的，只要代码写得够精简，兼容性够好，我觉得就没有问题，而且反倒是纯的div对于浏览器来说，兼容性更好，当然我不鼓励所有的元素都用div来写哦。别跟我说什么语义化，谁规定strong就比em强，你难道是搜索引擎？当microformat和html5 十年后都未必能用的时候，语义化说白了就是忽悠老板的噱头；而且现阶段，我没见过哪家网站制作得和zen一样，可以用css来随便改版，基本上改版等于重写代码，因为太多的功能牵涉其中，没法只改css能控制全局。

所以，前端们，多从系统来考虑你写的代码，命名，结构，多研究研究行为层javascript的东西，多研究研究互联网产品的前世今生和页面布局，多研究研究数据分析，甚至多研究研究后端代码，比醉生梦死在一堆div和选择器中要强很多，如果只是div+css，那注定你也只是一个切页面的it民工。