Categories
main

Optimizing HTTP requests and CSS with @media

Situation

Room for ImprovementAll of our sites have three style sheets, an “all”, “handheld” and “print” all necessary to a well rounded web experience.

Problem

They come at a cost tho, three HTTP requests each page load. It doesn’t seem too bad when you get 1000 visitors a day or each file is only 100k but it get infinitely compounded when 40,000 visitors a day and the css weigh in at ~5kb total. Just in the access log alone that is 3 lines per visitor or ~160 bytes totaling ~6.4 megs of log data a day.

Solution

@media – The hidden killer.. er.. saviour. Combining all those style sheets into one and using @media to separate the pieces.

Example

@media all {
#content{
background: #0C5449 url(../images/content-bg.gif) repeat-y top left;
width: 706px;
}
...
}
@media handheld {
#content{
width: 100%
}
...
}
@media print {
#content{
background-image: none;
width: 100%
}
...
}

In the HTML:

<link href="/css/home-all-min.css" rel="stylesheet" type="text/css"  media="all" />

Results

A reduction of 2 less HTTP requests and 2/3 less data being written to the access log. Compression saves ~20% of the css size but combining into one file reduces the overhead of the 1kb or 500b for the mobile and print style. Multiply that by 22% of our new visitors a day with an empty cache is a savings of ~24,000 HTTP requests a day.

I would say that its well worth it, reducing the amount of net traffic while still presenting the same amount of information. Although this is straight data without compression, things really start to get interesting when compression is added to the mix, stay tuned.

Categories
main

Road to validation.

Overseeing the current Wayne State University homepage is like running with a tiny pebble in your shoe. You feel it every step but your going so fast you cannot stop to take it out.

Working with a site so large it can become discouraging but taking one step at a time one can accomplish anything. Yesterday we took our first step, moving the site to a new server in an environment that we are comfortable and flexible in.

The old version of the site was sitting on an NT box, a requirement of the company who built it over 4 years ago. When I started I had a few goals, one was to get the site off that server and get it validated and rewritten in POSH. Well that day has come and we managed to sprinkle in a few other goodies along the way, here are some highlights:

It took some work to get here but we made it. There is still some tweaking to go but all in all its setup. Now its time to concentrate on the content, we are going to be doing a page by page overhaul and adding greater functionality and layout to each child page.

In addition to the content we will also be shrinking the file size and HTTP requests further and further down to the base minimum. Right now we are ~90k depending on the panel that loads and 16 HTTP requests with an empty cache, we hope to cut the size down by a third and get rid of 2-4 requests.

Stay tuned for more progress.

Categories
main

Progressive Enhancement

Building for the lowest common denominator and then expanding upward. It sounds like a simple concept but most wed developers just can’t seem to grasp it. Not believing accessibility matters or being so inexperienced that building sites seems to just be a hack fest to make the “design” work in all browsers is the single largest issue with web design now a days.

One example off the top of my head is mtv.com which did a total redesign in flash and had all these crazy bells and whistles, integrated video, movement, etc. Well two months later guess what happened, they redesigned again this time into a fully xhtml compliant site which didn’t have all the movement but was 100x easier to use and you could actually get to it with a cell phone and actually search for text on the page.

Two simple things I always look for when going to sites, first since I don’t have a lot of time to read through pages for information I use the firefox built in find as you type and if it cannot jump right to the word i am looking for ill go someplace else.

The second I don’t use as much but I am sure other people do, phone browser support. I am not talking about iPhone safari support because that is not really developing for the lowest common denominator. I use either a WAP browser of Opera on my phone while out and about if I need to look up information quickly. If I cannot get to your page and get to the information I need I will leave your site and probably never return.

We have a CMS that we built at Wayne State and sometimes page updates need to happen right then. We built it for the lowest common denominator just for that reason. We can get to it on any WAP browser and update any page in the CMS as if we were on a full computer. Without it we would have to rush to a computer just to use some fancy ajax interface, it would be pretty but would it really be worth all the hassle? I think not.

Anthem:
Speed > Features
Simple > Complex
Enhancement > Degradation

Categories
main

jQuery vs Prototype – Document Load: jQuery wins

Recently I started using jQuery instead of Prototype for my web applications. When I first started using a javascript library I picked Prototype because to be honest jQuery intimidated me, there was a lot of mystery about it. Well I took another look at it a few days ago and I was floored, boy I was missing out. jQuery byte for byte in my opinion kicks prototypes butt.

Take for example attaching a function to the document load and adding an onclick action to a link.

Pototype:

// Initially set everything up
init = function (){
// If there is an expand dom element
if ($('expand')){
Event.observe($('expand'), 'click', ExpandMenu, false);
}
} // Attach the onload function
Event.observe(window, 'load', init, false);

jQuery:

// Initially set everything up
$(document).ready(function(){
// On click event
$("#expand").click(function(){
// Function actions here
});
});

It may not seem like a great deal of code reduction but scanning the code from top down (say if you were a developer brought in to fix a bug) shows how more fluid jQuery is in terms of execution flow. Prototype jumps all over the place…

  1. First define the initializer function
  2. Next find the element on the page
  3. Set an observer on it and direct it yet another function
  4. Last but not least attach the initializer to the document load

It seems that is the exact opposite order of its execution, jQuery on the other hand…

  1. Create a function and attach it to the document ready state
  2. Create a function and attach it to a dom element on click
  3. Done.

First round goes to: jQuery

Categories
main

Javascript yeilding and graceful degration

I’ve been watching a few YUI Theatre and Joseph Smarr’s talk about AJAX and Plaxo.