30 ms·

Chrome Never-Slow Mode Prototype

96 points by jupp0r 8y ago

tyingq 8y ago
I wonder if they ran it against Google properities first. I imagine Gmail wouldn't fare well.
- xiphias2 8y 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.
  - josteink 8y ago
    But I prefer webpages over apps. Especially on mobile. The apps frensy was over years ago. Nobody wants an app anymore.
    - what_ever 8y ago
      > Nobody wants an app anymore. Citations needed. I, for one, like apps.
    - grandmczeb 8y ago
      > Nobody wants an app anymore. News to me. You sure you’re not just projecting your personal preference?
      - josteink 8y ago
        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 8y ago
        > 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.
    - criddell 8y ago
      For anything I use regularly, I'll choose a native app over a web site or web app every time because they typically consume less battery, cpu, memory, and bandwidth. They are usually also faster and a well written app is always going to feel better than one running in a web browser.
    - bassman9000 8y ago
      Haven't heard that to anyone in my professional circles and, yes, we all work in software. Anything worth it is native.
  - sjjshzvuiajhz 8y 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.
    - xiphias2 8y ago
      That's cool, I have nothing against improving the experience of any site :)
- tyingq 8y 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)
underwater 8y 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 8y 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.
amelius 8y ago
Sounds like something they should have done ages ago.
neurobashing 8y ago
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
akyuu 8y 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 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 8y 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 8y ago
    > It picked up after the WebKit/Safari discussions last week looks like it picked up on Jan 3 according to that PR?
  - slightlyoff 8y 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.
    - daxterspeed 8y ago
      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?
Someone1234 8y 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 8y 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 8y ago
    There are legit uses of RAM, fully fledged web apps are ordinary now
  - developit 8y 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 8y 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 8y ago
  This comments page has over 1194 elements on it right now, with only 34 comments. Thousands is peanuts.
gfwhuuku 8y ago
Chrome is already much faster than Firefox, with stuff like this they'll wipe the floor with the competition.
- zelon88 8y 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.
- tyingq 8y 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-extension-manifest-v3-may-break-ublock-origin-content-blocker/ https://www.bleepingcomputer.com/news/security/chrome-extens...
  - microcolonel 8y 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 8y ago
    That's only a proposal and it was put out to get community feedback (which was overwhelmingly negative...)
    - tyingq 8y ago
      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/declarativeNetRequest https://developers.chrome.com/extensions/declarativeNetReque...
burtonator 8y 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/ 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 8y ago
  Your product looks amazing but I see no use of encryption with the cloud sync? Unfortunately that's a dealbreaker for me :(
  - azinman2 8y ago
    From the product description doesn't look like the main use case... it seems more for academics?
gok 8y ago
I'd like to see a 5x reduction in those limits but awesome idea.
- penagwin 8y 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.
  - slightlyoff 8y 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.
- deleted 8y ago
  [deleted]
tanilama 8y 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 8y ago
  I imagine they’re trying to encourage code splitting.
  - tanilama 8y 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.
    - tadfisher 8y ago
      On the other hand, with advancements such as HTTP/2, there's not a substantial reason to pack multiple scripts.
      - jimrandomh 8y ago
        The main reason you pack scripts is because you're compiling, and your compiler is checking and optimizing your cross-file interactions. For example, you need to merge scripts to be able to detect and delete unused functions, because otherwise some unmerged script might call the function without the compiler being able to detect it.
        setr 8y ago
        It seems like it would be trivial for your compiler to go ahead and split the files up again afterwards. Its not like you cared about file organization on the client side anyways if you were packing them, so its free to split however it feels. And ofc you’d naturally just attribute this as an artifact of optimization, just as single-file packing was. Which it is, given http 2/3
chirau 8y ago
So how do i install this?
lowonkarma 8y 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 8y 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 8y 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.
- palimpsests 8y ago
  You can kill this tab without closing the browser by using 'end process' in Chrome's Task Manager (available under the Window menu).
  - kartickv 8y 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.
    - palimpsests 8y ago

96 points by jupp0r 8y ago

tyingq 8y ago

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

xiphias2 8y 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.
- josteink 8y ago
  But I prefer webpages over apps. Especially on mobile. The apps frensy was over years ago. Nobody wants an app anymore.
  - what_ever 8y ago
    > Nobody wants an app anymore. Citations needed. I, for one, like apps.
  - grandmczeb 8y ago
    > Nobody wants an app anymore. News to me. You sure you’re not just projecting your personal preference?
    - josteink 8y ago
      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 8y ago
        > 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.
  - criddell 8y ago
    For anything I use regularly, I'll choose a native app over a web site or web app every time because they typically consume less battery, cpu, memory, and bandwidth. They are usually also faster and a well written app is always going to feel better than one running in a web browser.
  - bassman9000 8y ago
    Haven't heard that to anyone in my professional circles and, yes, we all work in software. Anything worth it is native.
- sjjshzvuiajhz 8y 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.
  - xiphias2 8y ago
    That's cool, I have nothing against improving the experience of any site :)
tyingq 8y 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)

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

amelius 8y ago

Sounds like something they should have done ages ago.

neurobashing 8y ago

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

akyuu 8y 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 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 8y 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 8y ago
  > It picked up after the WebKit/Safari discussions last week looks like it picked up on Jan 3 according to that PR?
- slightlyoff 8y 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.
  - daxterspeed 8y ago
    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?

Someone1234 8y 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 8y 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 8y ago
  There are legit uses of RAM, fully fledged web apps are ordinary now
- developit 8y 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 8y 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 8y ago
This comments page has over 1194 elements on it right now, with only 34 comments. Thousands is peanuts.

gfwhuuku 8y ago

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

zelon88 8y 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.
tyingq 8y 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-extension-manifest-v3-may-break-ublock-origin-content-blocker/ https://www.bleepingcomputer.com/news/security/chrome-extens...
- microcolonel 8y 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 8y ago
  That's only a proposal and it was put out to get community feedback (which was overwhelmingly negative...)
  - tyingq 8y ago
    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/declarativeNetRequest https://developers.chrome.com/extensions/declarativeNetReque...

burtonator 8y 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/ 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 8y ago
Your product looks amazing but I see no use of encryption with the cloud sync? Unfortunately that's a dealbreaker for me :(
- azinman2 8y ago
  From the product description doesn't look like the main use case... it seems more for academics?

gok 8y ago

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

penagwin 8y 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.
- slightlyoff 8y 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.
deleted 8y ago
[deleted]

tanilama 8y 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 8y ago
I imagine they’re trying to encourage code splitting.
- tanilama 8y 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.
  - tadfisher 8y ago
    On the other hand, with advancements such as HTTP/2, there's not a substantial reason to pack multiple scripts.
    - jimrandomh 8y ago
      The main reason you pack scripts is because you're compiling, and your compiler is checking and optimizing your cross-file interactions. For example, you need to merge scripts to be able to detect and delete unused functions, because otherwise some unmerged script might call the function without the compiler being able to detect it.
      - setr 8y ago
        It seems like it would be trivial for your compiler to go ahead and split the files up again afterwards. Its not like you cared about file organization on the client side anyways if you were packing them, so its free to split however it feels. And ofc you’d naturally just attribute this as an artifact of optimization, just as single-file packing was. Which it is, given http 2/3

chirau 8y ago

So how do i install this?

lowonkarma 8y 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 8y 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 8y 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.
palimpsests 8y ago
You can kill this tab without closing the browser by using 'end process' in Chrome's Task Manager (available under the Window menu).
- kartickv 8y 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.
  - palimpsests 8y ago