In order to get more people to adopt the methods of creating faster web pages, we need to make it easier for them to do so while still a making it easy for them to adhere to performance guidelines. Basically, make it possible for them to eat cat and lose weight at the same time.

I’ve spent part of last evening looking for plugins for WordPress that will find any javascript or css files, combine them into a single file, minify and gzip them, and then set far future expires headers. I’ve got a dream plugin in mind and none of them are quite living up to my fantasy.

One solution that comes close to being my dream is a piece of software called Smart Optimizer. Smart Optimizer used to be called JSmart. It was a project that hadn’t had any updates since July 7, 2006 until two weeks ago when the project was revitalized and the name changed.

Smart Optimizer will:

• Set up rewrite rules to intercept any calls to css or js files
• Minify, gzip any css or js files
• Creates static files on the server for css and js that are gzipped and set for caching
• Concatenate css or js files into a single file

It’s an interesting tool that I don’t think a lot of people know of. Take a look.

Popular AJAX libraries including:

• jQuery
• prototype
• script.aculo.us
• MooTools
• dojo

are now being hosted on Google’s servers for use on your site or applications. Why would you link to a file hosted on Google’s server? Because it is optimized for speed by providing the libraries in the following way:

• Gzipped
• Minified
• Far future expires headers to increase caching
• Delivered using Google’s extensive content delivery network

They are providing multiple versions of each library and even include a javascript loader for the libraries. For more on the benefits of this service, check out Steve Souder’s coverage and Dion’s extensive information on Ajaxian.

If you are using any of these AJAX libraries, you would be foolish not to seriously consider taking advantage of this service.

The advantages of using HTTP Basic Authentication are easier integration. In particular, mod_auth_mysql for Apache makes it possible to easily password-protect areas based on usernames, passwords and roles stored in a central authentication database. The main alternative for authentication, cookie-based authentication, provides a higher barrier for integration projects.

Despite the integration advantages, most web developers use cookie-based authentication because they want to control the user experience of logging in. When logging in using HTTP Basic Authentication, the browser shows a login prompt. Developers have no control over the look of this login prompt; therefore, there is no ability to add useful information like links to retrieve forgotten passwords.

After several unsuccessful login attempts, HTTP Basic Authentication redirects to a 401 error page. Only at this point can developers provide further instructions to assist the user. And with some browsers (ahem.. Safari), the 401 page will not be rendered if the user cancels their login attempt.

Once someone logs in, there is no way to log them out short of quitting the browser. Apache’s FAQs provide the best explanation of the limitation:

How do I log out?

Since browsers first started implementing basic authentication, website administrators have wanted to know how to let the user log out. Since the browser caches the username and password with the authentication realm, as described earlier in this tutorial, this is not a function of the server configuration, but is a question of getting the browser to forget the credential information, so that the next time the resource is requested, the username and password must be supplied again. There are numerous situations in which this is desirable, such as when using a browser in a public location, and not wishing to leave the browser logged in, so that the next person can get into your bank account.

However, although this is perhaps the most frequently asked question about basic authentication, thus far none of the major browser manufacturers have seen this as being a desirable feature to put into their products.

Consequently, the answer to this question is, you can’t. Sorry.

Because my company uses HTTP Basic Authentication, I’ve become very good at explaining why we can’t have a form in the web page for logging in and why we can’t provide a log out button.

A couple of years ago, John Keith (our CTO) and I theorized that if we could log the user into the same realm using credentials that were only valid for a single page that we could mimic log out behavior. We explored trying to set the credentials on the server, but found that this only worked in Apache 2.0.

Basically we hit a brick wall until a couple of months ago. Thankfully, the increased emphasis on web services has caused a resurgence in HTTP Auth interest. If you have a password-protected API, you can’t assume that the client will accept cookies. In fact, it is unlikely that the client will accept cookies so you have to find an authentication alternative.

We’ve been experimenting with a new technique that allows for both form-based HTTP Basic Auth login boxes as well as log out buttons. It works using AJAX to take the usernames and passwords from the form and pass log the user in via the XmlHttpRequest object.

A similar technique logs a user out by logging the user into a page with credentials that are only valid for that page. The user never truly logs out, but the effect is the same. Until the user supplies their original credentials, they will be unable to see anything other than the one page.

I’m pleased to say that we’re having some success with these techniques and are using them to solve a long-standing customer issue. Details on the technique we’ve been basing our development on were originally published by Paul James. I highly recommend taking a look at some of Paul’s other articles on RESTful implementations and HTTP caching.

If you’re using HTTP Basic Authentication, you should look into these techniques immediately. Your users will thank you for it.

At the time, the great promise was sections of the DOM II specification on range. Bugzilla listed support for this part of the specification on its future work. I signed up for a list and monitored the ticket waiting for the day when Mozilla would support WYSIWYG in-browser editing.

Today I read that the Yahoo UI team has finally bent Safari to its will to support WYSIWYG editing. We’ve come a long ways since I was hanging out on the Mozilla developer lists and asking questions about the range implementation. Now that someone has conquered Safari, we are close to assuming that this foundation piece of the read/write web is available to all users.

A few years ago, our CTO and I read Andrew King’s Speed Up Your Site book and became consumed with improving performance of our customer web sites. We decreased download time for one site by 75%. These changes prevented us from hitting our network capacity long enough to move to a new hosting facility where we weren’t constrained by bandwidth.

What amazes me is how frequently developers ignore the simple things that can be done to speed up their web applications. Most web servers contain options to supply their content in gzipped form. This option alone can save tremendous time for users and bandwidth costs for companies.

I have a short list of books that I wish everyone who develops online would take the time to read. Speed Up Your Site is near the top of that list.

P.S. I was pleased to find that my new hosting environment appears to be using gzip by default. The home page would be 19K uncompressed, but is delivered to the browser as a 4K gzipped file.