One of the bigger problems I see in the performance space is that a lot of the value of current content management systems and blogging tools is the ability to add widgets or plugins from a lot of different places. These plugins often do not provide compressed and cacheable versions of their content.
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.
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.
Dion Almaer of Google and Ajaxian.com announced late last week the AJAX Libraries API. If you use AJAX, you’ll want to pay attention to this announcement. What does it mean?
Popular AJAX libraries including:
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:
- Far future expires headers to increase caching
- Delivered using Google’s extensive content delivery network
If you are using any of these AJAX libraries, you would be foolish not to seriously consider taking advantage of this service.
“A new release of jQuery is out — 1.2.6, skipping directly from 1.2.3. Most noteworthy are the performance improvements.” via Ajaxian. Further details in the release notes.
There are many advantages to HTTP Basic Authentication, but despite these advantages, web developers have turned almost exclusively to using cookie-based authentication because of some limitations in how HTTP Basic Authentication can be implemented. Until recently, there has been no way to for developers to control the login form nor provide a way for users to log out.
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.
A few years back I helped build a content management system. At the time, Internet Explorer on PC was the only browser we could use for WYSIWYG editing. As a Mac user, I struggled with the fact that I was delivering a product that I could never use on a regular basis.
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.