What is @builder.io/partytown?
@builder.io/partytown is a JavaScript library that helps move resource-intensive operations from the main thread to web workers. This can significantly improve the performance of web applications by offloading tasks such as third-party scripts, analytics, and other heavy computations to a background thread.
What are @builder.io/partytown's main functionalities?
Offloading Third-Party Scripts
This feature allows you to offload third-party scripts to web workers, reducing the load on the main thread and improving page performance. The code sample initializes Partytown and forwards specific functions to the web worker.
import { init } from '@builder.io/partytown';
init({
forward: ['dataLayer.push'],
});
Web Worker Communication
Partytown enables seamless communication between the main thread and web workers. The code sample demonstrates how to forward a custom function to be executed in a web worker.
import { init } from '@builder.io/partytown';
init({
forward: ['myCustomFunction'],
});
function myCustomFunction() {
console.log('This runs in a web worker');
}
Improving Performance
By offloading resource-intensive tasks to web workers, Partytown helps improve the overall performance of your web application. The code sample shows how to forward a heavy computation function to a web worker.
import { init } from '@builder.io/partytown';
init({
forward: ['heavyComputation'],
});
function heavyComputation() {
// Some resource-intensive task
}
Other packages similar to @builder.io/partytown
comlink
Comlink is a library that simplifies the use of WebWorkers by providing a proxy-based interface for communication. Unlike Partytown, which focuses on offloading third-party scripts, Comlink is more general-purpose and can be used for any kind of task that you want to run in a web worker.
workerize
Workerize is a library that automatically moves a module into a WebWorker and returns a proxy to interact with it. It is similar to Partytown in that it helps offload tasks to web workers, but it does not specifically target third-party scripts.
greenlet
Greenlet is a library that allows you to run a function in a WebWorker and return a promise for its result. It is lightweight and easy to use, but it does not offer the same level of integration for third-party scripts as Partytown.
Partytown 🎉
A fun location for your third-party scripts to hang out
⚠️ Warning! This is experimental! ⚠️
Partytown is a lazy-loaded library to help relocate resource intensive scripts into a web worker, and off of the main thread. Its goal is to help speed up sites by dedicating the main thread to your code, and offloading third-party scripts to a web worker.
Negative Impacts From Third-Party Scripts
Even with a fast and highly tuned site following all of today's best practices, it's all too common for your performance wins to be erased the moment third-party scripts are added. By third-party scripts we mean code that is embedded within your site, but not directly under your control. A few examples include: analytics, metrics, ads, A/B testing, trackers, etc. Their inclusion are often a double-edged sword.
Below is a summary of potential issues, referenced from Loading Third-Party JavaScript:
- Firing too many network requests to multiple servers. The more requests a site has to make, the longer it can take to load.
- Sending too much JavaScript which keeps the main thread busy. Too much JavaScript can block DOM construction, delaying how quickly pages can render.
- CPU-intensive script parsing and execution can delay user interaction and cause battery drain.
- Third-party scripts that were loaded without care can be a single-point of failure (SPOF).
- Insufficient HTTP caching, forcing resources to be fetched from the network often.
- The use of legacy APIs (e.g
document.write()
), which are known to be harmful to the user experience. - Excessive DOM elements or expensive CSS selectors.
- Including multiple third-party embeds that can lead to multiple frameworks and libraries being pulled in several times, which exacerbates the performance issues.
- Third-party scripts also often use embed techniques that can block
window.onload
, even if the embed is using async or defer.
Goals
We set out to solve this situation, so that apps of all sizes will be able to continue to use third-party scripts without the performance hit. Some of Partytown's goals include:
- Free up main thread resources to be used only for the primary web app execution.
- Sandbox third-party scripts and allow or deny their access main thread APIs.
- Isolate long-running tasks within the web worker thread.
- Reduce layout thrashing coming from third-party scripts.
- Throttle third-party scripts' access to the main thread.
- Allow third-party scripts to run exactly how they're coded and without any alterations.
- Read and write main thread DOM operations synchronously from within a web worker, allowing scripts running from the web worker to execute as expected.
- No build-steps or bundling required, but rather update scripts the same way as traditional third-party scripts are updated.
Web Workers
Partytown's philosophy is that the main thread should be dedicated to your code, and any scripts that are not required to be in the critical path should be moved to a web worker. Main thread performance is, without question, more important than web worker thread performance. See the example page and test pages for some live demos.
If you're looking to run your app within a web worker, we recommend the WorkerDom project.
Docs
Related Projects
- Qwik: An open-source framework designed for best possible time to interactive, by focusing on resumability of server-side-rendering of HTML, and fine-grained lazy-loading of code.
- Mitosis: Write components once, run everywhere. Compiles to Vue, React, Solid, Angular, Svelte, and more.
- Builder: Drag and drop page builder and CMS for React, Vue, Angular, and more.
Made with ❤️ by Builder.io