Browser performance: what actually slows a site down
The three usual suspects
Images. A three-megabyte file displayed at 400 pixels is the most common waste on the web. Serve at fitted sizes, in modern formats, with lazy loading for everything below the fold.
Fonts. Four weights across two families add wait and text flicker. Two are almost always enough.
Third-party scripts. Analytics, chat, marketing pixels. Each looks small; together they're usually most of the run time. Count them once a quarter and delete what nobody looks at.
Measure what the user feels
Three things matter to the user: when the main content appeared, how fast the page responded to the first tap, and how much the layout shifted during load. The first two are well known; the third is the number-one cause of a cheap-feeling site.
Measure on a mid-range device and a cellular network, not on your fibre-connected dev machine.
Improvements in descending order of return
Compression and delivery from a network; explicit dimensions for images to prevent shifts; deferring scripts not needed for the first paint; splitting the code so each page loads only what it needs.
Going deeper
Set a performance budget — a maximum page weight and request count — and enforce it in the build. Without a budget, the site gets heavy quietly over months, and every single addition always looks negligible.