Chromium is the browser rendering engine used by Google Chrome, Microsoft Edge, Opera, and a number of other Internet web browsers to convert the HTML, CSS, Javascript, and images into the web pages you want to see.
The Chromium developers recently committed a new “Never-Slow Mode” set of changes to the prototype Chromium codebase in order to test out some new features designed to speed the rendering of web pages.
Note that this is currently a prototype, but it can also serve as a “Coming soon to a web browser near you” comming attractions trailer of where Chrome, Edge, Opera, et al will be heading once this codebase gets integrated.
Why Should You Care?
Nowadays, page bloat is becoming a bigger problem: large code modules, multimegabyte images, and bloated CSS all contribute to slower loading web pages. Newer Web Frameworks technologies like Angular, React, Ruby on Rails, et al, depend on larger client-side payloads and the browser doing more of the heavy lifting on rendering a web site. Easier site development comes at the cost of more work for the browser to render the content, and downloading all the components to make that function comes at a file size and rendering time cost.
Even without those Frameworks, web page size has grown as faster mobile networks and widespread availability of broadband Internet access has made dialup (and it’s draconian speed limitations) a thing of the past. Page speed is lower on a designers list of requirements, and page-bloat is the result. The “Never-Slow Mode” proposed by the Chromium developers would set hard limits on the individual component size and total size for that type of component on a per-page basis. Some of the currently proposed limits are:
| Component Type | Max Size Per Item | Max Size Per Page |
|---|---|---|
| Images | 1 MB | 2 MB |
| CSS | 100KB | 200KB |
| Javascript | 50 KB | 500 KB |
| Total Connection Limit | 10 | |
| Long Task Limit | 200 mSec |
Future enhancements already announced include limiting IFRAME nesting depth and a “Feature-policy” header which can trigger on a per-page basis. Currently, the prototype has no UI to inform users that a page is slow and subject to these thresholds/limits.
Since it is still in the prototype stage, it is not clear whether and when this Mode would be turned on. Would it be off by default for both Desktop and Mobile users? On for Mobile only? Turned on automatically when in a slow-bandwidth network area? It is not currently clear.
Page Speed Is Important
Google believes strongly that pages should load quickly, and has already made several steps to help:
- Advise: Provide their Page Speed Insights Tool for testing and grading a page’s speed on mobile and desktop
- Penalize: Google is using page load time as a Google Ranking Factor to downgrade slow-loading pages in the SERPS
- Speed Delivery: Google developed the AMP architecture to allow for fast, lean mobile pages
The Road Ahead
It appears that Google is approaching the point where they will move away from advising on slow pages, dunning slow pages in the SERPS, and providing an alternative delivery mechanism to actively trucating large sites/site components.
As a Site developer, it would be prudent to get jumpstart of ensuring that your site can run efficiently with these proposed limits in place or risk having the site degrade (possibly badly) once these new features are made mainstream. ChromeStory has a little more detail.
