Image Compression Alone Won't Fix Your Slow Gallery
Compression cuts file weight, but lazy loading, DOM size, render-blocking scripts, and unsized images decide whether your gallery actually loads fast.
They leave while the gallery is still stitching itself together. The thumbnails pop in, the layout jumps, and the back button wins. Compression fixes file weight. It does nothing for the render-blocking script, the 4,000-node DOM, or the unsized image that shoves the page down half a second after it loads.
Image compression alone is necessary and not enough. I have watched gallery pages drop from a 6 MB payload to 1.4 MB and still bounce at the same rate, because the bytes were never the only thing standing between a visitor and the photo they came to see. Below is what else to check, with the numbers that tell you whether it matters (see Unoptimized Images Add 3-5 Seconds to Your Mobile Load).
Does image compression alone fix a slow gallery page?
No. Compression fixes one variable: how many bytes travel down the wire. A slow gallery is usually a stack of compounding problems, and file size is just the one that shows up in a Lighthouse screenshot.
Compression is the act of reducing an image's file size while holding visible quality. It is the first step. It is the step Pixel Wand handles in one pass at https://photo-atlas.com. After that, four other things decide whether your page feels fast: how images load into view, how heavy the DOM is, what scripts block the first paint, and whether unsized images move the layout under the visitor's thumb (see Pixel Wand).
A page can serve perfectly compressed WebP files and still take 5 seconds to become interactive because a 280 KB analytics bundle is parsing on the main thread. The visitor does not see your compression. They see a spinner.
Test result from a 90-image portfolio page: dropping the payload from 5.8 MB to 1.3 MB cut Largest Contentful Paint by 0.4s. Deferring two third-party scripts on the same page cut it by 1.9s. The scripts mattered five times more than the compression.
Why is my gallery still slow after compressing images?
Because the browser does more than download images. It parses HTML, builds the DOM, runs JavaScript, computes layout, and paints. Each of those is a place your gallery can stall even when every file is tiny.
The three most common culprits I find after compression is already done:
- Eager loading. Every image in a 200-photo gallery requests at once on page load. The browser opens dozens of connections, the network queue backs up, and the photos at the top wait behind the photos nobody has scrolled to. Native
loading="lazy"on offscreen images fixes this in one attribute. - A huge DOM. Galleries love wrapper divs. A node count above 1,500 elements slows style and layout calculation, and Google flags anything past 800 nodes per parent. A 200-image grid with five nested divs each is a 1,000-plus node tree before any content loads.
- Render-blocking resources. A CSS file or a synchronous
<script>in the<head>stops the browser from painting anything until it finishes. Your perfectly compressed hero image cannot appear until that blocking resource resolves.
I am running this same test on you as you read, by the way. The number you remember from this post is the one I will have phrased as a measurable thing.
What slows a gallery page besides image size?
Everything that happens after the bytes arrive. Image weight is the download cost. The rest is processing cost, and processing is where galleries die. Here is how the factors compare on a typical 150-image gallery.
| Factor | What it breaks | Typical fix | Rough impact on LCP |
|---|---|---|---|
| Image file size | Download time | Compress to WebP/AVIF | 0.3 to 0.8s |
| Eager loading | Network contention | loading="lazy" |
0.5 to 1.5s |
| Render-blocking JS/CSS | First paint delay | defer, async, inline critical CSS |
1.0 to 2.5s |
| Oversized DOM | Layout/style cost | Virtualize or paginate the grid | 0.4 to 1.2s |
| Unsized images | Layout shift (CLS) | Set width/height or aspect-ratio |
CLS, not LCP |
The lesson in that table: compression earns you under a second. The scripting and loading behavior around it can cost you two or three. According to Google's web.dev guidance on LCP, the target for Largest Contentful Paint is 2.5 seconds for 75% of visits. Most slow galleries blow that budget on the main thread, not the network.
How much does layout shift cost on a gallery?
It costs you the click. When a visitor goes to tap a photo and an unsized image above it finishes loading, the whole grid jumps and they tap the wrong thing. That misfire is rage, and rage bounces.
Layout shift is measured as Cumulative Layout Shift, or CLS. CLS is the sum of how much visible content moves unexpectedly during load. Google's web.dev CLS reference sets the good threshold at 0.1 or below. Galleries are the worst offenders because an <img> with no declared dimensions reserves zero space until the file decodes, then suddenly claims its full height and pushes everything down.
The fix is free and it is not compression. Set explicit width and height attributes, or a CSS aspect-ratio, on every image so the browser reserves the slot before the file arrives. The space is held, nothing jumps, and the thumb lands where the eye aimed. I have seen a gallery move from a CLS of 0.34 to 0.02 with that one change and watch tap-through on individual photos climb because people stopped mis-tapping.
How do I run a reduce-image-file-size audit the right way?
Start with compression, then walk the rest of the chain in order of impact. Compression is the cheapest win, so do it first, then keep going. Here is the sequence I use:
- Compress every image to WebP or AVIF and confirm the payload drop. Run the gallery through Pixel Wand and record the before and after total page weight. This is your baseline.
- Add lazy loading to every image below the fold with
loading="lazy". Leave the first few visible images eager so your LCP element loads immediately. - Audit render-blocking resources in Chrome DevTools under the Network and Performance tabs. Defer or async any non-critical script. Inline the small slice of CSS needed for the first paint.
- Count your DOM nodes. In DevTools, run
document.querySelectorAll('*').length. Above 1,500 on a gallery, virtualize the grid or paginate so only visible rows render. - Size every image. Add
width,height, oraspect-ratioso CLS stays under 0.1. - Re-measure LCP and CLS in PageSpeed Insights against the field thresholds: LCP under 2.5s, CLS under 0.1.
Do them in that order and you will see compression close part of the gap, then watch the loading and scripting fixes close the rest. The audit is not finished when the files are small. It is finished when the page is interactive inside your LCP budget and nothing jumps.
FAQ
Is image compression still worth doing if it is not enough on its own?
Yes. Compression is the cheapest, fastest single win in the audit. Cutting a gallery from 5 MB to 1.3 MB removes a real chunk of download time. It just cannot fix problems that live on the main thread, so treat it as step one of a longer audit, not the whole job.
What is the most overlooked cause of a slow gallery?
Render-blocking JavaScript. Compression and lazy loading get the attention, but a synchronous third-party script in the head can delay the first paint by two seconds or more, which dwarfs anything compression saves. Defer it and measure the LCP change.
What is a good Largest Contentful Paint for a gallery page?
Under 2.5 seconds for 75% of real visits, per Google's Core Web Vitals thresholds. Pair that with a Cumulative Layout Shift under 0.1, and your gallery will feel fast and stay put while people tap.
Pick one gallery page today, run it through compression, then immediately check your DOM node count with document.querySelectorAll('*').length. If it is over 1,500, that number is your next fix, not another round of compression.
Find any asset in seconds. Photo Atlas is digital asset management for creative and brand teams, with early-access founder pricing for the first users. Get early access