Customer stories

Teams that stopped trusting lab scores.

Real-world engineering teams who used Pulsecadence to find the performance problems their Lighthouse reports were hiding.

-2.8s
LCP improvement (p75)
11%
Cart abandonment drop
<4h
Avg. time to attribution
Cartloom Commerce · SRE team · ~80-person engineering org

Finding the tag manager script that was costing conversions

-54%
p75 LCP on checkout

Cartloom's SRE team had a Lighthouse performance score of 94 on their checkout page, but mobile conversion rates had been declining for three consecutive quarters. Their existing synthetic monitor — running hourly from two US locations — reported no regressions. When they installed the Pulsecadence snippet, the field data told a different story: real-user p75 LCP on mobile 4G was 5.1 seconds, more than double what the synthetic monitor was showing.

The script attribution waterfall surfaced the cause within the first day: a tag manager container was loading a retargeting pixel synchronously before the LCP element could render. The pixel had been added by the growth team eight weeks earlier; it never appeared in Lighthouse because the lab environment blocked third-party network requests. Removing the pixel and deferring the remaining tag manager scripts brought p75 LCP to 2.3 seconds. Within two billing cycles, cart abandonment on mobile had dropped 11 percentage points.

Meridian Editorial · Frontend performance team · 12M monthly sessions

Attributing a CLS spike to a specific ad network

0.04
CLS (down from 0.22)

Meridian's article pages were showing a CLS of 0.22 in field data from the Chrome User Experience Report — technically "needs improvement," but the raw number didn't capture the user impact. The layout shifts were occurring in the bottom-of-article zone exactly when readers who'd scrolled to the end reached for an outbound link. Scroll depth on long-form articles had been declining for two months.

Pulsecadence's per-session CLS event timeline identified the source without a bisect: 89% of the layout shifts were caused by a specific programmatic ad network injecting an interstitial slot asynchronously after the initial render. The frontend team exported the session timeline data and handed it to the ad ops team with timestamps and element attribution. After renegotiating that ad slot's loading strategy — reserving space in the initial layout — CLS on article pages fell to 0.04 within a week. No code changes were required on the publisher side.

Runboard (B2B SaaS) · Onboarding engineering team · 6-person frontend squad

Catching an INP regression the same afternoon it shipped

<4h
Detection to revert

Runboard's onboarding engineering team ships several times a week. On a Tuesday afternoon, a React form component landed in the main onboarding flow as part of a larger feature release. By 4:03pm, Pulsecadence fired: p75 INP on the /onboarding path had climbed from 180ms to 460ms. The alert message included the correlated deploy timestamp — v2.9.4, pushed at 3:47pm — and a direct link to the 15-minute metric window showing the regression onset.

The team traced it to the new form component: state updates on each keystroke were triggering unbounded re-renders across a parent component subtree. A fix using React.memo and debounced input handlers was deployed at 5:30pm, same day. INP returned to 190ms p75 within the next data window. The team's existing synthetic uptime monitor — checking every hour from a single location — had not yet flagged anything. The regression would likely have sat undetected through the following Monday.

Start measuring what your users actually experience.

Free tier. No credit card. Real data within 5 minutes of installing the snippet.