Today, Alex Russell, a Google software engineer, submitted a patch called ‘Never-Slow Mode’ for Chromium. With this patch, various limits will be enforced for per-interaction and resources to keep the main thread clean.
Russell’s patch is very similar to a bug Craig Hockenberry, a Partner at The Iconfactory, reported for WebKit, last week. He suggested adding limits on how much JavaScript code a website can load to avoid resource abuse of user computers.
Here are some of the changes that will be done under this patch:
- Large scripts will be blocked.
- document.write() will be turned off
- Client-Hints will be enabled pervasively
- Resources will be buffered without ‘Content-Lenght’ set
- Budgets will be re-set on the interaction
- Long script tasks, which take more than 200ms, will pause all page execution until the next interaction.
- Budgets will be set for certain resource types such as script, font, CSS, and images.
These are the limits that have been suggested under this patch (all the sizes are in wired size):
Similar to Hockenberry’s suggestion, this patch did get both negative and positive feedback from developers. Some Hacker News users believe that this will prevent web bloat. A user commented, “It’s probably in Google’s interest to limit web bloat that degrades UX”. Another user said, “I imagine they’re trying to encourage code splitting.”
According to another Hacker News user putting hard coded limits will probably not work, “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”.
You can check out the patch submitted by Russell at Chromium Gerrit.
Read Next
Chromium blacklists nouveau graphics device driver for Linux and Ubuntu users
Chromium-based Brave browser shows 22% faster page load time than its Muon-based counterpart
