I've said it times and again: Chrome is optimized for a single use case (i.e. few tab users) at which it excels but tends to break down quickly once you leave its comfort zone, unless you have a fairly powerful system. Maybe the project leader nudge, nudge could divert some resources to make Chrome scale better. ;-)
Putting in the work to just improve the speed is the hard fix usually. But I guess firefox and chrome are fairly optimized for loading already.
However, some good heuristics might help. Things like number of tabs, most common tabs used, active tab, time to load and responsiveness(frame rate, latency etc) would be good indicators.
I'm not sure how good hard coding stuff in like number of tabs would be. Whilst just loading up to 8 tabs would probably work, these numbers seem to change over time. Like the oldIE 4 connections limit for example. But! With frequent automatic updates, this value could be tweaked later if needed.
Cpu, and IO could be set based on the indicators as well.
If *n* tabs >= x
Load tabs on demand
Else
Load tabs in background
x can be set by default at some arbitrary number and also be changed.We could use much more subtle algorithms - what about loading visible page, then queuing up X background tabs to concurrently load (based tab order)? What about a logarithmic backoff (ie, load up visible and several background pages, then slowly load others)?
Fact is, user-time is valuable, compute time (and for most users) bandwidth is not. What's valuable should be prioritized.