At CNet News today, the article What browser wars? The enterprise still loves IE 6 nicely sums all the reasons that Internet Explorer 6 is still in use in enterprise environments. The dominance of Internet Explorer 6 in the workplace is something I discussed a few days ago, supported by the pattern of higher weekday use of this browser during the work-week.

Limiting employees to a browser that is considered an ancient technology by Web developers poses an interesting dichotomy to companies. Internally, they are powering their internal applications with coal and steam, and turning the cogs of business with leather drive-belts. Externally, the customers get to see a site that is shiny, one that has all the gadgets of a rich-Internet application that require the computationally advanced capabilities of a modern browsers.

To some extent, the companies who use Internet Explorer 6 internally are saying to their employees that the Internet is simply another desktop application that they must use.

I am firm believer that the Web will be the home of many of the applications we use on a daily basis in the very near future [here and here]. My vision of this is that the Web application is designed to free the user, and lessen the workload for IT departments.

Most organizations continue to see the Internet as a negative, a threat to productivity, a necessary evil. So if they restrict their employees and provide them with a browser that doesn’t quite work properly on the Internet, they still have ultimate control.

I have had the benefit of working for organizations throughout my professional career that did (do) not limit my choice of browser or operating system, allowing me to find my own preference. I realize that this is rare in corporate Industrial Culture, and I consider myself lucky.

So, why is their still a need for Internet Explorer 6? Frankly, there is really no need for it in my opinion, and the CNet News article has a table from Forrester that supports that. That doesn’t mean that my browser idealism and utopian dream of “may the best browser win” will hold any sway over the IT decision makers in large organizations.

StatCounter still shows that during the week, Internet Explorer 6 holds 12% of the browser share in the US [here]. So, will this 12% of the browser world hold back the promise of the Internet for the rest of us?

Using the visitor trending data collected and shared by StatCounter, I have undertaken a general analysis of browser distribution by global region. These metrics are collected using the embedded tags that StatCounter customers embed on their site to collect visitor metrics for their own use.

US data shows that MSIE 7.0 is in a dominant position, with Firefox 3.0 in the 25% range of market share. This trend extends into the North American data, which is heavily influenced by the US trend.

MSIE 8.0, still reports a lower distribution than Firefox 2.0. This data is most likely based on the usage of MSIE 8.0 RC1 version, as MSIE 8.0 was only released in GA last week. It is highly probable that these stats will change in the very near future with the release of MSIE 8.0 to Windows Update.

In the EU, where fear and loathing of Microsoft runs deep and true, Firefox 3.0 is approaching parity with MSIE 7.0. Also, the perennially favoured native son Opera makes a very strong showing with their 9.6 release.

Asia is a Web designers nightmare, with MSIE 6.0 continuing to be the most reported browser. This is concerning, not simply for design reasons, but for web compliance reasons. Effectively Asia has throttled Web development to an old warhorse, but to such a degree that there must be some overriding advantage to using this browser.

As an example, the statistical comparison of four Asia nations is broken out below. We’ll start with Japan where MSIE 7.0 has a clear lead in the statistics.

However, when China (People’s Republic), India, and South Korea are added into the analysis, the pull towards MSIE 6.0 is massive.

This trend needs to be studied in greater detail in order to understand why MSIE 6.0 is so popular. Is it because of licensing? Continued use of Windows 2000? Compromised computers? The data doesn’t provide any clear or compelling reason for this trend.

Moving to Oceania shows a return to the trend of MSIE 7.0 being the predominant browser with Firefox in second place, with these two browsers showing a substantial lead over the remaining field.

South America sees MSIE 7.0 as having the largest market share, followed by MSIE 6.0 and Firefox 3.0. Effectively there are no other browsers with substantial market share at present.

These statistics show that the three most dominant browser platforms by market share are the two MSIE platforms followed by Firefox 3.0. This is likely to change with the MSIE 8.0 GA last week and its predicted release to the masses via Windows Update in the near future.

However, the release of MSIE 8.0 may not be as exponential as is predicted. Corporate IT policies, which have been slow to embrace MSIE 7.0, are likely not going to make a giant leap to MSIE 8.0 overnight. Adoption among the general population will also depend on the ability of existing Web applications to adapt to a more standards-compliant browser platform.

Noticeably absent from most of these statistics is Safari in a position to challenge the three leading browsers. This indicates that even hardcore Mac users continue to use Firefox as their primary Web application and browsing platform. StatCounter backs this up by indicating that within their data, 8.36% of visitors from the USA were on Macs, while 3.15% of visitors used Safari.

Trends to watch in the near future:

• New browser releases (Firefox 3.1, Safari 4.0) and their effect on browser distribution
• Uptake of MSIE 8.0 once it is released via Windows Update
• Browser distribution is Asia

The last two days of using Chrome have had me thinking about the purpose of the Web browser in today’s world. I’ve talked about how Chrome and Firefox have changed how we see browsers, treating them as interactive windows into our daily life, rather than the uncontrolled end of an information firehose.

These applications, that on the surface seem to serve the same purpose, have taken very different paths to this point. Much has been made about Firefox growing out of the ashes of Netscape, while Chrome is the Web re-imagined.

It’s not just that.

Firefox, through the use of extensions and helper applications, has grown to become a Desktop replacement. Back when Windows for Workgroups was the primary end-user OS (and it wasn’t even an OS), Norton Desktop arrived to provide all of the tools that didn’t ship with the OS. It extended and improved on what was there, and made WFW a better place.

Firefox serves that purpose in the browser world. With its massive collections of extensions, it adds the ability to customize and modify the Web workspace. These extensions even allow the incoming content to be modified and reformatted in unique ways to suit the preferences of each individual. These features allowed the person using Firefox to feel in control, empowered.

You look at the Firefox installs of the tech elite, and no two installed versions will be configured in the same way. Firefox extends the browser into an aggregator of Web data and information customization.

But it does it at the Desktop.

Chrome is a simple container. There is (currently) no way to customize the look and feel, extend the capabilities, or modify the incoming or outgoing content. It is a simple shell designed to perform two key functions: search for content and interact with Web applications.

There are, of course, the hidden geeky functions that they have built into the app. But those don’t change what it’s core function is: request, receive, and render Web pages as quickly and efficiently as possible. Unlike Firefox’s approach, which places the app being the center of the Web, Chrome places the Web at the center of the Web.

There is no right or wrong approach. As with all things in this complicated world we are in, it depends. It depends on what you are trying to accomplish and how you want to get there.

The conflict that I see appearing over the next few months is not between IE and Firefox and Safari and Opera and Chrome. It is a conflict over what the people want from an application that they use all the time. Do they want a Web desktop or a Web container?

Port80 Software is reporting that in their survey of Fortune 1000 Web sites, IIS 6.0 has overtaken Apache as the Web server platform of choice. [here]

My two-cents: I respect the Port80 Software team greatly and love their maniacal devotion to ensuring that IIS users actually make use of the HTTP compression and caching that can so greatly improve Web performance.

That said, they are tied to Microsoft and the IIS platform. I would be curious to see if, scratching below the surface, they were able to determine what the application platform these companies built their mission critical Web applications on. I am open-minded and willing to hear that IIS is winning in that area as well. In my mind, it’s about Web performance tuning, not what you use to get that performance.

That said, I think a critical Web application survey of these same firms would find that many of these companies rely on JSP servers to run their core business processes.

As well, it would be interesting to se, by Fortune 1000 ranking, what the companies are using what server platform.

And…people still use Netscape Enterprise, SunOne, and Domino as production Web servers? YIKES!

A little-used or discussed feature of PHP is the ability to compress output from the scripts using GZIP for more efficient transfer to requesting clients. By automatically detecting the ability of the requesting clients to accept and interpret GZIP encoded HTML, PHP4 can decrease the size of files transferred to the client by 60% to 80%.

The information given here is known to work on systems running Red Hat 8.0, Apache/1.3.27, Apache/2.0.44 and PHP/4.3.1.

[Note: Although not re-tested since this article was originally written, compression is still present in the PHP 5.x releases and can be used to effectively compress content on shared or hosted servers where compression is not enabled within the Web server.]

Configuring PHP

The configuration needed to make this work is simple. Check your installed Red Hat RPMS for the following two packages:

1. zlib
2. zlib-devel

For those not familiar with zlib, it is a highly efficient, open-source compression library. This library is used by PHP uses to compress the output sent to the client.

Compile PHP4 with your favourite ./configure statement. I use the following:

Apache/1.3.27
./configure –without-mysql –with-apxs=/usr/local/apache/bin/apxs –with-zlib

Apache/2.0.44
./configure –without-mysql –with-apxs2=/usr/local/apache2/bin/apxs –with-zlib

After doing make && make install, PHP4 should be ready to go as a dynamic Apache module. Now, you have to make some modifications to the php.ini file. This is usually found in /usr/local/lib, but if it’s not there, don’t panic; you will find some php.ini* files in the directory where you unpacked PHP4. Simply copy one of those to /usr/local/lib and rename it php.ini.

Within php.ini, some modifications need to be made to switch on the GZIP compression detection and encoding. There are two methods to do this.

Method 1:

output_buffering = On
output_handler = ob_gzhandler
zlib.output_compression = Off

Method 2:

output_buffering = Off
output_handler =
zlib.output_compression = On

The ob_gzhandler

The most important component of this entire process is placing the ob_gzhandler PHP command on the page itself. It needs to be placed in the code at the top of the page, above the HTML tag in order to work. It takes the addition of the following line to complete the process:

<?php ob_start("ob_gzhandler"); ?>

In Wordpress installs, this becomes the first line in the HEADER.PHP file. But be careful to check that it’s working properly. If the Web application has the compression function built into it, and you add the ob_gzhandler function, a funky error message will appear at the top of the page telling you that your can’t invoke compression twice.

Web servers with native compression are smarter than that – they realize that the file is already compressed and don’t run it through the compression algorithm again.

Once this is in place, you will be able to verify the decrease in size using any HTTP browser capture tool (Firebug, Safari Web Inspector, Fiddler2, etc.)

So?

The winning situation here is that for an expenditure of $0 (except your time) and a tiny bit more server overhead (you’re probably still using fewer resources than if you were running ASP on IIS!), you will now be sending much smaller, dynamically generated html documents to your clients, reducing your bandwidth usage and the amount of time it takes to download the files.

How much of a size reduction is achieved? Well, I ran a test on my Web server, using WGET to retrieve the file. The configuration and results of the test are listed below.

Method 0: No Compression wget www.pierzchala.com/resume.php	File Size: 9415 bytes
Method 1: ob_gzhandler wget –header=”Accept-Encoding: gzip,*” www.pierzchala.com/resume.php	File Size: 3529 bytes
Method 2: zlib.output_compression wget –header=”Accept-Encoding: gzip,*” www.pierzchala.com/resume.php	File Size: 3584 bytes

You will have to experiment with the method that give the most efficient balance between file size and overhead and processing time on your server.

A 62% reduction in transferred file size without affecting the quality of the data sent to the client is a pretty good return for 10 minutes of work. I recommend including this procedure in all of your future PHP4 builds.

Yes, I know. For the fourth time in a week, this is a post with a link to my resume.

But last night, while I was writing an e-mail to someone about the long-term future of GrabPERF, I wrote something that I had to read twice when it came out.

GrabPERF is my resume.

How can a simple Web application be a resume?

In my case, it highlights all of the things that I am interested in:

• Web performance
• Statistical analysis
• Clear presentation of data and information
• Web development skills
• Database administration skills
• System administration skills
• Distributed systems

GrabPERF showcases everything that I have taught myself over the last seven years. And I am proud of it.

So, what do you use for your resume?

Technorati Tags: GrabPERF, resume

This week, I had a conversation that included a discussion of whether Microsoft Office applications should be webified.

I think that this is the only way that MSFT is going to be able to get people to support a new version of their product. A web application running on an IIS server (you think they would make able to run on Apache? PSSSHAW!) would support thousands of users, even remotely (HTTPS).

How? Well, once you load the Web app…the load is effectively off the server until the user needs to save, or import, or merge, or speel…spellcheck. Users get to free up cruft and crap from their machines by only loading apps when they need them, and only the apps they need.

OWA is already good enough to replace the bloatware we call Outlook.

As one lunch companion pointed out, there has to be a version of these apps running in a lab somewhere in Redmond right now.

I would buy access to a new version of Office served over the Web in a heartbeat in order to dump the cruft and creep that currently occupies 300MB of drive space.

As the Web moves toward the delivery of services, I have been ruminating on the continuing importance of browsers.

Scoble writes:

Oh, well, back to my RSS news aggregator. That’s where I spend 90% of my Internet time now anyway. Are you still using a Web browser? Good. I’ve been telling audiences that those of you still using Web browsers are wasting your time. I think that Opera might be more concerned by that.

I agree. I use Firefox to handle large applications, such as my employers interface, and my blog editor, but beyond that, it has become less and less important in my everyday online life.

This is the trend. HTTP and HTTPS will be the vehicles to deliver this data. Web servers will become more and more important, but as transformation and application servers for back-end data, not as presentation and image servers.

This is a long-term trend. But it also explains things like the decline of Slashdot. Although they have had an RSS feed for a long time, their bleeding-edge readers found that Slashdot was no longer bleeding-edge. Information is flowing faster and in a more personalized manner through aggregator, desktop and online.

I agree with Scoble (something that happens infrequently): the browser war may be irrelevant. The Web Application era has begun.

I submitted a presentation proposal for OSCON 2005 just now. The abstract is below.

The Open Source community has driven the online world for the last decade. PHP, PERL, Apache, Java, and MySQL are all major components of large online enterprises.

However, putting an application online and ensuring that it satisfies the performance, availability and reliability demands of the increasingly knowledgeable online consumer are often two separate concerns.

Performance should not be an afterthought; performance should be a leading force in creating a Web application.

Using simple Open Source Tools, Web performance measurement solutions can be built that rival commercial solutions. But what does this data tell you? And how do you turn this into useful business information?

This discussion will expose the participants to key Web performance metrics that make sense to both technology and business leaders in your organization.

I have a snowball’s chance in hell of having it accepted, as it is not hip, technical or trendy, and I am not an Open Source Guru, but if you design stuff for the Web, then you better be ready to have your site examined in detail, because if you don’t do it, your customers will.