IE时代，每一个前端同学都要费尽心力兼容各代版本IE。如今IE虽渐渐淘汰，但移动互联网崛起，我们又有了新的麻烦。因为各个手机的屏幕不同，为了

作为一名合格的web开发人员，不应该仅仅满足于功能的实现，前端性能的优化也是我们必须要关注的问题。我们都不希望自己辛辛苦苦写成的代码，却因为优化不到位的问题，带给用户不好的体验。为此，我们可以做不少的事。

对于前端性能优化的讨论，一直都不是一个过时的话题，前有雅虎的35条黄金法则，后有O’Reilly 出版的两本性能优化圣经《高性能网站建设指南》、《高性能网站建设进阶指南》，这些都很值得我们学习，将会是我们在探索性能优化道路上的指路明灯。那么，我们首先来看看雅虎的军规吧，我选取了其中的一部分。

在进行网页开发的时候，一般会忽略到页面渲染给浏览器带来的性能问题；在实际情况中，浏览器进行页面渲染会进行大量的计算，来确定每个可见元素在屏幕上的精确位置、大小，还需要将每个确定好的像素绘制到屏幕上，这些操作都需要消耗大量的资源；如果反复的进行这些操作，对用户设备性能损耗不容乐观，因此希望通过这篇文章加深大家对浏览器渲染过程的理解，并希望大家能够重视渲染过程带来的性能问题。

做前端开发的同学应该知道：在移动端使用了 WebKit 内核的浏览器上，单击操作会延迟 300ms（也有延迟 350ms 的说法，下文统称为 300ms 延迟）后再执行。 造成延迟的

2011 年，Twitter 曝出一个 bug：当用户在滚动页面时，网站会变慢甚至无响应。John Resig 发表了一篇关于该问题的博客，并指出把高消耗的函数执行绑定在onscroll事件上是多么得不靠谱。下面以lodash中的debounce和throttle为例，来讲解函数节流在解决类似问题中的作用。

刷微博期间看见 @ruanyf 提出了一个问题与 TDZ 有关，但是貌似阮大当时还没有意识到这个问题，多亏一些其他业内同仁提出了与 TDZ 相关；当然，以阮大的能力这都不是事。由于当时我本身也还不知道 TDZ 这一回事没有看懂，所以就花了一些时间去搞清楚什么是 TDZ 及TDZ会带来一些什么问题，本文主要是用于介绍我对 TDZ 的一些理解，如有问题，多谢指出。

前言 关于 vertical-align，我们很容易想到，这不就是告诉我们元素在纵向上和什么对齐的属性吗？看似很简单的定义，在实战使用时却总是不

准确的说，HTTPS 不是一种协议，而是 HTTP 和 SSL 两种技术的组合，HTTP 本身所有的数据都是不加密的。

SSL ( Secure Socket Layer ) ，有时也称为 TLS ( Transport Layer Security ) ，是介于传输层和应用层的拓展层，可以将应用层数据加密后送入传输层。因此，使用了 SSL 传输的 HTTP 报文整体都是被加密的。

RDS（前端资源包分发系统），将原有的客户端资源包更新逻辑移至服务器端实现。统一IOS，ANDROID等平台的更新逻辑，统一入口，方便资源包更新算法的调整，监控资源包的分发，进行灰度发布。

设计

RDS 最基本的功能就是将最最合适的资源包版本分发给不同的客户端。

在此基础上，需要与前端资源发布系统进行合作，根据前端发布 Hybrid 资源包的流程，添加相应的功能。如资源包测试。

增量更新的使用已有一段时间，面对出现的一些问题，对初始的增量更新机制进行了扩展与优化。

丁香医生hybrid开发遇到的问题

1. 增量更新的安全

   如何保证客户端获取到的增量包不被篡改。

2. 资源包 diff 的不高效

   目前前端大多使用一些前端构建工具,如webpack, gulp, 将分散的源码合并成一个文件。在这种情况下，使用原先的 diff 算法并不能减少增量包的体积。