Introduction
There is much research to show that the response time of a site is the key factor in maintaining a user's interest. A slow site leads to a bored visitor, and one more failed visit. This series of articles aims to highlight simple techniques that can reduce page load times dramatically, whilst maintaining the rich graphical environment we have all become used to.

Performance factors
There are many factors in determining the time a page takes to load. These range from the amount of text and number and size of images on the page, through server and client performance, to network speed and congestion. For any site only some of these are directly under the author's control. However, it is generally true that smaller files and fewer requests reduce network traffic and improve performance.

The graphical environment
As user and designer sophistication has increased, so has the use of graphical elements on the page. These include the large images and graphics on many pages, but increasingly there are numerous small graphics used for a multitude of purposes. A complex page can include fifty or more graphical elements used as icons, border designs, backgrounds and more, and each element generates another network request and more network traffic.

The data: URI scheme
This problem was foreseen as long ago as 1995, and various partial solutions were implemented. In 1998 RFC2397 appeared, formalising the layout, notation and usage of the data: URL, a scheme to include small arbitrary items of data directly in the source document, but processed as though they had been included externally.

Using the data: url
The data: URL consists of four basic components: the protocol (data:), the mimetype, the encoding method, if any, and the encoded item. A simple image might appear like this:

Original image:

Base64 encoding and compression
Small images and other items sent this way reduce the number of HTTP requests needed to complete a page, and this can provide a useful reduction in load time. However, encoding a binary image with base64 encoding can increase the amount of data transmitted by up to 50% per image. Fortunately, the GZip compression support by modern browsers can reduce this overhead to less than 10%. For small data items handled this way, the saving in load time can be significant.

Caching
Modern browsers cache the content they receive extensively. The effects of this are particularly noticeable when moving from page to page within a site, where many layout graphics are cached. Images sent as data: URLs are not cached in this way, which can reduce the performance gain, or eliminate it altogether. Fortunately, there is a way around this too. External CSS files are cached by browsers, and loading an image as a background to a DIV element can be coded in such a file. For example: <style>

div#greentick {

width:30px;

height:30px;

background: url(data:image/png;base64,iVBORw0KGgoAA...(more base64-encoded data)...);

}

</style>
Of course, this will increase the size of the style sheet, but compression can help here too.

Browser Compatibility & Size Limits
All the current versions of the mainstream browsers support the data URL, but the size of the object they will accept this way varies. The RFC suggests a limit of just 1k bytes,  IE8 supports data URLs up to 32kbytes, while Firefox extends this to around 100kbytes. Opera 10 has been shown to allow video files up to 1.3Mb to be sent this way. For older browsers, or browsers where support is poor or poorly understood you may have to send a version of the page or style sheet using external references. Using PHP or other scripting language to examine the HTTP_USER_AGENT field of incoming requests can make that decision easily. For larger images, or where images change frequently, this technique has no value. For that we need to look at image sprites, the subject of the next post.