Over the last year or so we've seen an increasing emphasis put on the performance aspect of building responsive websites, which is great - there's no point building a beautiful, scalable, touch-friendly site if it uses up half your monthly bandwidth allowance just to load the homepage.
But performance considerations add yet more complexity to an already complex mix. Very little is clear-cut; many decisions need careful, site-specific consideration in order to avoid actually making things worse, not better. Is it better to lazy-load styles for breakpoints other than the current one? Or should we rather load all the styles in one go? Are our intuitive assumptions about image dimensions, compression and resulting file size really correct?
All these things and more need careful consideration. And to yet further complicate things, there is also a careful balance to be struck between styling, images, slick functionality and site performance. A vanilla HTML page with no styles, JavaScript or images is likely to be fast indeed, but highly unlikely to achieve the aims of the client from a branding, design or user experience perspective. So more often than not decisions around performance are not simply a 'development issue' - they are deeply intertwined with the UX and design sides of the project.
Setting a budget
To help us make objective decisions around these sorts of issues on a recent project, we looked at the idea of having a total page size 'budget'. Now this is certainly nothing revolutionary - and of course page size is only a small part of the performance puzzle - but using the 'size budget' as a touchstone throughout the UX and visual design process (as well as the dev process, of course) proved surprisingly helpful.
Suddenly discussions about what could or could not go in the design felt like conversations, rather than just the developer constantly saying "no!". You want a huge header image at the top of the page? Sure. But that's 100k of your budget used up, so you'll have to lose a weight or two of web font to bring things back under the limit. Or maybe we can claw some of that back by removing the slider, and save on both JS and the extra images?
Deciding on the size of the budget is something that needs to be decided on a per-project basis, and will decide on many factors. Erring on the side of smaller rather than larger is always going to be better, but it's important to be realistic with it too - it is hard to treat pie-in-the-sky numbers seriously because everyone will know that realistically they are never going to be hit.
The important point is to look at every decision, right through the design/build process, as something that has consequence. Having a pre-defined 'budget' is a clear, tangible way to frame decisions about what can and can't be be included, and at a suitably early stage in the project. It can also potentially provide some justification to the client about why certain things have been omitted (or rather, swapped out for something else).
Performance is everyone's problem
In our experience, the most effective way to build high quality responsive sites is to ensure tight collaboration between UX designer, visual designer and developer, to prototype early and go through small, quick iterations as a team to refine individual components and layouts. Using the concept of a size budget and making sure that everyone was involved in hitting that budget - right from the start - ensures that performance isn't just seen as a 'development problem', but instead is rightfully viewed as something that needs to be considered holistically as the site takes shape.
We'll certainly be using this again on future projects to help kickstart the performance thinking early on in the process.