Maybe, but probably not for most sites. My 2 cents as a tudent/freelancer who's been working on a project that does weird shit with scrolling because it has to.
The way I see it, most websites fall into two broad camps of layout and associated scroll behavior:
1. Articles
2. Dashboards
You're either trying to present some kind of information as text like most news sites, forums, etc. or you're doing a "web app." It's really less "either-or" and more of a spectrum, but if we're talking about compartmentalizing an entire website into scrollable containers this is where things fall.
For an article style website, you'd want either the entire page or the majority of the content on the site in a single scroll container. Perhaps you're a news site like Medium that has certain UI elements that persist during scroll. Normally you'd just position:fixed those elements, but let's say instead you decide to position your fixed nav and whatnot normally and instead scroll the article inside a box. You run into a few problems:
1. You don't get the benefit of compartmentalizing your scroll listeners because whatever blocks scrolling blocks whatever people care about anyway
2. Designs like this are really hard to get right. Positioning and sizing these elements is notoriously hard to fully test and easy to break. In mobile safari, for example, the showing or hiding of the UI is determined by scrolling the main page. Scrolling within a container does do this. Also Safari uses MacOS/iOS's native UI scrolling system, so scrolling really fast bounces back. However, your box may not bounce, the entire page will if they flick the box and there's still scroll velocity left when they get to the bottom. This bounce CAN affect the visible state of the UI and can really mess with innerHeight calculations. With multiple scrollable boxes on a page, dealing with touch input can be a huge pain. I'm sure you've seen websites that do this incorrectly, where things don't scroll like you think they do. Have you ever tried to scroll a page that had a poorly implemented map on it and scrolled the map instead? In fact, because of this behavior, early versions of mobile safari simply refused to scroll scrollable containers on drag. By default, it would only scroll the page itself and you had to drag with two fingers to scroll inside of Divs and Iframes.
Most sites I browse fall into this camp. The second camp is dashboard UIs.
The canonical way to do a dashboard with multiple scrollable elements is to do just that, which already has the optimization you suggested applied. However, a lot of designers these days actually try to design dashboards using the browser's native page scroll as much as they can. It turns out that there is a lot of complexity to that approach that makes development hard and breaks the user's expectation for how websites work. The story editor of the CMS we use at my college newspaper actually becomes unusable if you trigger the safari page bounce while a mouseover menu is open. They're in the middle of developing a new version, where the story is the page and the UI is position:fixed instead of everything being compartmentalized like you suggest, as it is now.
Back to native scrolling. There's a lot you can do to help the browser along.
The biggest thing you can do is utilize window.requestAnimationFrame(). Your function will be queued up and called when it is convenient for the browser, usually 60 times a second which is fast enough to render things smoothly without firing every time the onScroll event occurs, which can be hundreds of times a second on certain browsers.
The way I see it, most websites fall into two broad camps of layout and associated scroll behavior:
1. Articles
2. Dashboards
You're either trying to present some kind of information as text like most news sites, forums, etc. or you're doing a "web app." It's really less "either-or" and more of a spectrum, but if we're talking about compartmentalizing an entire website into scrollable containers this is where things fall.
For an article style website, you'd want either the entire page or the majority of the content on the site in a single scroll container. Perhaps you're a news site like Medium that has certain UI elements that persist during scroll. Normally you'd just position:fixed those elements, but let's say instead you decide to position your fixed nav and whatnot normally and instead scroll the article inside a box. You run into a few problems:
1. You don't get the benefit of compartmentalizing your scroll listeners because whatever blocks scrolling blocks whatever people care about anyway
2. Designs like this are really hard to get right. Positioning and sizing these elements is notoriously hard to fully test and easy to break. In mobile safari, for example, the showing or hiding of the UI is determined by scrolling the main page. Scrolling within a container does do this. Also Safari uses MacOS/iOS's native UI scrolling system, so scrolling really fast bounces back. However, your box may not bounce, the entire page will if they flick the box and there's still scroll velocity left when they get to the bottom. This bounce CAN affect the visible state of the UI and can really mess with innerHeight calculations. With multiple scrollable boxes on a page, dealing with touch input can be a huge pain. I'm sure you've seen websites that do this incorrectly, where things don't scroll like you think they do. Have you ever tried to scroll a page that had a poorly implemented map on it and scrolled the map instead? In fact, because of this behavior, early versions of mobile safari simply refused to scroll scrollable containers on drag. By default, it would only scroll the page itself and you had to drag with two fingers to scroll inside of Divs and Iframes.
Most sites I browse fall into this camp. The second camp is dashboard UIs.
The canonical way to do a dashboard with multiple scrollable elements is to do just that, which already has the optimization you suggested applied. However, a lot of designers these days actually try to design dashboards using the browser's native page scroll as much as they can. It turns out that there is a lot of complexity to that approach that makes development hard and breaks the user's expectation for how websites work. The story editor of the CMS we use at my college newspaper actually becomes unusable if you trigger the safari page bounce while a mouseover menu is open. They're in the middle of developing a new version, where the story is the page and the UI is position:fixed instead of everything being compartmentalized like you suggest, as it is now.
Back to native scrolling. There's a lot you can do to help the browser along.
The biggest thing you can do is utilize window.requestAnimationFrame(). Your function will be queued up and called when it is convenient for the browser, usually 60 times a second which is fast enough to render things smoothly without firing every time the onScroll event occurs, which can be hundreds of times a second on certain browsers.
Check out the MDN Doc for an example of how to do this. https://developer.mozilla.org/en-US/docs/Web/Events/scroll