Speed by design, not by optimisation

A little while ago, we spoke to a significant percentage of everyone who’d used ONEIS. Unexpectedly, over 80% commented on how fast ONEIS is when asked if they had any general comments on the service.

I consider this a shocking reflection of the current state of web development, rather than anything special about our service. There are very few speedy web sites out there, and it’s becoming an issue. Google have recently launched a drive for speed and Yahoo have some well known tools and guides.

Speed is most frustrating on a mobile device. If you’re browsing any of the many news sites which offer links to content over the web, reading an article downloads 100K or more, just to render a couple of K of text. This is very frustrating — almost enough to make me knock up a proxy which strips out the rubbish and just sends the text with readable mobile formatting, sort of Readability on the go.

The Yahoo guidelines are pretty good, but more aimed at large content sites such as Yahoo. If you’re developing a web application, then things are slightly different.

So here’s how I developed ONEIS with speed in mind:

Don’t send much data

When I started web development, a 14.4k modem was the height of luxury, offering a snappy download speed of a 1.5K/s. This forced you to be very frugal with your HTML. I’ve stuck with the habit, and when your pages are only a few K in size your site is naturally very fast.

In particular, my deployment process strips out as much as possible from the HTML templates, and rewrites all the CSS ids and classes to be one or two characters long. While the HTML it outputs is not particularly readable, it’s very small. The same applies to the Javascript and CSS files, which are run through various minification tools.

Take advantage of everything HTTP offers

Yahoo’s Best Practices for Speeding Up Your Web Site is a very good list of what you should consider doing, although mainly aimed at large content sites where a typical user might make only a few requests. Web application users tend to use the application regularly and make many requests, so there are a few things you may not want to do:

• Use a Content Delivery Network: I’m not convinced the hassle and expense is worth it for a web app. If you’ve done it right, you’re only going to load some small static scripts and stylesheets once, then everything else is just requests for new dynamic content.
• Flush the Buffer Early: If your HTML isn’t the sort of inflated rubbish you see on a typical “portal”, then you want to assemble it all, gzip it, and send it in one big chunk which will probably fit in a single TCP/IP packet.

Some of the suggestions at the end, such as “Pack Components into a Multipart Document” may be more effort than they’re worth.

The most important recommendation though, is the first, Minimize HTTP Requests. Making things fast is not just about the size of the responses — you also need to minimise the number of requests you make by design. This generally requires a bit of thought and avoiding taking the easy way out. In the context of a web app, it’s thinking about how AJAX is to be used, the flow around the site, and so on.

The second most important recommendation is setting expiry times on static resources. In ONEIS, the expiry time is about 8 years in the future, so in an ideal world they’ll be downloaded once and cached forever more. According to the logs, this works well with only minimal re-downloading by web browsers.

However, you’ve got to use new pathnames whenever the resource is updated. The deployment process for ONEIS puts the version number in the path for every static resource, so when an upgrade takes place the new versions have different paths. It’s slightly complicated because we enable our customers to choose their own colours, requiring per-customer CSS and images. For these files, we have a per-customer serial number in the path, and increment it when the colours are changed or the application is upgraded.

Design for performance

Reducing the amount of data you send and using HTTP effectively are all very well and good, but mean nothing if it takes your server too long to generate the response. So, you need to spend hours and hours optimising everything!

Not quite. I haven’t done any optimisation work on ONEIS yet, and yet we received glowing praise on how fast it is.

The great Donald Knuth famously said “premature optimization is the root of all evil”, which has been used ever since to justify bashing out code and worrying about performance later.

What he actually said was “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” ¹ This has a completely different meaning: don’t bother optimising the things which don’t take very long and aren’t used much.

In fact, I’d suggest that you should think about performance at the very beginning of the design process. Whenever I’ve been designing the next bit of ONEIS, I’ve thought about the amount of

• computation which has to be performed
• disc I/O needed (especially when it has to be synchronous to guarantee that the data is safe before telling the user)
• HTTP requests needed (AJAX and application workflow)
• data transferred
• “uncachable” data and computations

with the aim of minimising everything. This seems to have paid off pretty well, and hopefully I’ll avoid having to massively rewrite anything as the service scales.

Have great hosting

The standard advice for a startup with regard to hosting is to get someone else to do it, and just rent a virtual server from someone like Amazon. We’ve ignored this advice.

Firstly, we’re very aware that we’re handling quite sensitive data. We need to know that it’s being looked after properly, and exactly where it’s stored so we can guarantee that we’re complying with the relevant data protection legislation.

Secondly, since I’ve been doing my own hosting for many years, I just happened to have a suitable hosting platform available, with a great internet connection with our own address space and connections to several Tier 1 backbone ISPs.

While I have to buy and install the servers myself, it does let me use exactly the servers I need. I don’t have to contend with the virtualisation overhead of a virtual server or compete with other customers for disc I/O. This complete control avoids the compromise that you’d find in any other way of doing things.

Have a plan for scaling, but don’t worry too much about it

With ONEIS, I’m very lucky that scaling will be easy. Since every customer has their own “silo” of information which doesn’t interact with any other customer, scaling is easy. Just add servers to scale.

Most B2B services are likely to be similar. It’s social-network style consumer applications which have scaling problems as they grow, where the more data they have the harder it becomes to scale. If everyone using the service can potentially interact with anyone else, it’s difficult to split the service into independent instances of the application.

In either case, but for different reasons, there’s no point in thinking too much about scaling.

In the B2B silo model, as long as it’s designed for performance and you can get enough customers on a server, scaling is trivial.

In the consumer application, you don’t really know how it’s going to work at scale, so any guess now is likely to be incorrect. Besides, if you’ve got the business model right, when you get the problem you’ll have the resources to resolve it.

¹ Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.