Fix Below Average Landing Page Experience Caused by Slow Ad Clicks

We keep seeing the same complaint: the site tests fast in PageSpeed Insights and GTmetrix, yet Google Ads rates the landing page experience as “Below average”. Both can be true at once. Landing page experience takes speed into account, and the visitors arriving from your ads often get a far slower site than the one the speed test sees. Here is how we diagnose it and fix it on client sites.

Why paid clicks get the slow version of your site

A speed test loads a clean URL. A paid click arrives with tracking parameters on the end of it. Standard ones, like the UTM set or Facebook click IDs, are widely recognised and caching tools generally handle them. The trouble comes from non-standard strings: Google’s own gad_source, click fraud tools such as ClickCease, call tracking such as CallRail, and other third-party tools that add their own parameters.

To the page cache, a URL with an unfamiliar parameter is a different page. It bypasses the cache and any speed optimisation, so the server builds the page from scratch for every click. The result is a high Time to First Byte (TTFB) for exactly the visitors you are paying for. In other words, your most expensive traffic gets the slowest site.

Step 1: confirm it is a TTFB problem

Run a free Core Web Vitals report on the domain and look at the TTFB distribution. On a healthy site we expect it to be mostly green (around 60 to 70 percent), some orange and a thin sliver of red. When that picture is flipped and red dominates, page caching is either not working or being bypassed.

Google’s public data is a 28-day average and does not break results down page by page, so on bigger sites we use page-level real-user monitoring and filter for URLs containing a question mark, which is where a query string starts. On one large Australian site with plenty of paid traffic, the normal homepage had a TTFB of around 500 to 683 milliseconds. URLs carrying gad_source=2 showed TTFB of 3 to nearly 4 seconds, and the homepage itself sat above 3 seconds for that traffic. A standard speed test showed none of this.

It is not only paid search either. Google Shopping traffic, including free organic listings, can carry parameters added by a feed tool and hit the same problem.

Step 2: list every parameter your ads add

1. Open the tracking template in Google Ads. This is the quickest place to see the parameters attached to your clicks.
2. Check whether individual ads carry their own tracking strings as well.
3. Add anything appended by click fraud, call tracking or feed tools. ClickCease or CallRail alone can add five to ten parameters to a URL.

Step 3: ignore those parameters in the page cache (do not cache them)

Caching plugins give you two options for query strings: cache each variation, or ignore the parameter. Choose ignore. Caching each variation does not help, for two reasons.

• The values are close to unique. Different ads, keywords, campaigns and placements produce different combinations, so each visitor gets a new URL that is never in the cache.
• The first visit to any URL is never cached, and for a paid click that first visit is often the only one.

When a parameter is ignored, the server serves the normal cached page and leaves the parameter in the address bar for your tracking to read. In WP Rocket this needs their add-on plugin for ignored query strings; WP Rocket documents how query strings are handled. Other caching plugins and server caches have an equivalent setting. Add every parameter from step 2.

Step 4: fix the Cloudflare layer too

If you use Cloudflare APO, Cloudflare edge caching, or a host running Enterprise Cloudflare, ignoring the parameters in WordPress is only half the job. Requests carrying those strings will still bypass Cloudflare’s cache.

The fix there is Transform Rules. They get messy quickly, because the rules need to cover every permutation of your parameters, and five to ten parameters produce a lot of permutations. The easiest route we have found is to have an AI assistant draft the rule set from your parameter list, check it, then import it into Cloudflare.

If your Cloudflare is connected through your host’s built-in integration, you will probably not have access to Transform Rules or the full firewall settings. This is one of the reasons we always recommend running your own Cloudflare account: you keep control.

Step 5: check the fix in real-user data

With enough traffic, page-level monitoring shows the effect within a day or so: TTFB for the paid segment should drop to match normal visits. Set up a saved segment for paid traffic so you can watch the trend line rather than one snapshot.

Keep watching after it is fixed. On the site above we had already set up exclusions for gad_source=1, then a new campaign started sending gad_source=2 and the slowdown returned for that traffic. Every new campaign, tool or feed is a chance for a new parameter to slip through. With cost per click reaching 20 or 30 dollars in some industries, a visitor waiting three or four seconds for the server to respond is budget walking out the door.

If paid traffic is landing on a slow site and you would like us to dig into it, request a free site audit from the WP Speed Fix homepage or start with the free Core Web Vitals report.