Hmm. While it's nice to push rendering out to clients for saving your server CPU, that can lead to a suboptimal mobile experience, requiring more CPU and battery power on the mobile device to work on the javascript and render the page. There are other factors, for sure, but you want to be keeping client side javascript down to a minimum.
Taking a quick spin through yslow in the mobile browser suggests they've got a number of areas to improve on to make the time to screen significantly better on mobile devices (even on a fast connection here it took several seconds to even start showing me content, and several more before it had finally loaded everything)
Given the world wide reach of the BBC, expecting high speed and low latency networks seems like a bad idea. In the US, 3G & 4G typically see 90-100ms latency per request. Mobile Yslow is reporting that they've got 21 javascript scripts alone on the page. IIRC The android browser will limit itself to 4 threads retrieving content typically so that's (21/4 * 100ms) 525ms just lost in latency requesting the javascript, let alone actually downloading it and the overhead of the javascript renderer. It's also pulling in content from 21 different websites, so at the bare minimum that's 21 DNS calls being made (with the same latency penalty!) A bunch of those are being done just to load a single piece of content too, which is a little crazy.
Don't get me wrong, the site looks good.. it's just for a 'mobile-first' experience, they seem to be missing the all important time-to-screen and giving the mobile user a lot of work to do.
There's definitely plenty of room to optimize the time-to-first-render – in particular, switching to an async model would make a huge win since rendering is currently blocked by 6 stylesheets and 7 JavaScript files, most of which appear to be specific to certain content sections.
Hmm. While it's nice to push rendering out to clients for saving your server CPU, that can lead to a suboptimal mobile experience, requiring more CPU and battery power on the mobile device to work on the javascript and render the page.
How true is that though? Given that native apps render client-side too. In a much more optimized, device-specific fasion, I admit, but still - that too is client-side rendering.
Plus this is the only time I've ever seen "mobile first" interpreted quite so literally (i.e. on a desktop with a reasonable connection the mobile stylesheet loads before the main styles and content and is visible for just long enough for the eyes to register the layout, producing a horrible "flash of unstyled content" effect).
n.b. plenty of people looking at the BBC site are still being shown the old style.
The main sites from my last job load the mobile view/content first, then load in the desktop experience as appropriate (some are still in the process of transitioning to the newer design). However they were done in such a way that it shouldn't result in any jarring transitions. A couple of examples:
I've been wondering about that unstyled "flash" on BBC myself and whether it's just down to some chrome extension or something I had installed interfering with things. Glad to hear it's not just me.
Totally agree that it's not ideal to push rendering out to clients -- and this article specifically says they're using React.js and rendering the pages server-side, so they are sending a rendered page to the client (along with the js code to perform further front-end behavior if js is enabled, but content is still there without js).
Taking a quick spin through yslow in the mobile browser suggests they've got a number of areas to improve on to make the time to screen significantly better on mobile devices (even on a fast connection here it took several seconds to even start showing me content, and several more before it had finally loaded everything)
Given the world wide reach of the BBC, expecting high speed and low latency networks seems like a bad idea. In the US, 3G & 4G typically see 90-100ms latency per request. Mobile Yslow is reporting that they've got 21 javascript scripts alone on the page. IIRC The android browser will limit itself to 4 threads retrieving content typically so that's (21/4 * 100ms) 525ms just lost in latency requesting the javascript, let alone actually downloading it and the overhead of the javascript renderer. It's also pulling in content from 21 different websites, so at the bare minimum that's 21 DNS calls being made (with the same latency penalty!) A bunch of those are being done just to load a single piece of content too, which is a little crazy.
Don't get me wrong, the site looks good.. it's just for a 'mobile-first' experience, they seem to be missing the all important time-to-screen and giving the mobile user a lot of work to do.
A useful tool from google for analysing the site for both mobile and desktop: https://developers.google.com/speed/pagespeed/insights/?url=...
and a good talk from last year's Google I/O conference on optimising the mobile experience: https://www.youtube.com/watch?v=WrA85a4ZIaM