Per https://twitter.com/HTTPArchive/status/1031941537293205506 the WordPress lens on the State of the Web report shows that the median mobile page weight is actually heavier
than desktop!
https://httparchive.org/reports/state-of-the-web?lens=wordpress#bytesTotal
We’re not quite there in the global dataset, but the gap is clearly closing:
First thing that comes to mind is retina. Are the mobile tests indicating a DPI of 2 or higher? Are the desktop tests providing any DPI info? If the mobile tests are retina and desktop tests are not, then there could be more image bytes for the mobile tests.
Great idea @josephscott.
The median image bytes chart shows a growing gap between desktop and mobile, with mobile ~100 KB heavier.
https://httparchive.org/reports/page-weight?lens=wordpress#bytesImg
Not sure if it’s necessarily DPI related, but it’s a good guess. @pmeenan would know how the WPT tests are configured. Of course, not all mobile users have high DPI devices, but it’s still interesting to see sites serving heavier images/pages overall to some segment of mobile users.
The mobile tests emulate the Moto G4 which has a dpr of 3 (so 3x images for sites that support it). The sad truth of mobile is that the devices have higher resolution (and particularly dpr) than the vast majority of desktops and laptops.
My immediate thought is as much I wouldn’t discredit DPI, I’m willing to bet Mr Meenan’s car that there are resource loading mistakes being made. This is just a hunch. I feel like RWD is still an issue. I’ve seen enough sites loading 2 versions (mobile and desktop) of same img resource in the mobile viewport. I spoke at a conf last august where hiding the desktop assets was an accepted technique. Added, WP sites have quite oft also been a source of bloat in many ways - but one for sure is imgs. I’m in fact not surprised at this result - jaw dropping as it seems.
Just frequent your local WordCamps. They’re not all developers there. Lots of mom and pop shops/mommy blogger who’s last concern is page weight. Yup, a largely unscientific assessment on my part.
It looks like the median mobile byte sizes for different content types are very close, except for fonts (lower than desktop) and images (higher than desktop as @rviscomi mentioned above)
Given that the same amount of JS and CSS are being loaded to desktop and mobile, I believe @HenriHelvetica is right about download and hide on some popular wordpress templates being the likely culprit here.
btw - the query for the table comparing the byte sizes is here -
#standardSQL
SELECT
'desktop' AS client,
ROUND(APPROX_QUANTILES(bytesTotal, 1001)[OFFSET(501)] / 1024, 2) AS bytesTotal,
ROUND(APPROX_QUANTILES(bytesHtml, 1001)[OFFSET(501)] / 1024, 2) AS bytesHtml,
ROUND(APPROX_QUANTILES(bytesJS, 1001)[OFFSET(501)] / 1024, 2) AS bytesJS,
ROUND(APPROX_QUANTILES(bytesCSS, 1001)[OFFSET(501)] / 1024, 2) AS bytesCSS,
ROUND(APPROX_QUANTILES(bytesImg, 1001)[OFFSET(501)] / 1024, 2) AS bytesImg,
ROUND(APPROX_QUANTILES(bytesFlash, 1001)[OFFSET(501)] / 1024, 2) AS bytesFlash,
ROUND(APPROX_QUANTILES(bytesFont, 1001)[OFFSET(501)] / 1024, 2) AS bytesFont,
ROUND(APPROX_QUANTILES(bytesJson, 1001)[OFFSET(501)] / 1024, 2) AS bytesJson,
ROUND(APPROX_QUANTILES(bytesOther, 1001)[OFFSET(501)] / 1024, 2) AS bytesOther,
ROUND(APPROX_QUANTILES(bytesHtmlDoc, 1001)[OFFSET(501)] / 1024, 2) AS byteHtmlDoc
FROM `httparchive.summary_pages.2018_08_01_desktop` page
INNER JOIN `httparchive.technologies.2018_08_01_desktop` w
ON page.url = w.url
WHERE bytesTotal > 0 and app="WordPress"
GROUP BY client
UNION ALL
SELECT
'mobile' AS client,
ROUND(APPROX_QUANTILES(bytesTotal, 1001)[OFFSET(501)] / 1024, 2) AS bytesTotal,
ROUND(APPROX_QUANTILES(bytesHtml, 1001)[OFFSET(501)] / 1024, 2) AS bytesHtml,
ROUND(APPROX_QUANTILES(bytesJS, 1001)[OFFSET(501)] / 1024, 2) AS bytesJS,
ROUND(APPROX_QUANTILES(bytesCSS, 1001)[OFFSET(501)] / 1024, 2) AS bytesCSS,
ROUND(APPROX_QUANTILES(bytesImg, 1001)[OFFSET(501)] / 1024, 2) AS bytesImg,
ROUND(APPROX_QUANTILES(bytesFlash, 1001)[OFFSET(501)] / 1024, 2) AS bytesFlash,
ROUND(APPROX_QUANTILES(bytesFont, 1001)[OFFSET(501)] / 1024, 2) AS bytesFont,
ROUND(APPROX_QUANTILES(bytesJson, 1001)[OFFSET(501)] / 1024, 2) AS bytesJson,
ROUND(APPROX_QUANTILES(bytesOther, 1001)[OFFSET(501)] / 1024, 2) AS bytesOther,
ROUND(APPROX_QUANTILES(bytesHtmlDoc, 1001)[OFFSET(501)] / 1024, 2) AS byteHtmlDoc
FROM `httparchive.summary_pages.2018_08_01_mobile` page
INNER JOIN `httparchive.technologies.2018_08_01_mobile` w
ON page.url = w.url
WHERE bytesTotal > 0 and app="WordPress"
GROUP BY client
RWD will be a mess if it is applied only as a theme. As you say it’s popular on out-of-the-box systems like WordPress or Tumblr because users can just plug it in and they’re responsive. However, without proper server-side image optimisation (particularly serving WebP where possible) browsers will typically load all versions of an image. Add to this oodles of JS libraries that might be useful. But I’m not sure this tells us anything we don’t already know.