wanna hear something cool?
You can 2x your Lighthouse performance score just by changing how you embed 8 gifs on a gigantic 6000 word page with 130 requests and 16megs of data.
How I found out
On the internet, ain’t nobody got time to read 3 paragraphs of emotion setting. You’d find it boring.
So we use gifs.
But looking for gifs breaks your writing flow. You leave the editor, go on giphy, search for the emotion, dig through the search results, copy paste the link, go back to your editor …
Wait what was I saying? 🤔
Happens every time. Slows you down. Wasted effort.
What if you could find the perfect gif without leaving your editor? Write a search right in your markdown?
Been using that with TechLetter.App for over a year now and it is wonderful. Saves so much time and effort. 👌
This weekend I turned it into my first Gatsby plugin – gatsby-remark-giphy.
Now you can use it too ❤️
3 ways to embed a gif
gatsby-remark-giphy supports 3 ways to embed a gif
- using HTML5 video
- as an iframe
gatsby-config.js and the plugin changes how it transforms markdown nodes.
Here’s what happens.
At build time, gatsby-remark-giphy visits each markdown image node whose URL starts with
giphy:, pings the Giphy API, and runs 1 of 3 functions:
To embed a gif, we maintain the markdown-ness of this node. Change the URL to the search result and add a title. Further markdown transformers will turn it into a regular image.
Something like this:
This is the slowest.
You’re loading the gif as soon as the page renders. Whether it’s visible or not. And you have to wait for the whole gif to download before it plays.
Here we change the node into HTML and tell markdown exactly what to do. The gif becomes an HTML5 video element playing an mp4.
autoplay loop muted playsinline makes it behave like a gif. But with one crucial difference 👉 mp4 is optimized for streaming.
That means your browser can play the video while it’s downloading. And the filesize is smaller.
2.29MB gif vs. 1.09MB mp4 for our surprise example. 🤯
This is the fastest.
But this result is suspicious, we’ll get to that.
Similarly to the video embed, we change the node to HTML and tell markdown exactly what to do.
Create an iframe Giphy embed in this case. I borrowed the code from gatsby-remark-embedder and added
loading="lazy" to speed things up.
The result is an iframe with some annoying Giphy branding on mouseover and a nice Lighthouse boost.
What’s interesting is that Giphy’s iframe embeds a
webp version of the gif that’s just 880KB for our surprise example. 🤨
So iframe should be fastest, right?
loading="lazy" is a new native implementation of lazy loading. Mark something as lazy and the browser avoids loading it until it’s visible.
I think it’s only supported on Chrome right now, but that’s where we measure Lighthouse scores isn’t it? Also what Google cares about when determining page speed for that sweet sweet SEO boost 😛
Lazy loading will almost always give you a speed boost and improve user experience.
Where my results get tricky is that the
<video> element does not support loading=lazy. And yet it still gave me a Lighthouse performance boost. From 44 to 63 …
Maybe it’s a Lighthouse bug? 🤔
<video> is much better than
<img> and I don’t like the overlays and extra tracking that comes with
PS: I benchmarked using the ServerlessReact.Dev landing page, changing how 8 gifs are embedded and nothing else.
Learned something new? Want to improve your skills?
Join over 10,000 engineers just like you already improving their skills!
Here's how it works 👇
PS: You should also follow me on twitter 👉 here.
It's where I go to shoot the shit about programming.