On Visions for Performance, or: Performance Optimization Is a Process

Published on December 4, 2018 (↻ October 1, 2022), filed under Development (RSS feed for all categories).

Particularly in the context of performance budgets, it’s smart to develop a performance vision: What goals does one wish to achieve for the performance of a site or app? Yet assuming performance visions to be meant to be achievable, some of the soundest approaches have their own particular problems, and in them we recognize that performance, or performance optimization, is indeed a process.

Let’s start with those sound approaches, borrowing from Safwan Samla at this year’s GDE Summit. These entail the following main ideas:

• improve yourself; or
• be better than the competition; or
• be the best.

These main ideas are useful because it’s not possible to give specific criteria and visions that are applicable to every project, and so the ideas factor in that “it depends,” and that goals have to be related to the project in question. And still, there’s something problematic to be found with each approach:

• Improving oneself has a hard limit on how much one can improve. This is a bit theoretical, but the basic idea is this: Once we maxed out all the performance-related knowledge we have, we can obviously not improve any further. (I get back to this in a second.)

• Being better than the competition is ultimately a poor goal, especially if the competition is all worse than oneself; and if the competition is not worse but simply average, with this approach one would well end up average, too. In most cases, we’ll at some point need to switch to a different vision—which evidently undermines the approach.

• Being the best is a super-competitive stretch goal, and some may like it for whatever fuels them. Yet “best” is so tricky to define that one could not be best without also defining a tech-philosophical model that justifies respective claim and all underlying decisions—if it’s a basic website one could attack any claim of “best” performance on grounds that it’s too basic, and a complex site or app could likewise legitimately be attacked by questioning the mere existence of any element and pattern used (as its existence makes everything slower).

  Just imagine example.com and amazon.com were optimized to the absolute known performance maximum, more than any other site of the planet, and you could dismiss example.com’s optimization as naive and amazon.com’s optimization as premature. And then we could still add, what’s “best” anyway?

Most promising, therefore, seems to be to focus on oneself and one’s project for optimization. That, as I suggested, would depend on what oneself knows, and whether and how oneself learns—because, a difficulty with my counter-argument, we would probably not stand still and one day know that we reached our limit and we couldn’t improve performance any further. Just stopping here and dismissing the concerns I outlined seems too simple, however, because there’s only one tiny amendment we’d need to make explicit to save the approach: to set a new goal once we reached whatever we aimed for on the basis of improving ourselves and our projects.

This may appear obvious—but it’s not: It cannot (or probably shouldn’t) be taken for granted that everyone knows what happens once a vision has been accomplished—it needs to be called out. It needs to be made clear that any performance goal that got reached is to be followed by a new performance goal.

That, then, leads us to the idea of this post: If our performance visions can only be iterations, then performance optimization itself is, just like web design, a process.

We’ve all known this all along—when would we ever be “done” optimizing for performance?—, but I’ve liked this one angle at performance optimization. Please poke holes into my reasoning.

Figure: Performance visions. (Copyright King Features Syndicate, Inc., distr. Bulls.)

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)