RFC: Web Worker support in next/script

[housseindjirdeh]

This is a proposal to allow Next.js developers to off-load any third-party script to a Web Worker in order to run in a background thread.

<Script
  src="https://third-party.com/script.js"
  strategy="worker"
/>

Background

Web workers are scripts that run in a background thread independent of those that execute and run directly on the browser’s main thread. Isolating JavaScript that does not populate or interact with the immediate UI of a page to a web worker frees up main thread processing, which can improve page load performance.

The Script component in Next.js simplifies the process of loading third-party scripts in a few ways:

• Scripts can be inserted in any component in a Next.js app without needing to append to next/head or be placed in _document.js
• Deciding when to fetch and execute a script is simplified by the use of a strategy property. There are three strategies that are currently supported:
  • beforeInteractive: Load script before page becomes interactive
  • afterInteractive: Load script immediately after page becomes interactive
  • lazyOnload: Load script during browser idle time

Proposal

Although the Script component supports two strategies (beforeInteractive, afterInteractive) to defer loading of third-party scripts and prevent them from being render-blocking, this proposal suggests the addition of a fourth strategy; worker.

import Script from 'next/script';

<Script
  src="https://third-party.com/script.js"
  strategy="worker" // script is off-loaded to a worker thread
/>

Why?

The following table provides data on the average and median download times of render-blocking, third-party scripts across all Next.js sites grouped by category.

Category	Download time (s)
	Average	Median
Tag Managers (e.g. Adobe Tag Manager, Google Tag Manager)	1.82	1.73
Analytics (e.g. Google Analytics, Optimizely)	1.67	1.54
Utility (e.g. Google Maps, Mapbox, Stripe)	1.59	1.39
Ads (e.g. Google/Doubleclick Ads, Criteo)	1.44	1.36
Customer success/chat support (e.g. Google/Doubleclick Ads, Criteo)	0.98	1.04
Marketing (e.g. Mailchimp, Hubspot)	1.15	1.03

• How to read this table: The average download time of a render-blocking tag manager script in a Next.js site is 1.82s.
• Where is this data from?: HTTP Archive and Lighthouse, where queries similar to those used in Third Party Web where utilized but modified to only focus on scripts that are render-blocking.

This data shows that a significant number of third-party scripts used in Next.js sites that introduce extrinsic functionality (i.e. not critical to rendering immediate UI) are render-blocking with a non-trivial download time (~1s). The current recommendation is to fetch these types of scripts after the page becomes interactive or during idle time, but this still opens up the possibility of them competing with other resources that load late. For a lot of these scripts, the ideal approach would be to move their processing entirely to a separate thread in order to not compete with any page resources whatsoever, but there is no easy way to do this.

How?

The concept of using web workers to move processing of heavy, non-critical scripts that have been fetched externally is new and highly experimental. Web workers communicate asynchronously with the main thread and cannot access the DOM, where many third-party scripts directly access the DOM in a synchronous manner.

With that being said, there are two different approaches being considered to include experimental web worker support for next/script:

1. Dynamically import and use PartyTown

PartyTown is a 6 kB library that can isolate resource heavy scripts into a web worker. PartyTown can be ncc’d directly as a dependency in Next.js and lazy-loaded only when a component uses a Script component to move processing of a third-party script into a worker.

Pros:

• Less effort than implementing a custom solution
• PartyTown’s underlying logic relies on web workers, service workers, and proxies to allow synchronous communication between the main and worker threads. This isn’t possible with web workers on their own, and may be necessary in order to support the many third-party scripts that work by accessing the DOM synchronously

Cons:

• Partytown’s web worker and service worker scripts must be hosted from the same origin as the HTML page and not a CDN
• A /~partytown/ directory must be present to serve static files. This would would have to be taken care of in the Next.js app static server or via a copy task as a bundler step

2. Build a custom web worker solution

Pros:

• Not constrained to a library implementation

Cons:

• Web workers cannot access the DOM. Many third-party resources modify or read from the DOM
• Significantly more effort to implement

---

Using web workers to handle processing of third-party scripts is a very experimental technique and not technically possible without extra “magic”. For this reason, the first approach of using PartyTown is the proposed solution. If this feature gains adoption, switching to a custom solution will be considered in the future if that comes with advantages of its own.

The next steps are for myself to quickly prototype embedding PartyTown directly in Next.js, verify its feasibility, and then gather data on how much it can improve sample sites that use many third-party scripts.

Any thoughts? Suggestions? Please share! 💬

[mustafaabobakr]

YES. I can't get a higher score due to the Minimize main-thread work on mobile audit. Even though the site is SSG.
https://diettodoor.com/

Here is a comparison

[johnilizy17]

<Script src="https://third-party.com/script.js" strategy="beforeInteractive" /> this is the correct application not strategy = "worker"

[steve8708]

For this interested - you can use Parytown with Nextjs easily today! More info over here https://github.com/BuilderIO/partytown/wiki/Getting-Started#add-partytown-snippet-to-the-head

import Head from "next/head";
import { Partytown } from "@builder.io/partytown/react";

const Home = () => {
  return (
    <>
      <Head>
        <title>My App</title>
        <Partytown />
        <script src="https://example.com/analytics.js" type="text/partytown"></script>
      </Head>
      <main>...</main>
    </>
  );
};

export default Home;

[adamdbradley]

Documentation has been updated with a NextJS example: https://partytown.builder.io/nextjs

[FreTimmerman]

disclaimer: i'm not a pro in this topic, i'm just asking a question

Is it possible to execute even the 1st party scripts (those served on _next/static/chunks/abcxyz.js) off the main thread?

I have a SSG deployed website, but lighthouse still "complains" about Reduce JavaScript execution time and Minimize main-thread work even though I would think this JS doesn't really impact the initial page load, since the initial html is served statically and all the js is doing is rehydrating for faster navigation to other pages

Or if I can safely ignore those warnings (since i'm using SSG anyway), that'd be cool to know