通过iframe改善第三方脚本的性能

视频链接： http://geekcantalk.com/post/75874289073/improving-3rd-party-script-performance-with-iframes

We all know the rule. The best way to reduce network latency is to eliminate the network. Resources read out of a browser’s cache typically load up in 0-1ms. Setting your resource’s max-age to a very long time (like 10 years) tells the browser that this resource is never going to change. But as web developers, we also know that everything changes.

我都知道定律是什么。最好的减少网络延迟的办法就是压根不访问网络。从浏览器缓存里读出资源通常只需要0-1毫秒。把你的资源的max-age设置成一个很擦汗那个的时间（比如10年）可以告诉浏览器这个资源永远不会改变。但是作为web开发者，我们知道什么都可能会改变。

The common solution is to use versioned URLs. When a resource on the server changes, simply change its URL and the browser will load up the new version. This has two problems. Third-party widget providers cannot expect all of their customers to update all of their pages every time a change is pushed out. Even if they could, if the change is a critical security issue, there may not be enough time to wait for everyone to update their URLs. It also means that the browser uses up more of its cache, since it’s now holding on to an old cache entry that will never be used. This entry will eventually be purged by theLRU algorithm, but until then it takes up some space.

The solution, is to use a self-updating script with a far-future expires header.

Third-party scripts also have another problem. Unless they’re loaded after the onload event fires, they will block onload, and this could have a negative impact on page performance.

In this talk, we’ll discuss the code to load up a script in parallel with the page without blocking onload, and then the code to get this script to self-update when required.

We’ll cover all pre-requisites for such a script, and all issues that we’ve noticed while running this in production at LogNormal for several months. At the end of this talk attendees will have everything necessary to decide if they need to use these techniques, and how to do so if they do.