Fast is a design decision, not an engineering one

Performance work usually arrives at the end of a project, framed as an engineering problem. The build is finished, the scores are disappointing, and someone is asked to make it faster. By then the expensive decisions have already been made, and what is left is compression.

Where the weight comes from

A slow page is rarely slow because of the code. It is slow because it was designed to hold four full-bleed images above the fold, a video that plays on load, three typefaces at six weights, and an animation that cannot start until everything else has arrived. Each of those was a design choice, approved in a review, long before anyone opened an editor.

The same page designed with one hero image, two weights of a single family, and motion that degrades gracefully is not a compromise. It is the same page with its budget spent deliberately.

A constraint, not a score

Performance improves when it is treated as a constraint in the design phase rather than a metric in the launch phase. Decide the image budget before the layout. Decide which fonts ship before the type is chosen. Decide what has to be visible before anything is allowed to move.

These are unglamorous conversations to have in week one, and they are the reason some sites feel instant while visually similar ones do not.

What people actually feel

Nobody experiences a score. They experience the gap between tapping and seeing, whether the layout jumps while they are reading, and whether the thing they came for arrives before their patience runs out. Optimise for that and the numbers follow. Optimise for the numbers and you can pass every audit while still feeling slow.