Several weeks ago I touched on the front end design topic with the piece, “New Concepts in Front End Web Design Architecture,” which was a broad-strokes approach to some of the current and trending thoughts and principles stirring around the web development world.

In this post, I will delve more into the things that affect your website’s front end performance, and will highlight the main points from a relatively new resource called the Browser Diet. The Browser Diet calls itself “The definitive front-end performance guide: How to lose weight in the browser.” This front-end performance resource was created by a consortium of folks such as Briza Bueno from, Davidson Fellipe of, Giovanni Keppelen an ex-Peixe Urbano, Jaydson Gomes of Terra, Marcel Duran with Twitter, Mike Taylor at Opera, Renato Mangini with Google, and Sérgio Lopes at Caelum .  The Browser Diet GitHub resource lists over fifty references, including topics and sources from books, websites, people, HTML, CSS, JavaScript, jQuery, images, and servers. As a stakeholder in your organization’s website, you might want to consider some of these guiding principles for front end web design performance.

Figure B

Why performance matters?

We all know as web developers that if your web pages don’t load fast enough for your users then conversion rates fall, revenue per user falls, searches per user suffers, sales drop, and download speeds come to a crawl. The folks at Browser Diet put together a nice short Impact of Performance showing how the major search engines such as Bing, Google, and Yahoo! improved their performance, as well as examples from several vertical markets such as Shopzilla, Mozilla, and Netflix.

The “definitive” guide

The Browser Diet “Definitive Guide” is divided into seven sections which encompass the main topics of HTML, CSS, JavaScript, jQuery, Images, Server, and a Bonus portion. I will highlight several of the main guiding objectives that the Browser Diet details.


Avoid inline and embedded code

As a rule of thumb you want to use external calls to load your CSS from a <link>, and JavaScript from the src attribute within the <script> tag. While embedded and inline code can be useful for some implementations such as small pages, or pages that are only used for a temporary purpose, in most cases you will want to call your CSS and JavaScript from external sources. The other benefit is that the browser is able to cache the external files, which aids in the web page performance. One of the tools that is referenced here is the Assetgraph-builder, which is the AssetGraph-based build system (mostly) for single-page web applications.

Put your style calls up top and script calls at the bottom of the page

This is standard practice which really is a no-brainer, nevertheless you want to load your styles from within the <head>, so that the page will be rendered with the styles intact and applied as the page is loaded. And for any <script> tags you want to make sure they are placed just before the closing </body> tag at the bottom of the web document page. This seems to be the area that has not taken on much traction but is seeing more adoption among websites and developers. The reason for this is that some JavaScript or JQuery may take a bit more time to load on the page than what is normally expected by the user, and having the calls for the scripts at the bottom of the page allows all non-scripted content to load first.

Other HTML topics include minifying your html, maintaining readable code, and using the async attribute for better loading time, allowing scripts to download asynchronously while the rest of the page continues to load.


Minify your CSS

While commented and readable CSS code looks nice with indentation, this actually adds some bloat to your stylesheet. Browsers don’t concern themselves with comments and indentation within your stylesheet files, so CSS files will load faster when the extra human bloat is removed, and there are several automated tools that can take your commented CSS and minify it before you put it into staging or production environments, the example displayed below shows a sample of typical commented and indented CSS and then the same CSS code minified:


/* head */
.logo a {
.head .homelink {
       background:#0b5375 url('/i/bg-area-title.gif') no-repeat;

After (minified)

.logo a {    display:block;height:46px;text-indent:-999em;width:115px;}.head .homelink {background:#0b5375 url('/i/bg-area-title.gif') no-repeat;height:78px;left:-20px;position:relative;width:490px}

As the “browser diet” points out, “…those that use pre-processors like Sass, Less, and Stylus, it is possible to configure your compiled CSS output to be minified.”  Several other tools for minifying your CSS are listed in the reference as well including CSS Minifier and CSSmin.js.

Reduce the number of requests for CSS files

How many times have you seen something like this within the <head> of your web page documents?

<link rel="stylesheet" href="css/intra.css" />
<link rel="stylesheet" href="css/print.css" />
<link rel="stylesheet" href="css/moble.css" />
<link rel="stylesheet" type="text/css" media="screen" href="css/local.css" />

Each of these CSS requests takes more time to load the page, so it makes sense to combine all your CSS into one single file that requires the page to make only one request:

<link rel="stylesheet" href="styles.css" media="all">

The final CSS topic states that it is preferred to use the <link> over @import to call your stylesheet since browsers are incapable of downloading @import assets in parallel.


Load third-party content asynchronously

How many times do you embed third-party scripts from YouTube, Vimeo, Twitter or Facebook into your web pages? The issue is that many of these third-party content connections are not always clean or efficiently distributed; there are a multitude of variables that can alter the end user experience. To avoid this issue, you can load these codes in asynchronous fashion preferring a link to an import, and this script can be used to load multiple third-party widgets.

Avoid document.write

As this always requires the page to be fully loaded each time the document.write call is returned.

Other JavaScript topics include:


Always use the latest version of jQuery

This is another principle that should always be built-in to your script calls if you use jQuery, nevertheless, it had to be included since many folks link to static versions of the library. Reference the presentation, jQuery Proven Performance Tips and Tricks. The latest version of jQuery is available at:

Other jQuery topics include use for instead of each and don’t use jQuery unless it is absolutely necessary.


Use CSS sprites

Grouping several images into a single file, and then positioning them within your CSS helps to reduce the number of requests. The sprite technique, while widely, known is not widely utilized, however, it has been found in recent use with the parallax scrolling technique.

Data URI

An alternative to the CSS sprites, this is a scheme that provides a way to include data in-line. This technique allows normally separate elements such as images and style sheets to be called in a single HTTP request rather than from multiple HTTP requests, which results in higher efficiency and performance.

Other images topics include don’t rescale images in markup and optimize your images.


Enable smart caching

As I mentioned in my post, “Cache is king: Learn more about website caching policies,” several weeks ago, the best way to optimize your web page requests is to not have a request at all, and this means allowing the browser to cache your resources and assets.

The other server topic is the use of gzip to compress your files at the server level.


The bonus section includes a few resources to test your web site performance including extensions you can include in your browsers such as YSlow and PageSpeed, as well as online tools such as WebPageTest, and HTTP Archive.

If your organization already follows these principles then you probably have a website with fairly good performance levels; if not, then you might want to incorporate the missing ideologies into your web development and production environments.