Performance is not a polish pass you schedule for a quiet week after launch. It is a product feature, and when it is missing the bill arrives on four separate invoices.
| Consequence | What actually happens |
|---|---|
| Revenue | Conversions fall and bounces rise with every extra second. Google's own research put the probability of a bounce 32 percent higher when load time grows from one second to three. |
| Ranking | Google folds speed signals from real Chrome users into search ranking, so a slow page competes with a handicap before a word of its content is weighed. |
| Accessibility | A heavy page quietly excludes people on cheap phones, old hardware, and metered connections. For a large share of the web's users, a 4 MB page is not slow, it is unusable. |
| Cost | Every byte is bandwidth and every render is CPU. Heavy pages cost more to serve at exactly the moment they earn less. |
Most teams respond by optimising on instinct: someone read that WebP is faster, someone else minifies a file, and a month later nobody can say what any of it changed. Random optimisation hits diminishing returns almost immediately, because one bottleneck usually dominates the whole experience and everything else is noise until it falls.
This course runs on one working method instead. Capture a baseline measurement before you touch anything. Find the single biggest bottleneck. Fix only that. Measure again, and let the numbers say whether it worked.
A fix without a baseline is a story, not a result. The before and after pair is what proves the win, catches the regression, and earns you the time to do the next one.