My ever-growing notes on Front-End performance

Performance in front-end is an endless topic

How to think about Front-End performance

Front-end Performance as a concept is too broad

• What it can mean for technical people
  • Performance in back-end is probably a more straight-forward concept, it's easier to match a metric to money
  • How fast code runs:
    • this is more obvious for code that runs only in one place, benchmarking in front isn't that obvious
  • How much code is ran: this is a more common metric for front end
• What it can mean for non-technical people: it must be something that is
  • UX => an app is too clunky: non-technical people (sales, Customer support, Product) are the relevant judge for that
  • Customer satisfaction => an app crashes
  • Server costs => the load on the server is too big
  • SEO => a regression in payload size has degraded SEO

A Method

• Syllogism: it's important to translate the problem in technical terms whithout assuming the origin of the issue (unless it's really obvious)
  • For instance if we get the feedback that an app crashes for some customers, we need to find out if it's a complete bug or a performance issue
• Monitor
  • Observability
  • Use existing tools if possible
  • Otherwise, use tools that are more likely to be used
• Metrics
  • Ideally, metrics should measure the problem that we qualified in the first step, not the origin of the issue
    • How to measure something that is subjective ? (clunkiness ?)
  • Web Core vitals
  • Other common metrics

The key is to have good knowledge about front end browsers

"When the complex problems need to be solved, when the inexplicable happens, the person who understands the foundation leads the way." Steve Souders, Head Performance Engineer, Google,

The knowledge

END