When a page feels slow, the instinct is to reach for a faster server or a bigger CDN plan. But raw bandwidth is rarely the bottleneck on modern connections. The real cost is the number of round trips the browser has to make before it can paint anything useful on the screen.
Every separate file your page asks for carries overhead. The browser has to discover it, queue it, open or reuse a connection, and wait for the first byte to arrive. A page that pulls in forty small scripts and a dozen stylesheets spends most of its loading time waiting, not transferring. Shrinking those files helps a little. Asking for fewer of them helps far more.
Where the waiting actually happens
Render-blocking resources are the usual culprits. A stylesheet in the document head pauses rendering until it fully loads. A synchronous script does the same. If those files live on a different domain, the browser also pays for a fresh DNS lookup and TLS handshake before the download even starts.
- Combine small CSS and JavaScript files so the browser fetches one larger asset instead of many tiny ones.
- Defer or load scripts asynchronously when they are not needed for the first paint.
- Inline the small amount of critical CSS that controls what appears above the fold.
- Self-host fonts and key assets to avoid extra connections to third-party domains.
Measure before you optimise
Open your browser’s network panel and sort by time. You will usually find a handful of requests responsible for most of the delay, often analytics tags, chat widgets, or fonts. Those are the items worth questioning. Some can be loaded later. Some can be removed entirely.
The goal is not to chase a perfect score in a testing tool. It is to get meaningful content in front of a visitor as quickly as possible. Most of the time, that means doing less work earlier, not buying more speed later. A lean request list is the cheapest performance upgrade available to almost any site.