According to Google, if a page’s load time goes up from 1 second to 3 seconds, the probability of the user bouncing increases by 32%. In 2018, Google released a statement that speed is now used for landing page factors on Google Search and Ads. Way back in 2012, Fast Company noted that Amazon calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year.
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.
According to Google, these are some of the potential issues after adding third-party scripts:
However, it’s near impossible to run a successful business online without using third-party libraries like Google Analytics. Other examples include: metrics, ads, A/B testing, trackers, etc.
To counteract the negative effects of third-party scripts listed above, Partytown aims to do the following:
To put it simply, Partytown adds a worker to allow execution in both the main thread and worker thread.
To understand Partytown, it is important to first understand a few technologies used by modern web browsers:
Traditionally, communicating between the main thread and worker thread must be asynchronous: for the two threads to communicate, they cannot use blocking calls. Partytown is different. It allows code executed from the web worker to access DOM synchronously. The benefit from this is that third-party scripts can continue to work exactly how they’re coded.
As you can see in the below image, code that is running in a web worker that proxies global variables uses synchronous XHR to make an asynchronous operation synchronous. This gets intercepted by a service worker and the main thread value is retrieved via a postMessage and sent back.
You can easily add it to any site with a small snippet, and then tag any scripts that you want to load in the web worker with type="text/partytown".
It’s important to note that Partytown does not automatically move all scripts to the web worker, but takes an opt-in approach. It’s best that the developer can pick and choose exactly which scripts should use Partytown, while all the others would go unchanged. There are several ways to integrate Partytown into your code, which you can find in our Getting Started and Copy Library Files documentation.
Partytown can work with any HTML page and doesn’t require a specific framework. However, to make it easier to use in various frameworks or services, plugins/wrappers can be made for their ecosystem.
Partytown is only enabled for specific scripts when they have the type="text/partytown" attribute.
Here’s a sequence of events:
Any scripts that you add type="text/partytown" will load by default in a web worker, but have full access to global variables. The `type="text/partytown"` attribute does two things:
And here’s the best part: We use a *synchronous* XHR request to block the worker thread and retrieve the needed value from the main thread.
And now we can use a service worker to intercept the /proxytown request, async postMessage to the main thread to get the needed value, and return it.
And that's it! The end result: You can now seamlessly drop in a whole range of third-party scripts to run in a web worker, removing the main thread performance cost.