Somebody has told you to compress your images. They are right, and they have probably also oversold it. Here is what the formats actually do, how much they actually save, and what we found when we measured 36 Dominican tourism websites.

The three numbers that matter

The compression gains are well documented and not controversial.

According to Mozilla's image format reference, lossy WebP images are on average 25 to 35% smaller than JPEG images of visually similar quality, and lossless WebP is typically 26% smaller than the same image as PNG. AVIF goes further: against the same set of JPEGs, AVIF achieved a median 50% reduction where WebP achieved 30%.

So, roughly: WebP saves you a third. AVIF saves you half. Both look the same to the visitor.

That is the whole technical argument. Everything else is about whether you can use them and how much it will actually help your particular site.

Which ones you can use in 2026

Both are safe now, with a caveat.

WebP works in all current versions of Chrome, Edge, Firefox, Opera and Safari. Mozilla describes support as broad across major browsers, while noting it does not have deep historical support — meaning a very old phone may not render it.

AVIF has narrower support, with minimum versions of Chrome 85, Edge 121, Firefox 93 and Safari 16.1. That Edge number is the one to notice: AVIF support arrived there relatively recently.

The practical consequence is that you do not pick one. You serve AVIF to browsers that take it, WebP to the rest, and keep a JPEG as the final fallback. That is what the `picture` element is for, and any developer should set it up once and never think about it again.

If you are choosing a single format and cannot do the fallback dance, use WebP. Better support, still a third smaller.

What we measured on real Dominican sites

We tested 36 Punta Cana and Bayahibe hotel websites on a simulated mid-range phone. The results on images are more interesting than the usual advice suggests.

The median page weighed 8.05 MB. The median image payload was 2.66 MB. So images were a median 27% of total page weight — not the majority.

The spread matters more than the median. On one site, images were 98% of the page. On another, 5%. Eight of the 36 sites were shipping more than 5 MB of images alone, and the largest single image payload we measured was 14.7 MB on one homepage.

Here is the honest conclusion, which is less convenient for anyone selling image optimisation as a complete answer: on a typical Dominican tourism site, compressing every image perfectly removes about a quarter of the page weight. The other three quarters is mostly JavaScript, fonts and third-party scripts.

That does not mean skip it. A quarter of 8 MB is 2 MB, and converting to AVIF would halve the image portion — a real improvement for a one-off technical job. It means you should be suspicious of a quote that promises a fast site and only mentions images.

Format size is not the only thing wrong with your images

Three failures we see constantly in Dominican sites, all of which cost more than the format choice.

Serving a desktop image to a phone. A 2,400-pixel-wide hero photograph displayed in a 390-pixel-wide phone viewport. The browser downloads every byte and then throws most of them away. Responsive image sizes fix this and cost nothing.

No lazy loading. Every image on the page, including the eight below the fold nobody will scroll to, downloads before the visitor sees anything. One attribute fixes it.

Uncropped originals straight from the camera. A photographer delivers 6,000-pixel JPEGs, somebody uploads them to the CMS, and the site serves them at full resolution forever. This is the single most common cause of a 10 MB page we find.

Fixing those three is usually worth more than changing format, and changing format on top of them compounds.

What about PNG, GIF and SVG?

The formats people still reach for, and when they are actually right.

PNG is for images that need genuine transparency or must be pixel-exact — a logo, a diagram, a screenshot with text. It is the wrong choice for a photograph, where it will be several times larger than a JPEG of the same apparent quality. WebP handles transparency too and is smaller, so for new work a transparent WebP beats a PNG.

GIF should be retired. For animation, a short muted video file or an animated WebP is dramatically smaller. A 2 MB GIF of a looping beach scene is a 200 KB video.

SVG is not in the same category and is often the right answer. Logos, icons, simple illustrations and charts drawn as SVG are usually a few kilobytes, scale to any screen without blurring, and can be styled with CSS. If your logo is a 400 KB PNG, converting it to SVG is a five-minute job with a large payoff on every single page.

JPEG is still fine as a fallback and for photographs where you cannot run a conversion pipeline. It is not a failure, it is just a third larger than it needs to be.

Why this is a Dominican problem specifically

Two reasons, both measured.

Our hotel sample had a median main-content time of 17.1 seconds on a mid-range phone. Exactly one site in 36 came in under four seconds, and none reached Google's 2.5-second "good" threshold.

And your customers are on phones, not computers. The Oficina Nacional de Estadística's ENHOGAR-MICS 2025 survey found 89.4% of Dominican households own a smartphone and 32.3% own any computer, laptop or tablet. A heavy page is not an inconvenience here. It is the whole experience, on mobile data.

How to check your own site in five minutes

No tools to install and no developer required.

Open your homepage on a desktop browser, right-click, choose Inspect, and open the Network tab. Reload the page. Sort the list by size. You will see every file the page downloaded, largest first.

What you are looking for: any single image over about 300 KB, any image whose pixel dimensions are much larger than the space it appears in, and the total figure at the bottom of the panel. If that total is over 2 MB, you have the problem this post describes. If it is over 5 MB, you have it badly — eight of our 36 hotel sites were shipping more than 5 MB in images alone.

Then do the same thing with your phone, on mobile data, away from wifi, and time how long it takes before you can read anything. That number is what your customers experience, and it is the only one that matters.

What to actually ask for

If you are briefing a developer, these are the specific requests. They are not negotiable extras; they are what a competently built site does by default.

• Serve AVIF with a WebP and JPEG fallback, using `picture`

• Generate multiple sizes per image and serve the right one per screen width

• Lazy-load everything below the fold

• Set explicit width and height on every image so the page does not jump while loading

• Never upload an image wider than the largest size it will be displayed at

• Convert at build or upload time automatically, so nobody has to remember

That last point is the one that determines whether this survives contact with reality. If compressing images is a manual step somebody has to do, it will be done for the first ten images and never again. It has to happen automatically.

What it will not fix

Image optimisation will not fix a site built on a page builder loading nine plugins. It will not fix three analytics scripts, two chat widgets and a font library. It will not fix a 4-second server response.

We put a number on the overall state of Dominican business websites in a separate post, and the summary is that speed is a whole-site problem, not an image problem. Images are the easiest quarter of it.

If you want someone to do the whole quarter properly — and tell you honestly what the other three quarters are costing you — DR Web Studio builds and fixes websites across the Dominican Republic. Contact us for a free consultation.