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.

I am writing up a client presentation for next week, and I just realized just how flawed Internet Explorer is. Microsoft claims that the browser is standards compliant. Yet it still doesn’t support HTTP pipelining.

And the frustrating part? They won’t tell us why. I have my suspicions, which include TCP stack issues and a flawed HTTP handling mechanism that is still based on Windows 95 architecture, but an explanation from Redmond would be nice.

Every (and I mean every) other browser can do this.

Microsoft, it’s time you detached your Web browser from your OS, like you’ve forced everyone else to do.

Tags: HTTP, pipelining, RFC 2616, Firefox, Opera, HTTP Pipelining, Internet Explorer

Port80 Software in San Diego is a team who is dedicated to improving Web performance.

However, they just recommended Maxthon, which uses the MSIE engine. [here]

I can’t buy into that. It still uses a core browser which has been patched but has not evolved since 1999. Until Microsoft releases a browser that can handle HTTP Pipelining — don’t understand why it can’t do it…unless there is a technical reason — I will stick with Firefox.

I am extremely steamed at an article that just read on Caillon’s Blog which basically encourages people to disable HTTP Pipelining.

This is the wrong approach.

If a server announces that it is HTTP/1.1 compliant, then  it should be able to handle a browser that is using all of the HTTP/1.1 features. If someone is using a server version which cannot handle all of the features of HTTP/1.1, then they should be forced to fall back to HTTP/1.0.

By continuing to bow to the lowest common denominator, Web performance will not improve and Server developers will not be forced to accept that they must fix their code.

The only reason that server developers have gotten away with lousy pipelining support is because MSIE still does not support it. If MSIE begins to implement pipelining, then watch the mad scramble to resolve this issue.

Proactive Web performance excellence. Do it.