Starting Off on the Wrong Foot: The “SpeedIndex Tax” of Mobile Redirects
The HTTP Archive is a bimonthly run of the top 5k mobile websites (and 250k desktop sites). There is a wealth of data in these runs that are easily accessible from Google’s BigQuery. IN this post, I am comparing sites that kick off with a 301 or 302 redirect to those sites that do not, and attempt to quantify the difference.
This post is crossposted at bigqueri.es
In my post last summer on load times of m dot sites versus RWD, I showed that the SpeedIndex for RWD is competitive with “M.” mobile specific sites. I postulated that the reason that RWD sites were competitive (despite higher request and KB count) was that “M.” sites often incorporate a 301 or 302 redirect at the start of the critical rendering path. Let’s call that the “SpeedIndex tax.” In this post, I’m going to attempt to quantify the SpeedIndex tax for mobile sites that kick off the critical rendering path with a redirect.
SpeedIndex is a unitless indicator of how quickly the page loads. A lower SpeedIndex is better.
I re-ran my query from last summer on the mobile data from 1/1/15, and the count of M. sites is quite similar (~20%) to what I found 6 months ago.
Let’s look at the first request for all mobile sites:
SELECT case when requests.status == 200 then “200” when requests.status == 204 then “204” when requests.status == 206 then “206” when requests.status between 200 and 300 then “2xx” when requests.status == 300 then “300” when requests.status == 301 then “301” when requests.status == 302 then “302” when requests.status == 303 then “303” when requests.status == 304 then “304” when requests.status == 307 then “307” when requests.status == 308 then “308” when requests.status between 300 and 400 then “3xx” when requests.status == 404 then “404” when requests.status == 417 then “417” when requests.status == 420 then “420” when requests.status between 400 and 500 then “4xx” when requests.status between 500 and 600 then “5xx” when requests.status between 100 and 200 then “1xx” when requests.status between 0 and 100 then “0xx” when requests.status between 600 and 700 then “6xx” else “other” end responsetype, COUNT(*) as cnt,NTH(50, quantiles(bytesTotal)) medianKB, NTH(50, quantiles(SpeedIndex)) medianSI, NTH(50, quantiles(renderStart)) medianRenderStart, NTH(50, quantiles(onLoad)) MedianOnload, NTH(50, quantiles(fullyLoaded)) medianFullyloaded, // firstReqFROM [httparchive:runs.2015_01_01_requests_mobile] requests JOIN EACH ( SELECT pageid, SpeedIndex, bytesTotal,renderStart,onLoad,fullyLoaded FROM [httparchive:runs.2015_01_01_pages_mobile]) pages ON pages.pageid = requests.pageidWHERE requests.firstReq = trueGroup By responsetypeorder by responsetype asc
This gives me a list of the first HTTP response for all of the mobile sites (and median stats for each response type). I have added the same query for the desktop web as a comparison:
(Note that I omitted the 10 desktop websites that had additional HTTP responses (for simplicity).)
What is fascinating here is that nearly 50% of all mobile sites kick-off the loading with a redirect (while only 30% of desktop web does the same)! We can rationalize the difference, since we know that ~20% of mobile sites redirect to an “m”. We could further postulate that ~2% of the “m.” redirects are 301, and ~17% are 302 (based on the differences between the mobile and desktop percentages.) Here are the same results graphed:
Let’s dig into the rest of the data from the mobile query above:
Looking at the median KB for these sites, we see that sites with no redirect tend to be larger, 301 are 8% smaller (15% fewer requests), and sites with a 302 are 40% smaller (with 34% fewer requests). These values – despite a very different way of coming up with the data – closely mirrors the Median KB size of Mdot vs. other sites in my June 2014 post. So I think we are on the right track here.
The median site with a 301 has a SpeedIndex that is 1860 slower than a site with no redirect. The median 302 is merely 330 slower. However, with these sites being much smaller and having fewer requests, I would assume that they should actually be faster! But how much faster should they be?
Let’s take a look at how fast mobile websites with no redirect load (based on total KB size). By looking at only mobile sites with a 200 response at start (no redirect), and graphing the median SpeedIndex by the Total KB, we get the following plot:
The query here basically changes the case structure form above to:
when bytesTotal between 0 and 100000 then “100”
when bytesTotal < 200000 then “200”
when bytesTotal < 300000 then “300”
when bytesTotal < 400000 then “400”
etc… in order to group the mobile sites by 100KB ranges.
Sites with a 301 are ~800KB, and the graph above tells us that sites of this size (without a redirect) would have a median SpeedIndex around 8960 (but we measure the SI of these sites to be 11410.) This implies that the addition of a 301 redirect adds ~2450 to the SpeedIndex to these sites.
Mobile sites with a 302 are ~500KB, and based on the “no redirect” data, should have a SpeedIndex somewhere in the high 7000s (let’s say 7500). Since the median SpeedIndex we find for sites with a 302 is 9880, that means that the redirect is costing these sites around (9880 – 7500 = 2380) 2380 from their SpeedIndex score.
I did the same analysis for sites based on the request count, and found a Similar “SpeedIndex tax.”
This is a simplified analysis, but from this data, it appears that mobile sites with 301 OR 302 redirects are generally smaller (based on KB and requests), but the SpeedIndex of these sites is ~2200-3000 higher than similarly sized sites without a redirect. With a push to get websites on mobile to load in under 4 seconds, the redirect SpeedIndex tax is a major factor in page load.
Redirecting your mobile users to a “m.” or other mobile specific site has long been a tried and true method to ensure that pages load quickly on mobile (by reducing the amount of content delivered.) The analysis above shows that 49.3% of mobile sites issue a redirect on initial page load, and that these redirects add ~2400 to the SpeedIndex score of these pages – indicating that there is a real cost to mobile users to begin with a redirect.