PERFORMANCE ENGINEERING.

//Why performance work goes wrong#

A team knows the site is slow, so someone spends a sprint code-splitting, and the numbers barely move — because the actual problem was a render-blocking font request and a layout-thrashing sticky header. Lab tools on a fast laptop won't show you that. Real-user data will, and it also tells you which pages and which devices matter enough to justify the work at all.

//How I approach it#

First a week of measurement: field data segmented by device class and connection, a profile of the worst-performing real template rather than the homepage, and a check on long tasks and forced synchronous layout. That usually produces a list of five to eight causes ordered by how much of the delay each explains.

Then the fixes, largest first. Often two or three changes account for most of the improvement and the rest is genuinely not worth the effort — which is a finding worth paying for on its own. I've told clients to stop after nine days because the remaining items wouldn't be noticeable to a single user.

//What you get#

The fixes, implemented and verified against field data rather than a lab score. A written performance budget tied to specific numbers on specific devices. And a continuous integration check that fails a build when the budget is exceeded, because otherwise the regression arrives within two months. That last part matters more than any individual fix.

Performance work usually reaches into the rest of the stack: the frame budget on animated pages, the font strategy covered in web typography, and the delivery layer described under Next.js.