Developers are acutely aware of the importance of website performance and optimising websites by minifying code, creating CSS image sprites and various other techniques has become best practice. However for those designing websites, but not coding them, website performance is something of an abstract concept.
While I'm not an advocate of designers needing to know how to code websites, they should appreciate the technical complexities involved. Perhaps the most important of these is the way in which design influences website performance, which in turn impacts on its success.
Why care about performance
Several years ago, before wide spread adoption of broadband, users would tolerate slow websites to a certain degree, however faster connections and servers have significantly lowered the amount of time that users are prepared to wait. They now expect instant gratification and won't tolerate websites that are slow and unresponsive. This expectation has become so important that developers now talk in micro-seconds.
While this may seem somewhat extreme and anal retentive the statistics below from an article by Jeff Atwood are very insightful.
[Google found that] the page with 10 results took 0.4 seconds to generate. The page with 30 results took 0.9 seconds. Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.
In A/B tests, [Amazon] tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.
It's not only users though who dislike slow websites - in April of 2010 Google started to factor page loading times into its search algorithms. Therefore slow loading times now not only impact user experience, but SERP as well.
Website performance and page loading times are therefore a component of website design and development that cannot be ignored, as it is a core ingredient to creating successful websites and has now become more important than ever.
Developers can only do so much
Despite the importance of website performance it still seems that far too many regard it as an afterthought. From personal experience when website performance is discussed it's usually in response to a desire to improve SEO for an existing site or to boost conversion rates.
Using tools like YSlow the developers will analyse what's happening and attempt to optimise components if it hasn't already been done. They'll minify scripts and CSS, smush images, create image sprites and make sure assets and pages can be cached.
All of this is certainly in line with best practise and it should be done for every website, but all too often the elephant in the room is something related to design. It could be the massive gallery on the home page, excessive fonts files or massive background images. While these issues can be addressed in development it becomes obvious that they really should of been considered much earlier...
Website performance starts with design
The reality is that website optimisation and speed needs to be considered much earlier in the creative process. It needs to be considered as a feature from the very start when the initial wire-frames and mock-ups are being designed and certainly before the client sees anything.
Web designers need to consider layouts more carefully and question design decisions with website performance in mind. Do I really need to give the client the ability to insert ten rotating banners into the homepage? Do I need to really use another typeface in the footer? Do I really need the kitchen sink?
Given the emphasis that we as designers place on the relationship between form and function, thinking about website performance is a necessary part of what we do. As a collective we need to expand our understanding of what constitutes bad design. We all consider ugly nineties-looking websites to be examples of poor design, but how about websites that are slow and unresponsive?
Designing for performance
For many website performance is something of an abstract concept, especially when creating wire-frames or high fidelity mock-ups. When viewed in this context it can be impossible to try and form an accurate judgement about how quickly a page will load. However this doesn't mean that we can't employ methodologies that allow website performance to be factored in at this early stage.
The trick to designing high performance websites is to reduce components and design decisions to overheads - overheads that have a cost. For instance, choosing to use a different font in the website's footer implies that another component has to be loaded, meaning that it adds to the weight of the page. While you may not know the exact cost of this component, acknowledging that it does have a cost may make you reconsider its inclusion. Is this design decision really beneficial? Will it help my client achieve their goals?
Therefore designing for performance involves weighing the cost of components against the benefits they may provide. For instance a gallery containing nothing, but eye-candy may not warrant inclusion under these conditions, because the script for the gallery constitutes a unit of overhead in addition to each of the images contained within. However if this gallery may help convey an important message or increase user conversions in some way this overhead may be justified.
Another critical component of this approach is attempting to negate overhead. For instance a full-screen background image may not meet the conditions for inclusion, but as it offers no SEO benefit either it may be possible to dynamically load it after everything else, thereby minimising its effect on page loading time. For non-coders this requires seeking advice from developers earlier during the design process, as they will be able to offer advice that can be beneficial.
Desegerate design and development
As a coder and designer I often enjoy the benefits of rapid prototyping. I can identify issues concerning website performance and usability at an earlier point. It's not often that I have to backtrack to address an issue when working this way.
However my experience of larger teams is that specialisation by individuals leads to the segregation of design and development. Specialisation is by no means a bad thing and is certainly required within larger teams, but it does create an environment where designs are thrown over a proverbial wall to developers.
This negatively impacts things such as website performance, but desegregating design and development can minimise this. To create snappy and fast sites developers must be involved in the design process and given the ability to veto features and advise how the overhead associated with a feature can be minimised. Ultimately this improves design as things such as website performance are fundamentally intertwined with a projects success or failure.
Due to the way in which performance is fundamentally intertwined with a website's success, it's a core component of good design and best practise. Considering it during the design process should therefore be a requirement for any professional designing for the web and while performance can be a somewhat abstract concept, considering individual components as units of overhead can be helpful in creating balanced designs.
By balanced I mean design that weighs aesthetics against technical complexities, such as website performance, that are tied to the way in which a website performs. The inclusion of developers, who can provide a more technical perspective, during the design process is not only helpful, but extremely beneficial.
By addressing website optimisation in this way and other such technical complexities during the design process it’s possible to create work that is not only aesthetically pleasing, but satisfies or exceeds the expectations of our clients and allows them to attain their business goals.
Comments will be enabled soon. In the mean time let me know what you think via Twitter