[Feature] <Script /> component with web-worker support for third-party scripts

[benjaminsehl]

Third party scripts, like tracking pixels and widgets, can be a huge drain on performance (especially in ecommerce). Whether extending the <Scripts /> API, or providing a new component like Next.js' <Script />, it would be very helpful to be able to apply best practices to loading these scripts, and additionally leveraging something like Partytown to offload scripts from the main thread onto a web-worker.

Has this been discussed or considered?

A great article on this topic: https://www.patterns.dev/posts/third-party/

[ryanflorence]

I've never really looked deeply into these kinds of things but my intuition has always been that it has nothing to do with a framework like Remix, does it?

• Does it require the bundler to be aware of the tracker packages and serve them differently?
• Does it require some runtime integration with data loading / rendering?

I'd like to hear why it can't just be a <script> or part of your entry.client.jsx or root.tsx?

[benjaminsehl]

Does it require the bundler to be aware of the tracker packages and serve them differently?

I wouldn't imagine this would be automatic, and would require some user specification on the desired behaviour type.

Does it require some runtime integration with data loading / rendering?

Yes — I know we ran into some issues getting Partytown working with Oxygen, and believe there is some differences between Node vs. Workers, etc.

I'd like to hear why it can't just be a <script> or part of your entry.client.jsx or root.tsx?

The article I linked to at the end there (https://www.patterns.dev/posts/third-party/) does a thorough job of overviewing the issue overall. I'm not a good enough dev to know why entry or root would/would not make sense. Tagging @juanpprieto to weigh in more here, who explored a lot of this for the original Hydrogen framework, and has a lot of experience with this on client sites from his agency days.

From what I do know — while you certainly can instrument some of this on your own (e.g. this guide), it requires a good chunk of work and domain knowledge to get it done. In the same way that Image and Seo components can be a helpful shortcut in getting a best-practice outcome complete with minimal markup, this does the same.

Originally had considered this as a feature of Hydrogen, as we've seen many developers fall into this trap, as ecommerce sites tend to have a ton of tracking scripts on them, and all big performance offenders. However as it wasn't specific to ecommerce, with prior art from Next having it at the framework layer, I thought it would be best to first bring this up here for discussion.

Considering that Remix keeps things quite lean — it may be best as an independent "add-on" package, as opposed to a part of the core library. Perhaps something — at least for Hydrogen's purpose — we should be doing, and then can come down to Remix's world if appropriate.

Does Remix have a thought around the boundaries you want to play in?

[mjackson]

I believe the reason Next uses <Script> elements is because historically Next didn't actually give you access to the document markup, so it was a kind of react-helmet-ish way to get something into the document head/body because you weren't able to do it yourself. It seems like superfluous API in Remix, and probably Next as well since they now give you access to the document HTML.

[mjackson]

Creating our own <Script> abstraction around HTML's built-in <script> has the potential to leak and cause confusion. I'd prefer to teach people how to use <script async> and <script defer> and where to put their <script> elements instead of giving them an abstraction that obscures what's actually going on behind the scenes. Bonus is we can avoid writing articles that explain how to use our custom API.

I read the article you linked to @benjaminsehl and I'm still not clear on what exactly they mean by "interactive" as in "beforeInteractive". Does it refer to the DOMContentLoaded event? Or does it refer to some time after they have finished loading all the data they need?

Maybe for the case of specific tag managers we could have some higher-level thing, like a <GoogleTrackingPixel> element that would be provider-specific. But I tend to think that would be the right level of abstraction.

[benjaminsehl]

Thanks for the consideration @mjackson & @ryanflorence — I totally understand your position, and assumed that would be the case. FWIW, I applaud the restraint!

I'll have a go at some experimentation and see where I run into trouble before pushing this further.

As I think about it, I'm really just going after an easier ergonomic for setting up Partytown — but there is probably a better way to approach that than to obfuscate setup through adding to Remix. First thoughts would include a default inclusion in our Demo Store, a CLI command with jscodemod to scaffold, etc.

I'd advise against doing anything that's vendor specific — there is no more populated arena than adtech, and it's the ones are a little lower on the list (but hyper-common in ecommerce) who are the worst offenders.

One specific one that may make sense, is this feature of Shopify, but that should be in Hydrogen-land I'd think.

[DavidWittness]

Coming from the user land, it's far too easy to drop a <script> into a page that undermines all the hard work that has gone into making the site performant. I've seen it many times (I may have been guilty of it myself 😆 ).

One DX tool I noticed while working on my first Remix project was the helpful warnings and errors provided by Remix. <package> is possibly an ESM only package and should be bundled with "serverDependenciesToBundle in remix.config.js..

Maybe a good DX here is a similar warning for all non-deferred third party scripts added to the page. Something like <script> is render blocking. Consider adding a "defer" flag or using another pattern for loading third party scripts: https://www.patterns.dev/posts/third-party/

I think this is is a nice way to gently nudge towards a better outcome without being overly opinionated or prescriptive.

[mjackson]

Mmm, I love the thought of providing some feedback based on the <script> tags being rendered. We could possibly even provide some vendor-specific messaging based on the <script src> to explain the optimal way to include that particular script in the page.