1. HTML5终于名正言顺地冲上历史的舞台,无论是应用还是游戏 2. HTTP/2第14个草案版已发布,正式版将于明年发布。通过引进报头字段 压缩以及多路复用来更有效利用网络资源、减少感知延迟(TTI)。另外还 介绍了服务器推送规范。 https://github.com/fex-team/http2- spec/blob/master/HTTP2%E4%B8%AD%E8%8B%B1%E5%AF%B9% E7%85%A7%E7%89%88(06-29).md 3. HTML5的调用能力和开发手法在变化。可以了解百度BlendUI 4. 尽管全栈工程师是后端课程,但我们拥抱移动互联网 3. 一切的前端优化是为了节省资源,最终优化成用户体验,其次,一切都在 飞速地变化,不要把所有的内容当作终极的教条 #Quickling 与 PageCache 5. 前端链接监听与处理 6. 好处:公共资源不用重复下载解析,只需要得到内容部分的 7. 更进一步:PageCache 缓存 8. 对比 AngularJS 的实现:admin-flatify 关于 onhashchange 事件的描述以下不正确的是? A. onhashchange 事件,在当今主流浏览器中都支持。 B. onhashchange 事件,在早期的浏览器里,可以采用较频 繁定期检测地址实现或者采用iframe实现 C. 如果不支持 onhashchange 事件,并不影响quickling技 术中的链接指向定位,但会影响前进和后退定位 D. 只要URL发生变化,就会引发onhashchange事件 实现要点 1 链接监听 2 历史管理器与永久链接支持 3 忙指示 4 统计时间变更影响 缓存问题 1 页面更新怎么办? 2 Ajax 获取(动态) 3 即时更新(评论) 效果 1 Quickling Reduce user perceived latency by more than 10% Save 10% of Facebook’s data center cost! 2 PageCache 10X speedup in user perceived speed Save 2% of Facebook’s data center cost!    这张图有什么特点? 1. 最大的特点是顺序执行,当然,在某些节点上有并行的因素 2. 其次是:步骤繁多,周期漫长,但远远不细 3. 用户在最后的步骤才见到页面! 4. 问题:有没有什么办法提速?今天给你不一样的答案 5. #BigPipe 演进 1 史前 认识到页面输出的局限性 • 页面没有完成,无以输出 2 演进中 我们可以通过Flush出内容,来获得提前 的内容输出,一步一输出 3 达成 先输出框架,再JS填充内容  Bigpipe 第二层次 1 资源下载与重用 • 事实的Bigpipe 还涉及到资源的处理 2 并行处理与输出 • 并行处理,实现真正的 Bigpipe 3 SEO 与搜索引擎友好 • 通过 UA(User Agent)的检测来判定,如果是搜索引擎, 不启用Bigpipe 做一个链接检测的例子 第一步:顺序处理 第二步:提供 flush 第三步:并行获取 第四步:不成功的子进程实验 一个 Bigpipe的第三方库 • https://github.com/linares/bigpipe • 支持资源 • 模拟FB的实现 有关bigpipe 以下说法不正确的是? A. bigpipe 的核心思想是并发输出,这个一般服务器都支持 B. bigpipe 是一种前后端相结合的优化技术 C. bigpipe 先输出页面框架,再输出内容 D. bigpipe方式,对比Ajax优化方式填充内容的好处在于并 不需要发起多个请求 答案a 1. 清空LocalStorage, 观测天猫的类目和楼层输出 2. Bigpipe是稍缓后输出内容,先让你看到框架,感 觉速度加快 3. 类目、楼层、瀑布流是到了才去取,不到不去取 前端性能优化神器 1. Firebug + YSlow 2. PageSpeed Insights 可能需要翻墙