Together with Tideways, we took a real Magento shop and followed a slow Time to First Byte from real-user Core Web Vitals data all the way down to a buggy cache in the backend. Watch the webinar replay and read the key takeaways.
Performance problems rarely stay in one layer. A slow Time to First Byte shows up in your Core Web Vitals, but the cause usually lives in the backend. That's why we teamed up with our friends at Tideways for a live webinar: instead of slides full of theory, we took a real customer shop and followed a performance problem from the browser all the way down to a single line of backend code.
Missed it? The full recording is below, followed by a summary of what we covered.
Two tools, two sides of the same request
RUMvision and Tideways look at the same thing from opposite ends. Tideways, founded by Benjamin Eberlei, profiles PHP applications like Magento and Shopware and follows every request into the application: PHP execution, SQL queries and calls to external services. RUMvision measures what real visitors experience in the browser, from TTFB to LCP, INP and CLS.
Where they meet is Time to First Byte. Tideways covers everything up to TTFB, RUMvision covers everything that happens after it. We met at Magento community events, kept running into the same shared customers, and realised that for many shops you need both views to understand what is going on. We're also similar companies: small, customer-funded and focused on performance.
The case: Dutch Label Shop
The case study is Dutch Label Shop, a Magento store built and maintained by elgentos, who use both RUMvision and Tideways. At the start, the shop was failing its Core Web Vitals assessment:
- TTFB at 1.6 seconds, close to the red zone.
- CLS at 0.12, just above the 0.1 threshold, and the actual reason the assessment failed.
- FCP and LCP followed closely after TTFB, which told us the frontend after the first byte was relatively clean. The biggest win was clearly on the server side.
After the fix, the PageSpeed Insights (CrUX) numbers showed TTFB going from 1.7 to 1.2 seconds, an improvement of 500 milliseconds from one isolated change.
Why CrUX alone wasn't enough
Those PageSpeed Insights screenshots are familiar, but they are not the full story. To get the "after" screenshot, we had to wait 28 days. Add the 28 days you need to notice a problem in the first place and you're looking at roughly two months of delay. On top of that, CrUX only includes logged-in Chrome users, only reports the 75th percentile and gives you no way to drill down into why something is slow.
Because Dutch Label Shop was already using RUMvision, we could see the effect of the fix within hours instead of weeks. And we could look beyond p75: at the 90th percentile, the improvement in TTFB was even bigger, while it also showed that LCP still has room to improve for the slower part of the audience. Benjamin's rule of thumb for a healthy p90 TTFB: somewhere between 800 milliseconds and one second.
Following the trail into the backend
In Tideways, the product detail page told a clear story. The response time chart breaks down where the time goes: PHP execution, SQL queries and external services. The database was hardly a factor, which is good news for a Magento shop. But a large yellow block showed that a page that should just render content was spending a lot of time waiting on a third-party API.
As Benjamin put it: when a page that only needs to render something spends that much time talking to external APIs, that's a red flag. Some external calls are expected, such as Elasticsearch or a remote search service, but they shouldn't take up this big a share.
The root cause: an uncached reviews API
Drilling into the trace revealed the culprit: the Yotpo reviews API. It was used to display the shop's total review count on every page. That number is the same for the whole store and barely changes, so elgentos had already built caching for it. But a subtle bug meant the cache keys that were written never matched the keys that were read. The cache was effectively never hit, and every page view went back to Yotpo.
Third-party APIs are especially risky here because of their outliers. A database query that averages 5 ms might occasionally take 10 ms. An external API call can be ten times slower than its average for one in every hundred or thousand requests, and some unlucky visitor pays that price.
From insight to fix in about twenty minutes of human time
elgentos used Tideways' AI-assisted performance analysis to point a coding agent at the problem. The agent found the caching bug, suggested a fix and even went a step further: this number doesn't need to be fetched during a visitor's request at all, it can be refreshed by a cron job every hour. The agent did the heavy lifting; the people involved spent around twenty minutes in total, from flagging the issue to reviewing the fix. For a performance fix, where time estimates are notoriously risky, that's a big change. AI takes care of the heavy analysis and leaves the team to verify the suggestions.
The same principle applies to the frontend. Take a chat widget: if only a few percent of visitors use it, load it when someone hovers over or clicks it, not for everyone on page load. Third parties can hurt users who never even use them, especially at the higher percentiles.
Did real users actually benefit?
This is where the two tools really complement each other. Tideways measures backend performance, but that traffic can include bots and AI agents that are increasingly hard to tell apart from humans. And if most pages are already served from a full-page cache, a big backend improvement might only affect a small share of real visits.
So we validated the result in RUMvision, with known bots excluded. The release was marked with an annotation, and the RUMvision MCP compared the data before and after it: the p75 TTFB improved, the share of poor TTFB experiences dropped and server response duration went down. The improvement held up for real users: the people who actually request a quote or place an order. Verifying a fix is now literally one chat away.
Fixing CLS with the RUMvision MCP
With TTFB sorted, there was still the layout shift on desktop. Using the RUMvision MCP server, we simply asked what to tell the developer. By breaking down CLS per device, page type and element, it pointed straight to the product detail page: the main content and the product configurator area (options and add-to-cart) were responsible for almost all poor experiences. That's exactly the kind of precise, actionable brief a busy developer needs.
If your MCP runs in the same context as your codebase, you can even ask the agent to go and look into the code right away.
Key takeaways
- Start with real-user data. Field data tells you what is slow, for whom and where, without waiting 28 days.
- Follow TTFB into the backend. A large share of time spent on external services is a red flag worth investigating.
- Be selective with third parties. Cache aggressively where you can, move work out of the request and load widgets on demand.
- Validate with real users. A backend improvement only matters if it reaches real visitors, not just bots or uncached edge cases.
- Let AI do the heavy lifting. Tools like the RUMvision MCP and Tideways' AI-assisted analysis take the risk out of performance work by turning hours of analysis into a short verification task.
Want to try this on your own shop?
Already using RUMvision but not Tideways yet, or the other way around? We're offering a special onboarding audit: our teams find your first three frontend or backend performance improvements, and show you how to find the next ones yourself. Get in touch with us or reach out to Tideways during your trial.
