How do you speed up a website that’s weighed down by big images and video?

We spent some time last week helping a client get their pages loading faster, and it’s a job that’s felt a lot more pressing lately. Site speed has always mattered, but something has clearly shifted.

Our own research over at SiteVitals backs this up. Out of over 200 sites we surveyed (using the PageSpeed Insights API), only 8.7% now score as “good” – down from 18.2% before March 2026. And the share scoring “bad” has jumped from 14.9% to 25.1% over the same period. It’s very unlikely that many sites got worse overnight – it seems much more likely the bar has moved.

That timing lines up neatly with Google’s March core update and everything it’s been saying about leaning harder into AI. Reading between the lines, Google seems to be really prioritising speed to help with what it’s trying to do now. So if you care about SEO and GEO (getting picked up by AI tools – basically the new front line of search), a snappy site isn’t a nice-to-have anymore.

The client we helped this week is a large membership-based site running on WordPress. They’ve got their own marketing team and tend to do as much as they can themselves, just with our guidance when they need it. So rather than diving in and changing things, we went looking for the biggest, quickest wins and walked them through it. The three culprits were exactly what you’d expect – a massive GIF, a video embed, and a load of heavy images. Here’s what we found, and how you can check the same on your own site.

Is a big GIF slowing your homepage down?

The first thing we spotted was a single GIF being used on a couple of their busiest pages. It looked great – no complaints there – but it was weighing in at 4MB. That’s a lot of data for a brand new visitor to download alongside everything else on the page, and it slows that all-important first impression right down.

It wasn’t our place to just remove it, so instead we made an alternative they could swap in. Converting the GIF to an MP4 video brought it down from 4MB to around half a MB – a HUGE saving for something that looks practically identical. (There are loads of ways to convert a GIF to MP4 – free online tools, ffmpeg if you’re techy, or even asking an AI like Claude to do it for you.) We also made a slightly optimised GIF at 3MB in case they wanted to stick with that format, but the MP4 is the clear winner.

To use an MP4 in place of a GIF, you swap your <img> tag for a <video> tag, like this:

html

<video autoplay loop muted playsinline>
  <source src="your-animation.mp4" type="video/mp4">
</video>

The autoplay loop muted playsinline bit is what makes it behave like a GIF – playing immediately, on a loop with no controls and no sound.

Is your video embed costing more than the GIF did?

Once the team swapped the GIF out, the page weight on one of their key landing pages dropped from 17.7MB to 14.7MB on initial load. Going in the right direction! But when we looked closer, we realised they’d embedded the replacement using Vimeo, and that brings its own baggage.

The thing is, a Vimeo embed doesn’t just load your video. It loads the entire Vimeo player alongside it – the JavaScript, the analytics, the streaming infrastructure, the lot. Looking at the network tab (the list of everything a page downloads), it was pulling in multiple video chunks plus around 1MB of Vimeo’s own scripts on every single page load. So for a short looping background animation, the Vimeo version was costing as much as – or more than – the original GIF we’d just removed.

For a tiny video like this, a simple self-hosted video tag is therefore often a better answer. It brings the page weight down properly, and it removes the dependency on Vimeo’s CDN, so there’s no risk of your page slowing down or breaking if Vimeo is ever having a bad day.

How do you actually add a self-hosted video in WordPress?

That code snippet above is an example to show the structure – it’s not something you paste into a URL field. The proper way to do it in WordPress is to upload the MP4 to your media library first, then embed it from there, the same way you would an image. (Cloudflare and similar services will then serve it efficiently from there.)

If your CMS makes that awkward, don’t fight it – it’s usually the kind of thing a developer can sort in five minutes, so it’s fine to ask for a hand.

Are your images far bigger than they need to be?

With the GIF and video sorted, the next big lever was the images. The pages were still using a lot of imagery, and some of the source files were way heavier than they needed to be.

Now, one really useful thing with this client is that they’re already running Cloudflare, and it was doing a lot of the heavy lifting automatically – compressing images and converting them to WebP (a modern image format that’s typically 25–35% smaller than a JPG or PNG, with no visible drop in quality, and supported by every modern browser) before they reach visitors. So they didn’t need to worry about format conversion themselves. Brilliant, right?

Well… mostly. Because Cloudflare can only work with what it’s given. If the source image is enormous or saved in the wrong format, the delivered version will still be bigger than ideal. Garbage in, slightly-less-garbage out. So whoever’s uploading images still needs a few rules of thumb:

What to check	Rule of thumb	Why it matters
Format	JPG for anything photographic – heroes, backgrounds, photos of people, book covers. PNG only where you genuinely need transparency, like a logo or icon.	PNG is lossless, so a photo saved as PNG can be 5–10x bigger than the same photo as a JPG at 80% quality, with barely any visible difference.
Dimensions	Max 1920px wide for full-width images. Much smaller for thumbnails, author photos and the like.	There’s no point uploading a 4000px image if it’s only ever shown at 400px – you’re just shipping data nobody sees.
File size	Aim for source files under 500KB before you upload.	A free tool like TinyPNG compresses images in seconds with no visible quality loss.

Format is the big one. On the client’s site, their main hero image was a photographic shot saved as a PNG, which is why it was coming in at 2.1MB at source. The dimensions were actually fine, so no resizing needed – simply re-exporting it as a JPG would bring it well under 300KB, saving over 1.5MB on that one page. That’s a genuinely quick, worthwhile fix, and exactly the kind of thing worth doing across your heaviest pages.

If you want to see the difference for yourself, try converting one of your own PNG photos to a JPG at 80% quality and compare them side by side.

So where should you start?

If you only do one thing, open up your homepage and your busiest landing page and have a look at what’s heaviest – a big GIF or a video embed will usually be the worst offender, and that’s a single change that makes a real dent. After that, work through your biggest images using the three rules above.

And once your images are sorted, it’s worth knowing they’re not the only thing often weighing your pages down. Third-party scripts – the bits of code your site loads from other companies, like chat widgets, tracking pixels and spam protection – can pile on just as much, often without you realising they’re there. That’s a slightly different job to images though, so I’ve put it in its own post: how to find the third-party scripts slowing your website down. (We spotted a big client loading spam protection on loads of pages that didn’t need it.)

None of this is glamorous work, but it adds up fast, and with Google clearly prioritising speed right now it’s some of the best return you’ll get for the effort. If you’d like a hand checking your own site, please get in touch, or run a free site overview report with SiteVitals to see your main offenders for performance.