Chrome Never-Slow Mode Prototype

https://chromium-review.googlesource.com/c/chromium/src/+/1265506

by jupp0r • 7 years ago

96 71 7 years ago

chromium-review.googlesource.com

tyingq4• 7 years ago

I wonder if they ran it against Google properities first. I imagine Gmail wouldn't fare well.

xiphias22• 7 years ago

These settings look like something that's great for mobile phones. On mobile there's native GMail app, so this isn't a problem.

josteink2• 7 years ago

But I prefer webpages over apps. Especially on mobile.

The apps frensy was over years ago. Nobody wants an app anymore.

sjjshzvuiajhz• 7 years ago

I don’t think so - the owner of this issue is the tech lead of Progressive Web Apps at Google according to his LinkedIn. He probably envisions a future where GMail can run as a web app on a mobile phone with zero lag. Combined with previous additions to web APIs such as notifications, GMail the web app can be at parity with GMail the native app.

tyingq4• 7 years ago

Following up my own comment...looks like current Gmail will have trouble. Loaded in chrome with mobile set to "Pixel 2", and there's one js file that not only blows the per-script max size, but blows the whole "Total Script Budget" by itself, not including the other 78 js files gmail wants to download. Stopped looking there.

(Per-script max size: 50KiB, Total script budget: 500KiB)

amelius• 7 years ago

Sounds like something they should have done ages ago.

neurobashing• 7 years ago

WebKit also wanted to do something like this: https://bugs.webkit.org/show_bug.cgi?id=194028

akyuu• 7 years ago

It's probably in Google's interest to limit web bloat that degrades UX. AMP might be one strategy (with many negative aspects that many here will be familiar with), leveraging Chrome's browser share to impose limits might be another one.

Also reminds me on https://news.ycombinator.com/item?id=19038092 . I wonder if in the future we'll look at excessive JS bloat as we look at annoying pop-ups today.

ccnafr• 7 years ago

The two are related. Work on Never Slow Mode stopped last fall. It picked up after the WebKit/Safari discussions last week. I doubt Chrome will ship a "never slow mode" but I see looser budgets, a la WebKit proposal.

magicalist• 7 years ago

It picked up after the WebKit/Safari discussions last week

looks like it picked up on Jan 3 according to that PR?

slightlyoff3• 7 years ago

Hi, author of the NSM patch. Still very much under development, but most of the important considerations aren't technical, and making progress on a system like this is more about how to roll things out rather than implementation.

It's great to seeing WebKit folks thinking along the same lines, and I hope to be able to discuss with them. Coalitions -- like the Mozilla/Chrome work on TLS adoption -- are critical in making progress in large ecosystems.

Someone1234• 7 years ago

That's really cool. The only thing missing is the total number of DOM elements on a page. I've seen production sites with literally thousands, and it slows most browsers to a crawl (and balloons memory).

rifung• 7 years ago

If the issue of too many DOM elements is memory use, wouldn't it be better to just limit the memory use of a page?

Apologies if this is a really ignorant question as I know very little about browsers/front end development.

TomMarius• 7 years ago

There are legit uses of RAM, fully fledged web apps are ordinary now

developit• 7 years ago

It's more than memory use - it causes tree traversals to take longer, which means unbounded style recalculations (common) and side-effecting DOM changes take longer.

ummonk• 7 years ago

Thousands isn’t really a whole lot. If you have say a table with 10 columns and 50 rows and have complex content in the cells (including div elements) you’ll be well into the thousands.

recursive• 7 years ago

This comments page has over 1194 elements on it right now, with only 34 comments. Thousands is peanuts.

gfwhuuku• 7 years ago

Chrome is already much faster than Firefox, with stuff like this they'll wipe the floor with the competition.

zelon88• 7 years ago

Don't count on it. If they continue with policies like single-sign-on the privacy-centric crowd will flee, followed by mainstream users. It's happened before and no empire has ever lasted an eternity.

tyingq4• 7 years ago

Chrome is about ready to hobble ad blockers[1]. So soon, Firefox will be faster for many sites with ads.

[1] https://www.bleepingcomputer.com/news/security/chrome-extens...

microcolonel• 7 years ago

Chromium still being the better browser in most ways, I wonder what could be done about this. Maybe it's time to have a simple patchset for doing content blocking natively in the engine. With patches like that floating around, they can't very well say that it's an efficiency issue like they do in the doc describing Manifest V3.

vorpalhex• 7 years ago

That's only a proposal and it was put out to get community feedback (which was overwhelmingly negative...)

staticassertion• 7 years ago

Firefox isn't exactly stagnating - Servo has a lot of promise for performance.

alexdumitru• 7 years ago

Chrome feels way slower than Firefox and the only reason keeping me from making the jump to Firefox is laziness. I'm too lazy to find alternatives for all my extensions, move bookmarks, history, passwords etc, but Firefox feels way faster.

alexkavon• 7 years ago

all my extensions, move bookmarks, history, passwords etc

Minus the extensions, migrating everything else should be easily accomplished via importing and should only be a few clicks in a wizard.[0]

[0] https://support.mozilla.org/en-US/kb/import-bookmarks-google...

dzek69• 7 years ago

If you're comparing daily use browser tag includes a lot of extensions with another browser that's empty - the latter will won.

Then you start moving your stuff, you install extensions and while fighting with your habits from old browser ux you collect history, cookies and all that stuff.

Then some time passes and you're looking back at your old browser, now with cleaned profile, so shiny and fast :)

rb666• 7 years ago

Chrome feels slower to me, plus speed is not the #1 concern is it now? Firefox.

burtonator• 7 years ago

It would be cool to get some of this stuff in Electron but I think in that case it's actually possible to just do this in your app yourself.

I've been heads down on Chromium + Electron performance with my app around a personal knowledge repository:

https://getpolarized.io/

Electron has been great for this but it can be slow.

We have to render PDF and HTML documents for annotation and this part can get overwhelmed if I lock up the main thread.

We still have a lot of work to go with threads and web workers to make this stuff easier I think. It's possible to do but it's definitely not easy.

irq• 7 years ago

Your product looks amazing but I see no use of encryption with the cloud sync? Unfortunately that's a dealbreaker for me :(

azinman2• 7 years ago

From the product description doesn't look like the main use case... it seems more for academics?

gok• 7 years ago

I'd like to see a 5x reduction in those limits but awesome idea.

penagwin• 7 years ago

5x reduction? Heck, you'd struggle to find common libraries that fit under those existing limits! jQuery is 88kb (Yes everyone can hate on jquery all you want, but it's still commonly used), which is already over the 50kb limit! At 10kb...

Modern camera's take pictures measured in megabytes, and you're suggesting the per image max be 200kb, and total images to be 400kb?! Two crappy quality images would blow that out of the water (Heck a single crappy image could).

I get that this is a prototype, and seems to be intended for mobile devices, etc. But those limits are already something you'd have to work for, I'd argue it's near impossible at 5x less resources.

tl;dr by todays standards a 5x reduction in those limits is just code golf.

slightlyoff3• 7 years ago

Author of the patch here. Note that the limits are wire size, not disk size. jQuery, post gzip, is closer to ~30KiB, meaning it fits nicely under the per-file restriction. The total JS limit per-interaction is 500KiB gzipped. Uncompressed, that's often more than 3MiB. That's a whole lotta code!

The per-image limit is currently set at 1MiB (not 200KiB).

Hope that helps.

tanilama4• 7 years ago

Per-script max size: 50KiB

That is quite small actually... My application (internal use, not consumer facing, so no panic) has a single packed script file, that is around 100KB.

Gaelan• 7 years ago

I imagine they’re trying to encourage code splitting.

tanilama4• 7 years ago

Which is what popular setup like create-react-app and alikes are against. It doesn't make too much sense for more heavy application like interactive editors to have multiple artificially split files just to conform with this limit.

josephg• 7 years ago

That’s transfer (compressed with gzip or whatever) size. So its a bit more than it sounds; but yeah - still tiny.

If this is the future, I know a lot of web apps that will need retooling. That is just enough space for react (+react-dom). We’ll have to split up react and web apps themselves in future apps if chrome goes this route; although I suppose that’s marginally better for caching performance.

rakoo• 7 years ago

"Caps do not apply to workers". I have a limited understanding of them but I understand that if your scripts are fat then you have something closer to an application than a document, and it would be better served with service workers that can run in the background and keep most of your application structure in place ?

ijpoijpoihpiuoh• 7 years ago

Workers impose non-trivial architectural overheads vs. ordinary scripts. It's not at all a drop-in replacement for ordinary scripts.

tanilama4• 7 years ago

Workers works pretty differently than regular script. The way it is being loaded, how to import other scripts into worker and have it communicate with your main thread (window) is quite a standard on its own, it is just that it happens to use javascript as its language.

mfer• 7 years ago

A per-script max size of 50 KiB isn't realistic in the wild today.

For example, non-minified bootstrap.js is more than that. Just as a data point.

This will break a bunch of the web. I'll be curious to see how this gets worked out as the work progresses.

Sammi2• 7 years ago

And moment.js is 68 and luxon 64.

slightlyoff3• 7 years ago

Hey, author of the patch here.

The restrictions are wire size. `bootstrap.min.js` is ~10KiB on the wire, which means it comfortably fits (as do jQuery, most analytics packages, etc.).

That said, the prototype does break a lot of the web, but that's not a crisis. The intent isn't to have this rolled out everywhere against unwitting content, but rather (like TLS), to let developers opt-in to a single set of rules when they see value. There are also places (e.g. PWAs) where the browser-imposed quality bar needs to be high. Blocking PWA install for sites that don't send the opt-in header seems like a reasonable place to start.

chirau• 7 years ago

So how do i install this?

lowonkarma• 7 years ago

So the plan is to break the internet or get rid of all rich apps and just use the browser for crappy static pages?

ThePhysicist• 7 years ago

One thing that always surprises me with Chrome (and other browsers) is how easy it is to get a browser tab to freeze by running an infinite loop in JS. This happens to me from time to time due to programming errors and I usually have to close the entire browser to fix it, as the tab will neither close nor will I be able to access the developer console to turn the script off. That probably means the script runs in the same thread as the render/UI code for a given tab? Anyway I found this quite annoying and I wondered why the browser behaves like this (I’m sure there’s a good technical reason as other people must have encountered the same problem so if this was easily fixable someone would’ve probably already fixed it).

georgemcbay• 7 years ago

A similar thing that surprises me is how malicious ad networks are still able to effectively get your Chrome tabs into states where you can't easily close them without killing the entire chrome task.

While I'm sure there is a lot of complexity there that I'm not considering to avoid messing with legitimate usages of tab closing event handling by real apps, it would be nice if there were some kind of like alternate tab close input (eg. hold ALT or SHIFT, or both while clicking the tab 'X') where the user is signalling the intent that "yes, I absolutely want to close this tab, no matter what, kill it with extreme prejudice".

If such a thing exists, which it might, someone please correct me by telling me what it is.

palimpsests2• 7 years ago

You can kill this tab without closing the browser by using 'end process' in Chrome's Task Manager (available under the Window menu).

kartickv3• 7 years ago

But that's unintuitive. Why can't you click the X button on the tab to close it? That's browser UI, not web page UI, so it should never be unresponsive.

underwater• 7 years ago

This approach to web performance smacks of someone who has never had to build an app under real world conditions. "It will be smaller if you rewrite your app to be AMP-first. No, scrap that, the PRPL pattern is in, we'll hold the PWA rewrite for next week" are not viable solutions for engineers at companies that aren't Google.

Try telling your marketing department that they can't integrate third party scripts through Google Tag Manager, or a VP that the SDK for that third party service they championed is too large and the project will have to be shelved. Or put a pause on a critical project because the application is approaching the hardcoded JS limit and another department shipped before you did.

Hardcoded limits are the first tool most people reach for, but they fall apart completely when you have multiple teams working on a product, and when real world deadlines kick in. It's like the corporate IT approach to solving problems — people can't break things if you lock everything down. But you will make them miserable and stop them doing their job.

stupidcar• 7 years ago

Firstly: Too bad. The dysfunctional practices of corporate software development doesn't override people's right not to have their own computer's performance trashed by shitty websites. It's their right to run whatever browser they like, including one that doesn't allow slow, bloated and poorly engineered software to run, no matter how hard it makes life for the marketing departments of the world.

Secondly: For decades computers operated with extreme limits on their available memory and their processing capacity, relative to today's computers. Despite this, people managed to write software, even including companies with marketing departments and idiot VPs. It might take these people a while to accept that they can no insist on pushing whatever garbage they want, because the cost is borne entirely by the end user, but eventually they will. Or they won't, and these dysfunctional companies will die out. Either way, users win.

Chrome Never-Slow Mode Prototype

Related Stories