How to test speed changes safely

The two risks

Breaking something. Many speed changes work by doing less, later or differently, and each can have side effects:

The WordPress Handbook is direct about the last one. Newer versions of PHP bring performance and security improvements, but sites with older plugins and themes may not be compatible, so it advises testing for compatibility before upgrading and, if you have a staging environment, using it to resolve problems first.

Fooling yourself. Lighthouse's own documentation says that scores change because of variability even if the code has not, so you should run it several times and be wary of variability before concluding that a change made a difference. A page with an A/B test, or ads that change, is not the same page on every run. A cached test is faster than an uncached one. A busy afternoon is not a quiet morning.

Step 1: have a way back

Before you change anything:

• Make a full backup of the files and the database, and keep it until the change has run well for a while. The Handbook's guide to moving a WordPress site begins with the same step.
• Work on a copy if you can: a staging site, a duplicate theme, or a local version. Make the first change there.
• Note the current settings, with a screenshot or a list. Many optimization tools have dozens of options, and "put it back" is easier with a record.
• Know how to undo it. Disabling a plugin, restoring a backup, or switching back to the old theme should be a step you have already thought through.

Step 2: write down a baseline

You cannot tell whether a change helped without a before. Record:

The median of several runs is more reliable than one. See why scores change. Field data moves slowly, so write its date down. See lab and field data.

Step 3: change one thing at a time

If you change five things and the page gets faster, you do not know which one helped. If it gets slower or breaks, you do not know which one to undo. Change one thing, test, and decide. A few tiny changes of the same kind, such as compressing ten images, can count as one.

Pick the change by size of expected gain and risk. What to fix first sets out an order. The safe, large wins, such as a page cache that works or a correctly sized main image, come before the risky, small ones.

Step 4: check that nothing broke

Run through what your visitors do, and what the business needs:

1. Look at the main pages on a phone and a computer: the layout, the images, the menu.
2. Use every form with a real test entry. Check that the message arrives.
3. Search, filter and sort, if you have them.
4. Sign in and out, and check what a logged-in visitor sees.
5. For a store, make a test purchase from the product page to the confirmation, with a payment method in test mode. See WooCommerce checkout speed.
6. Check that tracking still fires. In the Network panel, look for the requests your analytics tags should make. See the Network panel.
7. Look at the console in DevTools for new errors.
8. Try a second browser and a real phone if you can. See testing on real phones.
9. Test with the cache cold and warm. The first visit after a change may differ from later ones.

A rule of thumb for what to test after which change:

Step 5: measure again, fairly

Use the same pages, the same tool, the same settings and the same number of runs. Run it several times and compare medians. Compare with your baseline, not with memory.

Some traps:

• A warm cache. Clear it or use a private window, as you did for the baseline.
• A different time. Server speed varies through the day.
• A different location or device profile.
• A deploy in progress. Wait until it has finished.
• A change you did not make. A third-party script can change without notice. See why scores change.

If the lab numbers improved and nothing broke, you have a good result. If they did not change, the fix may not have reached the problem, or the problem was elsewhere. Go back to the report.

Step 6: roll out, and watch

• Release at a quiet hour, when a problem will affect the fewest visitors.
• Watch for errors and drops in the hours after: contact form messages, orders, error pages, and the server's response time.
• Keep the way back ready for a few days.
• Wait for the field data. The Chrome UX Report covers a rolling 28-day window, so a fix takes weeks to show in full. The report is not wrong when it has not moved yet. Your own monitoring shows effects sooner. See real user monitoring.

Step 7: decide and record

After a few days, keep the change, undo it, or adjust it. Then write one line in a change log: the date, what changed, who did it, and the before and after numbers. Six months later, that log answers "why did we do that?" and "when did it get slow?".

Mistakes to avoid

• Testing on the live site first. A mistake costs customers.
• Changing many things at once.
• Skipping the checkout, the forms or the tracking. They are the parts a score does not test.
• Trusting a single run. Repeat, and use the median.
• Comparing different conditions.
• Not telling anyone. If the team does not know a script was delayed, they will not know where to look when something stops working.
• Judging the result on day one with field data that covers 28 days.

Check your own page

Pick the next fix from the free audit's list. Before you change anything, test the page five times and write down the median Largest Contentful Paint, Total Blocking Time and page weight. Then follow the steps above.

Sources

• PHP and Migrating WordPress in the WordPress Advanced Administration Handbook: testing a PHP upgrade for compatibility, using a staging environment, and starting a move with a backup.
• Score variability in the Lighthouse documentation: why scores change without code changes, and why to run several times.
• Chrome UX Report methodology: the 28-day window of field data.