
Chrome Never-Slow Mode Prototype - jupp0r
https://chromium-review.googlesource.com/c/chromium/src/+/1265506
======
burtonator
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/](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
Your product looks amazing but I see no use of encryption with the cloud sync?
Unfortunately that's a dealbreaker for me :(

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

------
akyuu
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](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
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.

~~~
slightlyoff
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.

~~~
daxterspeed
Is there preliminary plan of how Never-Slow Mode would be deployed? I assume
the idea is to eventually have it enabled by default on all mobile devices and
to prompt laptop/desktop users to enable it if they have a slow connection?

------
underwater
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
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.

------
tanilama
> 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.

~~~
mfer
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.

~~~
Sammi
And moment.js is 68 and luxon 64.

~~~
TheCoelacanth
Moment.js is 16.7k. Moment.js plus locale data for every single locale in the
world is 68k. There is no justifiable reason to ever load every single locale
in the world at once except for a few extremely niche cases. Real world use
cases typically need one locale at a time, occasionally two or three, never
hundreds.

Luxon, I believe, is a similar story.

~~~
Sammi
The whole reason I use a date formatting library is so that I can localize
dates into whatever locale the user is on. I can't just assume one locale and
only load that.

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

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

~~~
josteink
But I prefer webpages over apps. Especially on mobile.

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

~~~
grandmczeb
> Nobody wants an app anymore.

News to me. You sure you’re not just projecting your personal preference?

~~~
josteink
It’s clearly my personal preference, but also my experience that fewer and
fewer in my social circles wants “yet another app” when there’s already a
website which works fine. Games are the only exception.

And I work with software. None of my colleagues wants to work with or test
anything not _strictly_ web-based.

~~~
grandmczeb
> None of my colleagues wants to work with or test anything not strictly web-
> based.

If that's true, I'd be willing to bet there's some extreme self-selection
going on. Which is fine, but I'd be very careful about generalizing your
experience outside of your immediate social circle.

------
neurobashing
WebKit also wanted to do something like this:
[https://bugs.webkit.org/show_bug.cgi?id=194028](https://bugs.webkit.org/show_bug.cgi?id=194028)

------
Someone1234
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
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.

~~~
developit
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.

------
ThePhysicist
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).

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

~~~
kartickv
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.

~~~
palimpsests
I was responding to the parent comment with a way to kill the tab without
quitting the browser, that's all.

I didn't make this feature; I don't have the answer to your question. It was
intuitive enough for me to find it on my own without reading any
documentation. So, shrug.

~~~
kartickv
I wasn't criticising you, just asking the more general question here of why
clicking the close button doesn't work reliably.

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

------
chirau
So how do i install this?

------
amelius
Sounds like something they should have done ages ago.

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

~~~
tyingq
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...](https://www.bleepingcomputer.com/news/security/chrome-extension-
manifest-v3-may-break-ublock-origin-content-blocker/)

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

~~~
tyingq
There's an open issue[1] with people assigned to it. And even documentation
for the new hobbled API that is available in both the beta and dev
channels[2].

Feels a bit past being a proposal.

[1]
[https://bugs.chromium.org/p/chromium/issues/detail?id=896897](https://bugs.chromium.org/p/chromium/issues/detail?id=896897)

[2]
[https://developers.chrome.com/extensions/declarativeNetReque...](https://developers.chrome.com/extensions/declarativeNetRequest)

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

~~~
penagwin
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.

~~~
slightlyoff
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.

