不管是做前端开发还是测试，我觉得都应对网页内容加载和执行有所了解，特别是JavaScript，否则迟早都会得到教训，在我写此文之前就得到过教训，所以印象特别深刻，当时也为了搞明白其中缘由，查了些资料，现在终于有时间整理出来，也是承前面的《浏览器渲染原理及可能出现的bug》继续前端知识普及。
先说说当时我们遇到的一个问题：
网页第三方广告较多，出现严重客户端性能瓶颈；
第三方跟踪代码出现异常无响应，导致页面不显示图片。
为了解决以上两个问题，就需要了解以下知识。
JS执行时有两个特性：1. 加载后马上执行；2. 执行时会阻碍页面后续的内容，包括渲染和其他资源的下载。
再来看两个事件：
Window.onload：该事件要求网页内所有的元素全部加载完毕之后才会触发，如果网页里有很大的图片，flash等，加载时间非常长，那么我们的初始化函数会延时很久后才执行！在网速较慢的情况下，这样的延时往往是不可接受的。
DomReady：为了解决这个Window.onload的问题，很多JS框架提供了此事件，DOMReady 只判断页面内所有的DOM节点是否已经全部生成，至于节点的内容是否加载完成，它并不关心，所以速度更快。但是它并不是原生JavaScript支持的事件，不能直接使用，需要结合JS框架使用它。
因为JS的两个特性，所以很多网站都会把Javascript放在最后面执行，配合使用Window.onload或DomReady事件。而页面很多内容可能并不是非常重要的，那就又会引入异步加载。
关于异步加载，你可能听过这些内容：
AJAX
维基百科这么介绍：
AJAX即“Asynchronous JavaScript and XML”（异步的JavaScript与XML技术），指的是一套综合了多项技术的浏览器端网页开发技术。传统的Web应用允许用户端填写表单（form），当提交表单时就向Web服务器发送一个请求。服务器接收并处理传来的表单，然后送回一个新的网页，注意是新的页面，但这个做法浪费了许多带宽，因为在前后两个页面中的大部分HTML码往往是相同的。由于每次应用的沟通都需要向服务器发送请求，应用的回应时间依赖于服务器的回应时间。这导致了用户界面的回应比本机应用慢得多。
与此不同，AJAX应用可以仅向服务器发送并取回必须的数据，它使用SOAP或其它一些基于XML的页面服务接口，并在客户端采用JavaScript处理来自服务器的回应。因为在服务器和浏览器之间交换的数据大量减少（大约只有原来的5%）。结果，我们感觉服务器回应更快了。同时，很多的处理工作可以在发出请求的客户端机器上完成，因此Web服务器的负荷也减少了。这也是目前使用最为广泛的一项技术。
那具体实现Javascript载入方式有哪些呢？
Document.write
对于在同一个script标签里的JavaScript的代码来说，它不会阻塞后面的内容执行，但是对于整个页面来说，这个还是会阻塞，所以要尽量避免使用。
动态创建DOM
这种方式使用最为广泛，它能解决异步载入JS的问题，但是无法保证载入时机。为了解决时机问题，就需要绑定到具体的事件上。比如点击某个查询按钮或鼠标hover效果等来动态创建DOM。
延迟加载（lazy loading）
有些JS并不是页面初始化时就需要的，而是在稍后过程中才会用到，延迟加载就是一开始并不加载这些暂不用到的JS，而是在需要的时候通过JS控制来实现异步加载。例如大量图片的站点，可能只需要出现在可视范围内时显示即可。
了解了上面的内容，现在再来看出现过的那两个bug：
第一个问题就是因为过多的广告内容，加载内容很多，而没有使用异步加载，只是绑定了DomReady事件来加载资源，导致页面从请求到响应完毕需要大概9s多的时间，非常慢。为了解决这个问题就预先使用一张跟广告图片类似的打底图占位显示，再在页面其他内容加载完之后异步加载该广告，这样既可以解决性能问题同时还不会给用户带来较差的体验。
第二个问题是图片使用了延迟加载，并且绑定在domready事件上的，如果Dom能完全加载出来那就不会影响其图片的加载。而因为第三方服务器宕掉，发出的请求一直未响应，导致了其中dom节点未加载出来，导致延迟加载的脚本未执行，后来从DomReady改成了立即执行，即解决了这个问题。
通过这两次事件之后，目前所有要加载的第三方跟踪代码都需要通过前端开发人员的review和测试人员的细致测试才允许业务部门添加，把风险最小化。
===========================
关注微信公众账号“zzzmmmkkk”,不定期吐槽有关测试技术,测试经验,测试思考和生活感悟等。
