Web Pages That Suck - learn good web design by looking at bad web design

I’m spending a lot of time working with web page speed. I discovered an interesting factoid: if you throw all your HTML, Javascript, CSS and graphic files in the same directory (and modify your files to account for this), your pages will load 20-30% faster. Of course, I wasn’t a math major.

It sucks.

Submitter’s comments: Here’s one that really sucks!

Vincent Flanders’ comments: Yes, but it sucks in such an interesting way. Here’s a screen shot of what the home page looks like to the average visitor. Here’s what I find “amusing:”

1. The focus is definitely the logo. Even so, what does that buy you? I suspect most people who end up at the site know where they’re going. The web is all about expectations and your job, as a designer, is to meet those expectations. Logos are supposed to be unobtrusively “there” at the top-left of the page.
2. If you’re using horizontal navigation, it’s supposed to be at the top of the first screen — not down in the middle.
3. I realize it’s a golfing site, but the golf clubs are not a good idea to use for your navigation.
4. Fortunately, you can read most of the text — because it’s quite large and has to be large because it’s white on a black background.
5. The TITLE tag on the home page is “home page,” which isn’t very helpful for search engine optimization purposes. Speaking of SEO, I’m taking an ADHD detour here to mention Google’s own SEO Report Card. The description is at the Webmaster Central Blog. It talks about their failure to meet their own guidelines (which include the TITLE tag) and there’s a 49-page PDF file you should read.
6. There are pictures at the bottom of the page which seem to be centered, but they clash with the bottom navigation which tries to be centered.
7. The subpages are too long.

There’s lots more, but this list is a start.

Southern Crescent Tour

Submitter’s comments: Now this is nice! It has a beautiful horizontal navigation, which you can control by keyboard, too. Needless to say that it breaks my favorite hotkeys Alt-left and Alt-right to navigate backward and forward in my browser.

Just tried to click some post called “Rethink. Redefine. Redesign.” Would be a great idea. When you’re at the utmost left or right position, which you cannot tell as there’s no horizontal scrollbar visible, you automatically jump to the next/previous article. And as you can see at the upper right corner, you can also press the letter ‘s.’ No idea where that brings me, but at least it does something. You can even point with your mouse at the letter ‘s’ and my browser says that I can click on it. I do not dare, as no url shows up on my status bar, so I don’t know what happens.

Oh wait! The ‘s’ was the last letter of ‘Issues’. I just had to make my browser window a bit wider. Lucky me that I have a screen capable of 1280 pixels horizontally. But everybody has wide screens, nowadays, don’t they? (And lucky me I know how to turn off Javascript, which disables this crap and results in a normal, vertical page.)

Vincent Flanders’ comments: This site conveniently classifies itself as “experimental,” which disqualifies it from being a WPTS Daily Sucker — no matter how much the site sucks. And the site sucks much.

The site’s content consists of articles. Articles are composed of words. Words need to be presented in a linear fashion and that means top-to-bottom — not horizontally, which necessitates scrolling (or, in this case, clicking). The navigation goes batshit crazy on the feature pages. This is an information site and people expect to see content presented conventionally. Remember: it’s experimental; it sucks; and it isn’t the Daily Sucker.

There are a lot of contrast problems, as this screen capture by the Juicy Studio Contrast Analyzer demonstrates. Remember: it’s experimental; it sucks; and it isn’t the Daily Sucker.

I hate writing that looks like it came out of dack.com’s Web Economy Bullshit Generator. The modus operandi page of today’s not-the-Daily-Sucker has the following phrase:

We tried to think ahead and create a site that was a paradigm shift in interactivity and turn the traditional blog format on its head – or in this case, on its side.

Paradigm shift? Bullshit. If I want a paradigm shift, I’ll stand in front of the San Andreas Fault and wait for the big one. (Yes, I’ve used the phrase twice on WPTS, but it’s used sarcastically). Remember: it’s experimental; it sucks; and it isn’t the Daily Sucker.

Thinking for a Living

I ran into two articles about problems in using a CSS file for printing:

1. Browser Performance Problem with CSS “print” Media Type (December 2009)
2. 5c media=print stylesheets (February 2010)

It turns out that if you’re using a print stylesheet (shows up in the format <link href=”print.css” type=”text/css” rel=”stylesheet” media=”print” />), every other file has to wait to load until print.css finishes loading.

To get the full effect of the delay, I created a 583Kb print.css file — which may be the world’s largest print.css file — and placed it in the head of this HTML file. Notice how long the page takes to display (I’ve turned off caching and file compression.).

The following picture shows what happens (click graph for larger example):

The page took 7.42 seconds to load. Page Speed gave the page a score of 81. Yslow gave it a “B,” with a score of 84. These two tools are extremely important and should be in your arsenal.

Optimizing the page. I removed the CSS from the <HEAD> of the document and inserted the Javascript code from Article 1 just before the </BODY> statement.

<script>
window.onload = function() {
var cssNode = document.createElement(‘link’);
cssNode.type = ‘text/css’;
cssNode.rel = ‘stylesheet’;
cssNode.href = ‘print.css’;
cssNode.media = ‘print’;
document.getElementsByTagName(“head”)[0].appendChild(cssNode);
}
</script>

</body>
</html>

As you can see in the graph below, the document loads much faster (click on the graph for larger example). All files load in 5.97 seconds, but the whole page (everything but the print stylesheet) loads in 2.11 seconds — the visitor quickly sees the page and doesn’t care that the print stylesheet loads last because s/he may never want to print the page and if s/he wants to print the page, it won’t happen immediately.

Page Speed gave this version of the page a score of 85. Yslow gave it a “B,” with a score of 83. Page Speed liked the page 4 points more, but Yslow liked the page 1 point less.

Since nobody on Planet Earth is going to print a document immediately after it loads, it’s safe to use Javascript to load the print stylesheet. What if they don’t have Javascript enabled? See Article 1 for the answer.

Yes, it’s true that nobody is going to have a print stylesheet that’s this large (it’s composed mostly of comments) and the improvements aren’t as important as caching and compressing your site’s files, but it’s good to be aware of what causes roadblocks in displaying your web pages.