When I worked for MLive.com, one of our practices was to leave out quotes around attribute values (except for alt attributes). This was to save on bandwidth costs. In spite of the fact that the page was no longer valid HTML (technically), all target browsers rendered the pages properly.
That might seem like nitpicking, but with over a million pageviews a day, all that ASCII can add up. Personally, I would prefer valid HTML, but I bet the financial side of that decision was pretty interesting.
I’d heard a rumor that, for similar reasons, Yahoo! used extremely short filenames for images, e.g. a.gif, b.gif, c.gif, etc. I don’t know if this was ever true, but it doesn’t appear to be now.
When I still relied heavily on transparent spacer GIFs, I put a 1×1 pixel transparent GIF at the server root (/1.gif) to achieve the shortest possible filename.
A few months ago, I noticed an interesting technique that Google uses to save bandwidth. Check out the logo image that they use on their search results page:
They can use the same background image several times on the same page by changing the background position via CSS. That means one image call for multiple images. One roundtrip from client to server, after which the image is cached and reused. The colors are similar between the images, so the file size is not substantially increased over the size of 3 separate images. This technique may not save Google a lot of bandwidth, but it speeds things up for the user and presumably reduces the load on Google’s servers.
Now I work on sites that don’t have a fraction of the traffic of a Google or even an MLive, and such bandwidth-saving techniques are largely unnecessary (from a costs standpoint) and ignored. But I still have a lot of respect for such clever ideas.
Now that more users are accessing the web from their phones, I think we could all stand to pay more attention to bandwidth again. I know that my phone cringes when it’s working on a 300K page (that in reality should be 30K). Maybe it’s time the 5K Contest was resurrected.
Wow very interesting! I’ve never really considered that before but all those small requests probably add up over the long term. For my situation, the ratio between the the bandwidth that I get (pay for) and the bandwidth that I use are so great that I can get away with lazy design, but I have to admire a tidy design where everything unnecessary has been stripped away.
“one of our practices was to leave out quotes around attribute values (except for alt attributes). This was to save on bandwidth costs.”
I disagree with this approach because it is basically unnecessary. Modern web servers (Apache, IIS, etc) can be configured to send all responses compressed at run-time, and furthermore, they can fallback to the uncompressed version on the fly for the small minority of browsers that don’t support decompression (not IE, not Firefox, etc).
“with over a million pageviews a day, all that ASCII can add up. Personally, I would prefer valid HTML, but I bet the financial side of that decision was pretty interesting”
Actually, the more ASCII you have the better because it has a REALLY high compression ratio (much higher than images for example). Please talk to your server administrator. You could save them a lot more bandwidth than you were with this dangerous trick.
Also, if you’re really interested in tuning a site for performance its better to use a tool to measure the impact of your techniques instead of guessing. For example, Fiddler2 (http://www.fiddler2.com/fiddler2/) provides visualization of the amount of data (i.e. all http traffic) going to and from a website as you’re using your web browser (IE in this case).
You appear to have overlooked the use of the past-tense in those first 2 paragraphs. I’m not sure how many browsers supported compression in 1998, but I’ll bet that Web TV didn’t 🙂
Erratum: quotes are recommended, but not required on attributed values in HTML. A page with unquoted attributes can still pass validation. Not all attributes can be left unquoted, such as those containing spaces or quotes, for example.
See http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.2 for details.