Perhaps you've seen my recent tweet about improving the technical side of the website.
I've noted the biggest technical downside is the actual size of images that are being served.
And looking at the data ahrefs gives us, it looks like GIFs are the biggest struggle.
Let's take a page with the biggest GIF in file size and see what it looks like now.
We'll be looking for the second GIF and see how we can improve.
The first thing I'll do from here is open the actual URL and run the Lighthouse report for this page.
As you can see, Lighthouse states we should use video formats for animated content (GIFs). Also, below that, you'll see we should avoid enormous network payloads, which well also fix by moving from GIF to Video.
Using video instead of GIF for animated content
Then I'll go ahead and download the GIF from the website and save it on my desktop.
Now I'm going to open my terminal and navigate to the Desktop folder.
The first conversion is from GIF to MP4.
ffmpeg -i {original}.gif -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p {output}.mp4
Note: change the variables to the actual names of the files you are using and want to get.
This will give us a converted MP4 file, but let's also make a WebM file. These are even smaller.
ffmpeg -i {original}.gif -c vp9 -b:v 0 -crf 41 {output}.webm
To see the difference, let's check out the finder and see what we gained.
This is a massive difference:
-
GIF
: 13,2MB -
MP4
: 945KB -
WEBM
: 370KB
As you can imagine, this will make our website way faster already, and it actually doesn't make much difference user experience-wise.
Placing the video format as the content
Currently a image is loaded like this:
<img src="image.gif" alt="descriptive text" loading="lazy" />
To convert this into video, we can use the video tag and specify both formats.
<video autoplay loop muted playsinline>
<source src="video.webm" type="video/webm" />
<source src="video.mp4" type="video/mp4" />
</video>
After this, let's deploy the website and see if we fixed anything.
You can see no more errors in the console, and the total requests are down to 119KiB.
This is a massive improvement without really disbursing the user. If any, we help them by serving the website faster.
I'll be converting my GIF content to video this way throughout the weeks. Are you joining me?
Thank you for reading, and let's connect!
Thank you for reading my blog. Feel free to subscribe to my email newsletter and connect on Facebook or Twitter
Top comments (7)
It is also a superior experience other than just size. Native browser controls allow the user can click full screen, play, pause, and scrub. With just a tiny bit of J's we can also add speed control.
I recently made a plugin on my site that automatically swaps gifs for video if video is available at a similar url.
Oh that's even nicer!
I'm still looking if a CDN might have this option.
They have many conversions available, but not yet from GIF to MP4 it should be easily possible, so maybe I'll run a custom script on my S3 CDN
I'm still dropping images in a git repo, it's a separate git repo from my main blog as it got too big. I use actions for a lot of dynamic images, conversation and optimisation.
It's simple, but at some point I am going to reach it's limit.
Great post👍 Recently I faced the choice between adding video vs gif. I thought that videos are generally larger size and hence inefficient but I guess the opposite is true… By the way, the “playsinline” attribute works well to prevent video from opening in full screen when viewed in Safari(iphone).
Hi, that was my exact thought when first looking at this.
Surely a video will be larger, but they are so optimised these days.
I can see those pages perform way better where I converted the GIFs to Videos
Thanks for sharing this! I always assumed that gifs would take up less space than videos, but had never bothered to check whether it was true
I made some gifs for my next blog post, but now I might be using videos instead
I had the exact same idea before.
Surely a GIF would be smaller, but happy to have learned this ✨