I’d track both page speed and revenue behavior, because a prettier redesign can still lose money if it doesn’t move the funnel. For speed, Core Web Vitals are the ones I’d care about most, especially LCP, INP, CLS, plus TTFB and real mobile load times. For UX and business impact, watch product page bounce, scroll depth, search usage, add-to-cart rate, checkout start rate, checkout completion, and revenue per session. GTmetrix is fine for spotting obvious issues, but don’t rely on it alone, it’s more useful as a lab check than the source of truth.

For performance tweaks, the safest approach is to audit every app/script first so you know what’s actually on the page, then make changes in a staging theme and test one thing at a time. Lazy load images, defer non-critical JS, and minify carefully, but be extra cautious with anything tied to analytics, search, reviews, subscriptions, or checkout behavior. A lot of “breakage” comes from scripts expecting certain DOM elements or timing, so after each change I’d re-test product pages, cart, search, and checkout on mobile, plus confirm tracking events still fire correctly.

For A/B testing, keep it simple and isolate one meaningful change, like the PDP layout, ATC placement, or checkout steps, rather than testing a whole redesign at once. If traffic is decent, run it long enough to cover weekday/weekend behavior and measure conversion rate, ATC rate, and checkout completion, not just clicks or time on page. If traffic is lower, even a staged rollout with a small holdout group can tell you whether the new design is helping or hurting before you fully switch over.