Generally speaking, perceived reality is just as important as absolute reality. Whether we are aware of something or not, doesn't make it any less real, and sometimes, we are aware of things which we think are real, but really aren't.

See this video, and we will continue to discuss perception:

Okay, now that we're aware, let's begin by breaking down User Experience (UX) on a website. The user experience begins with the page load. If the page takes too long to load, then the user wants to leave, because there are better places where they can spend their time. The typical user will leave a site completely if a page takes seven seconds or longer to load. So what can we do about pages that have a lot of images, video, or other content?

What do we do about pages that are served from no-so-great-hosting? I have hacked a PogoPlug and have it running as a web server out of my home. I can tell you this, that poor little guy is a champ, but he's running on a not-so-great-upload-rate along with not the greatest optimal hardware for a web server, but he still works like a champ and you wouldn't know the difference.

Why? Because of intelligent layout for the page.

Let's say that I have a web page that is a total of 1.1Mb. If I were to have it display after everything was downloaded, and only then, a lot of people would probably not view the page, thinking it was a bad link. Right? But what if we were smart? What if we were geniuses? What if we could solve problems, come up with creative solutions, and end up delivering pages which are so natural to use, that most people wouldn't even know about all of the design, because it just fits together so well? We can, and it's not that difficult, once it's broken down.

When we examine problems, we need to know how to solve them. We might even have a solution, but we need to find a way to get to the solution from where we are. I'm going to don the role of Captain Obvious, and say that when we're working with problems dealing with time, we want to find out where our bottlenecks are. When we do that, we touch on a concept that can be called "Maximizing our Minimums". When we maximize our minimums, we help eliminate as much downtime and wasted time as possible. Programmers have been doing this for years, and one of the results is what we now know as "hyper threading".

In the web design world, there are two to three places that are going to present bottle necks. Those places are the server, the client and the browser. A lot of the server issues were handled in the previous tutorial on page load speeds. The client area is a place we don't have a lot of control over, since we cannot tell them to not do real-time video editing of themselves drawing self-portraits in Photoshop while documenting the entire thing in Word, with iTunes blasting in the background. But we can control part of the browser.

When we deal with the browser in web design and development, we have to get a good understanding of what we want to accomplish, and how the browser works. A lot of times, we can simplify our page loading time by simplifying our markup in HTML and CSS.

Complicated CSS rules, @import, CSS expressions all add to page rendering time. This is when the browser parses the rules, and renders the page accordingly to it. So adding unnecessary @imports, save an http request, meaning less "response-time" from another server. This can really add up, especially if you are working on a site that imports from a lot of various places.

HTML can be a culprit here equally. HTML can help our browser out by specifying the height and width in our IMG elements. This gives a great leg-up for our browser, as it won't have to parse the image, but instead it can take predefined measurements, and render from those. HTML containers, lists, definitions, etc, can a lot of the times be simplified, eliminating a lot of unneeded markup. The less markup that a browser has to parse, the less time it will spend parsing it (duh!).

CSS and HTML aren't the only two offenders though, there's also JavaScript, and the actual getting of external files as well. When you request multiple files, you are making multiple requests, which means you need multiple responses, and that means you need to wait for each of those. We already talked before about the @import in CSS, but what if you have 20 different CSS sheets? What if your sheets could be combined into one sheet? What if, you had an intelligent library that could generate your CSS files on the fly, put them into one big file, cache it, zip it, and deliver it when it's needed next? I think it's possible, and I think it's a good idea.

I'm currently writing a way of doing this via bit-masking. We can parse our pages through a pre-processing script, which will then generate a binary number, convert it to hex, and append it to a style.css file via a query string: style.css?14F254BA901, what this does is, the first time it is read, it generates a unique file, which contains all of the active bit rules, compresses them, and returns them, minified and gzipped. This makes sure that we're not putting unnecessary rules, which would only serve to bloat our pages. This same principal is being implemented for JavaScript libraries too.

On the subject of JavaScript, it is a well-known fact that JavaScript files cannot be downloaded in parallel, and when they're being downloaded, they cause a nasty bottleneck in the pages rendering. So the way that we combat the fact that the page is taking a long time to download is by placing as much JavaScript as we can at the bottom of the page, right before the "" element. This way, the page will render properly, however, the JavaScript will load after everything else. This is useful, but dangerous if you have functions which need to load when the page loads, or before other elements on the page load. So when you begin working with this aspect page load optimization, make sure you know what your scripts are doing, when they're doing it and why they're doing it. Sometimes you can break core functionality, which defeats the purpose of having a fast loading page. Unless you want them to have a page that loads fast, but doesn't do anything.

The thrust of the whole article is this: it's important to understand what we're doing, why we're doing it, and how we're doing it. If we are just adding things because we have seen other people do it, we need to take a step back and figure a few things out. If we're adding a JavaScript to the head of a program, that contains functions that are run on "onload" in the body, then we're in a good spot. But if we're keeping JavaScript files in the head which only deal with mouseovers, color changes, and other non-essential to have run first functions, it's better to place your script at the end of the body. Make sure you understand images, and overly complicated CSS as well. There is a saying which goes like this KISS, and it stands for "Keep it Simple, Sillyhead". It's very important for us sillyheads to keep things simple. In nature, we see a lot of very simple solutions to what we might call complex problems, and I think that is a great source for inspiration, application and implementation.