Make your website fast. (And why you should).

With the way people use browsers these days, load time has become even more important. As I tell my clients and bosses:

"It's never a choice between two seconds and five seconds. It's a choice between two seconds and whenever the hell they come back to this tab, possibly never."

Many people go about web performance the wrong way, though. It usually isn't about algorithms, or hard work of any kind. It's mostly about rigorous preparation (a build process to combine and minify your assets) and outright lying (async loading, etc.).

This is the same stuff I've been hearing for the past 5 years.

I think a few things are changing though. The new Basecamp's speed is mind-blowing. One thing that interested me about their approach was that they claim to use static HTML whenever possible. This allows them to cache a single file and serve it to everyone.

So I may have to disagree with the age-old wisdom: "It’s important to keep your Javascript in external files where possible, since it allows the browser to cache the scripts and not load them on every page load!"

Why? With single-page apps I think we need to separate out "Javascript" into two categories: Actual code and templates. I've been playing around with the 37Signals approach, where I store the site-wide base template inside a script tag right in the body. Then I send a cache header the first time that HTML is requested to ensure it's only loaded once. Then page-specific (route-specific) templates and scripts are asynchronously loaded. So my actual "code" JS is still loaded with src="..." but templates aren't.

On the "Serve your pages compressed" section, one should point out that static files (usually CSS, JS, etc) can be pre-gzipped (and pre-packed) to reduce server load. Serving the right version depending on the Accept-Encoding header is usually easy in most webservers.

I was hooping for something more than what Google's page speed or YSlow can tell you. Is this really "everything" one can do to optimize his site? I'm really hungry for some more advanced (if you will) techniques as I don't know what else to do with our pages (they are fast mind you, I'd just like to make them faster still).

And to add something constructive (besides a question) to the whole thing:

"Aggressive caches are best, with an incrementing querystring parameter at the end of them to force browsers to reload them when you make a change to them."

That is good. But even better is to include the version number in the filename (or path) itself: image.jpg?v=2 -> image_v1.jpg ... this doesn't throw some public proxies off and they cache your content that way. See this page for more details: http://code.google.com/speed/page-speed/docs/caching.html#Le...

edit: I would also like to see some article explaining how EXACTLY is google measuring our page load times. Because everything I've measured myself on our pages is fucking fast, but google seems to disagree (in order of magnitudes different results). The only logical explanation I've come up with is that google is measuring speed of our page from the states and our servers are in Slovenia. And that means that the page is super fast for our Slovenian users (which are the only one that matter since it is a local page) but slow for google who is way over there on the other side of Earth. This really pisses me off to be honest since there is only so much I can do and we are being punished (as in lower rankings due to speed) for not following some rules that we don't know.

Nothing new to see, nothing newsworthy, just the usual bunch of suggestions on how to speed up a website. Sorry to be so negative but this is just random noise and not something I want to see for the hundreds time.

On the topic of using subdomains, I was thinking of using subdomains as a way of cache busting when I release new versions. Rather than the typical build number in the URL folder name. I didn't build my application to have a "version" number variable. but did have a CDN URL. (Foolish mistake). So I'm left with the annoyance, of having to change a lot of code to include this.

Google Page Speed can be used online now - https://developers.google.com/pagespeed/.

Also wrt the article, http://www.scirra.com/blog/74/making-a-fast-website, won't naive bottom loading all your JS lead to them being serialised and thus cost you in page load time?

Also if your JS modifies the DOM tree shouldn't it arrive earlier so as to prevent reflows and such?

See eg http://code.google.com/speed/page-speed/docs/rtt.html#PutSty...

Not bad but very much focused on the optimising the "front-end" of delivery. My experience is generally optimising the back-end, for instance I notice you did no real digging to find out why your old server was slow, was it CPU bound? Memory bound? IO bound? In a lot of cases you can get big performance increases without expensive new hardware, the golden rule here is CACHE EVERYTHING. A good caching plan, a product like memcached and cheap hardware with lots of memory can often well outperform a much more expensive multi-core rig.

My current setup makes me pretty happy in terms of having a speedy blog: Octopress + S3 + Cloudflare.

Octopress will generate static HTML and use Disqus for comments: http://octopress.org/

S3 added the ability to serve an index.html file a while ago: http://www.allthingsdistributed.com/2011/02/website_amazon_s...

Cloudflare will be your DNS host and CDN in one: http://www.cloudflare.com/ (they also have a lot of other fun features)

I tried Amazon's Cloudfront too, but they aren't as great with hosting static files. (especially index.html data in subfolders seem to error out for me).

We also use Octopress to run a german-language podcast (http://blog.binaergewitter.de/). Adding the iTunes feed and flatter support wasn't all thaaat hard. Although I still think the liquid template system is kinda weird. (Our "Octopod" fork is here: https://github.com/Binaergewitter/binaergewitter.github.com/... , not 100% reusable though)

I'm surprised to see there hasn't been any mention of webpagetest.org yet. It's a great (free) service for measuring how fast your site is loading from different locations around the world in most of the major browsers.

The first step in losing weight is stepping on a scale.

this article left out the importance of IO. from our past experiences w/ several projects, implmenting SSD/SAS were the single biggest improvement in performance (as you can notice right away visually), all the other optimizations (minify/yslow/etc...) were just very subtle improvements. CDN is very good at relieving load off your server and comes in pretty important at times of HN/Digg/Slashdot effect. been toying around with cloudflare lately and I think it's a good replacement for your DNS hosting. it gives you CDN out of the box just by pointing your DNS at them.

Ironically the site is down. Anyone have a cache link?

Edit: working now

Tom, I was researching on the web about setting up a different, cookieless domain.

Should I use CNAME alias or direct A entries for those static0 ... static3 hostnames ?

i don't know why sprites are still recommended? they save big on HTTP request, but they have quite a DOM rendering overhead. the best icons, are no icons. you can cut back on icons big time without loosing any usability (as measured by time on site, average page views, ...). the benefit of a faster site by far outweighs the loss of some meaningless icons that are mostly only there to stroke the ego of designers. (but if you still need icons, use unicode)

Been using Edgecast via Speedyrails for a few years now. Top quality CDN.

Fast? No problem. GWT. Done.

That's a solid article for anybody getting started with web development, but it really needs more coverage on the importance of CDNs for static content. Between Amazon, Microsoft, Rackspace, etc. they're cheap and trivially easy to utilize. They're now extremely accessible to less experienced developers and developers on a shoe string budget.

My business has content that users can freely embed on external sites; it's dynamic locally, but served up static (15 minute refreshes) off of Rackspace Cloud Files CDN for the embed. The cost to serve 1 billion widgets on AWS came out to $1,236 due to the transaction costs, but on Rackspace (which has compression with Akamai and no per transaction cost)it got down to $180, which is insanely cheap for serving a billion widgets.