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.).
You're right imo, if the site is well designed most techniques for a good fast website really don't require much maintenance at all. If they are badly designed however they can be a headache. Some of them are just bog standard good practises though (like image dimensions).
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.
We have been using handlebar.js templates that are pre-compiled into js objects in a single file. So you get the same benefits of browser caching for your views.
I think the improvements 37 Signals has delivered on speed have a lot more to do with recent database optimization and hardware upgrades than anything to do with static js file serving.
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.
Didn't know that thanks. As far as I can tell though with static resources IIS caches the gzipped versions so I don't think it would make much impact at all.
It makes a useful difference in performance for a website I run.
However, the single biggest speedup I ever got (on Wordpress) was in pushing MySQL onto a separate machine from the web server. Nothing else has come close in my experience.
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.
In response to your edits I agree, it would be nice if we knew more. Our website performance chart is under-representing our site in my opinion and there doesn't seem to be much we can do about it.
I also think they are possibly counting Tweet button/g+1/Facebook frames in the time which is wrong in my opinion as these are such small fragments on a webpage yet are often responsible for a large percentage of the load time (for us it is up to 50%!)
Also I think that if you have video (at least flash, since that's what we have) or games, that then google times the amount of time it takes for the complete video/game to load. Which is complete madness considering that the video/game is playable long before it's fully loaded. But I can't say that it really does that since I have no way of knowing :/ But I do think that you are correct on the widgets part.
If you've got a few games or games on different sites then it seems this would be an easy thing to do A/B testing on. You could provide (what amounts to a splash screen) a small flash file that loads a second flash file when you click "play" or "help" or whatever. Does this for one set of sites and compare how they do in the SERPs and for retention, etc..
If you're looking for newer stuff going on in the performance world, check out some of the optimizations we are working on at Torbit using html 5 localStorage, WebP and async loading of CSS:
I beleive you can do more, for example if you start looking:
- DNS (I don't know too much about this though)
- How the web server handles the requests (I saw a post here on HN about this recently but can't find it where MS/Google change some deep settings to improve loading time)
- Preloading pages by guessing users next page choice
All are quite difficult to execute however and provide diminishing returns over making sure you have all the fundamental things set up correctly.
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...
Just a note - if you are using django, use django-mediagenerator. With a little bit of configuration, you can take care of quite a few of the easy wins - it will combine jslib1.js, jslib2.js, jslib3.js into jslib-<hash>.js and minify it (if you ever modify jslib2.js, the hash will change, of course).
Hitting only these easy wins shaved about 250ms off my page load time.
As a programmer, Allen was famous for often going straight to machine code to get maximum performance. Long after Microsoft moved to mostly using higher level languages for development, Allen continued to write tons of machine code. It was a lost art 20 years ago, that much more so now in the days of throw-away computing power.
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.
It sounds like you already know everything there is. How great it must be to have enlightenment such as your own.
This was a very well structured and thought out article. It is actually identical to an article I have been wanting to write for a while. Few things I might have added as an addition, being that while the spec notes 2 open connections per host, most browser these days allow considerably more.
> Chrome allows 6 connections per hostname
> FF allows 6 connections per hostname
Even the iPhone allows 4 connections per hostname.
Good job on the article. Exactly as you say, even if one person doesn't find it useful, doesn't mean other people share the same sentiments!
I'm not sure if you are being sarcastic, or serious, but it's pretty common practice to "hack" around particular provisions noted in lots of different specs in order to provide a faster browsing speed (perceived or actual for the user).
Just a few lines later the spec specifically says that:
> "This change applies to the initial window of the connection in the
> first round trip time (RTT) of data transmission following the TCP three-way handshake."
Well, guess what, lots of large companies ignore this, and they start with a much larger initial window. They do this in order to shave off as many round trips as possible, to reduce your load time. (Google AMZ Apple etc)
Pro-tip: Scan the article quickly, if there's nothing new in it for you, close it and move on, don't waste time lamenting the fact in a comment. That's how to win at Internets. ;)
That's fine, you might not want to see it though but other people seem to want to.
Suggestions on how to speed up your website is only about half the content, I thought it was worth posting because it also looked at why you should do it in more detail as well.
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.
The problem with that is that it would have the potential of preventing these CSS/JS from ever being cached, since proxy servers will commonly/often/always refuse to cache pages with a query string?
I think I am just going to bite the bullet and go through everything I have ever written and wrap it in some "CDN"izer, method to easily include version number.
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.
The reason for that is that Performance Golden rule which states that 80-90% of the end-user response time is spent on the frontend. This rule turns out to be surprisingly accurate across the internet.
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).
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.
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)
Care to provide numbers how "big" that DOM rendering overhead is?
Saving HTTP request is very important ant very noticeable, especially on mobile (high latency).
DOM overhead with sprites is negligible in comparison.
yeah, i agree totally, but even better are no icons at all.
i don't have exact figures by hand, but one sites (which used sprits very very heavily) we managed to save about 250ms in DOM rendering - on some slow, crappy, ugly plattforms (not talking about IE6 here, but IE7 and 8 aren't much better in that regard).
i recommend using chrome speed tracer extensively for DOM rendering optimization. what is just a little bit slow in chrome is unbelievable slow on IE.
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.
I agree with you on CDN's, I was in two minds which direction to take with the article as my original title was going to be along the lines of "... without spending any more money". I think using your own subdomains over a CDN is often more beneficial to startups as they save money, although it will cost a little at first in time.
Also admittedly I've very little experience with commercial CDN solutions (but this will change soon I think) so didn't feel confident enough to write about it.
Amazon's CloudFront uses (as you might expect) utility pricing. It's pretty cheap to try out.
It's also dead easy to set up -- you used to have to use S3 for the backend, but now you can have it refer to any server. So you could make cdn.example.com simply pull content from www.example.com and then just replace "www" with "cdn" in your img src's and you're done.
I'd recommend you give Rackspace a try. You can sign up for their CDN for free; they hit you for the storage and bandwidth used, but not per transaction. It's worth just experimenting with in a very simple manner to get familiar with (small text files, css files, and so on). Rackspace has a very convenient web based control panel for moving a smaller number of files into their CDN (and of course APIs).
Amazon's Cloudfront is excellent from the standpoint that you don't need to programatically upload any files into it, Amazon can absorb them to their CDN and then serve the files up thereafter (you just create a dns entry for Cloudfront, like cdn.mysite.com and use the same url structure you would on mysite.com). With Rackspace you have to get the files into their cloud, which can be inconvenient if you're talking huge numbers of individual files.
For less than $5 you can absolutely learn everything a developer would need to know about both of those offerings through experimenting with them.
We didn't go with Rackspace/Akamai specifically because they don't have a custom origin pull - pushing your assets somewhere else is at the very least a pain, and if you have images or video that is dynamically sized based on the URL it's pretty much a nonstarter.
We looked at Cloudfront but they don't have an Australian distribution point. In the end we went with EdgeCast (via GoGrid).
Originally we were with Voxel, but they've had a couple network issues in the past month (result of DDoS attacks I think).
They are cheaper through resellers like GoGrid. I believe it is competitive with Cloudfront.
As far as speed, they were among the best as far as we were able to test. There are lots of variables involved though that make it kind of hard to compare - how long things stay in the cache at the edge vs. your traffic patterns, etc.
Yep, it can be a big annoyance to say the least. I'm using Rackspace in this case because I only need to constantly export the same 5,000 to 10,000 data files. My individual embed file sizes are in the low KBs, so AWS was going to murder me on the per transaction costs (low file size, high volume).
I have started to use CloudFlare on all my sites. It took my sluggish Drupal personal site from a 4.5 second load time down to a paltry 1.6 - 2 second load time.
It's also free - and besides making your site faster, also blocks a lot of the spam you would normally see.
"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.).