A new feature called “Never-Slow Mode” is currently being tested for Google’s Chrome that would theoretically make the browser much faster on resource-intensive websites, based on a recently spotted change in the Chromium repository. While the code is marked as a prototype for internal use only and subsequently hasn’t been committed to any of Chrome’s Channels yet, it adds a flag to set ‘budgets’ for items loading on a given web page.
From Google’s perspective, it makes sense that the budgets would be tested internally first since those budgets could ultimately break some websites for end users.
In its current iteration, Never-Slow Mode acts on a per-interaction basis to block certain items from the main thread. The budgets are set at 1MiB per image with a total image size limitation per load of 2MiB. Stylesheets are similarly limited at 200KiB and 200KiB for a single stylesheet or total, respectively. Scripts are limited only on a per-script basis to 50KiB.
With current budget caps in place, that means that with the exception of Service Worker Cache Storage and service workers themselves, items exceeding the budget limitations simply won’t be loaded in the main loading process. In effect, the Never-Slow Mode will block blocks large scripts from running, as well as preventing the loading of fonts, CSS, or images that overextend in a bid to make the entire browser faster for users who enable the mode.
Not quite ‘Lite’
Regardless of how much faster the changes might make Chrome, they aren’t going to save users in terms of data usage and can’t fairly be compared to a ‘Lite’ mode for the browser.
The associated Chromium change notes that the change turns off certain elements such as document.write() and sync XHR, enables client hints pervasively, and “buffers resources without `Content-Length` set.” Scripts that take longer to load are basically disabled until a user interaction enables them, allowing the page to load much more quickly.
It also seems to work from top to bottom, loading elements the user sees first and loading elements later on, with budgets being reset as the user scrolls down a given web page. Aside from scrolling, the budgets are reset on taps or clicks, too — suggesting the feature could eventually work with mobile devices and touch-enabled Chromebooks.
Lazy loading improved
On its surface, the new feature wouldn’t be exceptionally different from a previously introduced feature called ‘lazy loading’ and seems to actually build on the concept. Offering as much as an 18-percent and 35-percent gain in performance and speed, according to Google, lazy loading forestalls the loading of large images and similar page elements on large pages that require scrolling.
By delaying the load time until a user is set to see the objects, the page can keep the appearance of, for all intents and purposes, loading up faster. The elements that still remain to be loaded as the user scrolls will load more quickly too since they’re essentially loaded on an ‘as-needed’ basis. On faster internet connections, the load time wouldn’t necessarily even be noticeable.
The new feature builds on that by setting strict limits for item sizes and cutting back on other clutter. At the same time, because service workers aren’t impacted, sites meant to function as web apps such as Google’s Squoosh image compression tool or Canvas drawing tool will still load up normally.