Helping a colleague this week, we uncovered some odd behavior with a site whose performance he was analyzing. Upon first glance, it was clear that this site had a performance issue – they had HTTP persistence disabled. Immediate red flag in the areas of network overhead and geographic latency.

Further digging exposed something more sinister. It seems that HTTP persistence was only disabled for browsers with MSIE in the user-agent string. Even if the user-agent string was just MSIE, HTTP persistence was off.

The customer was very forthcoming and sent us their standard httpd.conf file. This showed no sign of the standard (and frustrating) global disabling of persistence for Internet Explorer.

Finally, it came to us. The customer had provided a simple network diagram, and there, just before packets hit the Internet, was a Layer 7 firewall. How did we know the Layer 7 firewall was the likely cause? Because this device was also the one that provided compression for the content going out to customers.

A Layer 7 firewall happily rewrites HTTP headers to reflect the nature of the compressed content (content-length or transfer-encoding: chunked) and to add the gzip flag (accept-encoding:gzip). Since this device was already doing this, it was pretty clear to us that it also had a rule that disabled HTTP persistence for anything with MSIE in the user-agent string.

This was a fine example of the complexity of the modern Web application infrastructure. In effect, there were two groups with different ideas of how Internet Explorer should be handled at the network layer, and neither of them seems to have talked to the other.

When you have a Web performance problem, indulge in a thought experiment. Create an imaginary incoming Web request and try to see if you can follow it through all the systems it touches on your system. Put it on a whiteboard, a mindmap, whatever works.

Then invite the system architects and network engineers in and get them to fill in the gaps.

No doubt that will lead to the “ah ha!” moment. If nothing else, it’s a good excuse to put pizza on the company card. But I have no doubt that you will walk away with a better understanding of your systems, which will make it easier for you to talk to all the people responsible for keeping your systems running.

TAKEAWAY: Just because the part of the Web application you work on is working fine, it may be affected by other components that are not tuned or configured for performance. Get to know the entire application at a high level.

Tomorrow morning, at 09:00 PDT, Microsoft unleashes IE 8.0 on an unsuspecting Internet.

By 12:00 PDT, the number of Web sites having to put up IE 7.0 only stickers will be in the millions.

I haven’t done a lot of testing of the new monster (I mainly use Firefox on Mac OS 10.5.6), but it doesn’t seem any weirder than any of the other Microsoft browsers I have used.

Under the hood, it does amp up the number of connections that are used to download objects, but if your infrastructure is prepared, it should be no big deal.

The big concern lies in the rendering. If those users who can upgrade to the new browser (anyone not limited to IE 6 by a corporate IT policy written on parchment) do find there are problems, will they blame the site or the browser?

Have you tested your site to ensure that it actually works with IE 8? Or will you get burned?

What is the greatest benefit you see to your visitors having IE 8 instead of IE 6 or 7?

Is this a good thing?

Here are the browser stats for Newest Industry as of March 14 2009. Not a large amount of traffic, but it is indicative of what most folks with technical content on their blogs likely see.

What did surprise me was the number of people who are still using MSIE 6.0. I am not sure what is continuing to perpetuate the presence of this percentage of people on this antiquated browser, other than large corporations running this by mandate of the IT department.

I think that with the release of all the new browsers this year, support for MSIE 6.0 should simply cease. I will gladly install a javascript library that will kill pages for MSIE 6.0 visitors, announcing that the Internet is no longer available to them.

Last fall it was Chrome. Now it’s Safari 4 Beta. Soon it will be Firefox 3.1 and IE 8.

Each browser has its harsh critics and fervent supporters. But in the end, does the browser really matter?

The answer to this question depends on who you speak to. Developers will say yes, because browsers make their lives hell, as none of them subscribe to the same set of standards for display, rendering, or code processing. I would bet that if you asked any developer, they would prefer that only one browser existed and was used by everyone.

The people at the end of the browser chain, you and I, don’t really care either. We only care when the browser drops an unexpected rendering surprise on us, or doesn’t work because the Javascript functions were designed with Browser A and B in mind and we use C and the submit button on our purchase doesn’t work.

The question isn’t Does the browser matter? but Why does the browser still matter?

There is no reason to have five large browsers out there. There is no reason why they should all behave differently, render pages in their own unique way.

And while people will say that having multiple versions of multiple generations of uniquely developed browsers drives innovation and prevent stagnation in Web development, I say enough is enough.

There is no reason to have yet another browser. The browser doesn’t matter.

The content matters.

And when you switch the perspective around to that view, you should easily realize that the browser, any browser, is simply a window into the content being created for and by us. It should not matter to anyone that I use Opera, Safari, Firefox, IE, Camino, Chrome, or Lynx.

What does matter is that the content can be delivered to me the way I want it. Not the way the browser wants it.

What we need to realize is that browsers no longer matter. They are software. They are portals into what we are trying to do and say.

The browser is not the application; the Web is the application.

The intertubes of the Web are abuzz with talk of the new, open-source Google Chrome browser [two articles here and here]. I will not presume to wade into the debate of whether it is necessary, or what strategic business goals Google has set that rely on having its own browser. I will limit my comments to the area of Web performance.

Open-Source Browser: Ours or Theirs?

When I read that Google Chrome was an open-source browser, the first thought was: is it theirs or a re-branded Firefox? No one knows at this point, but that will have a direct effect on how the browser performs, and how extensible it will be.

HTTP Standards

Unlike other standards, HTTP standards set out how a browser uses the underlying TCP stack. MSIE6/7 have very broken implementations, and MSIE8 is building on those by increasing the number of connections per host to 6, up from 2 set out in RFC 2616.

Firefox can be configured to mangle this as well, but by default it plays by the standard, adding the option of HTTP pipelining into its mix of persistent HTTP connections.

It will be VERY interesting to see how Google Chrome comes configured out of the box, and how much control users have over the HTTP behaviour of this new browser.

(X)HTML/CSS/JS Standards

This area is a mess. No browser implements this standards in a way that is completely consistent with the written text, and page designers have to use a variety of page testing products (such as BrowserCam) prior to release to ensure that their design is somewhat presentable in all browsers on all platforms.

The rendering of Javascript will be crucial in this new browser, as so much of the new Web is built on applications that are almost completely Javascript-driven.

I am sure that there will be sites that will be completely mangled by the new browser, but, knowing Google, we will be getting a 2.0 release, the 1.0 release being used within Google for a while now to test it under real-world conditions.

Caching

As a few sites in the world do use cache-control headers properly, it will be interesting to see how a browser created by one of the major ad-serving and search providers on the Web tracks page objects. Will it follow explicit/implicit caching rules? Or will it impose a heavy penalty on bandwidth by downloading objects more frequently than other production browsers do?

Proxies, and the Debacle of the Google Web Accelerator

Back in 2005, Google launched a badly designed and gighly flawed product called the Google Web Accelerator. This product proxied Web traffic through the Google network and allowed the company to develop a pattern of user browsing habits and search selections that would allow them to better target their ad products.

I have a great fear that this will be an integrated part of the Google browser project. If it is, it should be a configurable option, not an out-of-the box standard.

I am sure that there will be a few performance conversations that occur around the Google Chrome browser in the weeks ahead. I look forward to hearing what the community has to say about this new addition to the browser wars.

Did we mention that the layout doesn’t work in Firefox or MSIE 7?

Oooops.

Apparent using HTTP compression alongside HTTP/1.1 will cause certain versions of MSIE 6.0 to implode. [here]

I personally think this was because the NSA power shortage was making it too hard for the spooks to snoop on compressed Web traffic. [here]

Via: Port80 Software

PS: No, I won’t turn off compression because Microsoft did something really stupid.

Technorati Tags: Internet+Explorer, Internet+Explorer+6.0, MSIE, Port80+Software, HTTP+Compression, Web+Performance, Microsoft, NSA

A colleague in Germany forwarded me this interesting Microsoft knowledgebase article.

Internet Explorer May Lose the First 2,048 Bytes of Data That Are Sent Back from a Web Server That Uses HTTP Compression

This appears to only happen if another program registers (Real8 Download is the example given in the KB article) to use some of the more obscure Internet Name-Space handlers with Urlmon.dll. These corner cases include rarely used protocols like HTTP, HTTPS, and FTP.

Also, this only applies if you haven’t bothered to patch your MSIE 6 for like, oh, two years. So, if you have bizarre behaviour with sites that use compression, use that Microsoft Update thingie you may have heard of.

I have been making some changes to this blog and MSIE continues to gibble the CSS layout.

Well, too bad for them.

Get a real browser.

This blog no longer supports MSIE <= 6.x.

Tim Bray makes a comment on the new MSIE exhibit at the Royal Saskatchewan Museum.[here]

Yummy geek humour.