Christ, so much hatred.<p>I like the desktop site, I like the mobile site, and I like and appreciate that you're giving us an insight in to your tech stack and how content is published.<p>Cheers beeb.
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.<p>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)<p>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.<p>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.<p>A useful tool from google for analysing the site for both mobile and desktop: <a href="https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fm.bbc.co.uk%2F" rel="nofollow">https://developers.google.com/speed/pagespeed/insights/?url=...</a><p>and a good talk from last year's Google I/O conference on optimising the mobile experience: <a href="https://www.youtube.com/watch?v=WrA85a4ZIaM" rel="nofollow">https://www.youtube.com/watch?v=WrA85a4ZIaM</a>
I do love when companies share this stuff. Thanks.<p>> Rather than using PHP or Java (that was the requisite of the Forge platform), we have chosen a non-blocking framework, NodeJS with the Express framework . This allows us to serve more simultaneous requests, increasing the performance of the application.<p>I don't doubt this is true, but its worth noting you can get good performance out of a "blocking" framework too. Node.js does better than others in some situations, but in this its not a snowflake, and is in some regards worse.<p>But I will criticize priorities: I think this is too much fad, not enough practical. the experience is notably worse than the old site, and it seems like they just threw buzzwords at their problems instead of really crafting a solid solution.<p>I think where they're coming from, maybe this makes sense - they needed to overshoot from their previous platform. But I think they'll find it problematic in the long run and change some of their approaches and release a new site, and that will be a good platform and serve their needs for a good while.
There seems to be some kind of bird theme going on with their CSS classes.<p><pre><code> class="distinct-component-group container-buzzard"
class="distinct-component-group container-pigeon"
class="distinct-component-group container-macaw"
class="robin sparrow-container"
class="sparrow-container sparrow-columns"</code></pre>
Tons of tech buzzwords, yet the blog intercepts middle-clicks. I want to open your links in a new tab so I can read them when I'm done with your blog!
It's like they monitored the front-page of HN everyday for a year, made a list of the top mentioned technologies and then gave that list to their management.<p>Their manager said "Your goal is to write a blog post mentioning each one of these technologies, and add links so it appears in dark-bold-blue text. If we don't have a project using a trendy tech-stack... you bust your ass and get something up and running."<p>The engineers balked... "but why?"<p>Then the boss said, "I'm tired of being ignored in 'Who's Hiring' on Hacker News. We make this article and they'll all come begging us for jobs. At the BBC we don't wait for news to come to us, we make the news. And THAT'S what we call journalism kids."
This mentions using Node/Express to help with concurrency. Ok. But this also mentions using 'isomorphic' javascript with React, and also not completely reliant on cache. React.renderToString (and all other isomorphic options -- Rendr, etc) are synchronous and slow. (rendering a large page in React w/ static data would take ~600ms; whereas the same page with with Mustache in Go for example would take ~30ms). End result, decreasing concurrency, and hurting overall performance.<p>OP - can you shed any light on how this is actually impacting your performance? Or maybe things that you had to do to get around the problem (ex - details of 'module level' cache with Redis etc).
I have not yet tested the new mobile site, but if the design of the normal site is anything to go by it will have been designed in hell by some teen demon reading too much Kafka.
Most of their tests take half a second each to run? Some examples:
"The first story displays an image and not an alt text attr if one is defined. (793ms)"
"The module banner color is BBC News Red (552ms)"<p>The 13 tests shown in the screenshot take an average of 577ms each, a total of over 7.5 seconds. 13 simple tests with wild variance in execution time. Checking a module <i>banner</i> color? 42ms. Checking a module <i>background</i> color? 552ms. So a 12x increase for checking a different color within a module?<p>Those tests are going to rot because of the expense of executing them and they'll be discarded. Over a 500ms average per test just isn't sustainable, particularly at the scale required for checking every conceivable kind of background color.
They mention using BEM (<a href="https://bem.info/" rel="nofollow">https://bem.info/</a>) Any idea what it is? The site is not at all clear.
The BBC produce quite a few intereting write ups of their R&D process alongside odd things they are hacking on here: <a href="http://www.bbc.co.uk/rd" rel="nofollow">http://www.bbc.co.uk/rd</a><p>Well worth a read.
Home page displays a bunch of javascript before rendering the rest of the page. Doesn't happen all the time though.Maybe you guys might want to look into that.
It nice to know what is happening in the BBC and the tech they are using. Additionally, It is appreciated they spend the time writing up what they have done/achieved.<p>Rock on!
Actually it doesn't look too bad. Its similar enough to the old one it doesn't seem like when Facebook upgrades and you feel lost. Shame the quality reporting has gone down so much over the years.
The new "BBC News (Beta)" website is bloody ugly. They've gone for a "flat UI" thing, but it looks so clumsy that it reminds me of the internet from before people used gradients.