---
title: "Use cases"
canonical: "https://www.rumvision.com/use-cases/core-web-vitals-on-autopilot-the-lazy-engineer-s-guide-to-beating-p90/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Use cases

# Core Web Vitals on autopilot: the lazy engineer's guide to beating P90

What if your team could start the day with a performance fix ready to review? Every night at 3 a.m., Magento 2 agency elgentos uses real-user data to find quick wins across its clients’ stores. Its Nightly Watch traces findings to the right file, tees up fixes and knows when to leave a finding alone. Here’s how elgentos built it and how you can put it to work as well.

# How elgentos built its 3 a.m. performance watch

Does AI really make you less busy? It can. Magento 2 agency elgentos used the RUMvision API to turn quick wins from our health checks into fixes for the shops it builds. Every night at 3 a.m., its Nightly Watch gets to work. In the first 30 days, elgentos filed 49 issues across 12 domains and closed 44. A typical nightly run took five minutes. The Watch also rejected 50 findings. Here’s how elgentos built it, and how you can start with one store.

## Start with the work developers keep repeating

A RUMvision health check can tell you that a product photo is a Largest Contentful Paint (LCP) candidate and appears to be missing a priority hint. A developer still has to figure out where that photo comes from. On a Magento store, that might mean following a layout block into a Hyvä template, checking which overrides are active and ruling out a hero managed in the CMS. The change can take a line of code. Getting to that line takes longer.

Across a dozen client domains, elgentos was doing some version of that detective work over and over. The Nightly Watch splits it up. A PHP command handles the schedule, API calls and GitLab bookkeeping. Claude Code reads the repository and decides whether the finding points to a small code change. A separate agent, Señor Code, can turn an accepted issue into a merge request. A developer reviews the patch.

## 1. Give the job a real-user finding and the right repository

It starts with `0 3 * * *` in GitLab CI. The scheduled job runs a PHP command built with Symfony Console, which goes through the client domains and makes this request for each one.

         ```
GET /api/v1/health-checks/rumvision.com?status[]=open&status[]=warning
```

A result might come back as `lcp-fetchpriority` for the `product-detail` template on mobile at P75. Those fields give the agent something specific to investigate and give the developer a way to find the same group of visits in RUMvision later. The command checks whether it has seen the finding, maps the domain to its GitLab project and makes a shallow clone for the analysis. [RUMvision REST API documentation](https://www.rumvision.com/help-center/apis/client/introduction/?format=md)

This is also where elgentos handles rate limits. Its job spaces requests 13 seconds apart and honours the API’s retry delay. If one domain fails, the others can still run. If every domain returns zero health checks, the job fails so the team can investigate a problem such as an invalid API key. It also fails if more than half of the agent’s analyses are unreadable. The dashboard shows whether the job ran and how long it took.

## 2. Ask the agent for a verdict

The command pins the Claude Code version and runs it headless inside the clone. The triage step has read-only access. Here’s the command elgentos shared.

         ```
claude -p "$PROMPT"     --allowedTools Read,Grep,Glob,Skill     --disallowedTools Write,Edit,NotebookEdit,Bash,WebFetch     --output-format text
```

The prompt asks the agent to trace the finding to its source. If it finds a small frontend fix that fits within a few hours, it returns the file and line, the change it would make and a test a developer can run. If the attribute is already there, the image lives in the CMS or the cause needs profiling, it records why the finding should be skipped.

The rejection count tells you a lot about where the workflow is useful. Of the 50 findings elgentos rejected, 20 came from the same image-priority check. Sometimes the hero came from Page Builder or Prismic. Sometimes the template already had the attribute. Other findings pointed to work that needed more investigation, such as profiling a slow menu interaction or tracing a third-party script. The Watch has a narrow remit, and the team still has those findings in RUMvision when it wants to pick them up.

## 3. Put a specific change on the client’s board

For an accepted finding, the PHP command creates a confidential GitLab issue in the client’s project. It fills in the device, page template and percentile from the API response, adds the agent’s file location, proposed change and test, and sets the labels and sprint. Notifications go to the client’s Slack channel. Clients can see the open tickets for their own project.

Señor Code handles the next step. It uses the issue to prepare a patch and open a merge request. The developer can review the change with the original finding and the test beside it.

The Hyvä gallery shows what that looks like. Mobile and desktop findings led to the same template. Claude traced the product image to `gallery.phtml` and checked a client-specific part-finder override along the way. The main image was already in the initial HTML, so the browser could discover it early. The patch added `fetchpriority="high"` to give it higher priority and made the active image in the Alpine gallery eager and high priority, while leaving the rest lazy-loaded. [web.dev’s LCP optimization guide](https://web.dev/articles/optimize-lcp)

The merge request linked both issues and gave the developer a test. Open a product with four photos on mobile and desktop and check that only the active image loads eagerly at high priority. A developer merged the one-file patch and closed both issues.

## 4. Keep the night shift from filling the backlog

elgentos spent the first few weeks in dry run. Once it enabled ticket creation, it kept the following rules in place.

    When What the Watch does     A repository has several candidates Try up to three findings and file at most one new issue per repository per night. Within a check, start with the oldest finding.   Several clients have candidates Stop after 15 new issues across all clients that night.   A finding has been seen before Store a fingerprint made from the domain, check and finding ID. Look for it in open and closed issues. Keep rejected findings in `state/rejected.json`.   A ticket or agent merge request already touches the file Leave a note on the existing issue so the team can handle the overlap there.   A patch is ready Leave review and merge to a developer.   

The five-minute figure is the typical runtime of the nightly job. The first-month figures tell you how much work moved through the board. To see what changed for shoppers, look at the real-user data after the patch goes live.

## Try it on one store

1. **Pick a finding you know how to verify.** Choose one store with about a week of RUM data and start with `lcp-fetchpriority`. Map the domain to its repo and fetch the open findings and warnings from CI.
2. **Run in dry mode.** Pass the check, device, template and percentile to a read-only agent and print the verdict to the CI log. Try a theme-rendered product photo and a CMS-managed hero. The first should give you a file, a proposed change and a test. The second should tell you where the work belongs.
3. **Let it create one issue.** Put that issue on the board your team already uses. Check that it includes enough context for another developer to pick it up. Review the patch, run the test and mark the deployment in RUMvision.
4. **Check the visits affected by the change.** Compare product-page LCP before and after deployment on mobile and desktop separately. Check the visit counts before drawing a conclusion. Look at P90 alongside P75 to see whether the slower visits improved too. [RUMvision’s deploy date filter](https://www.rumvision.com/help-center/filters/webpage/deploy/?format=md)
 
That fourth step is where elgentos wants to take the Watch next. The plan is to use raw RUMvision data and deploy annotations to compare performance around a release. A deploy marker gives the job a starting point. From there, it can inspect the metric distribution for the affected template and look for changes that a site-wide view might miss.