How landing page speed affects Google Ads performance

Landing page speed affects Google Ads mostly through one number: how many of the clicks you already paid for turn into conversions. On a slow page, some visitors leave before it renders, and fewer of the rest reach the form or the cart. The second effect runs through landing page experience. In Search campaigns, Google reports it as a Quality Score component and assesses landing page quality in Ad Rank.

Speed is not the constraint in every account, though. This post covers how speed enters Google Ads, how to tell whether it is your bottleneck and how fast counts as fast enough. It also shows what a conversion rate change is worth in a hypothetical account and ends with a fix list in priority order. The Quality Score discussion and the example account are about Search campaigns.

Landing page speed enters Google Ads in three ways: conversions after the click, the landing page experience assessment and measurement itself. The first hits the budget directly. The second shapes whether and where ads show. The third often goes unnoticed, because a slow page fails to record part of the loss you are trying to see.

After the click: conversions and lost visits

Google Ads counts a click the moment the ad is clicked. The page load, the analytics tag and the form all come later. Google's clicks and sessions troubleshooting page says a user may close the browser before the analytics tag fully loads. That click then has no session.

So the cost of a slow page has two layers. One layer is visitors who leave before the page renders and never appear in analytics. The other is visitors who see the page but give up on a sluggish form or a shifting button. Both layers mean fewer conversions for the same spend.

Landing page experience, Quality Score and Ad Rank

Quality Score is reported for Search campaigns.

Google's Quality Score help page defines landing page experience as how relevant and useful the page is to people who click your ad. The same page makes two points. Quality Score is a diagnostic tool and is not an input in the ad auction. It is also not a key performance indicator to optimize.

The assessment used in the auction sits inside Ad Rank. There Google lists the usefulness and relevance of the landing page, the expectations set by the clicked ad and ease of navigation. Google publishes no load-time threshold for any of this.

Quality Score components deserve their own post. What matters here is that speed is one possible input to this assessment, and its weight is not disclosed.

The mobile speed score and the Landing pages report

In 2018 Google Ads announced a 1–10 mobile speed score for landing pages. The landing pages help page, checked on November 5, 2026, describes only two mobile columns. They are "Mobile-friendly click rate" and "Valid AMP click rate" (AMP stands for Accelerated Mobile Pages). The page does not mention a speed score.

The same page says the mobile-friendly check uses Google's Mobile-Friendly Test. Google announced that it retired that tool on December 1, 2023. Check which columns your own account shows, and base speed measurement on the field data described below.

Finding out whether speed is your bottleneck starts with ruling out a mismatch between the ad and the page. A page that ignores the search term or hides the advertised offer will not convert, however fast it loads. Google's page on optimizing ads and landing pages says visitors who don't find what they expect right away are more likely to leave.

Telling message mismatch from slowness

Message mismatch and slowness can look the same in a report: people leave quickly and conversions drop. Where the loss concentrates, and in which segment, tells them apart. The table below compares the signs.

No single sign is proof. Each one is a hypothesis to check, and it gets firmer when two or three point the same way.

The split rests on whether the loss happens before the page is used or after it is read. A visitor who engages and still leaves may not have found what they wanted. They may also have reached the form and given up on a slow field, a slow checkout or a button that responds late.

So in that case look at the message, the offer and the form's technical performance together, which is the scope of conversion rate optimization. Engagement without conversions does not rule speed out.

Comparing devices

Comparing devices is the first step in isolating a speed problem. Slowness hits harder on mobile devices with weaker networks and processors.

In Google Ads, segment the campaign or landing page by device and take the last 28 days. For each device, divide conversions by clicks. You can check the result with the conversion rate calculator.

A gap between mobile and desktop does not prove a speed problem by itself. Mobile users may still be researching and may finish the purchase on another device.

So compare the same gap on two landing pages with different speeds. Keep everything else as alike as you can: the same offer, campaign, search intent and device. If the mobile gap is much larger on the slow page, that raises a speed suspicion. If the gap is the same on both, intent is one candidate, but offer, price, traffic source, form and audience can also explain it.

Sessions per click

The ratio of sessions to clicks is a signal worth investigating, not a rate of lost visitors.

Compare Google Ads clicks with Google Ads sessions in Google Analytics 4 (GA4), for the same period and landing page. The two are not counted one to one. Google's troubleshooting page notes that two ad clicks within 30 minutes may register as one session. Returning users can add sessions without a new click.

So fewer sessions than clicks does not mean the missing share of visitors was lost.

Speed is also not the only cause. Auto-tagging settings, redirects that drop campaign parameters and cookie consent can lower the ratio. Invalid clicks work the other way: Google Ads filters them, while Analytics still reports the sessions.

Hypothetical example: mobile records 0.80 sessions per click and desktop 0.925. If the other causes are similar on both devices, the lower mobile ratio is a reason to check for visitors leaving before the page loads. The ratio alone does not show the cause. But a higher mobile ratio after a speed fix is a second piece of evidence in the same direction.

The funnel analysis calculator shows where counts drop between clicks, sessions, engaged sessions and conversions. These are totals from two systems, not one path followed by each user, so read the result as a pointer. A large drop at the first step puts speed and the redirect chain on the list. A large drop at the last step points to the form or the offer, including how fast the form responds.

Field data and lab data

Field data shows what real users experienced, while lab data shows one simulated load. The PageSpeed Insights documentation says its field data comes from the Chrome User Experience Report (CrUX) and covers the previous 28 days. The lab test simulates a mid-tier phone on a mobile network. Google adds that good lab data does not mean real users have a good experience.

For ad landing pages, this split has three practical consequences.

• The CrUX methodology excludes pages that carry a noindex tag. A page built only for ads and set to noindex has no URL-level CrUX data. Its visits can still count in the data for the whole site, but that blend does not represent the ad landing page.
• CrUX strips query parameters from URLs. The gclid and UTM (Urchin Tracking Module) parameters added to ad clicks are grouped into the same page, so they do not show up as separate variants.
• Lab tests load the page with a cold cache, which is close to a first visit from an ad. They are usually run on the base URL, but PageSpeed Insights tests the URL you give it. Test the final URL with the ad parameters as well, since parameters can change content or stop a CDN from serving a cached copy.

A landing page with no field data needs its own real user measurement. You can send Web Vitals values to GA4 as events and split them by device. CrUX removed its connection type dimension in February 2025 and replaced it with a round trip time metric. Your own measurement stays more flexible for splitting by connection.

The closest answer Google gives to how fast is enough is the Core Web Vitals thresholds. Google Ads publishes no separate time limit. Core Web Vitals are three field metrics that rate pages as "good", "needs improvement" or "poor". Fast enough means meeting the "good" threshold for three quarters of page views, on mobile and desktop separately.

Core Web Vitals thresholds

Each of the three Core Web Vitals metrics measures a different moment. Largest Contentful Paint (LCP) marks when the largest content element appears. Interaction to Next Paint (INP) measures how fast the screen updates after a tap. Cumulative Layout Shift (CLS) measures unexpected movement of content.

The thresholds below come from web.dev's Web Vitals page and the page explaining how they were chosen. Each metric is assessed at the 75th percentile. A page counts as "good" only when at least 75% of visits fall under the threshold.

The table boils down to this: if your mobile LCP is 2.5 seconds or less, LCP is rated "good". That covers loading only. A page passes the Core Web Vitals assessment when all three metrics are good, and neither result shows the page is fast enough commercially. Organic search checks are covered in the SEO checklist.

What GA4 bounce rate counts

In GA4, bounce rate is defined as the opposite of engagement rate. Google's engagement rate and bounce rate page counts a session as engaged if it lasts longer than 10 seconds. A key event or at least two page views also qualify. Sessions that meet none of these make up the bounce rate.

This definition has two consequences for speed. A visitor who leaves before the page loads creates no session, so they never count as a bounce. As pages get slower, part of the loss moves out of bounce rate and shows up, if at all, as fewer sessions per click.

The second consequence is that the 10-second rule can mislead on slow pages. A visitor who waits for the page, then leaves, can pass 10 seconds and look engaged. So do not base a speed decision on bounce rate alone.

Diminishing value after the threshold

Each gain past the threshold may be worth less, but where that tails off can only be measured. Google's page on how the thresholds were defined says there is no single amount of time users wait before abandoning. Chrome data shows a smooth and continuous distribution instead.

So there is no cliff at three seconds. Every gain can recover some loss, and how much depends on your traffic.

So the order of work comes from field data. A metric rated "poor" on mobile comes first, and one in "needs improvement" comes second. Once all three are "good", show the value of further gains with conversion data instead of assuming it. Moving a lab score from 90 to 100 is not a goal by itself at that point.

Every figure in this section is hypothetical and chosen only to show how the calculation works. A Search campaign gets 20,000 clicks a month at a cost per click (CPC) of $1 on both devices. You can work out your own CPC with the CPC calculator. The table below shows the starting point by device.

Each conversion brings $90 in contribution margin. That is the margin left after product and variable costs, not revenue. A speed fix costs a one-off $6,000 and affects only the mobile conversion rate. The example assumes every extra conversion is a real extra sale.

Hypothetical example: the value of a conversion rate change

The table below shows three sizes of relative lift in the mobile conversion rate, plus a case with half the mobile traffic. CPC, contribution margin and desktop results stay fixed. The inputs that change are the relative lift and the number of mobile clicks. Payback is $6,000 divided by the extra monthly contribution.

Two inputs drive the decision: the expected relative lift and the paid traffic the page receives. With half the mobile traffic, a 10% lift pays back as slowly as a 5% lift at full traffic. On a low-traffic page, the same fix takes longer to pay for itself.

In a real account, part of the increase can be sales the slow page made but never recorded. The faster page lets the tag fire more often. If a quarter of the 18 extra conversions were such sales, payback stretches from 3.7 to about 4.9 months. Base payback on extra sales confirmed in the order system.

At a 10% lift, mobile cost per conversion falls from about $66.67 to about $60.61 at the same spend.

Getting the same 18 extra conversions at the old rate would take 1,200 more clicks, or $1,200 more spend.

The desktop conversion rate is about 1.83 times the mobile rate. That gap is not a ceiling speed can close, because part of it comes from user intent. The performance marketing metrics post covers which metric to decide on.

Hypothetical example: traffic needed to test the change

The traffic needed to see a speed effect in an A/B test grows fast as the expected lift shrinks. The table below uses the example's 1.5% mobile conversion rate, two-sided 5% significance and 80% power.

The duration column assumes the 12,000 mobile clicks are split evenly, so each group gets 6,000 clicks a month. It also treats every click as a separate visitor.

Decide the unit of assignment first. If you assign by user, repeated clicks from one person are not independent observations. Compute the sample on unique users and the share of them who buy, for example with the sample size calculator. Users who return in later months add no new participants, so the real duration can be longer.

With the example's traffic, testing for a 10% lift is not practical. The logic behind this calculation is explained in the sample size post. When a test ends, you can check the result with the A/B test significance calculator.

If you run a test, web.dev's guide to site speed and business metrics gives two warnings. The fast and slow versions must look identical. Client-side testing tools often hide content until the experiment loads, which skews the speed you want to measure. The guide recommends a server-side split instead.

If traffic cannot support the test, the decision rests on field data and thresholds. When mobile LCP is in the "poor" band, compute the value of a fix for a few plausible lifts. Then weigh it against the cost, as in the table above. A before and after comparison is not conclusive, because seasons and bid changes affect it too.

The fix list follows the path from the ad click to a usable page. The order can change depending on which metric is "poor" in your field data. The first two steps touch all ad traffic, so in most accounts they come first. After each step, measure the same metric in the same device segment.

1. Shorten the redirect chain

Every redirect between the ad click and the page delays the first byte the visitor receives. According to web.dev, Time to First Byte (TTFB) includes redirect time. In Google Ads, parallel tracking sends visitors straight to the final URL and measures the click in the background. Also check that the final URL does not redirect from http to https or to another subdomain.

2. Speed up the server response

A slow server response limits what the later steps can gain. Google's LCP optimization guide says a high TTFB can make a 2.5-second LCP challenging, or even impossible.

Break LCP into its parts and start with the largest one. As a rough target for most sites, web.dev gives a TTFB of 0.8 seconds or less. One way Google suggests is a content delivery network (CDN), which serves the page from servers close to the visitor.

3. Prioritize the main image

On mobile landing pages, the LCP element is often a large image at the top. Google's guide to improving Core Web Vitals recommends adding fetchpriority="high" to that image and removing loading="lazy". The image also needs to be discoverable in the HTML. If a script inserts it, the image waits for that script.

4. Clean up tags and third-party scripts

Ad landing pages collect tracking tags, chat widgets and testing tools over time. These keep the main thread busy and can make INP worse. Remove old and unused tags from the tag manager, and defer scripts the first view does not need. Do not remove the conversion tag, only check when it loads.

5. Reserve space for late content

Images, banners and cookie notices that load late push content around and raise CLS. Give images a width and height, and reserve space for content that arrives later. A shift can make a visitor tap the wrong button, so it hits conversions directly.

6. Confirm the effect with the same measures

When you measure the effect of a fix, compare the before and after periods with the same definitions. The sequence below shows step by step whether a change solved a speed problem.

1. Track mobile and desktop field data separately. CrUX uses a rolling 28-day window, so a change takes about four weeks to show in full.
2. Recompute sessions per click for the same landing page and device.
3. Compute conversion rate per click and per device. Note campaign, bid and ad copy changes in the same period.
4. Check landing page experience in the Quality Score columns. Google rates it against other advertisers on the same searches over the last 90 days, so changes show slowly.

To automate this monitoring, a script that flags spend without conversions is walked through in the Google Ads scripts guide. If field data improves after a speed fix but conversion rate does not move, the next candidate is the message and offer on the page.