DEV Community: Adam Bradley

Speculative Module Fetching: a Modern Approach to Faster App Interactivity

Adam Bradley — Tue, 07 Mar 2023 16:03:28 +0000

Speculative Module Fetching is an approach that optimizes app responsiveness by loading only the possible points of user interactivity based on the current state of the app. As the user interacts with the app, it continues to speculate and fetch the next possible modules.

An Analogy: video downloading vs. streaming

Before we dive in, let's compare the differences between downloading a two-hour movie and streaming it. When you download a video file to your device, you can't start watching it until the download is complete. For a multiple gigabyte video file, this can take a while.

Thankfully, services like Netflix, Hulu, and YouTube are well aware of this issue. That's why they stream content to your devices. When you start playing the movie, you stream only the first few seconds.

As you watch the movie, the service continues to buffer the next few seconds you're about to watch. And if the user stops and never finishes streaming the movie, that's fine. It doesn't waste resources on the user's device or the service's network.

Speculative Module Fetching

Qwik City applies the same streaming concept by anticipating which modules the user might interact with next, based on the content they are viewing.

Rather than loading modules on-demand (as known as lazy-loading), Qwik City pre-populates the cache ahead of time with modules the user may need. This also differs from prefetching, where often the entire application’s JavaScript is downloaded using main-thread resources.

Similar to video streaming, Qwik City fetches the next modules ahead of time in a background thread as the user continues to interact with the application. This allows the application to grow in size and complexity while still maintaining fast startup, interactivity, and responsiveness.

For instance, suppose that a page has a click listener on a button. When the page loads, the system ensures that the bundle for that click listener is downloaded and stored in the cache. When the user clicks the button and Qwik makes a request to the event listener's bundle, the bundle is already sitting in the cache, ready to execute.

To take it one step further, it’s similar to like a video game quest. Choose your own adventure. As the user navigates the app, the app will cache what’s needed next.

Advantages from Resumability

Since Qwik uses resumability, instead of hydration, the build creates many different entry points for the app, rather than a single main.js script.

The previous mindset has been that there’s only one script that starts an application. And even if there’s lazy-loading with dynamic imports and the <script> is added just before </body>, this initial script that contains the framework still has to run in order for the entire application to work.

With resumability, Qwik is able to continue an application from the state that it was when it left the server (either SSR or SSG).

Instead of a single entry that involves hydration to get up and running, there are many points at which the application can resume. In many cases, the app may never even need to start some parts or even the entire app.

Beyond Traditional Prefetching

Due to Qwik’s unique module extraction primitive and resumability, pages startup and become interactive extremely fast without requiring any JavaScript. The next question, however, is if JavaScript isn’t required, how does interactivity even work?

Traditional web development often resorts to prefetching and hydration, or a combination of both. Even though you may be lazy-loading per page, you still need the framework to hydrate the app. And when you require the framework in order for it to work, the user has a non-responsive app as the framework is downloading and hydrating. And for low-end mobile devices on real-world networks, this could be too long for the user to wait.

Qwik, on the other hand, does not use a traditional main-thread prefetching or lazy-loading approach, but rather takes advantage of service workers to execute Speculative Module Fetching.

Caching with a Service Worker

Service workers are typically thought of as a way to make an application work offline. However, Qwik City takes advantage of the powerful features of service workers to provide Speculative module fetching and heavily caching modules on the user's device.

The goal is not to download the entire application (which users probably won’t interact with most of it anyways), but rather to use a service worker to dynamically download what is possible to execute at that moment. By not downloading the entire application, resources are freed up to only request the small parts of the app a user could use for what they have on their screen at that time.

An advantage of using a service worker is that it's also an extension of a worker, which runs in a background thread.

Web workers make it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.

By moving the downloading and caching logic to a service worker (which is a worker), we're able to essentially run the code in a background task, in order to not interfere with the main UI thread. By not interfering with the main UI we're able to help improve the performance of the application for end-users.

How Speculative Module Fetching Works

Page HTML loads without any hydration or framework JavaScript.
Main thread sends to the service worker all of the possible user interactions on that page at that time.
Service worker receives a message from the main thread of all possible interactions.
Service worker fetches modules it does not already have stored in the Cache API.
When the user interacts with the app, dynamic imports pull from the pre-populated cache.

Reducing Network Waterfalls

A network waterfall is when numerous requests happen one after another, like steps downstairs, rather than in parallel. Below is an exaggerated case of a less-than-ideal request waterfall.

A waterfall of network requests usually hurt performance because it increases the time until all modules are downloaded, rather than each module starting to download at the same time.

Below is an example with three modules: A, B and C. Module A imports B, and B imports C. The HTML document is what starts the waterfall by first requesting Module A.

// module-a.js
import './module-b.js';
console.log('Module A');

// module-b.js
import './module-c.js';
console.log('Module B');

// module-c.js
console.log('Module C');

<!-- HTML page -->
<script type="module" src="/module-a.js"></script>

In this example, when Module A is first requested, the browser has no idea that it should also start requesting Module B and C. It doesn't even know it needs to start requesting Module B, until AFTER Module A has finished downloading. Basically, the browser doesn't know ahead of time what it should start to request, until after each module has finished downloading.

However, because our service worker contains a module graph generated from the manifest at build time, we already know all of the modules which will be requested next. Qwik can even know which interactions the user will most likely use next with Real Metric Optimizations, but more on that later.

So when either user interaction or requesting a bundle happens, the worker thread initiates the request for all of the bundles that it already knows will be requested. This way, we drastically reduce the time it takes to request all bundles.

Dynamic Imports and Caching

When Qwik requests a module, it uses the standardized dynamic import(). For example, let's say a user interaction happened, requiring Qwik to execute a dynamic import for /abc.js. The pseudo-code would look something like this:

const module = await import('/abc.js');

What's important here is that Qwik itself has no knowledge of a caching strategy. It's simply making an HTTP request for a URL. However, because we've installed a service worker, and the service worker is intercepting requests, and the service worker is able to inspect the URL and say, "hey look, this is a request for /abc.js! This is one of our bundles! Let's first check to see if we already have this in the cache before we do an actual network request."

This is where the power of the service worker and cache API comes in! Qwik first pre-populates the cache for modules the user may soon request within another thread. And better yet, if it's already cached, then there's no need for the browser to do anything.

And remember, the service worker also knows which additional modules are imported by each module, so we can reduce the network waterfall by kicking off each request in parallel.

Avoiding Duplicate Requests

It may be possible to fire off duplicate requests for the same resource. For example, let's say we want to import module-a.js, and while that's being downloaded (which may take a short time or a very long time, we don't know), the user interacts with the app, which then decides to request and execute module-a.js. Browsers will often fire off a second request for the same URL, which makes matters worse.

The service worker approach can avoid this by identifying a request that is already in flight, waiting on the first request for module-a.js to finish, and then cloning it for the second request.

Only one network request will happen, even though numerous module imports may call for the same request/response.

Advantages of Understanding the Module Graph

One of the unique features of the Qwik Optimizer is its ability to provide a deep understanding of how an application works and how it can be best split apart. Unlike blindly lazy-loading entire chunks of code (usually split at the page level), the Optimizer can bundle at an extremely fine-grained level due to its module extraction primitive.

<button onClick$={() => console.log("Clicked")}>Click</button>

In the above example, the button cannot be changed, so no templating or core rendering code is necessary. When the button is clicked, the app console logs "Clicked,” which is all that needs to be fetched ahead of time. Even Qwik's core library is not required in this case.

Furthermore, when using signals, very little JavaScript is needed because only the specific DOM node within the app needs to be updated, rather than re-rendering the entire component tree as is common in other frameworks.

Most of Qwik's actual work is done at build-time, and its core feature is understanding that the click event code is not the component's rendering code. The above is a simple example, but this optimization can scale by minimizing the need to load most of the application's templates, interactions, and logic.

Advanced Bundling and Real Metric Optimizations

Bundlers do a good job concatenating JavaScript. But they lack the context of how the application will actually be used out in the real-world, by real-users, on production servers.

Since Qwik uses module extraction and resumability to create many fine-grained modules, it combines modules, which results in fewer requests. Instead of having one tiny module per interaction, Qwik can bundle them more efficiently.

However, to take it to next level, Qwik can also bundle and prioritize modules depending on how users actually run the application. For example, if users of a product page most commonly click the Add to Cart button, and change the order quantity, then the bundler knows to group those modules together, and to make it the first module to cache on page load.

But much more on Real Metric Optimizations feature later…

Conclusion

Building a massive application, but without a massive amount of JavaScript, is quite a challenge. This is where we’ll continue to research ways to improve efficiently requesting, caching and bundling Qwik’s modules.

If you want to know more about Qwik’s Speculative Module Fetch please take a look at our docs:

About me

Hi! I’m Adam, Director of Technology at Builder.io.

We make a way to drag + drop with your components to create pages and other CMS content on your site or app, visually.
So this:

import { BuilderComponent, registerComponent } from ‘@builder.io/react’
import { Hero, Products } from ‘./my-components’
// Dynamically render compositions of your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}
// Use your components in the drag and drop editor
registerComponent(Hero)
registerComponent(Products)

Gives you this:

Experimental Performance Insights Panel in Chrome DevTools

Adam Bradley — Wed, 01 Mar 2023 18:11:45 +0000

Have you tried Chrome DevTool’s Experimental Performance Insights panel? If not, let's explore some of its many slick features together.

While the existing Performance panel you may be familiar with has many (many) capabilities, it’s also quite overwhelming at the same time. The Performance panel suffers from trying to solve too many use cases, which is why the new experimental panel’s streamlined and simplified UI is a welcomed update.

Enabling Experimental Performance Insights 🧑‍🔬

If you don't already see the Performance Insights tab, you can enable it by going to More options icon -> More tools -> Performance Insights.

Alternatively, you can also enable Performance Insights through the the DevTools Command Menu.

Enable Throttling 🦥

Before we start our first Performance recording, I recommend enabling Network and CPU throttling to get a better idea of what users are experiencing in the real world. Additionally, disabling cache also helps to ensure we’re testing more realistic conditions for first-time visitors.

Performance Recording 🔴

Click the "Measure page load" button for DevTools to reload the page begin the performance recording. It’ll automatically stop the recording a couple of seconds after the page load has finished.

Easily one of the best features of Performance Insights would have to be the playback feature. It allows you not only reply the entire performance recording, but also scrub and zoom into to exact moments within the record.

And making it even more powerful is how it visually lines up with the all the tasks the browser is performing at that moment, like network requests and rendering.

Insights and Details Panel 🧐

Performance Insights is more than just tooling, but also goes further into helping pin-point the problem, and recommend some solutions.

For example, the right-hand side lays out a timeline of what’s happened during the recording. Each section in the Insights panel provides a link to get more details.

Try out the Experimental Performance Insights Panel!

In short, the new Performance Insights panel provides a lot more information and is easier to use than the existing Performance tab. Give it a try and let us know how it goes. Thanks for reading!

About me

Hi! I’m Adam, Director of Technology at Builder.io.

We make a way to drag + drop with your components to create pages and other CMS content on your site or app, visually.
So this:

import { BuilderComponent, registerComponent } from ‘@builder.io/react’
import { Hero, Products } from ‘./my-components’
// Dynamically render compositions of your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}
// Use your components in the drag and drop editor
registerComponent(Hero)
registerComponent(Products)

Gives you this:

// Detect dark theme var iframe = document.getElementById('tweet-1630989157567692800-526'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1630989157567692800&theme=dark" }

How To Improve Lighthouse Scores by Avoiding Layout Shifts

Adam Bradley — Thu, 23 Feb 2023 18:04:39 +0000

One of the most common killers of Lighthouse scores, and also one of the easiest to solve, would have to be setting the correct aspect ratio on your images. Layout shifts can happen for many reasons, but here we’ll focus on how images can have a negative effect.

Basically, it’s annoying to be reading content only to see the layout adjust and that same content moved to another location. This is why Lighthouse and other performance measuring tools have a metric called Cumulative Layout Shift, or CLS.

It’s pretty straightforward: if your page has CLS issues, your Lighthouse scores go down.

Another challenge is that we’re also designing pages that are responsive. Meaning that the same content should look good on both desktop and mobile, so setting exact dimensions for images is usually not an option.

Luckily, there are two recommended cross-browser approaches to solving image CLS issues:

aspect-ratio CSS property on img selector
width and height attributes in the img tag, with height: auto CSS

Aspect Ratio CSS

The aspect-ratio CSS property, as you guessed it, sets the aspect ratio of an element. This means it determines the ratio between the width and height, rather than specifying an image’s exact dimensions.

img {
  aspect-ratio: 16/9;
  width: 100%;
}

Here we’re assigning CSS to the img element and using an aspect ratio of 16 units by 9 units.

What’s cool is that even before loading the image, the browser can now reserve space for it. This means that the layout and content of the page will not shift after the image loads.

Depending on your design, it also might be worthwhile to set a background color to the img element so users are given a hint that the image hasn’t loaded yet.

img {
  aspect-ratio: 16/9;
  width: 100%;
  background-color: gray;
}

In the screen recording above, you’ll notice that there’s initially a gray square in place of the image, which acts as an image placeholder so the content stays in the same place even after the image loads.

object-fit: cover

Another recommendation is to also add the object-fit: cover CSS:

img {
  aspect-ratio: 16/9;
  width: 100%;
  object-fit: cover;
  background-color: gray;
}

The object-fit property tells the browser what to do if the aspect ratio is off. So instead of forcing a poorly stretched image because the ratio is wrong, the image can instead keep its own aspect ratio, and still fit nicely within the given area.

Width and Height Attributes with Height Auto CSS

Another approach that’s worth trying for your use case is to set the width and height attribute of the img element, and also the height CSS property to auto.

<img width="1200" height="675" src="…" alt="…" />

img {
  height: auto;
}

Similar to the aspect ratio CSS approach, the browser now knows how to calculate how much space the image will take up before it loads.

Improve those Lighthouse scores

Which approach you use is up to you, but regardless, if you want an easy way to improve your Lighthouse scores, then ensuring the aspect ratio of your images is a quick win.

About me

Hi! I’m Adam, Director of Technology at Builder.io.

We make a way to drag + drop with your components to create pages and other CMS content on your site or app, visually.
So this:

import { BuilderComponent, registerComponent } from ‘@builder.io/react’
import { Hero, Products } from ‘./my-components’
// Dynamically render compositions of your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}
// Use your components in the drag and drop editor
registerComponent(Hero)
registerComponent(Products)

Gives you this:

// Detect dark theme var iframe = document.getElementById('tweet-1627708760293605384-250'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1627708760293605384&theme=dark" }

How Partytown's Sync Communication Works

Adam Bradley — Mon, 11 Oct 2021 17:26:35 +0000

Recently we announced the alpha version of Partytown, which is a library that helps relocate third-party scripts into a web worker so that the main thread can be dedicated to just running your code. For more information on why a website would benefit from this I’d encourage you to also read: Introducing Partytown 🎉: Run Third-Party Scripts From a Web Worker. This post is more for the curious and talking through “how” Partytown works.

Asynchronous postMessage()

Moving long-running and resource intensive tasks into a web worker has been encouraged for many years now. However, the significant constraint is that the communication between the main thread, and web worker, must be asynchronous. Meaning a message sent by one thread does not wait on the other thread to receive it, nor wait on it to return a value.

At the core, postMessage() is basically a fire-and-forget method. This is perfectly fine, and a communication layer can be built around postMessage() so your code can instead use promises, async/await or even callbacks (all of which are asynchronous).

An awesome project that can help you easily use Web Workers is Comlink, which “...removes the mental barrier of thinking about postMessage and hides the fact that you are working with workers.” Comlink is great, but at the time of writing this, you still hit the barrier that the calls between the main thread and web worker must be async.

Why Third-Party Scripts Can’t Use postMessage()

As I laid out in the first post, in reality you can’t just refactor third-party scripts. They’re hosted from another domain, controlled by another service, and built to handle countless scenarios so they can be executed by billions of different devices worldwide.

However, many scripts like Google Analytics, are just collecting information and posting that data to their servers using navigator.sendBeacon(). This is the best case scenario because Google Analytics is really just a background task. It can happily run on its own schedule and lazily collect and post data in another thread.

The problem, however, is there are still calls to blocking APIs that are not available in the web worker. For example document.title and window.screen.width are commonly used in scripts, but reading that information is blocking. So while Google Analytics itself is a great candidate to run in the background on another thread, it still requires synchronous communication in order to read values from document and window.

Since the third-party scripts must stay as-is, and because web workers must have an asynchronous communication, we’ve been in this stand-still where the bulk of our performance issues cannot be offloaded into another thread.

With this One Weird Synchronous Trick

This is the fun stuff! 🧑‍🔬 Enter the obscure API: Synchronous XMLHttpRequest. In today’s web development it’s a lesser known API for good reason. Basically in the olden days, when we were rocking Adobe Flash, Java applets, and Dreamweaver’ing DHTML, this was pretty common:

var request = new XMLHttpRequest();
request.open('GET', '/data.xml', false);  // `false` makes the request synchronous
request.send(null);

The problem was that in the main thread, this blocking call would lock up the webpage until the response came back. According to MDN:

Synchronous XHR is now in deprecation state. The recommendation is that developers move away from the synchronous API and instead use asynchronous requests.

And in today’s web dev landscape, it’s best to instead use the more modern fetch() API.

However, the web worker’s ability to execute synchronously is at the core of many tools. Mainly importScripts(), but Synchronous XHR falls in this category too. These synchronous APIs have not been marked as deprecated from within a web worker. A quick Github search for importScripts() shows just how widely used they are. But again, it’s only available in a web worker!

So, as it turns out...I guess we can make the web worker blocking...🧐

Intercepting Synchronous Requests

When code is executed from within a worker, and only a worker, we can make synchronous HTTP requests, which effectively block the web worker thread’s execution until the HTTP response comes back. With that power (and with our mad scientist wig on), we have the ability to execute the web worker code as blocking, and then use the HTTP request to asynchronously call postMessage(). Remember, an HTTP request and response is asynchronous. So while the web worker thread may “think” it’s sync, we can intercept the actual HTTP request and have an asynchronous response.

This is where the other weird trick comes in. Doctors hate it!

Service workers are able to intercept requests with onfetch. This means that the request the web worker makes can also be intercepted and handled by our own code. The requests are not external and do not hit the actual network, but instead are handled locally within the service worker. From within onfetch, we can then use postMessage() to do the real async communication.

A service worker still doesn’t have direct access to the main thread yet. But because we’re now communicating asynchronously, from within the service worker we can then use its postMessage() to talk to the the main thread, and have the main thread send messages back to the service worker. Then the service worker completes the HTTP response which it already intercepted.

So we still have the same asynchronous constraint, but with the combination of synchronous XHR, and intercepting requests, we can effectively convert an async call into a blocking one. Next, we make it a bit easier to use by wrapping up all the main thread’s access with Javascript Proxies.

Additionally, Partytown should still work for legacy browsers. Part of its initialization is that if the browser doesn’t support service workers, then it basically just runs the third-party scripts the traditional way (what we’re all doing today).

What About Atomics?

Awesome, glad you asked. Personally, I’m hopeful to see Atomics as the solution in the long run. Since the awesome OSS community has stepped up with some great ideas, we’ve already broken ground on having two builds available: atomics and service workers. When the library runs, it’ll decide which to use depending on the browser’s support.

Currently, the plan is that the service worker trick will ultimately become the fallback, but there’s much more Atomics research to do. Good news for the future of Atomics is that Safari Tech Preview just enabled SharedArrayBuffer!

// Detect dark theme var iframe = document.getElementById('tweet-1443650219770617857-311'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1443650219770617857&theme=dark" }

What’s Next

Partytown is still in alpha and undergoing many changes on each commit 😬. But we're already actively running it on a few pages within Builder.io so we can collect more production data.

Additionally, we’re working with a few ecommerce sites who have significant third-party script usage, and see if we can help improve their performance and usability. We’d love to have you hop in our Discord channel and chat ideas, or even help test and file issues in our Github repo!

So please stay tuned as we continue this experiment. In follow up posts we’ll continue to dig deeper into other parts of the library, and as we gather more data we’re hoping to present some good hard numbers showing Partytown’s benefits.

Party on, Garth!

Introducing Partytown 🎉: Run Third-Party Scripts From a Web Worker

Adam Bradley — Thu, 23 Sep 2021 15:59:13 +0000

A fun location for your third-party scripts to hang out

Performance is always top of mind for any website or web app. It’s of no surprise that a page that loads instantly, has no scroll jank, and responds immediately to any interaction, will provide an all around better user-experience.

Even with a fast and highly tuned site following all of the 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, ad pixels, A/B testing, trackers, etc.

When it comes to improving site performance, resources often explain and document tangible improvements with what you can do to your code, but for the most part our hands are tied when it comes to improving third-party code.

Third-Party Script Performance Issues

The elephant in the room is that third-party scripts are often to blame for eating up a large chunk of the main thread’s precious resources. There’s a few tricks to reduce their upfront damaging effects, like waiting until after the page load to run these scripts.

But regardless, they’re still running hundreds of kilobytes (and commonly, even a few megabytes) of Javascript on your user’s main thread! And end-users’ mobile devices have less resources than the machines developers are building the sites on! This can drastically affect Lighthouse scores, Core Web Vitals, search rankings, and even increase bounce rates and reduce user-engagement due to poor user experience.

All of this has surfaced as we’ve been building out Qwik for Builder.io. The tldr is that we can make interactive sites load immediately with only HTML and CSS, and only pull in the Javascript you need on-demand. But either way, even with the fastest of the fastest frameworks (or no framework at all), third-party scripts continue to drain site performance. So we got to thinking...

Running Third-Party Scripts Within a Web Worker

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 relocated to a web worker. Into a sandboxed location, kinda like...a little town for third-party scripts. Some sort of a...Partytown, if you will…

Web workers have been a practical solution that can off-load resource intensive tasks off of the main thread for many years now. The challenge, however, is that workers do not have direct access to main thread APIs, such as window, document, or localStorage. A messaging system can be created between the two worlds, but because postMessage is asynchronous, DOM operations that third-party scripts are packed full of simply won’t succeed with a traditional messaging system.

For example, here’s a snippet of code found in Google Tag Manager:

var w = document.body.clientWidth;

There’s nothing special about this code, actually it’s pretty darn common. But, notice how it has to be synchronous, and there’s three blocking getters:

Get document
Get body
Get clientWidth

If we’re unable to refactor this code to use promises or callbacks instead, then an asynchronous messaging system wouldn’t allow this to “just work.” And I want to emphasize, “unable to refactor this code.”

The same third-party scripts that are being executed by billions of devices, even as you are reading these lines, cannot just be “refactored.” In a perfect world, I’d message Google and say, “Hey, you know that analytics code that gazillions of dollars are dependent on? Please refactor it entirely. Thank you.” Next, I’d have to DM every single service in the world to refactor their code too. Wish me luck, but results may vary.

Take Me To Partytown

Partytown is a lazy loaded 6kb library that helps 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.

But, the most important piece it brings to the table is allowing the web worker to synchronously read from the main thread. If code running within the web worker can call blocking DOM APIs with synchronous return values, then that means we can run, unaltered, third-party scripts in a worker. The third-party code happily executes as intended, but within a different thread as to not take resources away from your code.

Sandboxing and Isolation

Third-party scripts are often a black-box with large amounts of Javascript. What's buried within the obfuscated code is difficult to tell. It's minified for good reason, but regardless it becomes very difficult to understand what third-party scripts are executing on your site and your users’ devices, and on the same thread/context as your app's code.

Partytown, on the other hand, is able to sandbox and isolate third-party scripts within a web worker and allow, or deny, access to main thread APIs. This includes cookies, localStorage, userAgent, etc. Because the code must go through Partytown’s proxy in order to access the main thread, Partytown also has the ability to log every read and write, and even restrict access to certain DOM APIs.

Essentially, Partytown lets you:

Isolate third-party scripts within a sandbox.
Configure which browser APIs specific scripts can and cannot execute.
Option to log API calls and arguments in order to give better insight as to what the scripts are doing.

This could be useful for many different use-cases, including:

Blocking access to document.cookie
Providing a standard navigator.userAgent
Not allowing scripts to write to localStorage
Turning document.write() into a noop function
Block scripts from requesting other scripts

Current Status and What’s Next

Partytown is still in alpha, it is highly experimental and not ready for production. However, we’ve been actively testing it out on a few pages within our production site on Builder.io, and so far so good. Data is being collected as expected and our analytics look unaffected. Our goal is to collect the data now, so that it can be presented in future posts.

In the next post, I’ll be focusing on how the synchronous communication channel works and some of its trade-offs.

Additionally, we’ll show how you can start testing Partytown within a React or Next.js project, or really any website or web app. Here's a quick example of how Partytown can be used within a Next.js document, but much more to come in follow up posts:

import { Partytown, GoogleTagManager } from '@builder.io/partytown/react';
import Document, { Html, Head, Main, NextScript } from 'next/document';

export default class MyDocument extends Document {
  render() {
    return (
      <Html>
        <Head>
          <GoogleTagManager containerId={'GTM-XXXXX'} />
          <Partytown />
        </Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

If you’d like to learn more, or even help test, please come party with us on our Discord channel, or ping me at @adamdbradley. I’d love to ensure Partytown can work with your service or use-case, so please don’t hesitate to start a chat.

I’d also like to thank some awesome people we’ve been lucky enough to bounce ideas off of, and help validate if this could work IRL: Addy Osmani, Ilya Grigorik, Kristofer Baxter, Shubhie Panicker, Zach Leatherman, Misko Hevery, Steve Sewell and the entire Builder.io team.

Party on, Wayne!