A few months ago someone sent me their landing page asking why it felt sluggish, even though there was “basically nothing on it.” One hero section, one headline, one button. I opened the network tab and found a 4.8MB PNG being used as a full-bleed background image, sized for a 4K display and served to everyone regardless of their screen. That one file was most of the page weight and almost all of the load time. This happens constantly, and it’s worth understanding why a background image, of all things, ends up being the thing that tanks your Core Web Vitals.
Why background images hurt more than people expect
A hero background usually sits directly behind your headline, which means it’s almost always the largest visible element on the page when it first loads. That makes it a strong candidate for what Google calls the Largest Contentful Paint metric, or it directly delays the LCP element by competing for bandwidth while it downloads. Unlike an <img> tag, a CSS background-imageisn’t discovered by the browser’s preload scanner as early, so it can end up loading later than a same-sized foreground image would, which is the opposite of what you want for something that fills the whole viewport.
The four fixes that actually matter
1. Stop sizing images for the biggest possible screen
A background exported at 4K resolution isn’t “extra safe,” it’s wasted weight for the roughly 90% of visitors who aren’t on an ultrawide monitor. I export at the resolution I actually need for a typical desktop viewport, then use CSS image-set() or a couple of media-query breakpoints to serve a smaller version to mobile. Mobile screens are physically smaller and usually on a worse connection, so serving them a desktop-sized background is the least efficient thing you can do twice over.
2. Compress it properly, not just “export and ship”
Most export tools, including plenty of design software, leave a surprising amount of savings on the table by default. Running the same PNG through Squoosh with a slightly more aggressive setting routinely drops file size by a third or more with no visible difference, especially for flat-color images like patterns and illustrations, which compress far better than photos to begin with. If your background is a photo, converting to WebP or AVIF instead of PNG or JPEG usually gets you another meaningful cut. For a flat-color pattern, PNG is already close to optimal, so the win comes mostly from compression settings rather than format.
3. Preload it if it’s above the fold
If your hero background is the first thing visitors see, tell the browser about it early instead of letting it get discovered late. A <link rel="preload">tag pointing at the image, placed in the document head, moves the download earlier in the request waterfall. This one change, on its own, has fixed LCP timing issues for me more often than image compression has, because the problem usually isn’t that the file is too big, it’s that the browser didn’t start fetching it soon enough.
4. Don’t animate or blur a full-viewport background carelessly
A slow pan, a subtle parallax effect, or a blurred gradient overlay looks nice, but if it’s implemented with a large, blurred image or a CSS filter: blur()applied to a big element, you’re asking the browser to do real rendering work on every frame, on the one part of the page most likely to be visible during the slowest, busiest moment of the page load. If you want a moving or blurred background, keep the underlying image small and let CSS handle the blur and scale, rather than shipping a pre-blurred multi-megabyte file.
What this looks like for a generated pattern specifically
Procedural patterns like triangle backgrounds have one advantage here that photos don’t: since they’re made of flat shapes, you have a real choice between PNG and SVG, and picking correctly can matter more than any compression setting. I wrote a separate, more detailed breakdown of when SVG actually beats PNG for a background if you want the specifics, but the short version for performance purposes is: a sparse pattern (bigger triangles, fewer of them) as SVG is often just a few kilobytes, smaller than almost any compressed photo could ever be. That’s the cheapest possible LCP element you can put behind a headline, and it’s part of why I export most of my own backgrounds as SVG when the design allows for it. When I export patterns from the editor, I check both formats and keep whichever comes out smaller for that specific pattern rather than assuming one is always right.
What happened to that 4.8MB page
Back to the page I mentioned at the start. The fix wasn’t clever, it was just the four steps above, in order. First I re-exported the background at a width that matched a realistic desktop viewport instead of a 4K reference monitor, which alone cut it from 4.8MB to around 900KB. Running that through Squoosh with a slightly lower quality setting brought it under 300KB with no visible difference on the actual page. Adding a preload tag for that specific image moved its download to the very start of the request waterfall instead of somewhere in the middle, behind a font file and two tracking scripts that didn’t need to go first. The reported LCP on that page went from a little over 4 seconds to under 1.5. None of it involved touching the design, the layout, or the pattern itself, which is usually true for this specific problem: the image people are worried looks “too small now if I shrink it” almost never actually looks different to a visitor, because nobody is viewing your site at native resolution on a 40-inch display and zooming in.
How to check whether any of this actually matters for your page
Before spending an afternoon optimizing something that might not be your actual bottleneck, run your page through PageSpeed Insights. It’ll tell you exactly which element is being flagged as your LCP, and whether it’s a render delay, a load delay, or the resource itself being too large. I’ve seen cases where the background image was fine and the real problem was a web font blocking text rendering, which is a completely different fix. Don’t guess, check first, then fix the thing the report actually points at.
The realistic takeaway
None of these four fixes require a rebuild or a new tool. Resize to what you actually need, compress harder than the default export gives you, preload it if it’s above the fold, and don’t blur a huge file when you could blur a small one with CSS instead. In my experience, doing just the first two on a typical hero background image cuts load time enough that the rest becomes optional polish rather than a requirement.