Web performance is vital, but lately I’ve felt that the topic has only been brought up by front-end developers, and only becomes a point of discussion at the end of a project. Subsequently, whenever I hear about solutions to trim down large websites, I can’t help but feel that these are merely suggestions or tricks that developers and engineers should employ after the initial design process has kicked off.
So what sort of design topics impact performance? Well, any question that a designer might ask themselves. Like these:
- How many fonts should we use?
- What sort of imagery should we apply?
- What kind of analytics scripts do we need?
- How does a user scroll through our app?
- How does this complex component affect our CSS?
- How should we even write CSS?
- What kind of frameworks should we choose?
More often than not, these questions will lead to more code, more complexity and more bloat in a design system since…
- The more fonts we add the longer we ask our users to wait.
- The type of imagery we choose for a project will impact what image formats we use.
- If we pick a crazy number of analytics tools then that can slow the whole app down, too.
- Adding a complex component in CSS, that will only be used once in the app, will lead to code bloat and it’ll further slow down the time to first render (if only marginally).
- Deciding which framework we use will have an enormous impact on the critical path.
In short, design teams should measure their success against key web performance metrics because every decision they make will eventually lead to drastic changes in what gets sent down the pipe to the end user.
And the way I’ve started to think about it is like this: every conversation about design is also a conversation about web performance. I try to remind myself that the two are inseparable from the other and so as a web designer I ought to be considerate of these problems from the very beginning of a project, not just at the end.