HTML and CSS Reference
What's going on here is that the browser is attempting to finish interpreting and running the scripts in question,
and it will draw upon all available system resources to do so. To remedy this issue in the new modern browser market,
a web worker can be used.
other scripts and the DOM, without ultimately affecting overall performance. This is really awesome; you can continue to
do whatever you want within the UI of the ad creative: clicking, tapping, hovering, scrolling—you get the idea—all while
the worker script runs in parallel “helping” the other scripts and the functionality within your content. Web workers
Figure 6-7. Demonstration of a typical web worker workflow
Hopefully, after looking at Figure 6-7 , you'll agree that delegating another worker to do your work is much more
efficient than taking on all the work yourself. This is what web workers strive to accomplish. They split up tasks for
Before web workers, developers needed to be crafty and break apart their code so that the browser could
interpret smaller “chunks” of code at a time. This amounted to a shoddy approach to multithreading in a single-
threaded browser universe. Obviously, this never really worked too well, since it required the script to be heavily
reliant on timers and intervals, all of which slowed the experience significantly, depending on the user's machine
resources. It often created an undesirable “chugging,” or staggered loading, effect for the user as well.
Initially a concept by Google with the Gears project, web workers have finally gained enough acceptance from
other browser vendors and the W3C to produce its own specification. It can really speed up text filtering on search
inputs, math computation, and even complex animations by offloading the physics or math onto a separate thread.
Did someone say particle generators?