Measuring a Widget's Impact on Page Load

To measure a widget's impact on page load, test the same product page twice, once with the script and once without it, and compare the results. Repeat the test several times on a throttled mobile profile, because one run on a fast laptop tells you very little.

This guide is for store owners and developers adding a script to a product template, such as a try-on button on a WooCommerce store. It uses free tools and works for any third-party script, not only ours.

What are you actually trying to measure?

You want to know whether the script changes how fast the page appears and how soon shoppers can tap it. Google groups this into Core Web Vitals: loading (Largest Contentful Paint), responsiveness (Interaction to Next Paint) and visual stability (Cumulative Layout Shift).

A widget can affect each one in a different way:

• Loading: the script competes with images and fonts for bandwidth.
• Responsiveness: heavy JavaScript on the main thread delays taps.
• Stability: a button that appears late can push content down.

How do you set up a fair before-and-after test?

A fair test changes one thing only. Use these steps:

1. Pick one representative product page, ideally a page with several images and variants.
2. Make a copy of the theme, or use a staging site, so you can remove the script tag without touching your live store.
3. Test the page with the script removed. This is your baseline.
4. Add the script back exactly as you plan to ship it, then test again.
5. Run each version at least five times and compare the median, not the best run.

Clear caches the same way before each run, and avoid testing while you have other tabs or extensions running.

How do you use Lighthouse to see a third-party script's cost?

Lighthouse is built into Chrome DevTools. Open the product page in an incognito window, open DevTools, choose the Lighthouse tab, pick Mobile and run an audit.

Look at two places in the report. The performance score and metrics show the overall effect. The "Reduce the impact of third-party code" audit lists each third-party domain and how much main-thread time it uses, so you can see the widget's share directly.

Lighthouse is a lab test. It simulates one device and one network, so treat it as a controlled comparison, not a prediction of what every shopper sees.

How do you check real-user data?

Lab tests can't show how the page behaves on your shoppers' phones. For that you need field data. PageSpeed Insights shows real-user Chrome data for a URL when enough visits exist, and Google Search Console reports Core Web Vitals across groups of pages.

Field data updates slowly, so use it as a check some weeks after launch. If a metric moves in the wrong direction after you add the script, you have a clear signal to investigate.

How do you load a widget so it costs less?

Most of the cost is controlled by how you include the script:

• Use defer or async. The ZeDaq.ai widget snippet uses defer, so it doesn't block the page from rendering.
• Load it on product pages only. There is no reason to ship a try-on script on your blog or checkout.
• Reserve space for the button. Give its container a fixed height so it doesn't shift the layout when it appears.
• Keep the page's own images lean. Heavy images usually cost more than any widget, so fix those first.

If your store is a single-page app, also read about routing pitfalls for product-page widgets, since the script may load on the wrong pages.

How do you set a performance budget?

A performance budget is a limit you agree on before you add anything new. For example, "Largest Contentful Paint must not get worse on the product page by more than a small margin you choose."

Write the budget down, test against it every time you add an app or script, and remove whatever breaks it. A budget turns "it feels slower" into a pass or fail result. Widgets also need to work for everyone, so pair the speed test with a review of accessibility for product-page widgets.

What should you do if the widget slows the page?

Work through these checks in order:

1. Confirm the script has defer and loads only where needed.
2. Check that the button container reserves its space.
3. Re-run the test to rule out noise.
4. Test the same page with another third-party script removed, to see whether the problem is the widget or the total number of scripts.
5. If the cost is still too high, consider calling the REST API from your own code instead, which lets you control exactly when anything loads. The try-on API for developers explains that route.

FAQs

Does one Lighthouse run give a reliable answer?

No. Scores vary between runs because of network and CPU noise. Run it several times and compare medians.

Should I test on desktop or mobile?

Test mobile first, since most fashion shoppers browse on phones and phones have less processing power. Check desktop afterward.

Does defer make a script free?

No. It stops the script from blocking rendering, but the code still downloads and runs. That is why you should still measure.

Can I measure a widget without touching my live store?

Yes. Use a staging site or a duplicate theme, add the script there and compare against the original.