Everyone blames bloated web pages on the browser

by Ashley Gullen | 12th, April 2017

Recently I read this critique of Slack's desktop app, which is built with Electron (basically a Chromium-based wrapper like NW.js). In other words, it's a browser engine plus the app.

The author notes the Slack app using 5% CPU while idle (much more in some cases), and between 300mb-1GB RAM. They wonder what on earth must be happening. And who gets the blame?

"And chrome is a hog. Its huge and complicated. It uses ram and CPU like nobody's business, and it totally thrashes your battery life."

As a comparison, I thought I'd run Construct 3 — an entire game development IDE we recently released — and open one of the demo projects (Space Blaster), and see how it compares to the author's numbers for Slack, an instant messaging client. We've engineered Construct 3 to be as efficient and lightweight as possible, given the scope of the app.

According to my measurements, Construct 3 with a whole game project opened and showing, uses about 290mb RAM and left idle the CPU remains a satisfyingly dead 0%. By the way I tested with a 4K display, so that includes hi-res graphics, including a full WebGL 2 context.

Then there's the TechCrunch homepage uses over 500mb RAM and the CPU on my 8-thread machine idles at around 15-20% audibly spinning up my laptop's fans as it tries to cope with multiple simultaneous video streams. So we built an entire game development IDE that is far less demanding than a typical web page.

Typical web content is incredibly bloated and inefficient. Rather than blame the bloated web content, everyone seems to blame the browser instead. Even technical people do this, as the blog post in question was very highly voted on the programmer-centric Hacker News.

One of our goals in developing Construct 3 was to show what's possible when web content is done right. In fact it can start up with just 1mb of content download — half the size of the average website today, and a fraction of the 60mb download for the full installer of our previous native desktop app. It's obviously not the browsers that are that inefficient. It's the bloated web content. Unfortunately everyone blames the browser for doing what it was told by the developer. It's like blaming Windows if iTunes is slow and uses a lot of memory. Why blame the platform for a poor application?

The author also bemoans the size on disk and inefficiency of running multiple browser instances. Well then, don't. Just run it in the browser. You're already running a browser to read this. Slack has a web interface. It won't necessarily be any more efficient if it's the same content, but you can use it literally right now with your existing, pre-downloaded browser engine. That's our solution with Construct 3 as well: it's a Progressive Web App (PWA) that can do almost everything without needing to be downloaded. You can even use the "Add to homescreen" or "Add to desktop" option in Chrome to get an app-like experience, without any extra download at all. Our goal is to do the maximum possible to make a downloaded app redundant.

In the past, web pages were "just" documents, which are intuitively lightweight in computing terms. However we really have reached the point where a typical web page is far more demanding than even a large and complex productivity app. This is the reverse of the intuition; now web pages are heavyweight media-intense interactive experiences, and an app can be significantly more lightweight. I think the tech community hasn't caught up with this new reality. Maybe that's why people blame the browser: we just can't quite believe this really has happened, that a modern document could be more demanding than a full IDE.

So we should stop blaming bloated pages on the browser. Chrome is an incredibly well-engineered browser, and no, you don't have to download copies of it. It's the web content that's the problem. And that can be made very efficiently too. We should probably focus on that instead.

Now follow us and share this

Comments

1
saiyadjin 9,297 rep

interesting @Ashley - when i tried the TechCrunch in Opera - the tab used ~150mb and 0.7% - 1% of processor (measured by Process explorer)
I think the problem might be that Chrome as a browser is horrid, as the badly made interface and usage of the underlying Chromium engine is made worse then for example as it is in Opera. Opera also uses Chromium but i guess the UI over it is way better done and doesn't eat up as much.

though this might be the case:
www.opera.com/blogs/desktop/2016/07/memory-usage-opera-heap-compaction/

since both Opera and Chrome use Blink, they added some compression on top of it..

when they released last version (44) a few weeks ago this was in release notes:
"Opera 44 features our own tuned-up version of Chromium 57. This adds support for CSS Grid Layout and WebAssembly which we believe has the potential to bring browser games to the next level."

Wednesday, April 12, 2017 at 12:12:35 PM
1
tutbarao 12.8k rep

You're right.
I agree.

Wednesday, April 12, 2017 at 12:15:19 PM
1
iceangel 31.9k rep

Thanks @Ashley

Wednesday, April 12, 2017 at 12:29:33 PM
3
Ashley 189.2k rep

@saiyadjin - Opera and Chrome share the same browser engine. I think you missed the point of the whole post as well. Chrome is not a horrid browser, it's the content it runs.

Wednesday, April 12, 2017 at 12:44:29 PM
1
jobel 14.5k rep

I think this points at a good common sense approach to any type of dev. Understanding your resources, understanding the architecture behind it and ways you can conserve. In the 90s I worked on a mainframe passing huge databases that would take 3 days to complete. I had to write low level code to optimize performance or it meant the process would take longer to run and time was money to the client. We had to scrutinize every line of code to make sure it was the most efficient way to accomplish our task. I see no difference in gamedev or app dev.

Wednesday, April 12, 2017 at 3:03:19 PM
3
saiyadjin 9,297 rep

@Ashley - no you missed my point. They use the same browser engine - Chromium, but Opera team does additional optimisations and some features that Chrome doesn't have. What i meant by horrid on Chrome is that the GUI/UI/Desktop app that wrapps the Chromium is horrid, compared to Opera (which is also a wrapper around Chromium).

And yes, I agree with your initial post that sites are unoptimized and bloated, but browsers could do better as Opera does by adding some of their own optimizations, check the link in my first post. (And i'm not saying that Chrome is bad, just that it could be even better).

Wednesday, April 12, 2017 at 3:51:59 PM
0
Ashley 189.2k rep

@saiyadjin - my whole point is we should focus on the inefficiency of the content, not the browser. You've immediately started talking about the browser, which is the whole problem this blog post is talking about.

Wednesday, April 12, 2017 at 4:57:43 PM
1
pxzin 1,912 rep

@Ashley - Yeah, I agree with you. I think most of the developers working with progressive web apps came from a reality of frontend dev, living the dream of HTML5 and CSS3 solving major problems after the IE death. They get slob, addicted to heavy-weight frameworks and we come to this point.
The easiest solution? Blame chrome!

Wednesday, April 12, 2017 at 5:56:18 PM
1
Noman Khan 464 rep

Really Thanks @Ashley

Wednesday, April 12, 2017 at 6:10:33 PM
2
oosyrag 60.1k rep

Enjoy your blogs as always.

Unfortunately I think this is a very basic logical conclusion that is made regardless of the reasoning, that as you mentioned even technical people reach (possibly even more so).

"A browser is made for and does more than what I want or need it to do, therefore there must be unnecessary overhead for my specific application."

There is a reason for that overhead, but people don't get that far in their reasoning before making their conclusion. Take away the browser, and you're left with an operating system... If people experience the pain of coding and compiling for multiple operating systems, they might feel differently. The whole point of utilizing HTML5 is to take advantage of all the built in capabilities. People who haven't worked with needing to find and integrate all the libraries they need don't have a point of reference for the marginal benefits vs the marginal costs.

Then on the flip side there are the experienced coders who think they can trim off all the extra stuff they don't need and be left with a more "pure" *coughnativecough* end product that runs x amount more efficiently. But how significant is that "x" compared to what is gained? For those who have the ability to do so, do it (without Construct, or in another dev environment). If not... then they can decide at that point if they are willing to give up a little performance for the ability to create a finished product at all.

And that brings us back to the blog post. Do people actually have a metric for measuring performance of a native versus web app or are they just making assumptions based on their own preconceptions? Why not spend all the effort and frustration from complaining about how something we have no control over limiting our performance when we can just work on improving our own work?

Wednesday, April 12, 2017 at 6:47:48 PM
1
Alberto Roman 376 rep

Ashley when are you gonna make an exporter plugin for the NintendoSwitch >>> We need that !!!

Wednesday, April 12, 2017 at 7:09:29 PM
1
vtrix 9,718 rep

To critique, you have to compare apples to apples, to compare browsers you have to run the same content in different browsers as of yet c3 to me is more a chrome app then a webapp.

And when the same content runs smoother in another browser? Yes.. why? ...

my daily driver is chrome, but from a certain level of pc, it doesn't really matters,
but slower devices tends to heat up faster on chrome therefore...

Websites have different goals, marketing sites, blogs, all have different goals an will run smoother depending on it and other factors like the amount of optimization & hosting,
The difference between ssd hosting and regular is astonishing and makes the size of a page more about traffic-cost then anything else.

That all said, c3 runs very smooth, as smooth as any native program, but on tablet, bigger levelscenes (scene navigation) tend to run slow from my first tests. which might have to be further optimized depending on hardware.

Wednesday, April 12, 2017 at 10:52:23 PM
1
saiyadjin 9,297 rep

@Ashley - i never said that I don't agree with you :) sites tend to be mega slow and horrid, whereas browsers are really great today.
When you wrote 500MB and 20% cpu usage i went to test it out in opera and chrome just to see if it was real..

so here's what I just measured -> Opened chrome with 1 tab and web site techcrunch.com, did the same with Opera:

Chrome - > total memory - 653MB / 0.1% CPU, Respective tab - 300MB, 0.07%
Opera -> total memory -735 MB /0.7% CPU, respective tab - 150MB, 0.7% CPU

now opera does have more features than Chrome (as an app) therefore all together the memory usage is higher then Chrome, but on the respective tab's process it has way less. (Not sure about the CPU though, must be that video playing)

if you want me to measure more stuff PM me, I like benchmarking stuff :)

Thursday, April 13, 2017 at 11:10:11 AM
1
Lordshiva1948 39.0k rep

interesting Ashley my boy thanks

Thursday, April 13, 2017 at 4:39:05 PM

Leave a comment

Everyone is welcome to leave their thoughts! Register a new account or login.