“Make the site faster” is the most consistently misunderstood request in engineering. Teams reach for a tool, run a report, and then chase whatever numbers light up red. The actual levers that move real-world page speed are fewer and duller than people think.
This is a field guide to the bottlenecks that matter, ranked by how often they are the real cause.
1. Bytes on the wire
The single biggest predictor of a slow site is still how much JavaScript ships to the browser. Framework overhead, third-party scripts, analytics, tag managers, and ad SDKs add up. A page that sends 600 KB of JavaScript will be slow on a mid-range Android phone no matter how cleverly it is rendered.
The fix is unglamorous: send less. Code-split, defer what is not above the fold, and ruthlessly audit third parties. A single chat widget can outweigh your entire application.
“You cannot optimize what you do not measure, but you can always just delete what you do not need.”
2. Images, by a mile
Unoptimized images are the second most common cause of slow pages — and the easiest to fix. The playbook is now standard but worth restating:
- Serve modern formats: AVIF first, WebP as fallback.
- Size images to the display dimensions. A 4000-pixel-wide photo in a 320-pixel card is not “high resolution,” it is waste.
- Lazy-load everything below the fold.
- Use
widthandheightattributes (oraspect-ratio) so the browser reserves space and avoids layout shift.
3. Network round trips
Every request is a negotiation. A page that makes 80 requests over a slow connection will feel slow even if the total bytes are modest. HTTP/2 and HTTP/3 help, but the cure is reducing requests: fewer files, inlined critical CSS, bundled where it pays off.
4. The render path
Even with fast HTML, the browser can be blocked. Render-blocking CSS in the head, synchronous fonts that flash, and JavaScript that runs before the page is interactive all delay the moment the user sees something.
The remedies: preload the one font you actually use, inline critical CSS, and defer scripts with type="module" or the defer attribute.
5. Server response time
A server that takes 1.2 seconds to start sending HTML makes every other optimization worse. This is usually a database query, a cold origin, or a CDN misconfiguration. Static or edge-rendered sites skip this entirely — which is why they feel instant.
The metric that matters
Largest Contentful Paint — roughly, when the biggest visible element appears — is the single number that best predicts whether a user perceives your site as fast. Optimize for it. If your LCP element is a hero image, that image is your priority; if it is a text block, your server response and font loading are.
Speed is not a vibe. It is a short list of specific things, and you are allowed to ignore the rest.
