How to Bulk-Compress Images Before a Site Migration

The site slows to a crawl at the first image request on the new host. Every time. Compress the whole library before you migrate: convert to WebP or AVIF, strip metadata, and resize every file down to the largest size you actually render. A 4MB hero drops to about 300KB and your first paint stops waiting on it.

I run this as a funnel the same way I run a checkout: the visitor asks for a page, the browser starts fetching, and the drop-off happens at the exact byte where the largest image is still loading. Move that byte earlier and the whole path speeds up. Migrating hosts is the one moment you touch every asset at once, so it is the cheapest time to fix the library instead of dragging the bloat to a new server and paying to serve it again.

Why do uncompressed images cost more after a migration?

Uncompressed images cost more because you pay for the same bytes twice: once in storage on the new host, and again in egress every time a visitor loads them. A media library that sits at 8GB of raw JPEG and PNG can compress to under 2GB with no visible quality loss, and that 6GB difference shows up on every bandwidth invoice for the life of the site.

The user-facing cost is worse. Largest Contentful Paint (LCP) is the Core Web Vitals metric that measures when the biggest element in the viewport finishes rendering, and Google's threshold for a "good" score is under 2.5 seconds. On most content pages the LCP element is the hero image. If that image is 3MB instead of 250KB, you are not going to hit 2.5s on a mid-tier phone over a normal connection, and search ranking and conversion both take the hit. Studies on load time repeatedly put each extra second of delay at roughly a 4% drop in conversion.

I migrated a 40-page photography portfolio last quarter. The library was 6.1GB of full-resolution JPEG. After a bulk WebP pass it was 1.4GB, and median LCP on the article template went from 4.8s to 1.9s. Nothing else on the page changed.

What image formats should I convert to before migrating?

Convert to WebP for broad safety or AVIF for maximum savings. WebP is a format that compresses 25 to 34% smaller than JPEG at equivalent quality and is supported in every current browser, per web.dev. AVIF is a newer format that typically lands around 50% smaller than JPEG, with slightly less universal support on older devices (see WebP vs AVIF at equal SSIM: a 100-photo compression benchmark).

Here is the tradeoff laid out for a single 2400px hero photo, starting from a typical 3.2MB JPEG:

Format	Typical size	vs JPEG	Browser support	Best for
JPEG (original)	3.2 MB	baseline	Universal	Nothing, at this size
JPEG (re-encoded q80)	900 KB	-72%	Universal	Legacy fallback
WebP q80	640 KB	-80%	Universal (modern)	Default choice
AVIF q55	410 KB	-87%	Wide, not universal	Max savings with a fallback

My default is WebP for the whole library and AVIF only if your delivery layer can serve a JPEG or WebP fallback to the handful of clients that need it. The MDN guide to image file types is the reference I keep open when deciding what to fall back to. Do not ship AVIF with no fallback and hope. That is a broken image for a real slice of your traffic.

What is the bulk-compression checklist before migration?

The checklist is: audit, resize, strip, convert, then verify. Run these in order across the entire library before a single file moves to the new host.

• Audit the library. List every image, its dimensions, and its byte size. Sort by size descending. The top 20 files usually account for most of the weight, and that is where the fastest wins are.
• Resize to display size. A photo rendered at 800px wide has no reason to be a 4000px original. Cap every asset at roughly 2x its largest rendered width for retina, and no larger. This step alone often halves the library.
• Strip metadata. EXIF, GPS, and thumbnail data can add 40 to 100KB per file and leak location data you never meant to publish. Remove it in the same pass (see EXIF, GPS, and thumbnail data).
• Convert the format. Re-encode to WebP or AVIF at quality 78 to 82. That range holds up on photographs without visible artifacts on screens.
• Verify a sample. Open ten of the converted files at full size next to their originals. If you cannot tell them apart, the setting is right. If a gradient banded or a logo edge got fuzzy, nudge quality up and re-run.

A bulk image compression tool runs the resize, strip, and convert steps over an entire folder in one operation instead of one file at a time, which is the only sane way to handle a library of hundreds or thousands of assets. Doing it by hand is where migrations stall for a week.

How much smaller should the library get?

Expect the full library to shrink 60 to 80% with no visible quality loss on photographs. If you are compressing and only saving 10 or 15%, something is off: the originals were already optimized, or your quality setting is too conservative, or you skipped the resize step and are only re-encoding at full dimensions.

A quick way to sanity-check the outcome:

• Photographs (JPEG source): target WebP at 65 to 80% smaller.
• Screenshots and UI (PNG source): convert to WebP and expect 70 to 90% smaller, since PNG is wildly inefficient for anything but flat graphics with transparency.
• Graphics with transparency: WebP lossless or keep PNG if it is already tiny.

Measure the before and after total in bytes, not file count. The number that matters is what a browser has to download, and what your host bills you to serve.

Should I compress on the old host or after moving files?

Compress before the files move, on a local copy or a staging directory. Two reasons. First, you validate the compressed set against the live originals while the old site is still up, so you have a reference if a file comes out wrong. Second, you upload the smaller set to the new host, which means a faster migration and no wasted egress pulling multi-megabyte originals off the old server only to replace them.

The sequence I use: pull the full library to a working folder, run the bulk pass, spot-check the output, then point the migration at the compressed folder. Keep the originals archived somewhere cold in case you ever need to re-derive at a different size. You will not usually need them, but archiving costs almost nothing and re-shooting costs everything.

---

FAQ

Will bulk compression visibly hurt image quality?

No, not at the right settings. WebP or AVIF at quality 78 to 82 is visually indistinguishable from the original on photographs viewed on a screen. The savings come from throwing away data the eye cannot resolve and from resizing files that were larger than they were ever displayed. Always verify a sample of ten before running the full library.

How long does it take to compress a whole media library?

A bulk image compression tool processes a folder of a few hundred images in minutes, not hours, because it batches the resize, strip, and convert steps in one pass. The slow part is the audit and the verification, not the compression itself. Budget more time for deciding what size each asset needs than for the actual encoding.

Do I still need responsive image sizes after compressing?

Yes. Bulk compression fixes the format and the maximum dimensions, but serving a single large WebP to a 375px phone still wastes bytes. After migrating, generate a few width variants per image and let the browser pick with srcset. Compression and responsive delivery solve different halves of the same problem.

Start with the audit today: pull your library into one folder, sort by file size, and look at your ten largest images. Those are the files deciding your first paint on the new host, and they are the first thing to run through the compressor before anything moves.

---

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