---
title: "Do retargeting pixels fire on slow mobile data? What we measured, and how Linkbreakers waits for them"
description: "On a slow phone connection, the Meta Pixel and TikTok Pixel lost their page view before the redirect in every one of our test visits. We measured 175 visits across five network profiles, changed how the pixel page waits, and here are the results before and after, the trade-off, and what it does not solve."
canonical: "https://linkbreakers.com/help/article/how-retargeting-pixels-fire-on-slow-mobile-connections"
last-updated: 2026-11-04
---

# Do retargeting pixels fire on slow mobile data? What we measured, and how Linkbreakers waits for them

> On a slow phone connection, the Meta Pixel and TikTok Pixel lost their page view before the redirect in every one of our test visits. We measured 175 visits across five network profiles, changed how the pixel page waits, and here are the results before and after, the trade-off, and what it does not solve.

## Short answer

On a fast connection, a retargeting pixel fires before the visitor is redirected. On slow mobile data, it often did not. In our tests at 150 ms latency and 1.6 Mbps, the Meta Pixel and the TikTok Pixel sent **no page view in 5 of 5 visits each**, because the page redirected before their scripts were ready.

Linkbreakers now waits for the Meta and TikTok page views themselves, not just for their first script. With the change, the same visits sent and got an answer for **5 of 5 page views** for each pixel. The cost is a longer wait on slow connections only: up to 2 seconds, and only for links that have a pixel. Links without a pixel still redirect instantly.

## Why a redirect has to wait for a pixel

A retargeting pixel is JavaScript that runs in the visitor's browser. A plain redirect runs no JavaScript: the browser asks for the link, is told where to go, and goes. So when a link has a pixel, Linkbreakers sends people's visits through a brief page that loads the pixel and then redirects. Bots, link previews, AI agents and command-line tools such as curl keep the instant redirect.

The question is how long that page should wait. Too short and the pixel never sends its page view, so the visitor never joins your ad audience. Too long and the visitor stares at a blank page.

## Meta and TikTok load in two steps

Meta's base code downloads a library of functions and "automatically tracks a single PageView conversion" ([Meta Pixel documentation](https://developers.facebook.com/docs/meta-pixel/get-started)). TikTok's base code is installed the same way ([TikTok Pixel setup](https://ads.tiktok.com/help/article/get-started-pixel)). In our measurements, neither sends the page view as soon as its first script loads:

| Pixel | Step 1 | Step 2 | Then |
|---|---|---|---|
| Meta Pixel | `fbevents.js` (about 114 KB) | The pixel's own settings from `connect.facebook.net/signals/config/` (about 100 KB for our pixel) | Sends the PageView to `facebook.com/tr` |
| TikTok Pixel | `events.js` (about 2 KB) | `static/main.*.js` (about 112 KB) | Sends the page view to `analytics.tiktok.com/api/v2/pixel` |
| Google tag | `gtag.js` | None | Sends the page view right after the script loads |
| LinkedIn Insight Tag | `insight.min.js` | None | Sends the page view right after the script loads |

Sizes are compressed transfer sizes we measured on 2026-11-03. The step 2 file is what made the difference: our page used to leave 300 ms after step 1, which is plenty for Google and LinkedIn, but not for a second 100 KB download on a slow connection.

## How we measured

- **Browser:** Google Chrome emulating an iPhone (screen, touch and Safari user agent), with a fresh cache for every visit.
- **Pages:** the exact page Linkbreakers serves, rendered from its template, once as it was before the change and once after. The link without a pixel answers with a plain redirect.
- **Pixels:** a real Meta Pixel (our own test pixel), a TikTok Pixel and a Google tag. We tested Meta alone, TikTok alone, and Meta, TikTok and Google together.
- **Network profiles:** Chrome's network emulation adds latency to every request and limits bandwidth.

| Profile | Latency | Download |
|---|---|---|
| Fast | none added | the office line |
| 4G | 40 ms | 12 Mbps |
| Slow 4G | 100 ms | 4 Mbps |
| 3G | 150 ms | 1.6 Mbps |
| Very slow | 300 ms | 400 kbps |

- **Runs:** 5 visits per page and profile, 175 visits in total.
- **What we recorded:** when the browser started loading the destination (time to redirect, from the moment the link was opened), and for each pixel whether its page view request left the browser and whether the platform's server answered it.

We count a page view as delivered only when we saw the platform answer it. A request that left the browser but whose answer we never saw may still have reached the platform; we cannot tell from the browser, so the counts below are conservative.

The pages were served from the same machine as the browser, so the times show what the visitor's browser and network add. A real scan also includes Linkbreakers' own server time, a median of 65 ms (see [how fast is a Linkbreakers scan](/help/article/how-fast-is-a-linkbreakers-scan)).

## Results: page views delivered

In the charts, the light bars are before the change and the solid purple bars are after it.

### Meta Pixel alone

**Meta PageViews answered, out of 5 visits**

- **0 → 5** Meta PageViews answered on 3G
- **2 → 5** Meta PageViews answered on Slow 4G

| Profile | Before the change | After the change |
|---|---|---|
| Fast | 5 of 5 | 5 of 5 |
| 4G | 5 of 5 | 5 of 5 |
| Slow 4G | 2 of 5 | 5 of 5 |
| 3G | 0 of 5 | 5 of 5 |
| Very slow | 0 of 5 | 0 of 5 |

Meta Pixel alone, 5 visits per network profile, counted only when Meta answered the PageView.

### TikTok Pixel alone

**TikTok page views answered, out of 5 visits**

- **0 → 4** TikTok page views answered on 4G
- **0 → 5** TikTok page views answered on 3G

| Profile | Before the change | After the change |
|---|---|---|
| Fast | 4 of 5 | 5 of 5 |
| 4G | 0 of 5 | 4 of 5 |
| Slow 4G | 0 of 5 | 5 of 5 |
| 3G | 0 of 5 | 5 of 5 |
| Very slow | 0 of 5 | 0 of 5 |

TikTok Pixel alone, 5 visits per network profile, counted only when TikTok answered the page view.

On 4G before the change, TikTok's page view left the browser in 5 of 5 visits, but the page was already leaving and we never saw TikTok answer it.

### All the numbers

Page views answered out of 5 visits, before and after the change.

| Profile | Meta alone | TikTok alone | Meta, with TikTok and Google | TikTok, with Meta and Google | Google, with Meta and TikTok |
|---|---|---|---|---|---|
| Fast | 5 → 5 | 4 → 5 | 5 → 5 | 3 → 5 | 5 → 5 |
| 4G | 5 → 5 | 0 → 4 | 5 → 5 | 0 → 4 | 5 → 5 |
| Slow 4G | 2 → 5 | 0 → 5 | 4 → 5 | 2 → 5 | 5 → 5 |
| 3G | 0 → 5 | 0 → 5 | 0 → 0 | 0 → 0 | 0 → 0 |
| Very slow | 0 → 0 | 0 → 0 | 0 → 0 | 0 → 0 | 0 → 0 |

Each cell reads "before → after". With three pixels on a 3G profile, the three downloads share the same 1.6 Mbps, and none of the page views is out by 2 seconds; in a separate test with no limit on the wait, they were answered after about 3.4 seconds.

## Results: time to redirect

Median time from opening the link to the browser starting to load the destination, in milliseconds.

**Median time to redirect with a Meta Pixel**

- **287 ms** on a fast connection, was 468 ms
- **1,879 ms** on 3G, was 1,267 ms

| Profile | Before the change | After the change |
|---|---|---|
| Fast | 468 ms | 287 ms |
| 4G | 545 ms | 431 ms |
| Slow 4G | 840 ms | 978 ms |
| 3G | 1,267 ms | 1,879 ms |
| Very slow | 1,653 ms | 1,679 ms |

Median time from opening the link to the browser starting to load the destination, Meta Pixel alone.

| Profile | No pixel | Meta alone | TikTok alone | Meta, TikTok and Google |
|---|---|---|---|---|
| Fast | 4 | 468 → 287 | 536 → 519 | 635 → 702 |
| 4G | 45 | 545 → 431 | 565 → 664 | 645 → 755 |
| Slow 4G | 107 | 840 → 978 | 690 → 991 | 1322 → 1431 |
| 3G | 162 | 1267 → 1879 | 781 → 1442 | 1389 → 2204 |
| Very slow | 327 | 1653 → 1679 | 1160 → 2479 | 1648 → 2477 |

Cells with a pixel read "before → after". The no pixel column is the same before and after: those links never load the page. Times include loading the brief page itself, which takes one round trip before any pixel starts.

## What changed

The page now watches the requests the browser makes, through the browser's standard [resource timing](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming), instead of guessing:

1. **Meta and TikTok:** the visitor leaves as soon as the platform has answered the page view. If the page view cannot be seen, the visitor leaves 300 ms after the step 2 file has loaded.
2. **Google tag, LinkedIn and Google Tag Manager:** as before, 300 ms after their script has loaded.
3. **Normal limit, 1.2 seconds:** the page never waits longer, unless a Meta or TikTok page view is already on its way.
4. **On its way at 1.2 seconds:** if a Meta or TikTok script has loaded and its page view is not answered yet, the page waits for it up to **2 seconds**, and leaves as soon as it is answered.
5. **Nothing to wait for:** a script blocked by an ad blocker stops being waited for, and a page with no pixel at all leaves at once.

These limits count from the moment the page starts running. The times in the results above also include loading the page itself, one round trip on the connection, which is why the slowest ones are above 2 seconds.

We chose 2 seconds from the 3G results: Meta alone was answered about 1.7 seconds after the page started, and TikTok alone about 1.3 seconds. Covering three pixels on the same connection would take about 3.5 seconds, which we judged too long to make a person wait.

## The trade-off

**What you gain**

- Visitors on slow mobile data now join your Meta and TikTok audiences. These are often exactly the people who scan posters and flyers outdoors.
- On fast connections a Meta link is now quicker: the page leaves as soon as Meta answers, instead of a fixed 300 ms after its script (287 ms against 468 ms in our fast runs).

**What it costs**

- On slow connections, people wait longer before reaching your page: up to 2 seconds instead of 1.2 seconds, and only when a Meta or TikTok page view is on its way.
- On very slow connections (300 ms, 400 kbps) and with several pixels on 3G, the page can wait the extra time and still not get the page view out. TikTok alone on the very slow profile went from 1.2 to 2.5 seconds with no page view either way.
- A TikTok link on 4G now waits for TikTok's answer, about 100 ms longer than before.

**What does not change**

- Links without a pixel never load the page and redirect instantly. We checked this with automated tests on the scan itself: the same redirect, no page, and no extra database work.
- Bots, link previews, AI agents and command-line tools never load the page.

## Limits: what this does not solve

- **Ad blockers and content blockers.** If the pixel's script is blocked, no page view can be sent. The page notices the blocked script and stops waiting for it.
- **Very slow connections.** At 300 ms and 400 kbps, neither Meta nor TikTok got its page view out within 2 seconds in our runs; TikTok alone needed about 4 seconds in a test with no limit on the wait. A longer wait would recover some of them, at the cost of keeping people on a blank page.
- **Server-side conversions.** Pixels fire in the browser. Reporting scans to an analytics tool from our servers, with no wait at all, is what the [Google Analytics 4 integration](/help/article/google-analytics-4-integration-for-qr-codes-and-links) does.
- **iPhone specifics.** We measured in Chrome. Safari also supports resource timing; where a browser does not report a request, the page falls back to 300 ms after the step 2 file. Separately, Safari caps cookies that scripts set, such as the pixels' own, to seven days ([WebKit, Intelligent Tracking Prevention 2.1](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/)), which limits how long a visitor can be matched later whatever the redirect does.
- **Consent.** In the EU, pixels set marketing cookies that usually need the visitor's consent, and a banner has no time to be answered on a page that redirects within seconds.

## Frequently asked questions

### Does this slow down links without a pixel?

No. A link that no pixel fires on answers with a plain redirect, exactly as before. The brief page is never loaded, so there is nothing to wait for.

### Why not always wait longer?

Every extra second is a second the visitor stares at a blank page before your content. The data showed that 2 seconds recovers the single-pixel cases on 3G, while recovering three pixels on 3G or anything on very slow connections would need 3.5 seconds or more.

### Does this change the Google tag or LinkedIn?

No. Both send their page view right after their script loads, so they keep the 300 ms after their script. The Google tag's page view was answered in every test where Meta's and TikTok's were; LinkedIn was not part of the measured runs.

## Sources

- Linkbreakers measurements, 2026-11-03: 175 visits in Chrome with network emulation, raw results kept with the test that covers this behaviour
- Meta Pixel base code: https://developers.facebook.com/docs/meta-pixel/get-started
- TikTok Pixel setup: https://ads.tiktok.com/help/article/get-started-pixel
- Resource timing in browsers: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
- WebKit, Intelligent Tracking Prevention 2.1: https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/