chhamilton
Since initial grants are larger (roughly 2x) than refresher grants, the equal vesting of the initial grant (old behavior) could cause a significant drop in compensation for new hires after 4 years at the company (the dreaded equity cliff). This would only happen for relatively "flat" performers, as if you're on an upwards trajectory the larger size of later grants would eventually catch up to your initial equity grant.
Let's say the sign on equity was 200 shares, and refreshers were 100. With equal vesting it would look like:
Year 1: 50 shares
Year 2: 50 + 1 x 25 = 75 shares total
Year 3: 50 + 2 x 25 = 100 shares total
Year 4: 50 + 3 x 25 = 125 shares total
Years 5+: 4 x 25 = 100 shares total (20% drop!)
The problem has actually been worse, because grants are actually in dollars and the stock has been growing consistently year over year. Which means earlier grants are worth more in dollars in later years than new grants, despite having the same dollar value at the time of issue. Let's say 20% yoy, which is not far off from average over the last 10 years. We'll work in dollars and say the initial grant was worth $200K at sign-on time and later grants worth $100K.
Year 1: $50K = $50K
Year 2: $50K * 1.2 + $25K = $85K
Year 3: $50K * 1.2^2 + $25K * 1.2 + $25K = $127K
Year 4: $50K * 1.2^3 + $25K * 1.2^2 + $25K * 1.2 + $25K = $177.4K
Years 5+: $25K * 1.2^3 + $25K * 1.2^2 + $25K * 1.2 + $25K = $134.2K (23% drop!)
With the frontloading this becomes:
Year 1: 66 shares
Year 2: 66 + 1 x 25 = 91 shares
Year 3: 44 + 2 x 25 = 94 shares
Year 4: 12 + 3 x 25 = 87 shares (7% drop)
Years 5+: 4 x 25 = 100 shares
With stock appreciation this becomes:
Year 1: $66K
Year 2: $66K * 1.2 + $25K = $104K
Year 3: $44K * 1.2^2 + $25K * 1.2 + $25K = $118.4K
Year 4: $24k * 1.2^3 + $25K * 1.2^2 + $25K * 1.2 + $25K = $132.5K
Years 5+: $25K * 1.2^3 + $25K * 1.2^2 + $25K * 1.2 + $25K = $134.2K
So the dip is entirely smoothed over. Add in natural increases do to career growth and you no longer notice it.
We don't throttle workers (that could change, but we don't have firm plans here yet).
All things being equal, if you move complex work to workers we're happy because it frees up the main thread to handle input events, compositing, etc. Just because your tab is in the background doesn't mean your renderer process isn't sharing a main thread with a tab that is in the foreground, so in this case it can improve foreground tab performance.
Also, spreading a fixed amount of work across more cores and fewer wake-ups is actually more efficient from a power point of view (assuming the wake-ups are synchronized).
Doing the work in one giant update is actually better from a power consumption / battery point-of-view, because the CPU cost is fixed but there are fewer wakeups overall.
Note that the new throttling logic means you get woken-up once per minute; we're not talking about preventing your page from doing work for a 24 hour period.
For full details of how the throttling works, see here:
For the most part, events can't really accumulate, because not running code means no new events are posted. The throttling applies to setTimeout/setInterval, and not to any external event (incoming network data, API callbacks, etc).
Sites that legitimately have to do a fixed amount of work per unit time (via timers) will simply do that work with 1 wake-up per minute. All things being equal, this still means less battery usage because energy usage is a function of both wakeups and total CPU usage.
> The primary source of energy savings would be poorly written websites that constantly poll in the background.
This is the key insight here, and really what we're going after. There is a lot of this on the web.
Yes, lots of sites are written with tight setInterval/setTimeout loops, checking for modifications to the DOM, visibility, doing animations, etc. In most cases there are modern web APIs that do these things for you that don't require polling (rAF, MutationObserver, IntersectionObserver, etc). Throttling is mostly about reducing the impact of these sites. We are not trying to penalize well-written sites, and if you have valid use cases that you feel are being unfairly penalized we're more than happy to accept feedback!
Yes, for now all workers continue to run unthrottled (shared, dedicated and service). They may also be throttled at some point, but we have no firm plans around this yet.