Internet Explorer 9 Network Performance Improvements


The browser’s networking subsystem is a crucial component for delivering a high-performance Web experience. In today’s post, I’ll demonstrate this using some real-world measurements, showing that even in a “fast” network environment, the network time dominates the time spent in other subsystems that affect page load time. Next, I’ll provide a brief tutorial of how Web browsers use the network, and outline the improvements we’ve made in Internet Explorer 9 to help ensure speedy page loads.

Real-world Browser Performance and Networking

Last year, we analyzed top sites to measure how much of the overall page load time was related to time spent retrieving content from servers. We ran the tests in what we consider a “fast” environment, on an Intel Core2 2.4ghz running on an 802.11N network connected to a 20MB/sec cable modem. For each iteration of each site, we took 4 measurements of page-load-time (from about:blank to top-level document complete) measuring both PLT1 (clear cache) and PLT2 (primed cache) in “real world” conditions and in an “ideal” world in which network time was zero’d by returning all resources instantly from a proxy located on the local computer.

The results from six representative sites are shown in the following set of charts, one for each site tested. Each ring represents the ratio of “non-network” time (red) to “network” time (blue). The outer rings represent the ratio for the first page load (“clear cache”) while the inner ring represents the ratio for the second visit (“primed cache”).

Chart of six Web sites showing their network vs. non-network load times

As you can see, there’s a wide range of network performance ratios. For sites that make good use of caching (e.g. those in the third column), very little time is spent on the network for PLT2 because the vast majority of content is cached locally in the browser cache. For other sites, while the overall load time in PLT2 is much faster than PLT1, network time still represents the biggest component of page load time because even a single network request takes a relatively long time.

These findings show that even in a “fast” network environment, the network time dominates the page load time. On the initial page load, downloads account for 73% of the time needed to load the page; on a subsequent reload, 63% of the page load time is spent waiting for resources.

Chart showing overall network vs. non-network load times

Stated another way, this set of sites initially loaded in a total of 17 seconds, which would be reduced to 4.6 seconds if not for download time. On reload, the sites loaded in 6.7 seconds, which would be reduced to 2.5 seconds without download time.

Now that we’ve looked at the “real world” impact of network performance, let’s examine the sources of network delay.

Browser Networking 101: Where the bottlenecks are

Every time your browser loads a Web site, an intricate set of steps occurs behind the scenes. A brief summary of these steps follows:

If your computer is not running behind a Web proxy, then your browser uses the network to perform a DNS lookup to convert the hostname you’ve typed (e.g. www.microsoft.com) into the network address (e.g. 65.55.12.249). The browser must then establish a TCP/IP network connection to the target address.

If your computer is running behind a Web proxy, your browser must first locate the proxy. The proxy might be specified directly within your browser settings, or located via a process called Web Proxy Auto-Discovery Protocol (WPAD). After the hostname of the proxy is determined, the browser uses a DNS lookup to convert the proxy hostname to a network address. The browser then establishes a network connection to the proxy server.

If the URL calls for a secure connection (HTTPS) then a SSL or TLS handshake must take place, and the certificates from the server must be verified. This can result in one or more additional network requests to Certificate Authorities (called “Revocation checks”) to ensure that none of the certificates in the chain have been revoked.

After the connection has been successfully established, the browser must send a HTTP request to the server. The server, upon receiving the request must load (or generate) the requested file and begin transmitting it to the client. If the document is a HTML file, it will typically contain references to other resources (e.g. images, script, stylesheets) that must also be loaded in order to fully display the Web page. For each resource referenced by the page, the browser must typically repeat many of the previous steps in order to download the resource needed.

Many of these operations must be performed serially (for instance, you cannot establish a TCP/IP connection without first obtaining the IP address using a DNS lookup) and hence delays in any one operation can dramatically increase the load time of the page.

In some cases, operations can be parallelized or caches can be introduced to reduce the risk of delay. Internet Explorer 9 makes use of both techniques for enhanced performance, as I’ll explain in the remainder of this post.

Faster Networking through DNS Pre-resolution

The Domain Name System (DNS) allows the client browser to convert a hostname into a network address. This process may take between a few milliseconds to several seconds; one recent study pegged the US Median at approximately 150ms, although there is wide variance. Because the browser can only begin establishing a network connection after determining the remote address, DNS is the first bottleneck in network performance.

Internet Explorer 9 includes three optimizations for improved DNS performance; all of these optimizations are based on the fact that multiple DNS requests may be issued in parallel.

Address Bar DNS Pre-resolution

After the third character you type into the address bar, Internet Explorer will issue DNS resolutions for the top 5 hostnames in the dropdown. The results of these resolutions will be stored in the local operating system cache for quick reuse in the future. In this way, if you subsequently navigate to one of these top matches, the browser will have a small head start and will spend less time waiting for DNS results to be returned.

Speculative Pre-resolution for Visited Sites

When you visit a page, Internet Explorer 9 will annotate the page’s history entry with the list of hostnames that were contacted to download content used by the page.

For instance, when loading the IEBlog, the HTML references resources from five other sites (i.msdn.microsoft.com, cdn-smooth.ms-studiosmedia.com, go.microsoft.com, ie.microsoft.com, and silverlight.dlservice.microsoft.com).

Internet Explorer 9 stores these five hostnames in the history entry for the IEBlog site. If you begin to navigate to the IEBlog in a future browser session, Internet Explorer will immediately issue DNS resolutions requests for these five stored hostnames, in parallel with establishment of a connection to the blogs.msdn.com server. This helps ensure that when the blog’s HTML is subsequently returned from the server, the local DNS cache will typically already contain the network addresses needed to download the page’s embedded resources.

Page-initiated Pre-resolution

Internet Explorer will also resolve any hostnames for resolution that are specified by the Web developer in a LINK REL=PREFETCH element. For instance, with the following markup:

<link rel=”prefetch” href=”http://www.example.com/someresource.htm”>

…Internet Explorer will kick off a DNS resolution for www.example.com. That way, if a connection is later made to www.example.com, the DNS resolution will have already occurred and the browser can immediately connect to the server without pausing to look up its address.

Faster Networking through Proxy Improvements

Many corporate users are configured to browse the Web using proxy servers, and proxies can have a network performance impact. To that end, we’ve made two key changes to improve performance in an environment that requires a proxy.

First, Internet Explorer has moved its proxy determination logic from the tab processes to the single unified frame process. This helps ensure that when the Web Proxy Auto-Discovery (WPAD) feature runs (and it may take from tens of milliseconds to multiple seconds) it only does so once per browser session, no matter how many browser tabs you open. This also saves some CPU time and nearly 500kb of memory per tab process. The proxy determination improvement can significantly improve the performance of starting a new browser tab and loading a site into it.

Second, Internet Explorer 9 increases the connections-per-proxy limit to 12. This allows the browser to perform more downloads in parallel as compared to IE8, which enforced a six connection limit when using a Web proxy. While the browser’s connections-per-host limit remains 6, many sites use resources from multiple domains and thus benefit from the higher connections-per-proxy limit.

Faster Networking through Parallelism

As mentioned in the DNS Pre-resolution section, doing more work in parallel is a great way to improve overall performance. Some of the browser’s network operations are not inherently sequential and time can be saved by doing work in multiple threads simultaneously.

For instance, we noticed that virtually all sites end up using more than one HTTP connection per hostname, and time could be saved if we open a second “background” connection when establishing the first connection. This background connection is available for the next HTTP request without forcing it to wait for the original connection to become available, and without the delay of opening a new connection in a “just in time” manner. Only one background connection is opened per host, and this improvement can save tens to hundreds of milliseconds when loading a page.

Next, we noticed that in some cases we had a blocking behavior in our connection handling, whereby there were multiple (e.g. 3) open connections to a server, but opening another connection to the server (#4) was delayed until a prior request had completed, even though the connections-per-host limit of 6 meant that we could open a new connection right away. We’ve removed that blocking behavior and allowed more work to finish in parallel.

Lastly, we observed that we could allow the browser to get download requests for images out onto the network more quickly by enabling the lookahead downloader to kick off image file downloads. In support of the HTML5 specification, we also tweaked the image download code to prevent images with an empty source (e.g. <img src=”” />) from making a network request.

Faster Networking through Cache Enhancements

Of course, the most effective way to ensure great network performance is to eliminate network time entirely. The Temporary Internet Files cache allows IE to reuse previously downloaded content without re-downloading the content over the network. Last summer, I summarized a number of caching-related improvements in IE9 that help the browser make better use of the cache. Today, I’ll build upon that post by explaining the other work we’ve done to enhance the functionality of the cache.

Cache Size

Internet Explorer 6, 7, and 8 limit the Web content cache size to 1/32 of the disk capacity by default; in IE7 and IE8, the default capacity value is capped 50 megabytes. Virtually all hard disks in use today are larger than 1.6 gigabytes, which means that nearly all users of IE7 and IE8 are browsing with a content cache limited to 50mb.

Internet Explorer 7’s default 50mb cache size was introduced because analysis in the Windows Vista timeframe showed that the browser’s cache-hit ratio was not significantly improved with caches larger than that size. Beyond consuming more disk space, larger caches can take longer to enumerate and clear (for instance, when performing the Delete Browser History operation). Therefore, an important design strategy is to only increase the cache size when an improved hit rate will result.

In IE9, we took a much closer look at our cache behaviors to better understand our surprising finding that larger caches were rarely improving our hit rate. We found a number of functional problems related to what IE treats as cacheable and how the cache cleanup algorithm works. After fixing these issues, we found larger cache sizes were again resulting in better hit rates, and as a result, we’ve changed our default cache size algorithm to provide a larger default cache.

Internet Explorer 9 has a default cache size limit of 1/256th of the total disk capacity, with a cap on the default to 250 megabytes. The new ratio was chosen to help ensure that low-end netbooks with tiny solid state disks are not impacted by (relatively) huge caches, while desktops with large disks will default to a 500% larger cache vs. IE8. A disk as small as 16gb will result in increase in the default cache size between IE8 (50mb) and IE9 (64mb). Any disk larger than 64gb will reach the default cap of 250mb. In all versions of Internet Explorer, you may manually adjust the cache size limit (within the range of 8mb to 1gb) using the Tools > Internet Options > General > Browsing History Settings dialog box.

If your Temporary Internet Files are stored on a high capacity disk drive with plenty of free space, you may be wondering if you would benefit from configuring an even larger cache. It is definitely possible, but our analysis suggests that increasing the limit above 250mb only results in benefits for some browsing patterns. Importantly, the caching system is internally limited to storing approximately 60,000 objects. Depending on the size of your cache and the size of the resources you download, you may encounter the object count limit before encounter the size limit.

Technical Note: Internet Explorer maintains two caches, one for content used in Protected Mode (Internet and Restricted Zones) and one for content used outside of Protected Mode (Intranet, Trusted, and Local Computer zones). Each cache is individually capped at the limit, so the aggregate maximum disk space consumed by caches is double the individual limit.

Cache Cleanup

As mentioned in the previous section, our analysis of the cache cleanup algorithms used in IE8 and below indicated significant room for improvement. As a result of that analysis, we’ve substantially rewritten the cache scavenger (which removes low value entries to free up cache space) for Internet Explorer 9. The new scavenger is significantly more likely to retain valuable entries (those cache entries which are likely to be used again) by discarding less valuable entries.

Internet Explorer’s cache scavenger is kicked off as the cache limit (size or object count) is approached. Its goal is to remove the least valuable 10% (by size) of the objects in the cache. It does this by enumerating the objects in the cache. In the first pass, it assigns each a score between 0 and 66,000. In the second pass, it deletes the entries which are ranked in the lowest 10% of the scores.

In IE9, we’ve made significant changes to how the scores are calculated to better ensure that the most valuable entries are kept and the least valuable entries are discarded.

Of the 66,000 possible points, 40,000 points are determined by how recently a given resource was used. 20,000 points derive from how often the resource has been used, and 6000 points derive from the presence of validator information (HTTP response headers like Last-Modified and ETag) that allow conditional revalidation of resources after their freshness period expires.

We also take the MIME type of the resource into account; script, CSS, and HTML/XHTML resources receive full credit, while other resource types (e.g. images, audio, etc) receive only half of their allocated points. This helps ensure that the resources which have the greatest impact on page load time survive in the cache longer than lower priority resources.

Cache entries that have been used more than once receive an increasing number of reuse points; to get more than 10,000 points, the resource must have been reused over a period longer than 12 hours. This helps prevent resources that were reused frequently but only within a short period (e.g. when you’re browsing around a site you rarely visit) from getting the same amount of credit as a resource that is reused frequently across a long period (e.g. a script on a site that you visit every day).

Entries which have validators collect validator points, but the biggest impact of validators occurs after resources are no longer fresh. Any resources which have expired and do not contain validators receive a score of 0 points (since they cannot be reused nor revalidated), while those with validators retain 70% of their score. Expired resources with validators retain most of their score because they allow the browser to quickly recheck the freshness of a cached resource– the server may reply with a small HTTP/304 response (with no body) indicating that the cached copy may be reused.

The scavenger is also sensitive to a number of special cases—for instance, no resource will be scavenged for the first 10 minutes after it was downloaded, and resources that exceed the cache size (e.g. downloading a 4gb ISO file) are temporarily exempted from scavenging to permit the download to successfully complete.

Faster Networking through Content Filtering

Internet Explorer 9 also includes new Tracking Protection and ActiveX Filtering features. Both of these features can improve your overall browser performance by preventing download and execution of undesired content. For instance, when loading the homepage of one popular news site, enabling the ActiveX Filter and one popular Tracking Protection list results in a significantly faster page load:

HTTP Request Count Bytes Sent Bytes Received Page load time
Filtering Disabled 168 98.5k 1.9M 7.5s
Filtering Enabled 138 71.7k 1.6M 3.6s

The page load time is improved by more than 50% because the browser is able to avoid downloading and running content which is not critical to the display of the page.

Conclusions

As you can see, we’ve taken a very broad approach to improving Internet Explorer’s network performance, in support of our engineering goal of building the world’s fastest browser. Of course, the speed of your own network connection remains an important factor in the equation, and Web developers should continue to follow best practices for performance, but IE9’s investment in network performance helps us deliver a significantly faster page load time across a wide variety of pages.

—Eric Lawrence

Comments (45)

  1. Steve Warnock says:

    nice post.  I find it interesting to hear about some of these subjects and appreciate the effort.

  2. Roman says:

    Eric,

    So you suggest using LINK REL=PREFETCH as close to the top of the rendered html document as possible to enable the lookahead downloader start sooner?

  3. Mack says:

    That all sounds great (no, really, it does), except for Address Bar DNS Pre-resolution.  It sounds a lot more speculative than the other enhancements, and if I understand it correctly a slow typist can generate dozens of DNS queries as they type out a full URL.  There are also privacy implications with Address Bar DNS Pre-resolution because I might not want to generate network traffic to http://www.some-scandalous-site.com when planning to look at http://www.super-cute-puppies.com

    Otherwise this is good stuff.  I wish I could use IE9 on XP.

  4. Mack, IE actually only does the address bar DNS preresolve once (a batch of up to 5). Your "scandal" site won't be in the autocomplete list if it was previously visited in InPrivate.

  5. Dave C says:

    Mack,

    DNS resolution doesn't send any traffic to the named site. Rather it sends a query to a DNS server to find the IP address of that domain. I suppose a packet sniffer would see multiple DNS requests for similarly named domains, but no content.

  6. MikeGale says:

    This is a very useful technique.  I imagine a lot of users (like me) would like to run it on their own pages.

    Do you have a description of how you did this?  What is worth knowing before we do it ourselves.

    (I assume it uses fiddler, maybe run from code to automate data collection.)

    Any comments about doing it with other browsers?

  7. Rob Colburn says:

    Chromium / Chrome uses a DNS pre-resolution technique, not sure about their caching algorithm.

    blog.chromium.org/…/dns-prefetching-or-pre-resolving.html

  8. EricLaw [MSFT] says:

    @MikeGale: Yes, I was using a local capture for replay; this technique will work for any browser. I describe the general process here: blogs.msdn.com/…/capturing-and-changing-websites-using-fiddler.aspx although some manual tweaking is required to handle URLs with randomly-generated components.

    @Rob: Yes, that's correct.

  9. GoodThings2Life says:

    @Dave C,

    You're right UNLESS a particular malicious site also uses their own servers as its own DNS servers (an option available with many domain registrars). I would say you're right about 98% of the time, but there is some potential risk. I would add, however, that the likelihood of it being a genuine issue is pretty minimal as long as Microsoft has done due diligence in safeguarding it from "poisoning".

  10. SG says:

    Great article

  11. Radek says:

    How about  IE9 use the same prefetch control keywords that other browsers have standardized on.

    Other Browsers (chrome, safari, ff, etc) :  rel="dns-prefetch"

    IE9:   rel="prefetch"

    Come on IE team, be a team player and save people for having to do special handling for your browser.     developer.mozilla.org/…/controlling_dns_prefetching

    ( prefetch control can be important, example:  http://www.pinkbike.com/…/DNS-Prefetching-implications.html

  12. EricLaw [MSFT] says:

    @Radek: Sites indicate which content the user is likely to download in the future by using the Prefetch relation. Internet Explorer uses this existing relationship information as a signal of a site which may be valuable to prefetch. IE's DNS Prefetch does not cause the problems mentioned in the "pinkbike" blog you cited because we only do DNS prefetching of explicitly identified targets, not every hostname mentioned in a given page's markup.

  13. Radek says:

    @EricLaw  I realize that IE does not prefetch all link subdomains ( which is welcome ), as opposed to other browser which do in fact prefetch unless explicitly turned off.  I think IE is a better citizen in this case.  The pinkbike article was a reference in order to show that prefetching control is used, and because there are links there to both the chrome and mozilla prefetch control syntax.

    Other browsers can explicitly identify targets also,  but as mentioned,  IE has chosen to use a different keyword to identify this function.  At pinkbike we also use explicit prefetching for high probability targets and it comes as a thorn to have to specify a different keyword for IE.  Developers have had great hopes for IE9 to stick to standards and we're hoping to not have to litter our code with if(ie9) statements.  Since this explicit  dns prefetch function keyword seems to be the same for all other browsers, we'd hope that IE9 would follow suit here, especially since the term difference  "dns-prefetch" and "prefetch" is so minor.

  14. Phil says:

    radek– What "standard" do you think isn't being followed?  (hint: There isn't one).

    You also seem to be confused about the point that LINK REL=PREFETCH existed long before the notion of independent DNS prefetch. The introduction of a REL=DNS-PREFETCH relation was a bit silly, since the regular PREFETCH would have sufficed, as the prefetching of a resource inherently causes a DNS prefetch.

  15. Andre says:

    Eric, the development of IE will be faster now, or we have to wait three years for IE10?

  16. John says:

    @Radek I thought Firefox DOES support rel=prefetch? developer.mozilla.org/…/Link_prefetching_FAQ dns-prefetch is something different.

  17. John says:

    @Andre I read somewhere that the IE team would continue to release platform previews with new features after the release of IE9, so I guess that's a "probably yes."

  18. Will says:

    Well seeing as Firefox  now has a similar release schedule to Chrome: downloadsquad.switched.com/…/mozilla-details-new-chrome-like-release-schedule-and-channels-firefox-5-soon

    I'm willing to bet Microsoft will be forced to reconsider their own release schedule and will have to start releasing more builds more often as well or risk loosing even more users.

    Opera releases betas weekly, if not sooner. So now the top three IE competitors will be releasing more builds more often and Microsoft will be expected too as well, which I hope Microsoft does sooner than later.

    Don't be surprised if we start seeing IE 10 beta builds by summer 2011.

  19. Yes! Welcome to my home to see ... says:

    Yes! Welcome to my home to see …

  20. Mario says:

    Hey IE Team, If you put IE9 in full screen mode it makes the browser look a lot nicer,     Plus with smartscreen filtering report page I think you should allow the user reporting a link to input the link but  have the link they clicked report the link on auto typed up for them.   To input the link that would help block a lot more Malware sites.

  21. Radek says:

    @Phil @Others   It looks like like I did get thrown for a loop with the blog post showing an example with the rel=prefetch tag in the "dns pre-resolution" section.  So yeah, rel=prefetch is for prefetching CONTENT which, of course is a given that it would resolve the dns first to actually get at that content.  So in IE, if you want to pre-resolve DNS you actually have to prefetch a bunch of the content too.  rel=prefetch as pointed out  is also available in say ff to prefetch CONTENT, but additionally there is a rel=dns-prefetch that allows the browsers to pre-resolve just the dns.  

    It then would seem that IE does not have a facility to pre-resolve DNS which is not interconnected in prefetching the CONTENT.  My bad for trying to draw a parallel to dns-prefetch functionality.

  22. Klimax says:

    @Will: Doubtufll. There is minimum for corporate networks and MS own complete tests.(like compatibility) I suspect they cän't go faster then year or significant fragmentation occurs. (Not only forced fast autoupdate are evil,but MS is mostly forbidden to do that in any case. WU is maximum.)

  23. Olivier says:

    @Will : you talk about Firefox, Chrome and Opera, then you write : "So now the top three IE competitors…". I hope you were kidding, Opera is nowhere near a top competitor to any browser : look at their marketshare, it's barely used by anybody. Safari is in the top three IE competitor, and Opera is far behind.

  24. steve_web says:

    @EricLaw[MSFT] – well done! I normally have complaints to make about a posting on the IE Blog but this one is all WIN – much appreciated!

    I'm a tad confused about the images getting only half points in the cache though.  I agree that they are not as important as the JS/CSS etc. but I think they rank higher that audio/video etc.

    I'm thinking that on sites like Twitter, Facebook, LinkedIn, Blogs, StackExchange, or any site that shows Avatars etc. that the images comprise most of the download "weight" and outnumber the text based page content 10:1 on average.

    I guess I see the images deserving a 75% point ratio… slightly above audio, video, flash, etc.

    Cheers,

    Steve

  25. Helpp! says:

    Hello Microsoft and IE Team  I have a Question ThAT NEEDS TO BE ANSWERED      Is it safe to delete the debug file in Internet Explorer Folder in C:Program FilesInternet ExplorerDebug.txt     Or is it safe to delete the toolbar entry for  Conduit toolbar?

  26. JoB says:

    There is a odd behavior in the browser: the very first website that IE browses after a PC was rebooted seems to always take longer than browsing a second website after that. This seems to be true whichever website comes first and whichever comes second. Loading the first website can take something like 30 seconds. What happens in the background that causes this behavior?

  27. Lance says:

    it seems like their might be a benefit to having separate tiers for  text documents, images, audio and video so the most used of each tier is retained instead of automatically cutting the images points in half.

  28. Helpp! says:

    Well ANSWER MY QUESTION ABOVE PLEASE! I need to know… =(

  29. Arieta says:

    Andre: IE9 didn't take 3 years iirc, only two, and we had bi-monthly previews for most of that.

    Still, I too encourage a faster development cycle. IE9 is still playing catchup, but it's progressing much faster than any other browser. It would be nice if we could see incremental updates from now on, not yearly major releases that always introduce yet another compatibility mode. IE9 is modern enough now so you can keep on *improving* it.

  30. Ooh says:

    @all: Regarding the release schedule, please look forward to MIX11! They announced that Dean will present the day 1 keynote and I'm pretty sure he won't demo IE9 on Windows Phone 7 (that would be pretty lame). I think it's more likely that he will either announce IE10 PP1 or something like a change in release scheduling and thus IE 9.1 🙂 Not sure as I don't work for MSFT, but what else can you think of?

  31. jader3rd says:

    Since network time is so much of the time taken in navigating to a page, I wish that IE 9 did a better job of displaying that that's what it is waiting on. I realize that there's a spinning donut on the tab, but there have been plenty of times where to donut goes away, and the tab doesn't render the new page. Most of the time it will mysteriously render a few seconds later, but there's a gap in time when you're not sure if hitting Refresh will cause it to refresh the currently rendered (old) page, or the latest one requested.

    I've also thought that it would be nice for the situation where IE was able to grab the html page (or perhaps most of the html page) to start to render it, even though it had yet to grab any CSS or javascript included files. That way I could see the page build. During times when the CSS page isn't coming, I would at least be able to start seeing content. While I do admit that it does cause the time when the CSS comes instantly, that it might take a few milliseconds longer to render the final page (because IE does it twice), I think it would result in the page "feeling" to load faster to the end user.

  32. Steve Souders says:

    Great article Eric!

    In the first six rings, how is "other" time defined? Is that the time it took the page to load under "ideal" conditions? If instead it's the time in which you saw no network activity, that's overly stating the impact of network because during that network time the browser is doing other things in parallel (parsing HTML, JS, CSS, etc.). I'd love to see comparisons of normal vs ideal page load times.

    The link=prefetch early DNS resolution is nice. Is there a way developers can use this to get DNS resolutions started early in the page before resources *in the current page* are actually requested during HTML parsing?

    Is the connections-per-proxy limit of 12 per a single domain or across all domains in the page?

    Wow! Images are now included in lookahead parsing – that's HUGE! I'll try to test this soon in Browserscope.

    Can you share the data you gathered about caching that led to the 250mb conclusion? Great Velocity topic.

    Wow – the caching changes esp. by mime type is huge. You must have run some studies simulating typical usage over weeks of surfing – any estimates of how these changes improve the cache hit ratio?

    Great work!

  33. EricLaw [MSFT] says:

    @Will, @Andre: IE8 to IE9 was almost exactly two years, and there were 8 preview releases in that time. We've had great feedback about the Platform Preview process; it's respectful of web developers time in a way that nightly builds often are not. However, that's a bit off-topic for this post, so I'll leave it at that.

    @Mario: The IE9 SmartScreen feature has an extremely high success rate against socially-engineered malware. You can report any malicious site using the Tools > SmartScreen menu. I'm not really sure I understand your feature suggestion.

    @Radek: IE9 does not actually pre-fetch content; it performs a DNS pre-fetch of the content which the page suggests might be needed in the future.

    @steve_web: The key thing to remember about images is that their download typically will not actually block other progress (as they have no embedded links to other content, etc). The other thing to recognize is that commonly-used images will have a high hitcount and get points that way. Overall, the larger cache size helps ensure that even images will be cached for quite some time.

    Properly scoring Audio and Video is an interesting exercise, because these are not yet common on "real world" sites and hence it remains to be seen what algorithm provides the best balance between hit-ratio and size. We'll continue to look at that.

    @Helpp!: Debug.txt isn't a part of IE, and probably can be deleted without issues. You can certainly uninstall toolbars you do not want; often you need to use the Windows Add/Remove Programs applet for this.

    @Lance: I'm not sure I understand why you think that a split cache would result in a meaningfully different overall outcome?

  34. EricLaw [MSFT] says:

    @Steve: The experimental methodology was briefly mentioned in the text: I measured the time it took to load the page "normally" then I reran the test with all content "instantly" available from a local server. This was done a few times and the results averaged, because the variability of the "real world" network tends to be pretty high.

    You're absolutely right that measuring the actual "seconds waiting for resources" would not be very useful, and it would completely overlook the very complicated relationship between network time and everything else (e.g. a browser will do many more relayouts, etc, when content is streaming in from the network slowly, and will get requests out on the wire more slowly, etc).

    Using LINK REL=PRE-FETCH won't likely significantly help in getting other resources in the page faster, since the pre-parser is already ripping ahead of the rest of the processing of the page and kicking off network traffic as quickly as possible. It's also key to recall that this would only be useful on first-visit, since on subsequent visits, we're pre-resolving DNS from the historical needs anyway. But that would certainly be an interesting experiment to do!

    Connections-per-proxy is an *overall* limit of connections to the proxy, across all hostnames used by a page. In IE6/7, the limit was 2, and in IE8, the limit was 6. You'll probably see some of this in your BrowserScope results.

    Vis-a-vis the improved cache hit ratio: The numbers are *wildly* variable, depending on the user, their browsing patterns, and whether they use the Delete Browser History feature often. We have a few preliminary numbers at this point, but we don't have anything that's "publication ready" at this point; maybe at Velocity?  One interesting research project is to determine what the overall average *maximum possible* hit ratio is for the web as it exists today (e.g. given an infinitely-sized cache with perfect standards-compliance). I don't know that anyone has publicly published any research in this area yet, but it would be interesting to see how far off today's browsers are.

  35. Sergio says:

    Unfortunately Opera is 100% faster than IE

    ie.microsoft.com/…/Default.html

  36. @Sergio: First, the test you are using as the proof has nothing to do with this topic. This topic is about network performance, not CSS layout rendering. Second, despite its performance and good features, Opera has very small market share. It is time its authors and developers found out why. I don't know about others but personally, I won't use Opera when Firefox, Internet Explorer or Chrome are respectively present on the computer.

  37. Menno says:

    Does IE set TCP_NODELAY?

  38. dkb1898 says:

    Bravo! I have to say, I switched over to IE 9 from Chrome 10 once the final came out, and I don't see myself going back. IE 9 is noticably faster on page loads and scrolling, noticably. And I'm running an 1st gen Core i5 with Intel Graphics. I saw a review on Dailytech saying IE9 isn't up to speed on the page load of their own site, this is either a blatant lie, or poor analysis because it loads much faster on my laptop.

    Excellent job guys with this release, you just won back a user who never thought you would be able to catch up to Google Chrome! Looking forward to IE 10 because you know Google will respond quickly!

  39. dkb1898 says:

    Bravo! I have to say, I switched over to IE 9 from Chrome 10 once the final came out, and I don't see myself going back. IE 9 is noticably faster on page loads and scrolling, noticably. And I'm running an 1st gen Core i5 with Intel Graphics. I saw a review on Dailytech saying IE9 isn't up to speed on the page load of their own site, this is either a blatant lie, or poor analysis because it loads much faster on my laptop.

    Excellent job guys with this release, you just won back a user who never thought you would be able to catch up to Google Chrome! Looking forward to IE 10 because you know Google will respond quickly!

  40. Sergio says:

    @Fleet Command

    Keep ignoring the characteristics and performance of competitors and who will soon be a derisory marketshare IE!

  41. MKD says:

    BUG – Incorrect download speed reported.

    I used the "download as .zip file" option to download a folder from skydrive. I observed that the download speed reported continuously decreased (though the download itself was progressing at a constant speed) – the reported speed started off at around 30kb/s, and was at 500bytes/s when the download finally completed. I guess there is a bug in the calculation when the total size of the downloaded file isn't known.

  42. @Menno: Yes, IE8 and IE9 (and likely earlier) set TCP_NODELAY.

  43. dengxf says:

    and more, ie can store the user's hot request site in disk, and precreate a connection when launch the ie.

    for cache control, does ie use LRU for the hot data? these maybe helpful to control the cache size.

  44. Patrick says:

    Great info.