My property or product photos are huge and the site loads slowly on phones. How do I fix this?

This page may contain affiliate links from which Blur Studio earns commissions.

A phone on a mediocre connection loading a 4-megabyte photo straight from your camera is one of the most common, most fixable reasons a website feels slow. The fix isn't manually resizing every photo before you upload it, since that's tedious and you'll forget half the time anyway. It's having the server automatically serve a smaller, appropriately compressed version to whoever's actually loading the page.

How Netlify Image CDN actually works

Once it's enabled on your site, you request an image through a specific URL pattern, something like /.netlify/images?url=/photo.jpg&w=800, and Netlify transforms it on the fly: resizing to the width or height you specify, converting to a modern format like WebP or AVIF automatically if the visitor's browser supports it, and falling back to the original format if it doesn't. That transformed version is then cached at the edge, so the first request does the work and every repeat request after that serves instantly from cache. Crucially, this doesn't touch your original source image or slow down your site's build process; the transformation happens per request, not at build time.

It respects atomic deploys too: if you replace a source image with a new version, the next request for it triggers a fresh transformation rather than serving a stale cached copy of the old photo, so you don't end up stuck with an outdated image after an update.

Step by step: setting it up

1. Identify your actual image sizes. A typical phone screen needs roughly 400-800 pixels wide for a full-width photo, far less than a camera's default output, which is often 3,000+ pixels wide.
2. Replace your direct image URLs with the Image CDN pattern, specifying the width (and height, if you want a specific crop) your layout actually needs at each breakpoint.
3. If you're pulling images from an external source rather than your own site's files, add that domain to the remote images allow list in your netlify.toml configuration file; Netlify requires this explicitly for security, so an unlisted remote source will be rejected rather than silently transformed.
4. If you're on a framework with built-in support (Astro's Image component, Next.js 13.5 and up with the right adapter, Nuxt's image module, Angular's NgOptimizedImage), it often wires into Image CDN automatically with very little manual setup.
5. Test on an actual phone over a slower connection, not just your office wifi, since that's the real-world condition this is meant to fix.

The real limitations worth knowing before you rely on it

Three things are worth knowing upfront, confirmed directly on Netlify's own documentation. First, it isn't part of any HIPAA-compliant hosting offering, so if you're in a regulated healthcare context handling protected images, this specific feature isn't the compliant path. Second, it doesn't play well with split testing, since you may get inconsistent image results between test branches, worth knowing if you're running an A/B test on a page with transformed images. Third, it doesn't forward authorization headers (like a login cookie) to remote image sources, so if your photos live behind a login-protected URL elsewhere, you'll need a presigned, time-limited URL rather than relying on your normal authentication.

When Shopify or WordPress already handle this for you

If your site runs on Shopify or WordPress rather than a custom Netlify build, check their own built-in image handling first: both platforms have mature, built-in image optimization that's usually simpler to use than wiring up a separate CDN yourself, and switching to something like Netlify's Image CDN would mean moving your whole site off that platform, which is a much bigger project than fixing slow-loading photos justifies on its own.

A worked example: a real estate listing site

A small real estate brokerage's site was loading listing pages with ten to fifteen full-resolution photos per property, each straight off an agent's phone camera at 3,000+ pixels wide, served at the same size regardless of whether a visitor was on a desktop or a phone screen a fraction of that width. On a mobile connection, a single listing page was pulling down tens of megabytes of image data for photos that would ultimately be displayed at a few hundred pixels wide on screen, a massive, completely unnecessary data cost paid by every visitor on every page load.

Switching the listing template's image tags to request sized, format-negotiated versions through Image CDN cut the actual transferred image weight dramatically, often by more than three-quarters per page, without the agents needing to change anything about how they uploaded photos. The fix lived entirely in the template code, a one-time change, rather than requiring every agent to learn to resize photos correctly before uploading, which was never going to happen consistently across a team that wasn't thinking about file size when they took the picture in the first place.

Cloudinary as the alternative, and when it wins

Cloudinary is a dedicated image (and video) management platform that does more than on-demand resizing: asset organization, more advanced transformations, and its own separate pricing and account. It wins over a built-in CDN feature like Netlify's when image handling is a significant, standalone part of your business (a real estate platform with thousands of listing photos, for example) and you want dedicated tooling and support for just that piece, rather than a feature bundled into your hosting.

A practical note on checking whether it actually worked

After wiring up Image CDN, don't just assume it's working because nothing broke. Open your site's network tab in the browser's developer tools, reload the page, and check the actual file size of a photo that loads, confirming it's genuinely a few hundred kilobytes rather than the multi-megabyte original. A misconfigured width parameter, or an image URL that accidentally bypasses the transformation pattern entirely, can leave a page looking fine visually while still quietly serving the full original file underneath, which defeats the entire point without anything looking obviously wrong on screen.

What I'd actually tell you

For a typical small business site hosted on Netlify, with product or property photos that are simply too large straight off a camera or phone, this is close to a free, automatic fix once it's wired in, and I'd use it before reaching for a separate paid image service. The setup is a one-time change to how your image URLs are written, not an ongoing task, which is exactly the kind of fix that's worth doing properly once rather than manually resizing photos forever.

How I'd approach this

When I'm building or fixing a site with heavy photo content, property listings, product catalogs, portfolio work, wiring up automatic image resizing is one of the first performance fixes I make, specifically because it's a one-time setup that keeps paying off on every future photo upload without anyone needing to remember to resize anything by hand.