Video on the Mobile Web: A Performance Study

As more and more customers use high bandwidth networks, video has become the norm on the web.  Streaming movies, YouTube, and Facebook Live now all stream right onto your phone. Video is shown to enhance engagement, so we should not expect that the growth of video will abate.  

To better understand how video is being used on the mobile web, I looked at the HTTP Archive. The HTTP Archive runs WebPageTest across the top 1M ALexa sites every two weeks, and allows us to understand what kinds of content are being served on the landing pages of these top sites.  CAn we gain any insight into how these sites are delivering video content to their customers?

A quick HTTP Archive query ( shows that website homepages that request video files video have grown by 35% from January 2017 to November 2017:


We can see that over the last 11 months, 4515 sites have added video, leading to an average growth of about 400 sites a month.

Of course, with adding video downloads to your webpage, you are committing to download very large files, and potentially JavaScript to help you play these files – so you are likely to take a hit on how fast your webpage loads (which is another customer engagement factor).  I accept that pages with video are likely to be “busier” than those without, so there may be an extra hit in the measurement of SpeedIndex, but if we compare the mobile sites above with those that have no video:

It is clear that sites with at least one video request are significantly slower than sites with none. In fact, the median site with video is ~ 3 seconds slower – and has been 3 seconds slower all year.

As Colin Bendell pointed out in the 2017 performance calendar, video tag loading and rendering is often deferred by the browser, and perhaps this leads to slower page rendering.

Does Video Imply That Your Site Will Be Slower?

What about sites that use video, but never request any video files until they are needed?  Can we quantify this number?  If we look into the HAR data in the HTTP Archive, we can search every mobile body for the <video> tag, and see how many pages use this tag.  Now, you can parameterize the video element, so I ran my search for the “</video>” tag (“All good things must come to an end.”)  This is a 500 GB search, and due to the quantity of results, I have to save as a table, and allow large results.  

  //find all responses with a video tag
  //since you can parameterise the open tag, I search for the close tag.
  body CONTAINS "</video>"


After 42 seconds, we discover that there are 33,805 response bodies with the video tag on them.  It is possible that there are multiple responses per page.  Searching my new table (a paltry 6GB) for unique urls shows that 27,325 sites use </video> in their site.

Now, it would be easy to assume that if ~27,300 sites have the <video> tag, and ~17,400 sites have video requests – that ~9,900 sites might have the video tag, but no video files were downloaded.  It’s just subtraction, right?  The HTTP Archive results do not agree with that math however.

Of the 17,428 pages with video requests, 7,759 use the <video> element, and 9,669 do not (likely using a javascript method to call the video).  

Of the 27,000 sites that use the video tag, 19,500 do not request any video files.


Now we see three types of “video” sites.  Those that download videos (17,400) and 19,500 that use the video tags, but don’t actually download any video files!  We would assume that the latter would load faster (“the fastest request is the one never made.”) – but let’s look at the data.

If we look at the median SpeedIndex for all of these different groups, what we see is that, no matter how many video files are downloaded, sites with video (or even just the video element) are generally 3s slower than sites without any video:


How much data do these pages consume?  The median page size shows that sites with video requests are 7.1 MB. The median site with the <video> element and no video requests is 2.5 MB, and sites with no video at all are 1.4 MB.

It is possible that sites that use the video tag, but have zero video requests may still have alternative MIME types (like Octet-stream) that are delivering video.  (there are some weird IE-9 <picture> workarounds with the <video> element:

17,000 sites are autoplaying video? 

The tests in the HTTP Archive do not interact with the webpage.  No one is clicking “play” to start a movie.  Does this mean that >17k sites are autoplaying video?  Perhaps not – the Video element also has a “preload” tag.  How do these tags in the video element affect page load time?  If we go back to the query with the response bodies, we remove all the extraneous content from the response body, to just focus on the video element present (with a little regex):

//this regex will grab all groupings that begin "<video"  and end "</video>"
//so that we can see what the video tags look like.
REGEXP_EXTRACT(body,r'(<video[\s\S]+?<\/video>)') AS videotag
//this table has every page with a </video> tag in it.
from [scratch2.sites_with_video_InBody]

Now we can search this table for preload/autoplay and other features of the video element:

( gives me the count of all tags on each page)


Now, as to be expected with ~27k sites, there are a number of unique ways video is used. I want to examine as many as possible, but without worrying about a bunch of outliers.  Looking at the video element:

<video width="320" height="240" controls>
  <source src="movie.mp4" type="video/mp4">
  <source src="movie.ogg" type="video/ogg">
  Your browser does not support the video tag.

There are 2 ways to name the video source:

  1. using “src” inside the video element
    1. I further require the number of src elements to equal the number of video elements.
  2. using the tag <source src =””>
    1. In this case I require src = source, and both are >0/

To limit my query to these 2 parameters, I limit the sites:

where (source =0 && src =videocnt) || (src = source && src>0) 

My dataset is 15,896 sites – 58% of the sites.  20% use just “src”, and 80% use the source element (with an average of 1.75 source references per video).

We see that the most commonly used attributes are height and width, followed closely by autoplay, poster and preload:

Screen Shot 2018-01-04 at 11.23.01 PM
Initially, this looks pretty terrifying – are 38% of videos going to autoplay on mobile?  Not really.  On mobile Chrome and mobile Safari, both autoplay AND muted must be referenced for the video to autoplay.  Searching for that overlap results in 2778 videos, or 14.7% of all video requests in the study.  

Possibly a bigger worry is that 19.5% of videos are set to “preload=auto” – where videos do not play, but are downloaded anyway.  This is the catch-22 of web development.  When a user clicks the video link – we want that video to start up quickly. But if only x% of users watch the video, that means that 100-x% of users are downloading content that they will never use.  The numbers above are all on mobile, and downloading large movie files that are never used can be very expensive to your customers.

Does Autoplay (autoplay + muted) or preload affect webpage load time?

I went through all of the possible tags in the video element, and it appears that setting a video to autoplay, or to preload does not adversely affect site SpeedIndex.  As we might expect, the  MB of video downloaded is largest for these options, but as video attributes are often deferred, we see that they do not they do not significantly alter the page load time.

It is perhaps not surprising then that the tags that affect the layout and rendering of the video on the screen DO affect the SpeedIndex slightly.  We see that adding a Poster and setting a height does slightly increase the SpeedIndex.



In this study, we have examined the HTTP Archive results for how the presence of video affects the load time of mobile websites.  The number of mobile sites with video is growing by about 400 sites a month, and the median site with video loads ~3s slower than the median site without video.

Video tags are deferred to render (see Colin’s post linked above), and that is likely the major reason for increased SpeedIndex for these pages.  However, it is very clear that setting the video to autoplay, autoplay + muted, or preload = auto leads to a much larger page load in MB for the end user.



Thanks to Rick Viscomi for reviewing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.