Choosing a page to test

Before launching an A/B test on site speed, you need a page that can produce meaningful results. The ideal candidate should meet several criteria:

  • Mobile-first: More than half of global traffic now comes from mobile devices. Mobile users are more sensitive to slow loads due to hardware constraints and less stable networks, making speed differences easier to observe.
  • Funnel-critical: Pick a page that matters to your conversion journey. For an e-commerce site, that might be a product or category page; for a content site, a monetized article page.
  • Single purpose: Avoid the homepage. Its many functions and links dilute the effect of speed changes and create noise in your results.
  • Sufficient traffic: You need enough visits to reach statistical significance without waiting weeks for results.
  • Demonstrably slow: Slower pages give you more room to improve and produce clearer data. Check Google Analytics Speed Report or Search Console Core Web Vitals to identify your slowest pages.
  • Stable content: Avoid pages that receive frequent updates or layout changes during the test period. External variables make the analysis harder.

If you're unsure where to begin, ad landing pages are convenient because they often already have tracking and testing infrastructure in place. For other verticals: content sites can test articles or sections; storefronts can test category or product pages; media players can test video discovery or playback pages; service and booking sites can test their initial form page.

Measuring performance

Field data—also known as Real User Monitoring (RUM)—is generally more valuable than lab testing for this exercise because it reflects what actual visitors experience. Useful RUM tools include Perfume, Firebase Performance Monitoring, and Google Analytics Events.

Track several speed metrics alongside your business metrics so you can later determine which performance signal correlates most strongly with your success. The Core Web Vitals are a solid starting point, and the web-vitals.js library can capture them in the field, though browser support is not universal. The "Other Web Vitals" are also worth monitoring, as are custom metrics tailored to your product, such as "time to first ad click."

Creating speed variants

The test compares the current version of the page against a faster or slower variant. Whatever you do, keep the visual design and user interface identical—the only difference should be load performance.

Making the page faster

For a quick optimization pass, focus on the highest-impact changes:

  • Manually compress images with a tool like Squoosh.
  • Remove unused JavaScript and CSS using DevTools code coverage.
  • Reduce the weight of third-party scripts or eliminate any that can be dropped for the purpose of the test.
  • Load fonts and above-the-fold render-critical CSS inline (consider a tool like Critical).
  • Move analytics tags to asynchronous loading where possible.

Run Lighthouse via PageSpeed Insights during development to confirm your changes deliver the expected improvement. Once the variant is live, switch to RUM for the accuracy that matters in the final analysis. Be mindful that optimizing one metric can worsen another; report on the combination.

Slowing the page down

Introducing deliberate latency is often the easiest way to create a contrast group. You can add a small delay script, throttle server responses, or serve heavier images. The Financial Times used this method when studying how performance affected their business; details are in A faster FT.com.

Speeding up subsequent loads by prefetching

When the page you want to test (for example, a product detail page) is reached from another page (like the homepage), you can prefetch or prerender it during the previous page's load. The A/B split happens on the referring page. Just be aware that this can slow down that first page, so account for that when interpreting the results.

Setting Up the Experiment

Once you have two versions of the same page where one is faster, the next step is to split traffic to measure the impact. Not all A/B testing methods are suitable for measuring performance impact. Many popular client-side tools like Optimizely or Optimize work by hiding page content until the experiment loads, which would skew the very metrics you are trying to capture.

For accurate results, we strongly recommend a server-side test. The request goes to the backend, which distributes users to the two different versions of the page. While this is a solid setup, it often requires IT resources to implement.

If you can only do client-side testing, consider running the experiment on a separate page and manipulating the outgoing links to split traffic to your test page. This keeps the test JavaScript off the page you are measuring, so it does not affect performance.

An easier alternative is to pick two pages that behave and perform similarly, apply your changes to only one, and compare the difference in metrics over time. This is not a proper A/B test, but it can still be quite insightful.

If your test page is an ad landing page, use your ad network’s built-in testing tools, such as Facebook Ads Split Test or Google Ads Drafts & Experiments. Alternatively, set up two campaigns with identical settings but different landing page targets.

Analyzing the Test Results

Once you have run the test long enough to have confident data, it is time for analysis. If you used the ad network tools mentioned above, reading the results is straightforward. Platforms like Optimizely or Optimize also have easy ways to interpret the speed impact.

If you are pulling the report yourself in Google Analytics, start with a custom report. If you sent speed data to Google Analytics via a custom dimension, use the Reporting guide to set it up and include it.

Regardless of the tool, your report should include the business metrics that matter most to you: conversions, page views, ads viewed, conversion rate, e-commerce metrics, or click-through rate. Standard page metrics like bounce rate, average session duration, and exit percentage also strengthen the case for improving site speed.

Filter out bot traffic and isolate mobile data. More advanced analysis could segment by region, network, device, traffic source, or user type (new versus repeat visitors). Different groups may have different sensitivity to speed.

Visualization tools like Looker Studio (formerly Data Studio) make it easy to bring data sources together. They allow you to create shareable dashboards for stakeholders. For example, the Guardian built an automated alert system that warned editorial teams when recent content crossed page size or speed thresholds.

Interpreting Findings and Next Steps

With data linking performance and business metrics, you can start drawing conclusions.

If you see a clear correlation between faster performance and better business outcomes, summarize the results in business language and share them company-wide. This helps grab stakeholder attention and puts site speed on everyone’s radar. Use the results to set performance budgets and plan work to meet them; since you know the value this work will provide, you can prioritize it accordingly.

If you cannot find a correlation, review the caveats below and consider whether similar tests should be run elsewhere—for example, through the entire purchase funnel or on a different type of page.

Caveats to Consider

  • The page has little influence on the business metrics you examined. A faster product page may not affect conversion rates if the checkout page is hostile or slow. Look at metrics more directly tied to the page, like bounce rates or add-to-basket rates.
  • The speed difference between the two versions is too small. Judge this against the RUM metrics you are measuring.
  • The A/B test mechanism has a fault. Traffic may not be distributed correctly. Rule this out by running an A/A test—the same version of a page on both sides—and confirm there is no difference in results.
  • Speed really does not influence your business metrics. This is rare but possible when your audience is less sensitive to speed (e.g., strong devices on fast networks) or when user demand outpaces choice (e.g., ticketing for sold-out shows). Remember that a faster site still improves user experience and can affect brand reputation.

Making Speed a Company-Wide Goal

Launching optimizations site-wide is tempting, but it is more beneficial in the long run to first understand what a faster website means for your users and your company. The difference lies in reporting: “we improved FCP by 1.5 seconds” versus “we improved FCP by 1.5 seconds and that improved our conversion rates by 5%.” The latter lets you prioritize work, secure buy-in from stakeholders, and turn site speed into a cross-functional effort.