How we made our home page load faster

Few of my own tips, most of which you covered.

- Load everything asyncronously. RequireJS etc... (if you don't use AMD loading, then seriously start reading up about it).

- The overhead of including Facebook Like button and Twitter, is like 150kb. It's ridiculous. We load them after the page has loaded. In their place, we load placeholder Facebook buttons. That mimic the like button. (Similar to what TechCrunch does).

- Bundle everything. We use shrinksafe for this. (Sometimes Closure... it really depends on which one is playing nicer at the time of doing the build). This allows us to create enormous JS files of all of our application. What we do is create one "kernel.js" file. This is always loaded first. And once the page has loaded we fire off using AMD loading asyncronously to the actual application.js. I've played around testing on this as to whether it's best to only include the javascript that is relevant to the current page, but in the end we settled on loading absolutely everything. This makes the JS about 280kb gzipped. The user doesn't really ever notice the hit, since we load the "kernel.js" first, which contains the bare bones minimum.

- Use a CSS preprocessor. We use LessJS. We managed to reduce our CSS overhead by an overhead of 20% in file size while using the same sheet. When you use a preprocessor (although we supply the compiled versions) you are making the file gzip heaven. The ungzipped version is larger, but the compression is great. Additionally, maintainability improved by an order of magnitutde that I can't even count. Incidentally, we also provide the entire CSS for the entire site in a single .css file. Again, tests were done with splitting the CSS, but it just makes more sense to provide everything and improve the page loading on second requests (We don't have a high bounce rate so it might make more sense on our types of sites).

- SpriteSheets. You can't really over emphasise the importance of these. HTTP requests are expensive when you are firing off multiple requests to the same domain. Depending on the browser you could hit blocking/waiting pretty quickly. It really pays off to merge your images into a sheet. Don't use a premade sprite sheet with 100 icons on it, where you only use 8. Make your own.

- Cookieless Domains. Serve all of your static assets from cookieles domains. This one isn't neccessarily a major win, since the gain you get is reduced based as you optimize more. However, before I started optimizer, a single request would fire 80 HTTP requests just to static assets. The average user on the site would have about 500bytes worth of cookie data. I set myself the target of getting the request down to 400kb for everything. So like 2% (I can't do maths) of that was being taken up just on the users /GET Request. It's not neccessary! Move everything to a CDN. We use CloudFront.

- Browser Blocking. We don't have this issue any more, but we used to load a lot of assets. As a result we would hit "blocking" really quickly. (This is where the browser stops loading assets from the same domain). This number changes depending on the browser you are using, but the normal number is 6. (Some even as low as 2!). The iPhone is the only phone which is also around 6. Most other phone devices are still at 2. This means that requests to the same domain (where you have lots) really sucks. So as a possibility you might want to consider using an asset serving library. The idea of this is that you provide multiple links to the same assets in your application, and round robin through the sources to make sure that you are rotating between hosts where the asset can be found. If you do implement somethign like this you need to make sure that the user is served the same host otherwise they wouldn't benefit from caching. The "hack" way that we implemented it was to use their HEADERS as a "seed key" which created a cache, which we would then perform some type of modulus caclulation on to serve the correct server. It isn't perfect, but it works.

- Headers. Use correct headers.. expires... cache... if you are serving up cacheable content. Say so! Some study I read recently showed that over a period of a month, rechecking the same 1000 sites daily and checking each asset. Of those that never changed, over 50% didn't make correct use of expiry headers! If you do this you are telling your users that you don't care about performance!

- Speed isn't always about waiting for that DOMContentLoaded to fire. It's also about perceived performance and loading. This means that you should always give your images a height and width attribute too.

- Use a reverse proxy cache! The stack that we use is nginx(port 80) -> varnish -> nginx. This is so that we can benefit from server side includes which are cached in varnished, and rebuilt by nginx.

- Eager Loading. I've only just started experimenting with this as a way of improving my knowledge on machine learning. As I mentioned above we have a really load bounce rate, so it might make more sense for us than it does for your site. Basically, I've started using Markov Models to build a probalistic model of the liklihood of a user navigating to another internal page and figuring out based on all other users which page that might be. I then drip feed load the assets from the other page.

Here are a few that were not mentioned:

- If you have a lot of images like in a product catalog, try lazy loading the images - http://www.appelsiini.net/projects/lazyload

- For sprite-ing your images, use some tool which will automatically generate the css for you: http://spritepad.wearekiss.com

- Have a git commit hook for compressing images. (It could be part of your build, but then you are doing the work every time and the build will be slow if you have a lot of images.)

- If you are using LessCSS or something similar (hint: you should), have your compiler compress the css for you. - http://wearekiss.com/simpless

- Have multiple hosts referring to your CDN to facilitate parallel downloads in the browser.

- Compress your HTML too before deploying - http://code.google.com/p/htmlcompressor/

- Have proper versioning in the name of your JS/CSS files and then cache them for ever. Whenever you change your files, the version should change and only that file will be updated in the client. We normally take the hash of the latest git commit on that file:

   cookie-wrapper.js -> cookie-wrapper.bb9303b809210674.js

- Offload whatever you can from your cookies to localStorage or things like that to reduce request size.

Lots of good tips in here already. Yahoo has a great speed guide (http://developer.yahoo.com/performance/rules.html) which I'd suggest reading through, they cover pretty much everything in this blog (and chrisacky's comment above), and go into some more detail.

For testing your site, I recommend WebPageTest (http://webpagetest.org/). Run the test a couple times to get an averaged score, then start tweaking. Watch the HTTP requests. Watch the total download size.

Google also provides a Page Speed tool (https://developers.google.com/pagespeed/) (also built into Chrome) that will point out any mistakes you may be making.

The biggest things to focus on are caching, limiting HTTP requests (combining images into sprite sheets, bundling scripts), and optimizing images. Learn about these.

My favorite tools for optimizing images are PngOut (http://advsys.net/ken/utils.htm) and JpegTran (http://jpegclub.org/jpegtran/). Both are lossless, I generally just run the tools batch through my websites image folder. If you want lossy Jpeg compression (you probably do, just keep the original file safe) then try Jpeg-Optimizer (http://jpeg-optimizer.com/). If working with a large photo on the homepage or something like that, try multiple levels of compression and find the best quality/filesize tradeoff. You can often cut the filesize in half with no noticeable degradation at 100% zoom.

> Make sure you define a width and a height for all images on your webpage. This helps save time since the browser doesn’t have to do the work of calculating the dimensions.

This isn't correct in my opinion (it might be technically but not to a level where anyone would notice it), what it actually does it reserves the space in advance for the image as the rest of the page loads. If you don't do this then what happens is that the content keeps being pushed down which makes it seem like it's loading slower. So this impacts perceived loading time over actual loading time.

About the twitter/facebook buttons. You can just delay until after the window.load event has occurred. It will have no impact on the page load, since the page is fully rendered at that point.

  $(window).load(function() { /* load twitter and Facebook buttons */ });

Regarding gzipping, you don't want your webserver doing this on the fly. At least in nginx, you can tell the webserver to load pre-gzipped files, I'm sure apache has something similar.

Put this into nginx.conf: gzip_static on;

Then run this command in /var/www to gzip your content: find . -name "*' + ext + '" -print | xargs -I filename echo "gzip -c filename > filename.gz" | sh

This is a small win (reduced cpu/disk IO), but at two lines it's an even smaller cost.

Also, if you use django mediagenerator, it will handle a lot of this stuff for you.

http://www.allbuttonspressed.com/projects/django-mediagenera...

Nice overview, for even more tips on performance the best resource is Steve Souders' blog:

http://stevesouders.com/

The most important thing for page loading times is reducing the number of network roundtrips required to view a page. A visitor across the globe will have a latency of around 300ms per request. If you include a javascript that adds a link to a stylesheet, this means you have at least 3 serial requests, and the page loading time is now at least 1 second, no matter how large the bandwidth or how much you compress files.

This is also important on mobile. Mobile broadband is optimized for high throughput, but you often have very high latency. Therefore it's especially important to reduce the number of round trips.

I'm surprised they left out concatenating your javascript files into as few files as you can without breaking caching. The concept is the same as using sprite sheets, with similar gains if you are using many different scripts.

Kind of looks like you're loading jQuery and not using? That's a good chunk of bandwidth and execution time there!

With regards to Twitter/FB, frustratingly in my Webmaster tools it shows our homepage loads slowly, and a huge percentage of this loading time is actually the FB/Twitter buttons.

For users this doesn't impact their perceived loading time much at all so when Google reports it as a slower load time it's an unfair bias in my opinion.

It's important to get it fast as it's a well known fact they use it as a metric in their ranking algorithms. I've tried various ways of delaying it but nothing seems to stop it being counted in page load time tools:

http://stackoverflow.com/questions/9502972/stop-pingdom-coun...

How we trimmed 2 seconds from page load times: remove AdSense.

We did something similar with KeepAlive on http://settleapp.com - we figured that a new user with an empty cache (it's just a holding site, so most users are first-time visitors) would need to load the index and 23 other assets.

We set keepalive to 24 requests over a single http connection - the whole site loads noticeably quicker as a result.

A somewhat silly tip: don't include the Google PlusOne button. Even when it's set to load after every other asset, and load asynchronously, it still takes ages to load. I've sometimes browsed off the page before it finishes loading.

I'm not a web designer, but to me 400kB sounds like a huge amount of data.

ah, I so much wish that my app reaches "optimization" stage.