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.
Best resource ever! They just starter second season! Good one Chris!
Making about performance from the beginning is good. However, with any project there are trade offs. The single most important factor to consider in my opinion is launching. Next is making sure it is maintainable. I find if you think about performance too much at the beginning you start performing premature optimization, which bogs down the project and can become a direct opponent to the single most important factor…launching.
Well said Robin — I couldn’t agree more. As Brad Frost stated: “The road towards better performance doesn’t start with developers or technology stacks. It begins with a shared interest on everyone’s part in making a product that’s lightning fast.” Link
Such a great post! Thanks for the link, Jon.
What kind of question(s) do you have to ask for a designer to consider that (lets say) a complex 20 MB parallax scrolling design may not be the best solution for their client? How do you assess trade-offs of this kind?
Fine, let’s try to improve the article.
Here are some questions I feel could improve the article:
And here are my problems with the article as it stands – line by line.
Where do you work? Possible performance concerns are almost always brought up before any work ever begins and unknown unknowns get discovered and fixed later. Unknown unknowns become “known” only with more experience. The more experienced team you have the fewer unknown unknowns you’ll run into.
I have a feeling we were never actually talking about graphic design…
Rather, which fonts you use are far more important. Using Google Fonts? From personal testing there is a negligible difference in initial load times between 3 fonts and 10 weights and 2 fonts with 4 weights. If your design is using over 2 fonts and 5 weights it may be worth having a discussion with your designer.
Maybe it is my own ignorance – but can you name me more than 3 types of analytics that aren’t completely redundant?
Is this web performance or app performance? Are we talking websites (first line: “…trim down large websites….”) or apps now? Wep-apps maybe? Is this trying to make a decision for the user or is it using analytic tools like hotjar to see how users actually interact with the web-app? (I’m assuming we’re talking about a web app now.)
CSS optimizations should be the last of your concerns unless you have as much traffic as Google or Facebook.
“Well”? This isn’t exactly an optimization question – this is a question about tooling. Unless we switched from web performance to developer performance.
Also a tooling problem.
We went from web design to app design to system design and tooling.
The size of the fonts matters more than the number of HTTP requests.
Aha! Finally a purely design-related optimization concern: “Should this image be a jpg or a png? Hell it may even be able to be an SVG instead.” fortunately it is a very easy question to answer and it can be easily measured.
See my earlier comment. Also why is design picking the analytics tools? The analytics selected will largely depend on what needs to be tracked for the marketing team. If it is more web-app-like then you might try and track users for error debugging purposes.
Yes! This was not touched upon at all by the rest of the article. Maybe how a discussion about reworking the component or simplifying it? You should touch more on this subject.
This is literally three buzzwords strung together in a sentence. Could you define “critical path”? How I typically see it used has most everything to do with “everything above the fold” and any front-end framework you end up using has very little with how the first bytes of your site are going to be delivered.
What are those “key web performance metrics” that were never mentioned at all in this entire article? You’re attempting to summarize something that isn’t even there.
Anything that touches code will be a concern about the optimization and performance of said code at some point.
Someone woke up on the wrong side of the bed.
About web performance, if you resize this page it lags (Safari on a early 2015 Macbook Pro 13″ 10.11.6)