Consider extending the behavior of delay to support additional delay types · Issue #19 · WICG/scheduling-apis (original) (raw)

While implementing early experiments using the postTask scheduler at Airbnb, we took some time to change our early initializers that load things like tracking, google maps, recaptcha and such to use the postTask scheduler. One thing that was incredibly helpful for us in this was extending delay to support waiting until a DOM event, such as load or DOMContentLoaded, we even allowed for a custom event that we fire post React hydration called hydrate-complete. The flexibility and power this gave us helped us to overwhelmingly maximize initial loading performance by deferring non-critical events until after our UI becomes interactive.

// Notice the usage of load to the delay argument instead of a number postTask(initializeServiceWorker, { priority: 'background', delay: 'load' });

// here we wait for our custom hydrate-complete, waiting to do things like show // a flash banner until just after we hydrate React postTask(() => Flash.display(), { delay: 'hydrate-complete' });

While the hydrate-complete custom option might be questionable, the extension to allow waiting for standard DOM events seems genuinely useful, especially around 3rd party script loading and deferring non-critical tasks until later. We've seen issues where some of our 3rd party scripts do unfortunate things, like cookie checks or things that might case a repaint or reflow or do some really heavy computation and lead to unnecessary blocking, having this mechanism allowed us to improve both our total blocking time and first input delay considerably, and would love to get folks thoughts on if they think this would be a valuable addition to the spec.