scourgen

If It still has something wrong,please tell me,thanks .

I have a project that has hundreds of js/css files, on each times of deploy, We need spend about 10 minutes to compile all js/css fies(I was use google compiler...

这篇文章已经很老了，你翻译的文章里的链接都是错的，https://github.com/speed/pagespeed/optimization 这个页面现在已经不存在了。 现在稍微复杂一点的网站，没有多少页面是和用户身份完全无关的。你提到了用Memcache存页面内容，但有没有考虑过在这之上其实还是有一个程序需要去负责根据URL和session判断应该显示什么内容，以及连接memcache的实例，并把memcache的内容提取出来再发送给客户端的，这个程序的逻辑本身也是会耗费一定的时间的。 你的“一律采用整页缓存”能够应用到的页面是很少的，对于整站的整体性能提高帮助并不会很大。 而其实解决这个问题的思路和整页缓存很类似：不是整页缓存，而是把动态页面拆成许多个component，然后根据实际的逻辑需要去分别做缓存。 任何页面都是由很多个逻辑组成的，就好比现在github的这个页面，可以分为：页头，项目头，issue信息，帖子（又分为主贴和N个回帖），然后是页尾。我们假设页面逻辑也是分为这么几块来处理的，在普通情况下，这几块内容都需要经过程序的处理和渲染才能被输出给用户，即使是简单地内容例如页脚，也至少需要一个文件读取的过程，但这也是需要一些时间的。而最佳的作法，则是将页面的某一部分也缓存起来。 关于具体的实现办法，有很多技术解决方案，入门成本最低的当属用Varnish实现ESI，如果有兴趣的话可以研究一下。 回头说到这篇文章，其实真正影响到页面渲染速度的地方反而一点都没有讲，倒是为了推销他们的那个pagespeed模块打了很多广告，至少从技术上我不觉得这是一篇值得学习的文章。这篇文章就好比告诉你“家用车如何百公里跑进5秒”，但通篇却说了很多马路，天气，赛车手的因素在里面，并不是说不对，但我想读者最想看的是你汽车的引擎到底是怎么设计的，轮胎用了什么技术之类的技术点。而就篇文章也是如此，对于如何减少dom节点，如何进行做css优化，如何做lazyload……倒是没提，反而讲了一些不那么相关的东西。 总之这种文章可以看看，但认真你就输了

@edokeh 不麻烦，你只是不熟悉所以觉得觉得麻烦而已。 相对技术投入和产出来说，用Varnish实现ESI是对页面片段做缓存的方案里代码改动最少以及性能提高最高的做法。 页面端只需要把模板拆开，本来的include代码现在变成了标签 后端则只需要把逻辑拆成可以用url访问的地址，然后设置过期时间等等 基本的ESI方案就已经完成了。 当然如果你项目所用的框架支持那就更好了，就比如Symfony2就可以对ESI做无缝的集成，而且Symfony2模拟了Varnish对ESI的实现，也就是说即使你没有Varnish，依然可以用ESI。

这个标准有点年头了，最早是Akamai定的，完整的实现也只有Akamai自己的系统才能支持，开源的方案里Varnish只是支持了一部分而已。

朋友，转载多不代表就是正确的，与其说这些媒体和转载者是被内容吸引，倒不如说是被标题吸引，毕竟“如何做到一秒渲染一个移动页面”这个标题实在是太有诱惑力了，很轻易就会让人漏看“移动”二字，以为任何页面都可以一秒内渲染完成。大部分小白没有自己判断的能力，看到满篇的英文也不会去细心阅读，他们只是看到文章来自Google，就盲目地认为Google大神又出来拯救地球，于是带着崇拜的心理盲目地进行转载罢了。 这篇文章最关健字的字不是“1秒”，而是“移动”，不是因为Google的这个工具有多强悍，而是因为在给移动设备使用的页面中，页面中的元素普遍很少，图片尺寸小，各种外链少，所以整个页面被优化在1秒以内是可以达到的。 这就像耍了个花招一样，还是具个汽车的例子：就像某厂商说自己的车在某小城市测试下来发现车性能很好，市区里也开得很快。但其实呢？不是因为车有多好，而是因为小城市里车流量本来就很少，车自然可以开的很快。

update your composer. change ``` "rwoverdijk/assetmanager": "~1.3", ``` to ``` "rwoverdijk/assetmanager": "1.3.1", ```