Testing the Performance of Social Media Embeds
I’ve been writing and speaking about web sustainability quite a bit this past year. One thing I’ve done periodically for my talks is to test the data transfer size of various social media embeds — they’re pretty bad!
What’s up with the cache?
These tests were all conducted with a fresh, uncached page. There seems to be some decent caching going on, as Chrome reports only 75kB of JS transferred on a return visit, as well as when visiting a page with a different embed. On Firefox however, the same page with the same embed reports 2.9MB of JS transferred! What is going on?! Are dev tools inaccurate, or are different browsers downloading resources differently?
After a bit of Googling, I discovered that Firefox introduced a feature called RCWN (Race Cache With Network) some time ago. This led me to this fascinating article by Simon Hearne, When Network is Faster Than Cache. It turns out that sometimes retrieving a resource from the cache can take longer than fetching it from the network! In Firefox’s case, files are being requested from both the cache and the network, and the fastest one wins. On my home broadband connection, the network seems to beat the cache nearly every time, which (I assume) is why we’re seeing those files transferred each time. On slower connections this probably wouldn’t be the case.
It’s reassuring to know that users on poor connections would have those files served from the cache. But Simon’s article makes the point that cache retrieval can be slow, and becomes slower the more resources are requested from the cache, which particularly for those with low-powered devices and connections.
There is an assumption that cached assets are retrieved instantly and at zero cost. What we have discovered here is that there is in fact a cost to retrieving assets from cache based on the number of cached assets (not file size) and the user's devices.
Additionally, I’m not sure that hitting the network every time (in Firefox’s case) is more sustainable?! Google’s explanatory article on cache strategies notes that it can be ideal for small assets. It also notes:
However, going to the network when the user has the content on their device can be a waste of data, so bear that in mind.
Hmm. Surprisingly enough (or not at all surprisingly), the best route to good performance and a more sustainable website is to keep your pages as lightweight as possible, and avoid your users having to download all that data in the first place. In that case, it’s all the more disappointing to see Google increase the amount of JS shipped with the YouTube embed, perhaps in the mistaken believe that the cache will save the day.
I’m not a performance expert, so I might be missing a crucial piece of the puzzle. I’d love to hear from folks who have some more insight into this!
If you’d like to test the performance of a few different types of social media embed (including YouTube videos), I’ve made a lightweight website to do just that.
Webmentions for this pageAbout webmentions
Test page: https://output.jsbin.com/rojadof/quiet- Šime Vidas
@michelle The YT embed situation is really crap… they should allow the page their embed is within to specify lazy loading but fundamentally they don’t seem interested in lightening the load- Andy Davies
@michelle very much related to this:
I went back and had a look at the COP28 homepage today (for funsies, as one does). Both "versions" of the site are now over 34MB ... almost entirely thanks for YouTube embeds. Absolutely crazy.
Captured some updated notes in the blog post: https://fershad.com/writing/cop28-uae-a-low-carbon-website-review/- fershad