Front-end performance for web designers and front-end devs

Thanks for a nice intro in front-end performance Harry. I've found the section on prefetching especially interesting. Speed (performance) should be seen as a major _feature_ in any site/app.

But there's a lot of "It depends" regarding performance, no?

Us 'techies' must be ware of focussing too much on (premature?) micro-optimizations while forgetting some of the most obvious quick-wins: obviously limiting DNS lookups are of little worth when we are loading in unnecessary massive JS libraries or using huge images (imageoptim.com all the things!).

You touch briefly on the subject but I feel these 'simple' things are worth mentioning (more) I think.

Such as…

YSlow yslow.org

Make the Web Faster - Google Developers developers.google.com

ImageOptim - make websites and apps load faster... imageoptim.com

Valuedstandards

- Perceived speed matters (most?): progressive JPG, lazy-loading, etc.
- Big images, JS libs & webfonts probably account for most load-time delay
- _Bad JS code_ (or third-party plugins?)
- Reducing the number of DOM nodes?
- Slow back-end (hosting)?

You say very little of _caching_ (Expires, etc), another huge topic.

I am sure you are aware of initiatives such as yslow.org & developers.google.com. Don't you think the tips in these tools should be a starting point and we should focus on other 'exotic' issues only after the basics are dealt with?
My feeling is that it's best to leave most of these micro-optimizations to the browsers.

Thx, I've learned a couple of things and would like to read more of your thoughts on this.

Make the Web Faster - Google Developers developers.google.com

YSlow yslow.org

Make the Web Faster - Google Developers developers.google.com

Andy Davies

The network is generally the slowest link in the chain of creating a webpage and delivering it to the browser and as it's abstracted away by the browser tends to be missed by too many developers.

There are some very easy things that many people don't do e.g. turn on gzip, enable keep-alive, optimise images, set cache lifetimes etc.

There are other performance rules that are 'it depends', e.g. when merging files to reduce requests there becomes a point where it's better to have two smaller files (say 75KB gzipped) than one large one (say 150KB gzipped) as they'll download in parallel.

You've only got to look at some of the sites on mediaqueri.es to see how far we have to go in educating people about performance good practices.

Media Queries mediaqueri.es

Teddy Zetterlund

Not taking anything away from your article and its important message, but I'd add links to Google's [1] and Yahoo's [2] performance pages as attribution and valid sources for the information.

[1]: developers.google.com
[2]: developer.yahoo.com

Kaelig

"Never serve it from a static/asset domain because this can incur DNS lookups that further delay rendering."
I'm not sure this statement applies to every context. In your case, it seems that you are serving pages to a UK audience, in which case CDNs don't really give a geographical advantage to your users and your statement makes a lot of sense.
Now, let's say your main domain is pointing to a server in the US and you are serving CSS with it to a UK user on the same domain than the application itself: then you are serving a static file from a distant location (and with cookies). A static domain can serve the asset from a closer location (if the CDN is intelligent enough), without cookies.

Marcus Greenwood

A few small things.

1. Avoid document.write() like the plague. 3rd party scripts (particularly ad-servers use this quite a lot) and can be remedied with async script loading combined with tools like WriteCapture: github.com

2. Make sure the TTL setting on your DNS is *not* 0. This will stop DNS queries from being cached which mean the browser has to look up the ip address for the domain on every request.

3. PJAX provides a very simple way to speed up page loading by only loading the <body> (or specified) portion of the page. It is pretty easy to configure and usually only requires a couple of changes to your server-side code:
github.com

Jacob

You mentioned putting a Twitter widget on your website, which takes another DNS/http request. Many social websites have the ability to post stuff via just an url, which takes away the necessity of an external js library. Obviously you don't get the fancy stuff such as tweet count, but in certain cases I'd say it's definitely worth it. Here's a link to some examples. github.com

Peter Gasston

You skip over it, but image optimisation can be incredibly important too; things to consider:

* using an icon font instead of bitmap icons overcomes the HiDPI problem
* when saving JPGs, quite often you can get away with quality as little as 51% (using Photoshop), which greatly reduces file size
* if using JPGs for HiDPI you can drop the quality even lower (see here: blog.netvlies.nl)
* Running an image through ImageOptim can shrink the file size even further, sometimes by up to 25% for larger images, and 75% to even 95% for smaller images

Perhaps I should write this up on my own blog...

Andy Davies

There is the compressive images technique too - Thomas Fuchs talks about it in his book retinify and others have picked up on it recently where for 2x images you make a image twice the size but use low quality (blog.netvlies.nl)

One thing that I haven't seen much detail for that approach is how the increased memory usage on phones and tablets etc. affects performance.

Retina revolution blog.netvlies.nl

Ted Goas

What do you guys think of Sergey Chernyshev's .htaccess? ( may have been referred to as 'drop in .htaccess' in the past ). It could be used as is or changed on a site by site basis. Looks like an easy win in supported environments.

github.com

Andy Davies

Thing the @h5bp .htaccess is the one to go for now (although the config is better in httpd.conf). Sergey has an an open issue on whether he should merge into @h5bp

Kelly Dyson

I just spent a whole day last weekend struggling to improve the performance of my own website - I wish you had published this a few days earlier! There's some good advice here, and important reminders of stuff I should already be doing - I barely ever think to check that 'progressive' box when saving an image in Photoshop, but it makes a huge difference down the line.

I couldn't get the prefetch to work with an image unfortunately.

Adrian Westlake

A nice overview. There are a couple of things I would like to add:

1. Putting JS at the bottom of your site is a good start, but you might consider using a JavaScript Asynchronous loader such as RequireJS or LABJS which are designed to not only start loading JS after everything else has loaded, but can also handle defined execution order, useful if you have JQuery plugins with associated bits of JS to trigger them.

2. Use Google's DN for JQuery and any of their other hosted libraries. Most likely people will have this cached on their machine. Also look at CDN.js for many other JQuery plugins and libaries that handle stuff not hosted on Google.

Jeremy Church

I was really curious about image prefetch, so I tested it with a background-image and :hover. Short story, it didn't seem to work. Posted the test and findings here: j.eremy.net

Clement

Hi great article. When your are talking about using sprites something poped up in my mind. What about the paint action performed by the browser to chop down that sprite? Should we only sprite small images eg < 100px or can we sprite the world ?

Jake Lazaroff

The image prefetching example (for a sprite included on every page) would have a negligible affect on performance, since the browser would cache the image on the first pageview and load it from the cache on every subsequent one.

The best images to have prefetched, I think, are content images; ones your browser is likely to be receiving for the first time.

Tim von Oldenburg

Thanks Harry for the very informative and well-researched article. I already made a list for optimizations for my own site :) Very helpful!
Especially, I noticed that I was loading FontAwesome, but only using 3 of the font symbols. Better change that to a PNG sprite...

Christian Eaton

Great article, Harry. I'm interested as to why you've used an <i> element rather than a <span> for the "Spriting element" - is it just to save 6 characters? The latter would seem more semantic to me..

Harry Roberts

@Christian Eaton It is purely a time saving thing, less chars to type. It is important to note that because the `<i>` is empty then there is nothing to pass the semantics on to; there is no semantics involved :)

Kristina Auckland

@Harry

Really great article, thank you for sharing.

@Tim von Oldenburg

You could also try icomoon.io as you only include the symbols that you actually use. Hope this helps.

Front-end performance for web designers and front-end devs

top highlights

Great conversation?

Uh oh! We encountered an error.

Can you do us a favor?

and paste in Safari

Highlighted By

Front-end performance for web designers and front-end devs

top highlights

Great conversation?

Uh oh! We encountered an error.

Use your email

Can you do us a favor?

and paste in Safari