Exactly this. Google sign-on equity is actually front loaded now: 33%, 33%, 22%, 12%. Refresh grants (nominally every year) vest equally at 25% per year. Vests are monthly or quarterly, depending on the size of your…
(Chromium dev here.) 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…
(Chromium dev here.) 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…
(Chromium dev 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…
(Chromium dev here) 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…
(Chromium dev here.) 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.
Exactly this. Google sign-on equity is actually front loaded now: 33%, 33%, 22%, 12%. Refresh grants (nominally every year) vest equally at 25% per year. Vests are monthly or quarterly, depending on the size of your…
(Chromium dev here.) 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…
(Chromium dev here.) 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…
(Chromium dev 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…
(Chromium dev here) 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…
(Chromium dev here.) 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.