淘宝广告技术部李牧同学， 在懒懒分享了《广告前端代码优化》，分享内容充实、实战经验宝贵，其多维度的解决方案更是令人大开眼界。

1. 广告前端代码优化 开发无阻滞、无侵扰、无延迟的广告前端代码 淘宝 广告技术部 李牧 2010年7月30日

2. 1 第三方内容对网站速度的影响 2

4. 页面是复杂的:44个请求来自7个域名,平均大小320KB

5. 很多加载的内容来自第三方3

6. 第三方内容对网站速度的影响 Third-party Publisher site % Impact Digg services.newsweek.com 14 第三方内容对页面加载时间的影响: Digg realtalkny.uproxx.com 9 FriendConnect www.artinstructionblog.com 10 FriendConnect friendconnectdirectory.com/Food 30 FacebookConnect truveo.com 17 FacebookConnect www.huffingtonpost.com 12 TribalFusion www.xe.com 53 TribalFusion www.wareseeker.com 31 Google Adsence top 100 publishers 12.8 Google Analytics top 100 publishers <5 Google Doubleclick top 100 publishers 11.5 4

8. P3PC 项目专注于第三方内容的性能分析.

9. 目标是找到让第三方内容更快的关键点,促进第三方的改进性能.5

10. P3PC:第三方内容性能分析 下表是P3PC 给出的第三方内容主要性能指标,从中我们可以清晰看到P3PC主要关注哪些方面. 6

11. 2 广告埋点分析,优化思路和限制 7

12. 广告埋点是怎样结构?如何运行? 8 <script> alimama_pid="mm_12852562_1778064_8320227"; alimama_sizecode="910"; alimama_width=270; alimama_height=390; alimama_type="i"; </script> <script src="http://a.alimama.cn/inf.js"></script> 广告位信息 客户端信息 PV Session信息 所属网页信息 inf.js document.write: <iframe(script) src="http://t.alimama.com/alimama.php? i=mm_1_1_1&t=2&h=760&w=90&cf=10.1&ctz=8 &cg=6bd079cde47&u=a.com%2Fa.html "></iframe(script)> 1 2 5.Http请求附加信息:IP,Cookie,UA(浏览器标识),Refer等 3 4

13. 选择这种埋点技术带来的好处 业务要点: 位置明确+接口简单+速度+安全+客户端信息 方便安排广告展现位置:广告出现在埋点所在处. 接口代码简单,而且发布代码可以嵌入HTML,也要能被嵌入到JS通过document.write输出. 保障广告展现速度:页面解析到埋点处立即触发广告展现 保障按效果计费类广告安全:展现在广告域的iframe中 收集足够的客户端信息:inf.js保证了动态展现请求中包含足够的信息.竞价类广告的广告请求中必须包含这些信息. 所依赖的技术实现要点: 静态<script>节点 + document.write("<iframe>") 9

14. 埋点带来的性能问题 inf.js阻滞页面加载 inf.js文件较大,Gzip后11k,Gzip前38k. 一个页面多条广告时,JS重复加载和执行 doc.write引入的Iframe节点性能不佳 doc.write引入动态script节点依然阻滞页面 inf.js文件缓存时间较短(2小时) 代码发布在客户的网页上,无法实现永不过期策略. 代码出现位置未知,容易出现无法预知的问题,所以缓存时间仅2小时. 10

15. 埋点引入SPOF(单一故障点)带给合作网站稳定方面的侵扰 SPOF: A single point of failure (SPOF) is a part of a system which, if it fails, will stop the entire system from working. (一个会被反复提及的概念) 阻滞不仅仅是速度问题还涉及客户网站的稳定! 客户网站稳定依赖CDN上inf.js的稳定 还可能依赖doc.write("<script>")指向的动态广告服务的稳定 而当严重阻滞发生时,问题主要出现在HTTP建立连接,等待响应等阶段.往往和文件大小关系不大了. SLO-JS and how to speed up widgets 11

16. 第三方埋点代码优化思路 以及我们在优化时无法绕开的限制 思路一: 推倒!让用户修改发布代码! 寻找不依赖静态<script>节点和doc.write的解决方案.(案例: dojox.analytics.Urchin对GA的封装,GA自身的改变) 思路二: Fast By Default!尽最大可能提升每天数十亿已经加入了广告埋点网页的速度.(案例:Google Adsence在Velocity2010最近披露的优化方案) 待解决问题和业务限制: 脚本阻滞x2+文件大+缓存短+重复加载 需要解决! 位置明确+接口简单+速度+安全+客户端信息 不能牺牲! 12

17. 3 无阻脚本下载方案 13

18. 无阻脚本下载方案 Steve: Loading Scripts Without Blocking 14 脚本存在于不同域名下 无阻加载备选方案: Script Defer Script DOM Element Doc.write Script in Iframe Doc.write Script in Iframe

19. Defer载入脚本或 DomReady时展现广告.速度不符合要求 15 国内前十大网站主要页面的domready时间数据采样: 大量页面DomReady时间在1.5s以上,在onload总时间的50%之后. 所以可以得到结论:Script Defer技术异步加载广告脚本不可行. 同时可以得到结论:在DomReady事件中展现会严重拖后广告展现速度,影响广告效果

20. Script Dom Element 真异步!真无阻? 玉伯:Script 元素的异步加载属性 async-test.js: var g = 1; <script> function scriptDomElement(u) { var a = document.createElement('script'); a.src = u; document.getElementsByTagName('head')[0].appendChild(a); } scriptDomElement('async-test.js'); </script> <script> alert(typeof g); // 预期结果是 undefined, Firefox 3.6 弹出 number </script> 16 a.async = true; 阻滞并不仅仅是平行下载的问题,还要区分下载阻滞和运行阻滞. 上面的场景,如果async-test.js比较慢,会在下一个script节点处导致运行阻滞. 上面代码在给script增加了async属性后,除了Opera浏览器都做到了真无阻.

21. Script Dom Element 是否稳定?展现速度是否有延迟? 17 Script Dom Element技术代替静态script埋点的另一个关键是其稳定性和速度如何? 在复杂的网页上下文环境中,浏览器是否会及时的启动异步脚本的加载和执行? 我们在inf.js内选取部分流量做了一些测试:

22. 在CND上准备1.js, 2.js, 3.js (Gzip后7k)主要运行一句话: alimama_test.callback("1"); 方法一:模拟静态script埋点加载脚本 document.write("<script src='1.js'></script>"); 方法二:直接通过Script Dom Element 加载脚本 scriptDomElement("2.js"); 方法三:用setTimeout包裹,(同YUI2中内部调用了Y.later的Y.Get.script方法) window.setTimeout((function(){scriptDomElement("3.js");}),0); 在随机选中的PV中让这三个方法按照随机顺序执行分别执行 Script Dom Element 稳定和速度测试 18

23. Script Dom Element 稳定测试结论 19 综述:两天的测试中doc.write,scriptdom,timeout0+scriptdom三种方法收到PV基本一致,说明Script Dom Element基本可靠 紫色区域提示:在非IE浏览器中doc.write表现不佳,请求丢失率较高 蓝色区域提示:settimeout0+scriptdom在IE下表现不佳,请求丢失率稍高

24. Script Dom Element 速度测试结论 20 速度测试关注两种script dom方法与doc.write的载入js后执行callback的时间差 综述:script dom相比doc.write有近8%的请求慢300ms以上,待定. timeout0+script dom则有35%左右的请求慢300ms以上.淘汰之. 蓝色区域提示:有很多时候domscript是快于doc.write的,这和我们让参与测试的三种方法按随机顺序执行相关. btw:在性能要求高的情况时考虑优化YUI2的Y.Get.script()?

25. Doc.write Script in Iframe无阻滞脚本下载的又一个方案 21 function dwScriptInIframe(s){ document.write("<iframe id= 'testiframe '></iframe>"); var d = document.getElementById("testiframe").contentWindow.document; d.write('<!doctype html><html><body><scr' + 'iptsrc="'+s+'"></scr' + 'ipt></body></html>'); window.setTimeout((function(){d.close();}),0); } dwScriptInIframe("4.js"); 没有src的iframe的location和父页面相同,所以不存在跨域问题. iframe内的脚本下载对父页面其他内容而言是无阻滞的.

26. Doc.write Script in Iframe速度测试结论 22 综述:doc.write script in iframe相比doc.write同样有9%的请求慢300ms以上,也加入备选方案 蓝色区域提示:速度差超过300ms的基本请求均分在1000ms左右. 紫色区域提示:非IE浏览器中,Doc.write Script in Iframe比IE好,也比Script Dom Element要好.

27. Doc.write Script in Iframe技术存在的问题 23 Google的提示 在一个页面不同iframe内载入相同的JS,其中前一个请求可能会被IE取消(abort); iframe中由JS输出的图片.在前进后退或刷新时可能会被再次请求,而此时JS输出内容可能已经发生变化. 其他问题 iframe中window变化,需要对JS进行一些加工 iframe引入额外的性能消耗 Firefox可能无法直接获取iframe的引用,比如: document.write("<scr"+"iptsrc='1.js'></scr"+"ipt>") dwScriptInIframe("4.js");//代码中getElementById("testiframe")执行出错

28. Doc.write Script in Iframevs. Script Dom Element 两种技术都能做到无阻滞. 都能够做到无侵扰,不引入SPOF(单一故障点). 都略有延迟,8%左右的反馈慢于直接doc.write引入的JS300ms. 在直接较量中,测试收到的25013次反馈中,有14404次Doc.write Script in Iframe先返回.略占优. 如何选择?期待您的建议! 24

29. 插!测试结论:页面loading过程中的new Image() 不太靠谱 25 同样的测试方法 测试三种在页面载入时植入img埋点做PV统计的做法: 方法1： document.write('<imgsrc="1.gif" />'); 方法2：(new Image()).src="2.gif"; 方法3：window.setTimeout((function(){(new Image()).src="3.gif";}),0); 在复杂的页面环境中,IE6,7下(new Image).src=”..”的做法不靠谱, IE6中85%的请求服务端收不到,即使使用了setTimeout,依然有20%以上的丢失.所以不要使用这种写法

30. 4 解决使用无阻脚本下载方案引入的其他问题 26

31. 解决广告所在位置问题 使用异步下载方案随之而来的第一个问题是广告出现在哪个位置,两种方案: 用户指定广告容器 在发布代码的in-line脚本中通过document.write一个锚点做参照. 27 <div id="c1"></div> <script> insertAsyncScript("http://adhost/?cid=c1"); </script> <script> document.write("<a style='display:none !important' id='a1'></a>"); insertAsyncScript("http://adhost/?aid=a1"); </script>

32. insertAdjacentHTML插入广告内容 28 function showAd(sHTML,anchor,container){ if(anchor){ anchor.insertAdjacentHTML("afterEnd",sHTML); }else if(container){ container. insertAdjacentHTML("afterBegin",sHTML); }else{ document.write(sHTML) } } showAd("<a href='1.html'><imgsrc='1.jpg'/></a>", document.getElementById("a1"), document.getElementById("c1")) insertAdjacentHTML@W3C HTML5insertAdjacentHTML@MSDN FireFox不支持insertAdjacentHTML! 在服务端根据UA决定输出内容.....

33. 页面Loading过程中的Dom安全操作(避免IE进程崩溃) 29 小马:“无法打开 Internet 站点 已终止操作”前因后果 这种错误很可能直接枪毙掉上面的使用anchor解决位置问题的方案. 而可能的解决方案类似YUI针对节点的onContentReady事件 YUI2YUI3 : Executes the callback as soon as the specified element is detected in the DOM with a nextSibling property (indicating that the element's children are available, determine if the content of the available element is safe to modify. ) 但这会延缓广告展现速度,如果有更好的方案还请不吝赐教!

36. 5 inf.js 优化进行时 32

39. 首个广告请求加载内容从11k下降至6k左右,但多一个脚本请求.

40. 在用户不修改发布代码前提下,页面第二个广告的加载量仅2k.

42. 对写法的简化(lang,selector…)补强部分是Mashup亟需的:

43. 扯远点:本地存储 + eval可行? 36 velocity2010：TCP and the Lower Bound of Web Performance 数据在美国东西海岸走一圈要90ms (侧面说明不是传10k要90ms 那么1k就只要9ms.) 理论上读取本地数据一定是快的 但客户端缓存很小经常被冲刷掉 本地存储+eval是否会有帮助? (BannerMaker会在Flash中首先做一些类似尝试.) eval性能问题:GoogleMap中测试结论是eval对性能的影响可以忽略. Diffable: only download the deltas eval安全问题:本地文件容易被篡改,我们没有完全安全的沙箱保证eval出的代码不对外产生干扰.

44. 6 期望:所有第三方内容都能做到不引入SPOF(单一故障点) 37

45. 钻石展位无阻埋点遇到的问题 在钻石展位我们提供了无阻埋点,而遇到的问题是,当我们需要通过我们的埋点再引入其他第三方通过JS投放的内容时(icast视频),引入的代码包含document.write()...问题无法解决 所以投放这类广告埋点只能使用原有的埋点模式 重写document.write方法,实现起来很困难.(本以为Google会在"Don’t Let Third Parties Slow You Down"介绍阻滞变无阻的魔术...) 38

46. 统一的锚点和容器命名规则无Doc.write的第三方内容开发 比如我们统一将动态script服务指定回调函数名参数定义为jsonp 比如我们统一的使用ClickTAG作为传入Flash的点击串地址. 希望容器ID或者锚点ID,或者任何能够去除第三方引入SPOF有效解决方案,在第三方开发者当中有统一的规范. 期望所有第三方开发内容都成为无阻滞,无侵扰也无延迟的三无产品. 最后补充一点,更应该形成规范的是第三方内容脚本开发涉及的安全问题.另一个让人无比头疼的问题.好在巨头们(YAHOO,GOOGLE)已经有所行动.这是另一个话题了. 安全,还有今天强调的稳定是第三方内容去追求速度的前提! 39

47. Thanks All! limu@taobao.com http://twitter.com/leneli 40