实际上，我们通过前台web端的梳理和逻辑的优化（哪怕是一个小的处理细节）都可以提高我们的页面响应速度，从而不断改善用户体验和提升用户价值。这里主要有下面几点分享：：
1， 对页面内容按照优先级进行分块，然后根据不同的级别决定各块拉取的时机。
就象版本特性一样，我们可以通过不断的敏捷迭代去实现用户最重要最care的特性，实际上，我们的页面内容也是可以根据用户的需求划分优先级的，
把用户最重要，最紧迫想看到的内容第一时间“送”到用户的面前，而不是第一时间去加载一些用户认为不是非常重要的内容，而这种内容一般可以延迟加载（晚点看到用户也不会觉得很不爽）。而用户如果没有第一时间看到这些内容会产生“失落感”和“迷失感”，从而会对这个站点的体验迅速产生“不满”，那么这些内容我们都可以认为是高优先级别的，应该安排在早点拉取，比如炫铃，用户最想看到的就是炫铃的一个个item，而不是上面的一句话：尊敬的xxxx。因此这里的上面的提示语可以延迟加载。
2， 不要用<script src=’xxxx.php’></script>的形式实现静态页面拉取动态内容。
<script>拉取内容的方式本质上是一种同步模型，通过该script请求的资源如果无法及时拉取到，页面是无法继续往下渲染的，通过这种方式，我们无法享受到
静态页面带来的好处。
3， 减少页面拉取的图片数目很重要。
浏览器拉取页面图片的开销是比较大的，而实际上，我们的页面为了提升用户体验使用了大量图片，这里我们常采用cdn存放，图片合并(几个图片合成一个，然后使用css进行截取片断显示)，永久cache（存在图片变更的维护成本,工具的建设等），甚至有些效果是可以用css来实现的代替图片
4， 统计需要等非业务逻辑的实现方案尽量要轻量化。
为了实现一个isdstat统计，跳转了一次php，这样的代价有点高，可以等到用户的页面数据拉取完毕后“偷偷”的发送个请求去实现统计即可，基本原则是：
统计出现的位置1，不能影响页面功能；2，发到页面最后执行。
5， 对性能要求更高的站点首页可以单独处理。
首页作为一个站点门面，可以进行特别处理：如单独build成静态页面，写只对该首页有用的js等，会员这边对好多首页是直接使用html页面而非php。
Js的一般执行顺序是从上到下的执行，但defer属性在IE下可以延迟脚本的执行时机(Firefox忽略该属性)，特别是结合src属性的使用可以告诉浏览器先从后台下载该js代码但不立即执行它，从而实现延迟加载的效果。
Php方面的优化主要包括两点：1,php本身的优化，包括减少不必要的包含文件，php不同写法的性能差异，php的环境配置等，这里可以参考下网上的php的40条优化建议
（http://www.yeeyan.com/articles/view/davidkoree/4409 ），A HOWTO on Optimizing PHP：（http://phplens.com/lens/php-book/optimizing-debugging-php.php）；
2，php里面的业务逻辑优化：把更重的逻辑后移到Server其执行，php只负责接入；考虑是否可以把部分逻辑省略，去掉重复调用的接口等。
8， 充分利用浏览器的cache机制，必要时，考虑实现js层面的cache;
通过设置http头中的Cache-control和 Expires 字段，可以利用浏览器本身的cache，从而减少http请求数，如果有必要，特别是在js模板替换方面，可以实现js层面的cache层，把已经parse后的模板内容进行cache。如何使用cache-control和expires可以参考以下网址：
（http://www.exp2up.com/blog/2008/07/24/http%E5%A4%B4%E7%9A%84expires%E4%B8%8Ecache-control/ ）。
9， 尽量少用重定向机制；
Header(“Location:url”);会增加两次浏览器和web server之间的来回，因此减少这里的重定向是我们优化的一个重要方向，这里的例子是会员专区的跳转优化。
10， 考虑cpu和内存资源和带宽资源的互换。
就好像算法设计中的时间和空间复杂度一样，我们可以通过缓冲中间的计算结果减少计算的时间，但相应的增加存储空间，相应的，如：我们可以利用json从服务器上拉取数据，由于json的简洁性，使得数据通讯量比较小，一旦拿到客户端，在对json数据进行模板替换，生成html代码（生成的代码一般比json大许多），达到利用用户cpu和内存资源降低带宽压力的目的。
11， 其他：
对js和css进行压缩，去重，合并等处理；html尽量使用标准规范的写法，提高渲染引擎的执行效率；对广告图片进行适当的压缩处理；
tenfyguo 于2010年01月tx
