---
title: "Blog"
description: "Read about the background of our monitoring solution, new features and case studies"
canonical: "https://www.rumvision.com/blog/increased-inp-impact-from-meta-pixel/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog

# Increased INP impact from Meta Pixel. Here's what we found

Why is Meta Pixel suddenly showing up more often in slow interactions? After spotting the same INP regression across multiple websites, we dug into its click handling as well as historic versions and found some interesting clues.

The pattern is remarkably consistent: JavaScript from `fbevents.js` shows up during click interactions, with `#document.onclick` as the invoker.

Our data is showing a **77.5% regression** when comparing data from April 2026 with data from August 2026. See the screenshot below.

[![facebook-js-time-per-loaf-invoker-mobile-p75.png](https://www.rumvision.com/file/upload/img/blog/facebook-js-time-per-loaf-invoker-mobile-p75.png)](https://www.rumvision.com/file/upload/img/blog/facebook-js-time-per-loaf-invoker-mobile-p75.png)

I then started checking other sites and saw similar regressions coming from Facebook's event tracking script. So I [posted about this on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7500606117295616000/).

We are not the only ones seeing it. Similar observations have surfaced around Shopify websites, which made us curious: did something change in Meta Pixel's click handling?

> I can confirm we're seeing the same thing across the whole platform
> 
>  Mateusz Krzeszowiak from [Shopify performance team](https://performance.shopify.com/pages/meet-the-team)

It also isn't just the 75th percentile that is impacted. It is [showing a regression across every percentile](https://www.rumvision.com/file/upload/img/blog/facebook-js-time-mobile-percentile-chart.png).

## Timeline research

To start my research, I needed historic versions of `fbevents.js`. I knew the Wayback Machine could retrieve historic webpages, but wasn't sure whether individual JavaScript files were archived as well. They were, so I fetched Pixel versions around each date where our timeline showed a clear regression.

[![facebook-js-time-timeline.png](https://www.rumvision.com/file/upload/img/blog/facebook-js-time-timeline.png)](https://www.rumvision.com/file/upload/img/blog/facebook-js-time-timeline.png)

### 1st regression: June 6th

Around June 6–7, we see the first clear step-up in execution time as it went **from 34 to 39ms**.

A comparison between [Meta Pixel 2.9.329](http://web.archive.org/web/20260531000123/https://connect.facebook.net/en_US/fbevents.js) and [2.9.334](http://web.archive.org/web/20260607235413/https://connect.facebook.net/en_US/fbevents.js) does not show a new click listener or new geometry checks. Those already existed.

What did change is Meta's parameter-extraction pipeline:

- support for custom parameters was added (`custom_parameter_name`)
- and partially valid extractor configurations could now still be accepted.
 
That potentially allows more automatic extraction work to run behind the existing click handling, although this diff alone is not enough to prove it caused the regression.

### 2nd regression: July 1st

Around July 1–2, we see another clear step-up, this time from roughly **39ms to 49ms**.

During this period, Meta Pixel moved from version 2.9.334 to [2.9.349](http://web.archive.org/web/20260702235628/https://connect.facebook.net/en_US/fbevents.js), and reached version [2.9.361](http://web.archive.org/web/20260726002525/https://connect.facebook.net/en_US/fbevents.js) by July 26th. Unlike the first regression, I did not find an obvious change to its existing button-click detection, Event Setup Tool rule matching or geometry checks.

Meta did continue expanding other automatic functionality. This included:

- improved Facebook click-ID handling
- and, later in July, considerably more Automatic Advanced Matching logic for values such as phone numbers, postal codes, states and gender.
 
Some of this processing is experiment-driven and can include additional normalization and browser-locale checks.

A relevant string that appears in this period is:

 ```
enableBetterFbcDetection
```

Those additions show that the Pixel was becoming more complex during the same period, but we still cannot directly connect them to the `#document.onclick` regression. The button-click experiment and its existing layout-dependent checks were already present before this second increase.

### 3rd regression: August 1st

Around August 1st, we see the third and largest step-up in execution time, increasing from roughly **49 to around 59ms**.

This regression lines up with a remarkably fast rollout of a large set of Meta's Automatic Advanced Matching experiments.

In Meta Pixel [2.9.363](http://web.archive.org/web/20260728000037/https://connect.facebook.net/en_US/fbevents.js) on July 28th, many of these experiments were already present, but were allocated to only 1% of page loads. This included features such as:

- Shadow DOM extraction
- expanded element selectors
- SPA form observation
- data-attribute classification
- same-origin iframe extraction
- and FormData extraction.
 
For example, the experiment configuration contains names such as:

 ```
"name":"aam_shadow_dom_extraction"
```

There is another detail worth highlighting. In 2.9.363, the platform-specific experiments for WooCommerce, BigCommerce, Magento, Klaviyo and several other platforms were still configured with an allocation of `0`. By July 30th, version [2.9.364](http://web.archive.org/web/20260730001842/https://connect.facebook.net/en_US/fbevents.js) had moved those partner-specific experiments to 1% as well.

The source contains separate experiment gates such as `aam_woocommerce_partner_integration`, `aam_partner_bigcommerce`, `aam_partner_magento` and `aam_partner_klaviyo`. That tells us Meta has platform-specific Automatic Advanced Matching paths rather than treating every website identically. The global bundle does not reveal enough to claim exactly which selectors or data sources are different for every platform, so I would not interpret these as performance exemptions. They are separate platform-aware matching experiments.

One day later, version [2.9.366](http://web.archive.org/web/20260731175541/https://connect.facebook.net/en_US/fbevents.js) increased the allocation of the broader experiment set to 10%.

By August 2nd, version [2.9.368](http://web.archive.org/web/20260801001728/https://connect.facebook.net/en_US/fbevents.js) had moved those same experiments to an allocation of 1, effectively completing a rollout from around 1% to 100% in only a few days.

The timing closely matches the largest regression in our RUM data. It still does not prove that one specific AAM feature caused the increase in `#document.onclick` time, but the gradual 1% → 10% → 100% rollout provides a much stronger correlation than a simple version change.

## What happens during a click

The timeline gives us useful correlation, but it does not explain why Meta Pixel can show up with so much JavaScript time during an interaction. For that, we need to look at the click path itself.

The first important finding is that Meta listening for clicks at document level isn't new. Meta Pixel has supported automatic click detection for a long time, so the regression cannot simply be explained by Meta suddenly adding a `document.onclick` listener.

### The work behind a click

What is more interesting is **how much work can happen behind that listener**.

A regular link click can cause Meta to inspect the clicked element and surrounding DOM. Among other things, the code can extract:

- element text
- ID and classes
- destination URL
- image information
- element type and name
- child buttons
- whether a link is outbound
- whether the destination looks like a downloadable file
 
### Event Setup Tool rules

That information can then be used by Meta's automatic event detection and its EST rule engine. EST stands for Meta's **Event Setup Tool**, the functionality that allows events to be configured based on interactions with elements on a page without manually adding event code for every element.

The EST rule engine can evaluate click rules using properties such as destination URL, text, element ID, class name and image URL. In the Pixel source, a `CLICK` rule can ultimately map to `SubscribedButtonClick`.

 ```
CLICK: "SubscribedButtonClick"
```

So something as innocent as clicking an article link can potentially result in considerably more JavaScript than just registering that a click happened.

## Interesting geometry reads

While determining whether an element qualifies as a button-like element, Meta performs geometry checks. The code contains reads such as:

 ```
element.getBoundingClientRect().height
```

with a fallback to:

 ```
element.offsetHeight
```

Both APIs require the browser to know the element's current geometry. They do not always trigger layout, but if style or layout is dirty at that point, reading them can force the browser to synchronously update style and/or layout before JavaScript can continue.

That makes their position in the click path important. Meta is not necessarily doing only JavaScript during the interaction. Depending on the state of the page, its JavaScript can also cause the browser to perform synchronous rendering work before the handler can continue.

### Potential forced synchronous layout

A click could roughly become:

 ```
User clicks → document.onclick → inspect DOM → read geometry → potential layout flush → classify → extract → evaluate rules
```

That is particularly relevant to INP because this work happens as part of the interaction itself. On slower devices, the cost can become disproportionately visible.

## Reproducing it in DevTools

So far, the RUM data and historic Pixel versions point in the same direction. But could we reproduce that difference in a controlled lab test?

To find out, I repeated the same interaction using Meta Pixel 2.9.329 and the current 2.9.390 version, including the corresponding `signals/config` for each version.

Both tests were performed in incognito browser sessions with the same CPU throttling to minimize interference from browser extensions and other open tabs.

### The newer Pixel spends more time on the same click

Interestingly, the overall interaction with the older Pixel was actually slightly longer. But the click's processing time itself was almost identical: roughly 209ms in both traces.

What changed was Meta's share of that work. The execution scopes originating from Meta increased from roughly **80ms with Pixel 2.9.329 to 99ms with 2.9.390**. Thread CPU time within those scopes increased from approximately **32ms to 42ms**.

That means the newer Pixel/config combination occupied roughly 23% more wall-clock time and 32% more thread CPU time during the same interaction.

A single [lab comparison cannot explain](https://www.rumvision.com/blog/understanding-the-difference-between-core-web-vitals-tools/?format=md) the full 77.5% regression we see in the field. But importantly, it reproduces the same direction: **the newer Meta Pixel/config combination spends more main-thread time processing the same interaction.**

### Death by a thousand cuts

There doesn't appear to be one expensive new function responsible for the additional work. Instead, this looks more like **death by a thousand cuts**.

Meta's click-processing pipeline already existed in the older Pixel. What changed is the amount of automatic extraction, matching and classification logic available around it.

The newer Pixel contains substantially more Automatic Advanced Matching logic for inspecting forms, attributes, accessible labels and other DOM signals. This includes functionality for form scanning, data-attribute classification, autocomplete and inputmode detection, accessible-name extraction and other ways of identifying user data and element context.

Additions and expansions in the newer tracking pixel are outlined in red.

[![facebook-tasks-before-after.png](https://www.rumvision.com/file/upload/img/blog/facebook-tasks-before-after.png)](https://www.rumvision.com/file/upload/img/blog/facebook-tasks-before-after.png)

Not every one of these code paths necessarily runs during every click. But the code changes show how much broader Meta's automatic data collection has become, while our lab trace shows that the newer Pixel consumes more CPU during the same interaction.

[![facebook-fb-events-line-numbers.png](https://www.rumvision.com/file/upload/img/blog/facebook-fb-events-line-numbers.png)](https://www.rumvision.com/file/upload/img/blog/facebook-fb-events-line-numbers.png)

The growth of the Pixel from 20285 lines of code to 21978 lines of code illustrates the same trend. Between the versions used in our comparison, `fbevents.js` gained a substantial amount of additional logic. More code does not automatically mean worse performance, but in this case some of that growth is directly related to the automatic extraction and classification functionality we found during the same period.

Together with the gradual increase in our RUM data, this makes the regression look less like one newly introduced bottleneck and more like an existing interaction pipeline that has gradually accumulated more work.

## How to improve

### What Meta could improve

The bigger performance concern is not that Meta wants to classify clicks or improve matching. It is that non-critical analytics work can end up competing with the user interaction that caused it.

This is also a well-established INP optimization principle. Google's web.dev guidance recommends [breaking up long tasks](https://web.dev/articles/optimize-long-tasks) and [yielding non-critical work](https://developer.chrome.com/blog/use-scheduler-yield) back to the browser. It's something [we've discussed at performance events ourselves](https://www.rumvision.com/blog/performance-now-2024/?format=md) as well.

Meta can't defer everything, but click handlers should do the minimum work needed. Non-critical extraction, classification and AAM processing should happen outside the interaction's critical path wherever possible.

### What can website owners do?

Website owners have less control because the expensive code lives inside Meta's script, but that does not mean there are no options.

The first step is to verify the impact with real-user data rather than assuming every Meta Pixel installation behaves the same. Meta can load configuration per Pixel ID, so two websites running the same `fbevents.js` may not necessarily execute exactly the same feature set.

If Meta Pixel is hurting INP, consider limiting where it runs, delaying it, or sampling its deployment through GTM.

For teams that rely heavily on Meta attribution, reducing browser-side Pixel usage may need to be balanced against measurement quality and server-side tracking such as Conversions API. This is a business and attribution decision as much as a performance decision.

At roughly 60ms, Meta alone can consume a significant part of the 200ms INP budget, leaving less room for your own JavaScript and other third parties.

## So, did Meta recently make INP worse?

We cannot prove a single causal code change yet. But the combination of our field data, Shopify's data findings and the historic Pixel versions is becoming difficult to dismiss as a single-site implementation issue.

What we can establish is that Meta already had document-level click processing and layout-dependent checks before the regression. During the same months that our RUM data shows three step-ups, Meta continued expanding its automatic extraction capabilities. Most notably, around the largest August regression, a large group of Automatic Advanced Matching experiments went through a rapid staged rollout from around 1% to 10% and then 100%.

Our current hypothesis is therefore not that Meta recently introduced click tracking. Instead, **more work appears to be happening around an already existing click-processing pipeline**, while Meta has simultaneously expanded the amount of automatic DOM, form and matching functionality available to the Pixel.

That does not prove that every newly rolled-out AAM feature runs synchronously inside `#document.onclick`. The historic bundle alone cannot establish that causal path. But it does give us a concrete rollout timeline that closely matches the largest change in our real-user data.

Until the cause is clearer or the interaction cost comes down, website owners seeing the same pattern should at least treat Meta Pixel as part of their INP budget rather than as performance-free analytics.

We would be very interested to hear from other performance teams seeing the same `#document.onclick` impact. Feel free to chime in via [LinkedIn thread](https://www.linkedin.com/feed/update/urn:li:activity:7500606117295616000/) or [Bluesky thread](https://bsky.app/profile/erwinhofman.bsky.social/post/3mukbymzl2s2q).