CSS魔法
@edokeh 对，移动端的产品设计+前端开发。以后微博常联系。
@fa-ge 抱歉，没有遇到过。在实际项目中应用还算稳定。可能我的动作还不够快 😂
@JulesCesar @rccoder 😂 真这么严重？ 我感觉比较稳定，已经在生产环境用了很久了。并且在 CMUI 中封装了一个组件 [Scroll Box](http://cmui.net/demo/v2/theme/baixing/scroll-box.php)，感觉挺好用的。
发现很多同学把焦点集中在“服务器 200 ms 响应”这一点上，这对后端的同学来说可能是一个挺大的压力。 这里分享一下我们网站的实践，抛砖引玉： 所有跟用户身份无关的页面（首页、产品列表与详情、帮助中心等），一律采用“整页缓存”——当这些页面由服务器动态渲染完成之后，就保存到 Memcache 中。下次当用户请求相同页面时，直接从 Memcache 中取出已经渲染完成的整页 HTML 代码，返回给客户端。这样可以将页面响应时间控制在几十 ms 这个量级。 不过这些页面中也会出现一些和用户身份相关的少量信息，比如顶部导航中的用户名、用户状态、购物车数量等。我们的解决方案是通过 Ajax 接口异步加载这些信息，并在前端适量缓存。 而对于那些跟用户身份直接相关的页面（比如用户中心、结算流程等），就无法使用“整页缓存”的方法来做优化了。
@scourgen 哇，开博以来最长的评论，受宠若惊！链接已修正，谢谢提醒！ :thumbsup: 链接错误的问题不是因为文章老（我也不确定是不是真的很老），是因为我在把 HTML 转换为 Markdown 的时候没有处理好相对链接，所以……你懂的，哈哈。 另外，顺着你提到的几个槽点展开讨论一下吧。 **“整页缓存”的应用范围不广**。这个还是要看业务。我们做电商，所以几乎所有的前台页面都可以用这个方法来加速，而且实际效果也很理想。如果是做 SNS，那确实会不一样。 **把动态页面拆成许多个 component 分别做缓存**。这其实跟“整页缓存”不冲突，因为我们也在用“区块缓存”，当整页缓存没有命中、需要动态渲染时，就会用到区块缓存，原理也跟你说的类似。但这个速度（在我们的系统上）要低一个数量级甚至更多，所以一般都会避免不必要的动态渲染。 **Memcache vs Varnish/ESI，整页缓存 vs 区块缓存**。坦白说我对后端架构完全不在行，对于技术选型和实施，我完全信赖我们的后端架构师。而且技术本身并不是目的，（在当前的系统架构、业务场景、甚至团队结构等等条件限制下）实现预期的优化效果才是真正的目的。所以，对于选用的技术是过时还是拉风，实际上作为产品负责人，我并不是那么纠结啦。当然你建议的方案我会转达给架构师，嘿嘿。
接着聊。 **“此文没有技术含量/假大空/做广告/炒冷饭”**。这个观点是最有意思的，可以好好聊一聊。我实在是忍不住要把这个话题展开，单独写一段。 我在动手翻译之前，就有点小犹豫。因为 36 氪转载了 TheNextWeb 的“一秒渲染”新闻并且 [发到微博](http://weibo.com/1750070171/A3X4urjmR) 后，立刻就有大牛出来拍砖，说 Google 炒冷饭、说 36 氪哗众取宠。我当时那个汗颜啊，因为我自己看了 Google 的这篇文档觉得很有收获啊！ 犹豫了一下，还是决定翻译出来、给更多人看到。因为我自己觉得有用，应该也会有其它人喜欢。于是花了一天左右的时间翻译出来，[发到微博](http://weibo.com/1645021302/A4pML2pHc)，随后很快被几个大号转发转载。这篇文章目前在微博上的累计转发量超过两百，是本人开博以来最受欢迎的文章，没有之一。 很多同学都表示“有收获”、“有启发”，我就觉得这一天时间花得很值。不过还是有大牛出来拍砖，说没有干货……所以我觉得吧，每篇文章都有不同的受众。就像我在微博评论里说的： > 大牛们食之无味，不代表我等小白学不到东西，哈哈。 说它夸大其词夺人眼球，我觉得只要学到东西了，就算真被“忽悠”、被“广告”了又何妨？ 说它言之无物避重就轻，没错，文章确实没有手把手地教授读者如何逐一实践这六条准则；不过俗话说得好，“师父领进门，修行靠各人”。一篇文章告诉我们一些准则和思路，甚至带来一些启发，它的作用就已经达到了。文章的价值在于激发你去思考，而不是代替你去思考。 没有干货，就去创造干货吧，少年！
转发转载记录： - [微博] developerWorks： //weibo.com/1894238970/A4vMg4iGa - [微博] 伯乐在线官方微博： //weibo.com/1670481425/A4B9WloLY - 伯乐在线： //blog.jobbole.com/45648/ - [微博] HTML5梦工场： //weibo.com/2717844351/A4P20grIT --- 记录这个并不是为了显摆，主要是想收集反馈，顺便观察一下传播效果。
@scourgen 谢谢回复。 我认同你在第一段所说的，媒体都喜欢“耸动”的标题，这个标题也必然会吸引大众。事实上，我自己就是被 36 氪的报道激发起好奇心，然后追踪至原文的。但只要读完原文，真相自然洞穿。从被挑逗勾引、到掀起盖头、然后摸清套路、再到据为己有，这是一次很过瘾的消化吸收的过程。但凡留点心眼，都能各取所需。 如果看完了**中文翻译**，仍然没有抓到重点，仍然在盲目转发，这样的“资深小白”我承认可能真的会有。但我不会因为有这种特例的存在，就否定文章的价值，然后放弃传播。 所以总的来说，我承认你指出的“耸动标题的危害性”，但我认为它同样会激发有心人的求知欲。甚至从传播的角度，我希望好文章们都能有一个“好标题”。 :smile:
再发几个延伸阅读： - 《Creating High-Performance Mobile Websites》(英)： //mobile.smashingmagazine.com/2013/08/12/creating-high-performance-mobile-websites/ - 《创建高性能移动 web 站点 》(翻译)： //www.oschina.net/translate/creating-high-performance-mobile-websites - 《How To Make Your Websites Faster On Mobile Devices》(英)： //mobile.smashingmagazine.com/2013/04/03/build-fast-loading-mobile-website/ - 《让你的网站在移动端健步如飞》(翻译 @jtyjty99999)： //www.w3cplus.com/performance/build-fast-loading-mobile-website.html
> iPhone上的Safari可以说是没有缓存的。 @ZE3kr 愿闻其详。