In my post last summer on 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.
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,
FROM [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.pageid
WHERE requests.firstReq = true
Group By responsetype
order 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: I omitted 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 critical rendering path 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 - even though we are grabbing these numbers a totally different way - 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:
case
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 (recall that with a redirect, we get 11410.) This implies that the addition of a 301 redirect adds ~2450 to the SpeedIndex to these sites. This is the “SpeedIndex tax” of adding a redirect to your site.
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 SpeedIndex tax.
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 nearly 50% of all mobile sites kick off the critical rendering path with a 301 or 302 redirect. These sites are generally smaller (based on KB and requests), but the SpeedIndex of these sites is ~2200-3000 higher when compared to 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. With performance experts pushing for mobile websites to load in under 3-4 seconds (ideally under 1s!) a 2200-3000 “SpeedIndex Tax” is certainly starting off on the wrong foot!