Master browser caching and network congestion management. Learn how to use HTTP/3 and smarter cache headers to stop resource contention and boost speed.
Last month, my team spent three days hunting down a weird performance regression where our Largest Contentful Paint (LCP) was fluctuating by nearly 400ms. We initially thought it was a server-side bottleneck, but after digging into the Chrome DevTools Network tab, it became clear: we were suffering from massive cache contention and internal network congestion.
We were bombarding the browser with too many high-priority requests simultaneously, and our cache headers were actually working against us rather than for us. If you’ve ever felt like your web performance optimization efforts are hitting a ceiling, it’s often because you’re fighting the browser’s internal scheduler, not the network itself.
When we talk about web performance, we often focus on minification or image optimization. But browser caching and network congestion are the silent killers of modern web apps. If your Cache-Control headers are too aggressive on non-critical assets, you force the browser to hold onto stale data that clutters the disk cache. Worse, if you don't manage your HTTP/3 streams correctly, you create a "head-of-line blocking" scenario at the application layer, even though the protocol is designed to solve it.
We initially tried to fix our congestion by just throwing prefetch tags everywhere. That was a mistake. By prefetching everything, we were filling the browser's request queue with low-priority junk, which meant our hero image and critical CSS were waiting in line behind a secondary analytics script. It’s like trying to get an ambulance through traffic where every car is driving the speed limit—nothing moves.
HTTP/3 (QUIC) is a game-changer because it allows multiple streams to exist over a single connection without the performance hit of TCP head-of-line blocking. However, it requires developers to be more intentional. You can’t just dump 50 files into the browser and expect the network stack to magically guess what’s important.
You need to explicitly manage your resource prioritization. If you haven't yet, you should read up on Browser Resource Prioritization: Controlling Network Scheduling to understand how browsers actually pick which request to fire first. When we shifted from generic fetching to using the Fetch Priority API: Optimize Resource Prioritization for Core Web Vitals, we saw our LCP drop by about 180ms almost immediately.
Here is a simplified look at how we categorized our assets to reduce contention:
By marking these explicitly in our HTML, we stopped the browser from wasting bandwidth on low-value items during the initial burst.
Cache contention happens when the browser is busy reading from or writing to the disk cache while the main thread needs to render. If your Cache-Control headers are set to max-age=31536000 for everything, the disk cache becomes a chaotic mess of competing read/write operations.
We moved to a tiered caching strategy:
max-age=31536000, immutableno-cache or max-age=0 (force revalidation)max-age=3600 (short TTL to keep the cache fresh but not constantly writing)This approach cut down our disk I/O wait times, which were previously spiking during page transitions. It turns out, you don't always need to cache everything forever. Sometimes, the cost of checking for a new version is lower than the cost of managing an massive, bloated cache directory.
Another trap we fell into was ignoring the connection setup. If your server doesn't support HTTP/3 or isn't configured for efficient connection reuse, you're paying a penalty on every request. We implemented resource hints to warm up connections, but as I noted in TTFB Optimization: Using Resource Hints for Connection Warming, you have to be careful not to over-provision.
If you open too many preconnects, you're just creating more network congestion at the socket level. We limited our preconnects to only the critical third-party domains—like our CDN and our auth provider—and left the rest for the browser to handle naturally.
I’m still not 100% sure if our current prioritization logic is "optimal" for every device. High-end desktops handle concurrent streams better than low-end mobile devices, and the browser’s internal logic sometimes overrides our fetchpriority hints anyway. It’s a bit of a black box.
Next time, I want to spend more time experimenting with Critical-CH (Client Hints) to see if we can reduce the payload size even further before the request even leaves the client. For now, the combination of explicit priority hints and a stricter cache policy has kept our metrics stable. It’s a constant game of cat and mouse with the browser, but that’s the job, isn't it?
Master TTFB optimization by implementing resource hints like preconnect and dns-prefetch. Learn to warm up connections to slash latency before it happens.
Read moreMaster data hydration using stale-while-revalidate and Server-Sent Events to drastically improve LCP and INP for a snappier, more responsive user experience.