Thousands of websites use a Facebook plugin to embed social media content into their websites. In studying this plugin, I discovered that (for Chrome and Android users) it automatically downloads over 30% of any video present, whether the video is watched or not. This results in large amounts of data to be downloaded (sometimes upwards of 2MB of video), which can be very expensive to some users. Further, the same video is downloaded multiple times with different dimensions. This “Facebook penalty” is observed for Chrome and Chrome mobile (Android), but not on Safari or iOS.
Background
I’ve been digging through the HTTPArchive and examining sites that use video. In my research, I found that two thirds of the videos found in the HTTPArchive come from Facebook’s CDN fbcdn.net (mobile sites, 8/1/2018 run):
To test how these videos are being used, I randomly chose US Diesel Parts from the list of sites with Facebook video content. The two screenshots below show desktop (left) and mobile (right). The Facebook widget is highlighted in yellow. On the mobile site, the orange lines indicate one full page of the screen. This widget is on the 4th viewport for desktop, and the 7th viewport for mobile (read: pretty far down the page).
The widget is created and added very easily with either a small script and code, or with an iframe. This is the iframe loading the Facebook timeline of US Diesel Parts:
src="[https://www.facebook.com/plugins/page.php?href=https%3A%2F%2Fwww.facebook.com%2FUSDieselParts&tabs=timeline&width=500&height=500&small\_header=true&adapt\_container\_width=true&hide\_cover=true&show\_facepile=true&appId](https://www.facebook.com/plugins/page.php?href=https%3A%2F%2Fwww.facebook.com%2FUSDieselParts&tabs=timeline&width=500&height=500&small_header=true&adapt_container_width=true&hide_cover=true&show_facepile=true&appId)" align="center" width="500" height="500" style="border:none;overflow:hidden" scrolling="no" frameborder="0" allowTransparency="true" allow="encrypted-media"\>
This doesn’t look so bad, it’s just one small call to Facebook….
It’s Really Just One Request, Right?
To examine the performance of just the Facebook timeline widget, I created a test page with only the widget present. There are 4 Facebook posts loaded inside the iframe during this test, and only the 3rd and 4th posts have video files.
Running WebPageTest on the test page shows that this simple iframe code results in an additional 3.7 MB of content (1.8 MB of video!), with nearly 100 requests on both Chrome and mobile Chrome. (Note: I will point out, but totally ignore the 1.5 MB of JavaScript in the context of this post…).
This one little request ends up generating a lot of traffic.
Why Are Video Files Are Being Downloaded?
Facebook is preloading video content inside the timeline in order to minimize the startup time for the videos to playback.
What is Actually Being Requested?
Looking into the waterfall diagram, there are a lot of video requests — of many different video files:
There are 33 video byterange requests, meaning that each request is asking for just a small segment of the full video file. Looking at the root file name, there are a total of 9 videos being downloaded inside the Facebook timeline.
But wait! There are only 2 videos in the timeline — Why are there 9 videos being downloaded??
There are 2 ‘main’ videos, 2 audio tracks, and the other 5 videos are duplicate videos — just resized to different dimensions! The dark red and blue lines indicate the ‘main’ videos, and the light red and blue indicate the “other” versions of the same videos.
The main videos (and their audio tracks) are all 25–30% downloaded by the Facebook widget. The “other” versions appear to have just ~1KB downloaded each, but nonetheless, 2 requests are made for each of these files.
Video Dimensions
If we go back and look at the iframe code, it is defined to be 500 pixels wide. However, the ‘blue’ video is downloaded at 1280 pixels wide — over twice the size of the allotted space on the page. The widget could download a more appropriately sized 640×360 version of the video (we see two requests for this video in the trace) that would be 2.5x smaller (2.1 MB vs. 800 KB).
Reproducibility:
This effect is easily reproduced with *any* Facebook page. Facebook has a plugin generator that creates the iframe code for any page. Simply create the plugin using a Facebook feed with a video in the timeline, paste onto a page, and test the results (in Chrome). This effect does not appear when I use Chrome to emulate an iPhone, only with Android, and native Chrome.
Scope of The Issue:
In the HTTPArchive, there are 116k Facebook timeline video requests. They are found on 5564 websites (of 37k sites with video present, and 1.2M sites in the total dataset). This means that 15% of all sites with video are affected by this issue, and 0.5% of all sites in the mobile HTTPArchive dataset are impacted.
By downloading 25–30% of all videos present in the Facebook timeline, huge amounts of data are being used (for mobile customers) for videos they will probably never load from the webpage.
What Can I Do?
Whenever adding 3rd party widgets to your websites, you must perform a performance check to ensure that the new feature is not harming the load time of your page. Understand that the presence of videos in your social media posts will slow down your website for Chrome and Android users, and weigh the importance of this plugin on your page for those users.
Thanks to Colin Bendell for reviewing a draft.
Originally published at dougsillars.com on August 21, 2018.
Top comments (0)