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.

We had an exceptional audience tonight at DevGroup NW for my presentation on how to speed up web pages. There were a lot of good questions and an engaged audience. Thank you to everyone who showed up. Here is my presentation from tonight as well as some of the resources I mentioned.

• Speed Matters Presentation (pdf, 8.6MB)
• Speed Matter Presentation with My Slightly Incoherent Presenter Notes (pdf, 9.3MB)

The great irony is that I used so many images in my presentation that I can’t compress the pdf files to the degree that I would like. Sorry for the large file size. If it is any consolation, you’ll likely get to fully use your broadband connection unlike when you download web pages and are limited by current connections to a fraction of your connection speed. :-)

Books on Site Performance

• High Performance Web Sites by Steve Souders, Yahoo (Not released yet)
• Speed Up Your Site by Alex King (Out of print, but available used)

Articles & Resources

• Thirteen Simple Rules for Speeding Up Your Site
• Yahoo Performance Team
• What the 80/20 Rule Tells Us about Reducing HTTP Requests
• Maximizing Parallel Downloads in the Carpool Lane
• Yahoo Group for Performance
• Mod Expires
• Graphing Requests with Tamper Data
• Speed Up Your Javascript Load Time
  
• Optimizing Page Load Time

Measuring Site Speed

• Web Page Analyzer
• YSlow Firefox Plugin
• Live HTTP Headers Firefox Plugin

Minimizers and Compressors

• YUI Compressor
• JSMin
• Compress Web Output Using mod_gzip and Apache
• Using HTTP Compression for Faster Downloads (IIS 6.0)
• IIS 6.0, Content-Encoding: gzip

Statistics & Studies

• Akamai and JupiterResearch Identify ‘4 Seconds’ as the New Threshold of Acceptability for Retail Web Page Response Times
• The Bandwidth Report
• US Jumps to 24th in Worldwide Broadband Penetration
• Home Page Usability and Credibility Survey
• Replace GIF with PNG Images

Thanks to all of the Flickr users who posted their images with Creative Commons licenses. This presentation wouldn’t have been nearly as interesting without their photographs.

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.

In retrospect, AJAX seems like an easy call, but at the time I wrote this, the phrase had just been coined and no one was certain how widely the technology would be adopted. In fact, I received push back from engineers that there was “nothing new here” and that they were doing this before with Perl-based web clients.

I’ve decided to post the email here for archival purposes and back date it to the time of my original email:

To: Staff
Subject: AJAX Web Development

As technology develops, it seems that there are seminal moments that describe and amplify a trend that has been percolating under the surface. Four years ago Jeffrey Zeldman wrote “To Hell with Web Browsers,” and with that declaration changed the way web developers everywhere, including Kavi, build sites.

What Zeldman proposed wasn’t anything new. The technological underpinning that he advocated had been around for years, and there had been a growing trend towards standards-based design prior to his call to arms.

What made Zeldman’s declaration significant wasn’t the ideas in it. Instead, he said the right thing at the right time. He coalesced many trends in web site development into a single, forceful argument for the standards-based web site development.

Why talk about this now? Because the day after the anniversary of Zeldman’s article, Jesse James Garrett wrote an article that I believe will mark another seminal point in web site development:
http://www.adaptivepath.com/publications/essays/archives/000385.php

The article carries many of the same characteristics. It describes existing technology (XMLHttpRequest) that has been around for a long time that has only recently begun to be looked at in a different light. Recent projects, particularly by Google, have illustrated how powerful this technology can be.

Take a look at Google Suggest (http://www.google.com/webhp?complete=1&hl=en) to see a web page auto-complete your search terms or try Google Maps and drag the map around with your cursor (http://maps.google.com/). And of course Gmail’s major appeal comes from it’s wonderful interface based on the same technology. In each case, the traditional web paradigm of the user making a change, submitting a form, and then waiting for the entire page to load has been replaced with nearly instantaneous feedback.

Garrett’s article gives this technology combination a name—AJAX which short for Asynchronous JavaScript + XML. His article marks the launching point for broader adoption of this technology. I expect to see many more web sites utilizing this technology combination over the next couple of years.

AJAX holds tremendous promise for our applications as well. Imagine auto-completion functionality when editing a company record and the time-savings it would give our customers who interact with our applications daily.

Four years ago, we could not have anticipated that the change advocated by Zeldman we be pervasive throughout the work that we do. Yet it has become a key part of what we do. And we have benefitted from adopting that philosophy.

AJAX holds that same promise. I encourage everyone who develops sites to read Garrett’s article. Keep your eye on this technology. I guarantee that you will see more of it in the future.

-Jason

References:

Ajax: A New Approach to Web Applications
http://www.adaptivepath.com/publications/essays/archives/000385.php

And Jeffrey said, “To Hell”
http://www.dashes.com/anil/2005/02/17/and_jeffrey_sai

To Hell With Bad Browswers
http://www.alistapart.com/articles/tohell/

XMLHttpRequest References
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
http://www.xml.com/lpt/a/2005/02/09/xml-http-request.html
http://developer.apple.com/internet/webcontent/iframe.html
http://www.oreillynet.com/lpt/a/1557

Examples of Ajax (XMLHttpRequest)
http://www.google.com/webhp?complete=1&hl=en
http://maps.google.com/
http://gmail.google.com/
http://www.a9.com/
http://blog.bitflux.ch/wiki/LiveSearch
http://www.basecamphq.com
http://www.tadalist.com
http://www.papermountain.org/demos/live/@JWanaRSVkJNJuQov/aHmKJgXs