An Interesting Read for Developers

I came across an interesting article/eBook, Essential JavaScript Design Patterns For Beginners [Hat Tip: Hacker News]

At the beginning of this book I will be focusing on a discussion about the importance and history of design patterns in any programming language. If you're already sold on or are familiar with this history, feel free to skip to the chapter 'What is a Pattern?' to continue reading.

One of the most important aspects of writing maintainable code is being able to notice the recurring themes in that code and optimize them. This is an area where knowledge of design patterns can prove invaluable.

It is well written. Worth the read if you're so interested.

Page Size, Includes, and Page Rendering

I came across a site that took a long-long-time to load. I took a look at its source code. The code is well-written; there are no graphics or movies and yet it takes about 20-40 seconds for the page to render.

There are at least 22 .css includes and 17 .js files. The file is 512K NOT including the .css and .js files and has 3859 lines.

OK designers and developers I know that many users have great connections but when you have almost 4000 lines of code (not counting .js and .css files) including one line - jQuery.extend(Drupal.settings)- which had over 57,500 characters you've gone off the deep end.

Maybe in 6 years when computing power quadruples and we're all on Gbit networks then fine. Until then, at the very least, make certain that the file in question uses all the .js and .css files being called.

See other files that covered this topic:

1. Why am I waiting so long for some websites to download?
2. @Font-Face and Page Rendering Performance

Why am I waiting so long for some websites to download?

Too many sites I go to take a long time to render - often times over 30 seconds. The page displays but freezes so that the user is unable to scroll down and often the site temporarily freezes the browser so that one is unable to go elsewhere. (I find this issue to be more prevalent with IE than Firefox. It also applies only to the tabs and windows associated with that particular session.)

I've looked at the coding of these pages. Most of them are professionally done. The coding is fine and the graphics of reasonable size. So why do the pages take so long to render?

These pages had one thing in common. They had dozens of external javascripts for content scrollers, assorted widgets, jQuery, analytics and dozens more external CSS calls. Many of these .js and .css calls were unnecessary. The lesson here is that developers need to pay more attention to these external HTTP calls and limit them to what is necessary. It may be necessary to recombine the css and js to optimize the page loads.

Another big offender is the practice of preloading videos and podcasts. Developers cannot make the assumption that users will want to view these items. In delaying the page rendering in order to pre-load the videos they are alienating viewers. It may be a tough decision but pre-loading may not be an option.

See an earlier article: @Font-Face and Page Rendering

Designing for a Blackberry

If you're designing for BlackBerrys keep in mind the computing power of the late 1990s. The CPU's in phones such as the BlackBerry are not up par, being the equivalent to about 500MHz, and cannot properly render javascript-enhanced content.

@Font-Face and Page Rendering Performance

I found an interesting article discussing the use of @font-face. Some key points are

IE doesn’t render anything in the page until the font file is done downloading if there is a SCRIPT tag above the @font-face declaration.

Although font files don’t block other downloads, they do trigger the browser’s busy indicators. This has a negative effect on the user’s perception of page speed because it gives the impression that the page takes a long time to load.

IE is a little jumpy when it comes to downloading fonts. IE starts downloading the font file as soon as it encounters the @font-face declaration. This means IE downloads the font file even if no elements in the page use the font.

The author has a good solution: put the font-file at the end of page.

I recommend deferring the font file download until after the page has rendered, as shown in the Lazy Load Test. This solves the issues in IE – the page renders and then the font is downloaded in the background and enhances the stylized text once it arrives. This technique has benefits in other browsers, as well. By lazy loading the font file, most of the browser busy indicators aren’t triggered.

Too many designers forget that page rendering is still a primary concern. Viewers are willing to wait for a page to render but their patience is limited. Delaying page rendering for 6 seconds in order to deliver custom fonts is not acceptable.

CSS Tables

I don't usually make posts simply linking to someone elses work but Smashing Magazine has an excellent article on CSS and Table Designs

I'm glad to see that not everyone is a table hater. There is, after all, a place for tables.

When Do You Use a Table versus Divs?

When do you use a table versus divs? Some developers hate tables so much that they waste their time and effort creating divs when tables would do. It's simple - if you need to match up cells in a row across the columns then you need a table. If not, then divs would probably do.

Increase Page Rendering Time by Reducing HTTP Requests

Yahoo has shown the results of research, using packet sniffers, showing that download and rendering time is due almost entirely to HTTP Requests.

No less than 60-95% of the response "time is spent making HTTP requests to fetch all the components in that HTML document (i.e. images, scripts, and stylesheets)."

The impact of having many components in the page is exacerbated by the fact that browsers download only two or four components in parallel per hostname, depending on the HTTP version of the response and the user’s browser. Our experience shows that reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make.

EDIT: 4/17/2007

If a web page evenly distributed its components across two hostnames, the overall response time would be about twice as fast.

Performance Research, Part 4: Maximizing Parallel Downloads in the Carpool Lane

B versus using Span and Class

I have a client whose company name is bolded for branding purposes. It got me to thinking - ought the company name be bolded using the <b> tag or by attributes in the <span> tag?

Some have argued that <b> has been deprecated (or will be shortly) in favor of <strong>. It has not been deprecated although w3.org discourages its use in favor of stylesheets. The key difference between <b> and <strong> is that

EM and STRONG are used to indicate emphasis. ... These phrase elements add structural information to text fragments.

What are the relative merits of <b> versus <span>? If ever there was a case for the use the <b> element, this might be it as this its use is first and foremost a visual element. After all one cannot know how a browser will render <strong>. Still I would recommend <span> as the branding may change in time. <span class="logo"> maybe longer to write than <b> but it would solve all issues as rendering information will be located in the style sheets.

<b class="logo"> is an alternative. It will rank higher in today's SEO ranking (although is that really necessary for a logo?) and can be easily changed with a search and replace should the need arive at a later date.

Looking at .Net

I’m told that .Net is the future. It may very well be. There are some aspects that I like: namely the attempt to separate code from content, but I wonder if it actually accomplishes this task better than existing languages. I can do the same thing in CFMX. There is no reason to switch to .Net for this reason. There are some minor changes that I appreciate. I like that the default for their forms is POST and that the form refers back to the same file and automatically keeps the form data in state. But again – this is minor.

There is one thing that looks very interesting and that is .Net' conversion of standard HTML tags into server-side objects. I’m not certain how I would play with that but it is intriguing.

Overall my first impression of .Net is positive. I don’t know where they’ll be in 5 years but I think MS has dramatically improved its ASP product.

Why do we still have <u>?

Is there any reason for the <u> tag to exist? Underlining text was a means to highlight typewriting text. Typewriters, as useful as they were, were limited to a single font and size. Underlining text in these pre-published manuscripts was a kludge, allowing users to emphasize a particular portion of the text.

We understand why <u> was initially created: the web was originally conceived as a means for academics to exchange ideas. Since academic papers used underlines as a means of emphasizing reference titles; and since the people who created the original web standards still thought in terms of the typewriter they naturally included the <u> tag.

However a decade has gone by since Mosaic / Netscape revolutionized the web. What do we need the <u> for? Underlines are the default means of displaying a link and will remain that way for the foreseeable future even though underlines deface the types’ descenders. Still, usability trumps aesthetics in this case. As a result of underlines being used (almost) exclusively to designate links few professionals use the <u> tag anymore except when designers mean to evoke the look and feel of typewritten text.

This is a minor issue as there is no overriding reason to pull the <u> tag. Still, Web Standards are an evolving project – and this kludge from a bygone era needs to go.