Investigate offloading woocommerce-google-analytics-integration to a worker in Web Worker Offloading

[westonruter]

The woocommerce-google-analytics-integration script had to be removed from being offloaded to a worker in #1740 due to events like add_to_cart not being sent. We should investigate further why this wasn't working and potentially re-offload that script to the worker.

[ShyamGadde]

It seems the root cause of this issue lies in how the woocommerce-google-analytics-integration script attaches the onadded_to_cart function to document.body. The integration script sets up document.body.onadded_to_cart as an event handler to track the custom added_to_cart event dispatched by WooCommerce Core in order to send the add_to_cart event data to GA.

A key issue here is that WooCommerce Core uses jQuery's .trigger() to dispatch the added_to_cart event (code ref):

$( document.body ).trigger( 'added_to_cart', [ response.fragments, response.cart_hash, $thisbutton ] );

jQuery's .trigger() creates synthetic events that are not part of the native DOM event system. As a result, these events are not accessible to tools like Partytown, which rely on standard DOM events to forward interactions between the main thread and a Web Worker.

When the woocommerce-google-analytics-integration script is offloaded to a Web Worker, the onadded_to_cart function is registered in the worker instead of the main thread.

(credit to @b1ink0 for helping figure this out)

This limitation appears to be specific to Classic themes. Block themes handle these interactions differently (code ref), which might explain why the issue doesn't occur there.

Potential Workaround

A possible workaround involves creating a "stub" or "proxy" function in the main thread that bridges the gap between the main thread and the Web Worker. The idea is to capture the added_to_cart event in the main thread and forward it as a native DOM CustomEvent that can be intercepted by the Web Worker.

Here's a proof-of-concept (still hacky):

add_action(
	'wp_footer',
	static function (): void {
		?>
		<script>
			// Main thread: Define a proxy handler for added_to_cart events in the main thread.
			document.body.onadded_to_cart = function(...args) {
				const customEvent = new CustomEvent('wwo_wc_added_to_cart', {
					detail: args,
				});
				document.dispatchEvent(customEvent);
			};
		</script>

		<script type="text/partytown">
			// Web Worker: Listen for the proxied event in the worker and trigger the real handler.
			document.addEventListener('wwo_wc_added_to_cart', (event) => {
				if (document.body.onadded_to_cart) {
    				        // Call the original handler with the passed arguments
					document.body.onadded_to_cart(...event.detail);
				}
			});
		</script>
		<?php
	}
);

This workaround leverages the native CustomEvent system to bridge the communication gap. It ensures that the event data can be forwarded to the Web Worker, where the actual tracking logic can be executed.

Initial testing shows that this approach restores functionality for add_to_cart events when using Web Worker offloading.

wwo-wc.mp4

[westonruter]

Great investigation! Nevertheless, unless there is a demonstrated performance value for moving woocommerce-google-analytics-integration script to a worker then perhaps this workaround isn't warranted. In the end, gtag is still running in the worker at present, so that's the most important thing.