A shop owner I worked with recently could not make sense of his own numbers. Desktop PageSpeed said 98 and he was bragging about it to anyone who would listen, while his conversion rate fell off a cliff and visitors kept bouncing from a site he had been told was fast. That is the trap of leaning entirely on lab data for monitoring web performance. The test runs under conditions almost none of your visitors actually have.
I made the same mistake early on. Run a Lighthouse audit, see green circles, tell the client we were golden. Then a checkout page that felt instant in my local dev environment turned out to need 12 seconds to become interactive for mobile users on patchy 4G. I had been optimizing the score instead of the visit.
Synthetic tests vs. real user monitoring
A synthetic test is a treadmill run. Same conditions every time, which is exactly what makes it a decent baseline. Real User Monitoring is the same runner out in a rainstorm. Synthetic tools catch regressions before you ship and RUM tells you what happened when a real person clicked the link, so you want both running. Smashing Magazine framed this as the difference between measuring and monitoring, and the distinction stuck with me.
Google’s Core Web Vitals, meaning Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP), are where you start. The catch is that INP can look healthy in a lab, where the script is not fighting third-party tracking pixels and heavy ads for CPU cycles. On a real device, background tasks turn a simple click into a wait. You would much rather see that in your own data than in a “site is broken” email.
Monitoring web performance with custom metrics
The standard metrics run out at some point. If you have a WooCommerce action with moving parts, say an “Add to Cart” that refreshes three separate fragments, you need your own markers. The User Timing API handles that without dragging in a heavy tracking library that becomes part of the problem, and it surfaces technical delays a standard LCP report never shows you.
<?php
/**
* Track custom AJAX performance for WooCommerce cart actions.
*/
function bbioon_track_cart_performance() {
if ( ! wp_script_is( 'jquery', 'done' ) ) {
return;
}
?>
<script>
(function($) {
$(document.body).on('adding_to_cart', function() {
// Set a start mark
if (window.performance && window.performance.mark) {
performance.mark('bbioon_cart_start');
}
});
$(document.body).on('added_to_cart', function() {
// Measure the difference
if (window.performance && window.performance.mark) {
performance.mark('bbioon_cart_end');
performance.measure('Cart Add Time', 'bbioon_cart_start', 'bbioon_cart_end');
const measures = performance.getEntriesByName('Cart Add Time');
console.log('Cart addition took: ' + measures[measures.length - 1].duration + 'ms');
}
});
})(jQuery);
</script>
<?php
}
add_action('wp_footer', 'bbioon_track_cart_performance');Now you are not guessing about why “Add to Cart” feels sluggish, you have numbers. Pipe them into something like DebugBear and you can see whether particular browser versions or regions are lagging behind everyone else. It beats arguing with a client about whether the page feels quick.
What to watch instead of the score
If you take monitoring web performance seriously, it stops being a one-time audit. You find the slow experiences, work out the technical cause, then keep watching for regressions after the fix ships. Break your LCP into its subparts. Find out which scripts are holding the main thread. The data is already sitting there; the hard part is reading it from the visitor’s side rather than the lab’s.
Performance work turns into a rabbit hole fast. If you would rather hand it off than spend another evening staring at a waterfall chart, get in touch with my team.
Worth checking whether your site is quick for the people buying from it, and not only for the lab.
