Performance testing

The three metrics Google publishes and measures in the field: largest contentful paint, interaction to next paint, cumulative layout shift. Defined precisely enough to be a test assertion rather than an opinion.

Audits from the browser you already have, scriptable so a regression fails a build rather than being noticed six weeks later. Read the section on lab versus field data before treating the score as truth.

How to read a flame chart, which is the skill that turns “the page is slow” into “this function runs 400 times on scroll”. The single most transferable front-end debugging skill there is.

Load tests written as JavaScript, run from a Go binary, with thresholds that make a run pass or fail. The documentation's explanation of test types — smoke, load, stress, soak, spike — is a good short education in the subject on its own.

The long-standing Java option, with a GUI for building plans and a very large body of existing knowledge. Still the default in a lot of enterprises, and worth recognising even if you would start elsewhere.

Load testing in Scala, Java or Kotlin, with a simulation DSL and detailed HTML reports. The natural choice where the load tests should live in the same repository, and be reviewed in the same pull request, as the service they point at.

Gil Tene's talk, and the source of “coordinated omission” — the measurement error that makes almost every load test report a latency figure better than reality. If you are going to publish a percentile, watch this first.

The orders of magnitude: cache, memory, disk, network, datacentre round trip. Calibrates your sense of whether a number is surprising before you spend a week optimising something that was never the problem.