In this article, we'll explain how you can detect performance regressions, make the right people in your team aware of them, and get the data you need to identify what caused a regression.

Why is web performance monitoring important?​

Performance issues often come up once a website is released, as features are gradually updated or third-party scripts are added. Monitoring your website is essential to maintaining good performance over time.

Slowdowns can reduce conversions, hurt SEO (search engine optimization) rankings, increase bounce rates, and negatively impact customer trust and revenue. The longer regressions go undetected, the more challenging it is to detect what changed and when.

Checking dashboards daily works, but isn't a sustainable or time-efficient solution. Automated monitoring and alerting solve this problem by continuously watching your metrics and notifying you the moment problems begin to arise.

When you get notified of a regression, you need the ability to compare test results over time and trace metric changes back to specific technical causes. For example:

• Was a heavier image added?
• Did a script start blocking the main thread?

How to set up monitoring for your website​

DebugBear lets you keep track of your web performance using scheduled synthetic tests, real user analytics, and Google CrUX data.

To run synthetic tests, all you need to do is add the URLs you want to monitor. To collect real user monitoring data you need to install a small JavaScript snippet on your website.

How to set up alerts​

Once you've set up monitoring, you can configure budgets and notification channels to get alerted when performance changes.

What is a performance budget?​

A performance budget allows you to set metric thresholds based on your needs. Once the threshold is breached, you and your team will receive an alert. This allows you to define which performance changes matter to your team and get notified immediately when thresholds are exceeded.

Why use performance budgets?​

DebugBear automatically detects major changes on your website. But that doesn't necessarily match the metrics that matter to your team, or the frequency of alerts you need.

Performance budgets set clear boundaries for what constitutes a breach. If a metric crosses a threshold set up by your team, then investigation and a fix are needed. Without performance budgets, it becomes difficult to distinguish between normal metric fluctuations and meaningful regressions that require investigation.

Performance budgets add a layer of insurance to your monitoring:

• Custom thresholds tailored to your site: You can define thresholds that best suit your website rather than relying on the standard ones.
• Dashboard visibility: See which pages are meeting targets and which are failing.
• Proactive monitoring: Instead of receiving feedback from visitors that your website is slow, resolve the issue without damaging conversions and bounce rates.

Goals for a solid alerting setup​

When setting up your first performance budgets, it's a good idea to think about what purpose they serve and how often your team is alerted.

Overall, the goal is to catch regressions in real time, before they impact users or business metrics. Before creating your first performance budget, consider the following questions:

• What does our previous data look like? Setting up thresholds starts by looking at recent data. You want budgets that reflect a true trend change.
• What channels should notifications be sent to? Alerts can be delivered by email or to an integration such as Slack or Teams. Deciding which team members receive these alerts, and where they're sent, is vital so changes can be resolved together as they happen.
• Will these alerts lead to action? If goals are unrealistic, then many alerts could be ignored. Setting appropriate budgets will avoid notification fatigue.

You also need to make sure your alerts stay up to date, since they can become outdated as pages improve. Taking stock every few months allows budgets to be adjusted and remain meaningful.

Understanding performance thresholds​

A great way to understand performance budgets is by looking at the Largest Contentful Paint (LCP) thresholds. There are three ranges: Good, Needs Improvement, and Poor.

• Good — 2.5 seconds and under
• Needs Improvement — 2.5 to 4 seconds
• Poor — Over 4 seconds

These thresholds provide a starting point, but your budgets should reflect your site's current situation. In this example from searchengineland.com in our demo project, the LCP score is currently 2.23 seconds, with a recent history of heavy regressions.

Setting a budget at 2500 ms ensures you're notified before visitors endure a slow experience.

Setting up your first performance budget​

You can configure performance budgets in your page settings. Open a monitoring result, select Page Settings in the sidebar, click Show Advanced, then Add Performance Budget.

Click Create Performance Budget to define a new budget. Name your budget and select the metric you want to be alerted on. In this case, we want Largest Contentful Paint.

Next, we need to create the alert condition. Since we are dealing with the LCP good threshold, we can select 'goes above' and add 2500 ms as our threshold. Then click Create and save the page settings.

Which metrics should you set alerts for?​

If you're new to performance budgets, the fewer metrics you set alerts for, the better. This helps avoid alert fatigue: if a lot of alerts are consistently coming in from many different metrics, they may ultimately get ignored.

Critical metrics, such as the Core Web Vitals are a great place to start. You can then fine-tuner alert thresholds for your website. Let's take a look at some key metrics and the reasons for monitoring them.

Largest Contentful Paint​

LCP measures when the main content becomes visible. Set a "goes above" alert at the good threshold (2500ms) or slightly below your current baseline to catch regressions early.

Cumulative Layout Shift​

Cumulative Layout Shift (CLS) measures visual stability by tracking how much page content unexpectedly shifts during loading. Layout shifts frustrate users and often indicate missing image dimensions, font swaps, or injected ad content. A good CLS score is under 0.1, so set your budget there.

Interaction to Next Paint​

Interaction to Next Paint (INP) measures responsiveness by tracking the time from user interaction to the next paint. High INP indicates that the main thread is blocked, often due to heavy JavaScript execution. A good INP score is under 200ms, but consider an "increases by" alert of 20% to catch significant regressions relative to your baseline.

Real-time INP can only be measured well with real user data. You can check CrUX INP scores, but those will take a few weeks to update since Google aggregates data over a 28-day rolling window.

You can use Total Blocking Time (TBT) as a very rough proxy for interaction delays on your page. Or you can script specific interactions in your synthetic checks and measure INP scores for them.

Time To First Byte​

Time To First Byte (TTFB) measures server response time. Poor TTFB delays every other loading milestone. The good range is under 800ms, but an "increases by" alert of 10% can catch server-side regressions before they cascade into user-facing problems.

First Contentful Paint​

First Contentful Paint (FCP) measures how quickly users see the first piece of visible content. FCP and LCP often share bottlenecks, so an FCP regression may signal an LCP issue as well. The good threshold is 1.8 seconds.

Lighthouse Performance Score​

The Lighthouse Performance score provides an overall assessment on a scale of 0 to 100. A score below 90, or a significant percentage drop, can indicate broad regressions that individual metrics might not surface clearly.

Page Weight​

Page weight (the total size of all resources) doesn't always correlate with poor performance, but monitoring it can explain LCP or FCP regressions. An "increases by" alert of 5% helps you catch when new assets are added that might impact loading.

The budgets dashboard​

Once you've set up performance budgets, the budgets dashboard provides a centralized view of all pages and their budget status. Any team member can quickly see which pages have budgets applied and whether they're currently passing or failing. New budgets can be created by clicking the plus icon in the top right corner.

Viewing the budgets dashboard here, we can see that there has been a major LCP regression.

Clicking on the page will show the latest test result with the change. You can use the compare pages toggle to identify what caused the regression.

In this case, we can see the LCP image has changed, with the new image now being dependent on an additional LCP initiator request.

Setting up alerts for your team​

Email alerts work, but they have limitations as they can easily be missed. When a performance regression happens, you want the alert to land where your team is already working. Pairing email notifications with team chat integrations means faster action to fix issues.

Integrating alerts with tools like Slack makes performance monitoring more collaborative and efficient. Alerts are delivered to a dedicated channel where the whole team can see them immediately. This keeps conversations in context, allowing team members to discuss regressions directly where the alert appeared, share findings, and coordinate fixes faster without the need to forward emails.

Configure alert notification channels​

To set up email notifications, mark the subscribe checkbox. Click the gear icon to configure notification settings.

The Re-alert on consistent breaches option continues sending notifications while a budget remains breached. This setting ensures that further emails are sent if the breach continues.

You can also select which automatic alerts you want to receive, or mute notifications to reduce noise and keep alerts relevant.

Slack integration​

To integrate with Slack, click Configure Channels on the budget dashboard to reach the integrations page, then Add to Slack. After authorizing access, select your channel and choose which alert types to send.

In this example, we created a new Slack channel called #website-alerts. Now all lab alerts will be automatically sent to this channel for your team to receive. For complete setup instructions, see the Slack integration guide.

What happens after an alert?​

Once a budget is breached and an alert is received, you can quickly act to resolve the issue. Using the compare toggle on a test result is a great way to view test data side by side, making it easier to spot regressions and investigate their cause.

By comparing results over time, you can identify which changes introduced the issue, make a fix, and quickly confirm that performance is back to normal. This cycle of alerting, investigating, fixing, and verifying problems is what makes monitoring an important part of maintaining performance.

For example, when a synthetic alert is triggered, the comparison page lets you see what metrics changed. From there you can dive into specific technical changes: were new resources added to the page? Did the priority of a request change? Are there new long CPU tasks?

You can also visually compare test results and view a side-by-side video recording of the page load. That makes it easy to show team members the end-user impact of a regression.

Real User Monitoring alerts​

You can also set up Real User Monitoring (RUM) alerts to surface issues affecting visitors.

Within RUM settings, go to the Alerts & Budgets tab and subscribe to email alerts. Click the gear icon to configure alert frequency and metric thresholds.

For custom budgets, click Create Budget and configure the following conditions:

• Check Every: How often to evaluate the budget (hourly to every 72 hours)
• Alert After: When to notify (immediately, once after breach, or twice after breach)
• Baseline Duration: The reference period for detecting changes

In this example, we have set up a custom budget to monitor the LCP score for the homepage. This is checked every 4 hours. If there is an increase of 10% compared to the last 4 hours, an alert will be sent.

When a RUM alert is breached, an email will be sent notifying you of the change.

If you have Slack integration set up, these alerts can be configured to be sent to a dedicated Slack channel.

When clicking on the details for either an email or Slack alert, you'll be brought to the RUM alert landing page, where you can view more details on the change, as well as the alert history graph. In this case, we can see the LCP score has been regressing over the last 24 hours.

After a slight improvement in the previous 4-hour period, the regression exceeded 10% and the notification was sent. This timeline gives us context that the LCP score has been creeping up.

From this page, we can inspect further to see what has caused the change, looking at potential causes such as a TTFB increase or inspecting the LCP sub-parts data.

Monitoring best practices​

If it is your first time setting up alerts, these principles will help you get the most from performance alerting:

• Start small. Don't overwhelm yourself and your team with budgets. Begin with Core Web Vitals on your high-traffic pages. Then continue with more metrics and pages.
• Set realistic thresholds. Base budgets on your current performance plus a reasonable buffer. Alerts should indicate genuine regressions.
• Combine lab and field data. Using alerts on both lab and RUM data helps catch regressions sooner, minimizing impact on user experience, SEO rankings, and conversions.
• Make alerts actionable. Once an alert has been sent, compare against previous data to see what changed.
• Integrate with your team. Inviting team members to view the budget dashboard, receive email alerts, and join a Slack channel means everyone is on the same page.
• Review and adjust. Audit your budgets over time to reflect your website's current performance and future targets.

Get started with performance monitoring​

Performance budgets turn passive observation into proactive protection. Instead of discovering regressions days or weeks later through user complaints or ranking drops, you'll know immediately when metrics drift outside acceptable ranges.

Ready to set up monitoring for your site? Start a free DebugBear trial and configure your first performance budgets in minutes.

Monitor Page Speed & Core Web Vitals

DebugBear monitoring includes:

• In-depth Page Speed Reports
• Automated Recommendations
• Real User Analytics Data

Start Free TrialGo To App

However, this means websites can miss out on the performance benefits of HTTP caching. Even if two URLs return identical content, caches generally store them as separate entries simply because the query string differs. That leads to fragmented caches, lower cache hit rates, and unnecessary origin requests from Content Delivery Network (CDN) caches.

The new No-Vary-Search HTTP response header aims to solve this problem by giving browsers and CDNs more control over how query parameters affect cache keys.

In this article, we'll look at:

• why query parameters are problematic for caching,
• how No-Vary-Search works,
• what problems it solves,
• advanced edge cases,
• and when you should avoid using it.

The Problem with Query Parameter Caching​

Traditionally, caches treat the full URL as the cache key, which means these URLs are considered completely different resources:

/products
/products?utm_source=twitter
/products?ref=homepage

Even if the response body is identical, most caches will create separate cache entries for every variation, and this creates several problems:

1. Lower Cache Hit Rates: A CDN may already have /products cached, but a request for /products?utm_campaign=spring-sale can still result in a cache miss. At scale, this significantly reduces cache efficiency.
2. Increased Origin Traffic: More cache misses mean more requests hitting the origin server. For high-traffic applications, especially content-heavy sites, this increases infrastructure costs and backend load.
3. Browser Cache Inefficiency: The same issue exists in browsers. A browser may already have a page cached, but a slightly different query parameter combination prevents cache reuse.
4. Overly Complex Cache Rules: Many teams try to work around this problem manually by rewriting URLs, maintaining allowlists, stripping tracking parameters at the CDN layer, or configuring custom cache key normalization logic. These solutions are often vendor-specific and difficult to maintain consistently across platforms.

This is where the new No-Vary-Search HTTP header comes into play.

What Is No-Vary-Search?​

No-Vary-Search is a new HTTP response header that tells caches which query parameters should, or should not, affect cache matching. Instead of treating every query parameter as significant, servers can explicitly define which parameters matter, for example:

No-Vary-Search: params=("utm_source" "utm_campaign")

This indicates that the utm_source and utm_campaign parameters should be ignored when matching cache entries.

As a result, all of these URLs can reuse the same cached response:

/products
/products?utm_source=twitter
/products?utm_campaign=winter

The content is treated as equivalent for caching purposes. The header is part of ongoing work to improve cache efficiency and reduce unnecessary cache fragmentation on the modern web.

More Complex Use Cases​

Real-world query parameter behavior is rarely simple: the position of query parameters may or may not matter, and different parameters may need different rules. No-Vary-Search supports more advanced patterns for handling these cases.

Ignoring Everything​

When a page does not vary by query string, we could set the header value to the following:

No-Vary-Search: params
// or
No-Vary-Search: params=()

Keep in mind that this feature is still experimental. That is why there are two versions, params and params=(). Check this http-extensions pull request and this Chromium issue as pinpointed by Barry Pollard and Harry Roberts.

Ignore parameter order​

If a page returns the same content regardless of parameter order, we still want to serve it from one cache entry instead of caching each ordering as a different URL.

For example, the following URL:

/shoes?size=small&sort=price

Should be cached as the same page as:

/shoes?sort=price&size=small

To achieve that, we can set the header to:

No-Vary-Search: key-order

And it will return the same page from cache for these two seemingly identical URLs.

Ignore everything except X, Y​

Sometimes it is better to set the rule to ignore everything but have an exception for just a few query parameters and it can be done like the following:

No-Vary-Search: params, except=("variant" "price")

Combining multiple rules​

We may have a scenario where we need to use multiple rules at the same time and it can be done like this:

No-Vary-Search: params, key-order, except=("variant" "price")

This rule will instruct the cache that all parameters may be ignored, the order of query parameters does not matter, and to not ignore the variant and price parameters.

This way, all the following URLs will be cached under the same entry:

/products/shoes?variant=compact&size=small
/products/shoes?size=small&variant=compact
/products/shoes?utm_source=google&variant=compact

Combining the rules like this gives you fine-grained control over exactly which URLs share a single cache entry.

When should you not use No-Vary-Search?​

No-Vary-Search is powerful, but using it incorrectly can cause serious caching bugs.

The rule is simple: never ignore query parameters that change the response content.

But to be more precise, you should not use it in the following examples:

• Personalized Content: Avoid using it for parameters related to authentication, session state, localization, experiments, or personalization. For example /dashboard?user=peter must never share cache entries across users.
• Search Queries: Page /search?q=laptop is different from /search?q=monitor and that is why we shouldn't be ignoring the q query param as it would break the application.
• Pagination: Pagination parameters are also content-defining. Page ?page=1 is different from ?page=2. These must remain distinct cache entries.
• Unclear Cache Behavior: If you're unsure whether a parameter affects content, it's safer not to ignore it. Incorrect cache reuse can lead to users seeing stale content, broken personalization, or even security issues.

Keeping in mind these scenarios will help you avoid common caching problems.

No-Vary-Search and speculation rules​

Speculation Rules let web developers ask the browser to speculatively pre-render future pages a visitor is likely to visit. When the user actually navigates to the next page, this navigation can be practically instant.

However, you might have links to /login, /login?source=sidebar and /login?source=footer. If just the plain /login is pre-rendered the other two links won't result in an instant navigation. Using No-Vary-Search for the source parameter fixes this issue.

But what if you're pre-rendering the /login page but then click on /login?source=sidebar before the request is complete? The browser won't know about No-Vary-Search until the response is received.

To work around this problem, speculation rules offer the expects_no_vary_search option. The browser can then wait for the existing pre-render request instead of starting a new navigation.

<script type="speculationrules">
{
  "prerender": [{
    "source": "list",
    "urls": ["/login"],
    "expects_no_vary_search": "params=(\"source\")"
  }]
}
</script>

Browser compatibility​

The feature is currently marked as Experimental which can change in the future. Below is a small browser compatibility matrix that shows where this feature is currently supported.

For full browser compatibility, check out the MDN No-Vary-Search reference.

Summary​

Query parameters have always been one of the messiest parts of HTTP caching. Most sites depend on them heavily, but traditional cache behavior treats every variation as a separate resource, even when the response is identical.

No-Vary-Search introduces a cleaner and more standardized way to handle this problem. By explicitly defining which query parameters matter for cache matching, websites can:

• improve cache hit rates,
• reduce origin traffic,
• simplify cache configuration,
• and improve browser cache reuse.

For content-heavy websites with lots of tracking parameters, the performance impact can be significant. At the same time, the header must be used carefully. Ignoring the wrong parameters can easily introduce broken or unsafe cache behavior.

Like many caching optimizations, the mechanism itself is the easy part. The real work is correctly understanding which parts of a URL define the response.

Measure the impact of your performance work​

DebugBear lets you monitor the performance of your website and identify high-impact optimizations. Get alerted to performance regressions and see how better performance leads to better business outcomes.

Sign up for a free trial and start monitoring your website today! Run scheduled synthetic tests, benchmark Google CrUX data, and measure real user experience all in one place.

Monitor Page Speed & Core Web Vitals

DebugBear monitoring includes:

• In-depth Page Speed Reports
• Automated Recommendations
• Real User Analytics Data

Start Free TrialGo To App

What I had missed

One of them shared with me an article by Siddhant Khare, who lived that same reality up close. He builds AI agent infrastructure, meaning the tools other engineers use to run AI in production. And he still ended up hitting a wall. Not a performance wall. A human one.

His article, “AI fatigue is real and nobody talks about it”, haunts me, as it significantly completes what I had written.

The clash of probabilistic systems

My article talked about cognitive overload from validation. What I had not named is a very specific source of that overload: the fact of collaborating with a fundamentally unpredictable system, while our brains are wired for determinism.

Siddhant puts it with a precision I had not achieved:

you are collaborating with a probabilistic system, and your brain is wired for deterministic ones. That mismatch is a constant, low-grade source of stress.

The fact that the model decided to go a different direction today, that the same prompt produces different results from one day to the next, with no accessible explanation, no readable log, is terrible. For someone whose work depends on the ability to reason about deterministic systems, this is a source of quiet but constant anxiety.

I know, of course, that this is not inevitable. There are ways to reduce LLM variability, to make them more predictable. But it is a long-haul effort, and it is easy to underestimate just how much this unpredictability is a source of stress for teams.

The treadmill of new tools

All the more so because the pressure is constant to stay “up to date” in a team dynamic that reinvents itself every week, every day.

I fell into this trap hard. I was spending weekends evaluating new tools. Reading every changelog. Watching every demo. Trying to stay at the frontier because I was terrified of falling behind.

Entire weeks spent configuring a new tool, only to see it obsolete the following week. Carefully built workflows, outdated within three months after a model update. Siddhant calls this Knowledge Decay, the depreciation of accumulated knowledge. I had missed that one, but it is real.

This is not simply fatigue. It is a regular destruction of our cognitive investment, with no guarantee of return. And this destruction is systemic, not individual.

The “come on, let me try one more thing” trap

My article focused on organizational dysfunctions. Siddhant zooms in to the level of the individual daily work gesture.

You started with a clear goal. Thirty minutes later you’re debugging your prompt instead of debugging your code. You’re optimizing your instructions to a language model instead of solving the actual problem.

He calls this the Prompt Spiral, and I would be dishonest if I said I had never felt it. You start with a clear objective. The first response is 70% right. From there, you refine the prompt. The second iteration is 75% right, but it broke something the first one had gotten correct.

And so on. Forty-five minutes later, you have lost sight of the initial goal, you are in a vicious cycle, and you have not moved an inch.

What I find remarkable in his text is that Siddhant does not stop at the diagnosis. He proposes concrete rules, drawn from his own experience: three attempts maximum, then write it yourself; sessions capped at thirty minutes. The first hour of the morning without AI, to “warm up” his own thinking before delegating anything at all.

There is something sadly fascinating in seeing just how necessary these rules have become for good mental hygiene, and how difficult they are to stick to.

My article was addressed to managers and organizations. His is addressed to practitioners, directly. They are not at the same altitude. Both are necessary. Both are unsettling.

In short, I invite you to read “AI fatigue is real and nobody talks about it” because it completes everything I had left aside: the anxiety of the determinist facing the probabilistic, the exhaustion of permanent monitoring, the micro-decisions that accumulate until burnout.

And if you have lived what he describes, know that you are not alone. And that it is not a question of competence or discipline. What we are living through, what the market is imposing today, is hard, and will have significant consequences on our mental health, our ability to do good work, and our enjoyment of this profession. And this will hold true even if the bubble bursts.

Blame It on the Boogie 🎶

Between two articles questioning the how (how to better use these tools, how to reorganize processes, how to preserve one’s mental health), I also recently read another text that poses a different question: the question of why.

My article and Siddhant’s analyze effects: overload, erosion of skills, individual and collective fatigue. We describe what is happening on the deck of the ship. “Programming Still Sucks”, by Steven Langbroek, describes how the ship was built, who decided to throw the manual overboard, and who signed the list of eliminated positions while convincing themselves that “the juniors will adapt” (spoiler: no).

AI didn’t take our jobs. Greed did. Same greed that moved factories to Bangladesh and keeps slaves in cobalt mines in the Congo, wearing a new mask.

The text is more literary, more political, deliberately angrier (I love it all the more for it). It is an excellent illustration of how short-term productivity obsession destroys things without seeing it, without even knowing what it is destroying. Where my article asks “how to delegate better?” and Siddhant’s asks “how to survive this pace?”, this third text asks: who decided this was acceptable, and why?

The picture is fairly complete, and unfortunately fairly dark.

And unfortunately, we are right

To drive the nail in further, one last piece of reading: the INSEE¹ economic outlook note for March 2026, titled “Éclairage – Avec l’essor de l’intelligence artificielle générative, l’investissement numérique tire davantage la croissance aux États-Unis qu’en France, tandis que l’emploi recule dans les activités informatiques des deux côtés de l’Atlantique”.

One can read in particular:

In particular, sector-level indicators suggest an employment reversal over the past two years in the most exposed segments, notably in computer programming activities, and for which value added is trending upward, in both the United States and France. Furthermore, in both countries, employment adjustment in this sector would be concentrated among young entrants.

“Employment reversal”, in case you are not sure what that means, is an elegant way of saying that jobs are being destroyed. This is made explicit further on in a chart caption:

Employment in the information technology and information services sector fell by 3.0% between Q4 2023 and Q4 2025. The contribution of 15-29 year-olds (excluding apprentices) was -3.8 percentage points, compared to +1.4 points for 30-54 year-olds.

Because in this difficult context, older workers, who are able to draw on their experience to achieve the necessary emotional distance we are all talking about, are better positioned to cope with the situation (or at least, to cope with it the least badly). Young people are more vulnerable. They have not yet had time to build a career, develop transferable skills, or forge the experience that would make them more resilient in the face of this kind of shock.

In short, the numbers are there, and they are not good. We are right to be worried. We are right to feel tired. We are right to wonder how we are going to continue doing good work under these conditions.

Unfortunately our automated monitoring did not alert us to this outage. We were only alerted after reports of missing data from SpeedCurve customers. Once the initial report was received, we were able to identify and fix the issue within a few minutes. We then performed an investigation to discover the root cause, and put together a timeline of events.

The impact on your data

JavaScript error tracking is done in two parts: counting the number of errors on a page, and sending the full details of a small sample of those errors (up to 5 per page). The first part of this tracking was not affected, so the total number of errors shown in your dashboards remains correct*. The second part is what was affected: error message, filename, line, and column were all lost during the outage.

*One exception is when filtering to a specific error message.

This chart shows JavaScript error count during the outage period, with the total count unaffected by the outage.

The timeline

1. On 4 May we deployed and tested an update to the staging environment of our JS error tracking pipeline. This update included a new endpoint for receiving JS error beacons, and a new version of our RUM script (lux.js v4.5) that sends JS error beacons to the new endpoint.
2. On 7 May at around 08:00 pm (UTC) we deployed lux.js v4.5 to our production environment, but did not deploy the new endpoint. This meant that any JS error details generated by lux.js v4.5 were sent to an endpoint that did not exist, resulting in a 404 response code and the error details being lost.
3. On 7 May at 10:00 pm the majority of RUM traffic was using the new version of lux.js. Around this time, our monitoring alerted us that the number of JS errors in our ingest pipeline had dropped to zero. We spot-checked this alert against SpeedCurve's internal "dogfooding" account and determined it to be a monitoring issue.
4. The monitoring system was patched and the number of JS errors returned to a non-zero value. This value was significantly lower than before however this was falsely attributed to a monitoring system quirk.
5. On 11 May at 10:00 am, SpeedCurve received a report that JS error details were missing. This report was not forwarded to the engineering team until 07:00 pm on 12 May, at which point is was triaged as a P0 (urgent priority) incident.
6. On 12 May at 07:00 pm engineering identified the root cause as the endpoint not being deployed, causing JS error details to be dropped. The endpoint was deployed within several minutes.
7. At 7:20 pm the issue was confirmed as fixed.

What went wrong

Ultimately the root cause of this outage was human error, however there were gaps in our processes and monitoring systems that allowed it to go unnoticed for so long. The release process for the affected systems is nontrivial and entirely manual. In the past we have been able to rely on our monitoring to alert us of issues post-release. In this case our monitoring coverage was not sufficient.

This chart shows the number of errors from our RUM beacon endpoints. This metric did not increase during the outage, preventing any alerts from being issued.

The relevant part of our monitoring is a metric that tracks the number of errors in our RUM beacon endpoints. This metric is pushed to our monitoring service by Fastly, and for reasons unclear, this metric did not increase during the outage. This is shown in the chart above, which exhibited normal error rates during the entirety of the outage.

The alert that was triggered in event (3) of the timeline above was a strong signal that something was wrong. However because we used our internal dogfooding account for spot-checking, we were led to the half-baked conclusion that this was a monitoring issue and not a genuine data issue. While there was a monitoring issue, we mistakenly believed the issue was solved once we saw our internal data flow into the monitoring system. In reality, this data was coming from our staging environment only. This obscured the fact that no production data was flowing into the system.

And finally, there was a 35 hour delay between the issue first being reported and the report making its way to our engineering team. This delay did not directly contribute to the issue but did unnecessarily extend the outage.

Going forward

We're making some changes to avoid issues like this in the future: we'll expand our monitoring to cover many more types of potential issues, we'll improve our spot-checking so that both staging and production data is validated, and we'll onboard more engineers to support these systems.

We'd like to thank the users who reported this issue to support@speedcurve.com, and we're grateful for all of your feedback and patience.

What is the agentic browsing category?​

While Lighthouse has always primarily been a performance testing tool, it also includes other website quality checks looking at website accessibility, SEO, and other best practices.

The new category runs several checks to see how AI agents can interact with your website.

The agentic browsing category in the Lighthouse report runs several audits checking:

• That the website accessibility tree is well-formed
• Whether content shifts after rendering
• Correct WebMCP implementation
• llms.txt guidelines

Two important caveats​

The agentic browsing category is currently still marked as "under development". There's still a lot of uncertainty about what websites need to focus on in order for AI agents to use them effectively.

Also, you won't fail this category just because you haven't integrated new AI features. example.com gets a green 2/2 score!

How to check your agentic browsing score​

You can either test your website using an online tool or run Lighthouse on your own device.

Online testing tools​

To check your own website you can use the free DebugBear website quality checker:

1. Enter your website URL and run a test
2. Open the Lighthouse tab in the sidebar

PageSpeed Insights and Chrome DevTools still use an older version of Lighthouse, but this should change in the coming months.

Locally on your own computer​

To test your website locally from your own computer you can use the Lighthouse command line tool:

1. Install the latest version of Lighthouse: npm install -g lighthouse@latest
2. Run a test, e.g. lighthouse --view https://web.dev/

Building agent-friendly websites​

Google recently published a guide on how to build agent-friendly websites and there is some overlap between the new Lighthouse checks and the recommendations in the article.

One key take-away from the guide is that AI agents interact with website content in different formats:

1. Screenshots
2. HTML code
3. The accessibility tree

What checks does the agentic browsing category actually run?​

What AI agent issues can Lighthouse actually detect? The new category combines existing report data with several new audits.

Accessibility tree is not well-formed​

The accessibility tree is a simplified representation of the page structure that is used by accessibility tools and AI agents. This audit data is based on the existing accessibility checks run by Lighthouse.

AI agents can process the accessibility tree more efficiently compared to the full HTML code or a website screenshot.

WebMCP validation​

WebMCP is an API that lets websites provide specific commands that agents can use to interact with them. Unlike general MCP servers, WebMCP is built for front-end interactions in the context of the visitor's browser session.

There's a declarative version of the API based on annotating HTML forms on the page. The WebMCP audit checks whether forms are annotated and if the annotations match the expected schema.

Lighthouse also surfaces all WebMCP tools that have been registered on the page, whether they were added through the declarative API or programmatically with navigator.modelContext.registerTool.

llms.txt does not follow recommendations​

llms.txt files are a proposed way for websites to provide information to AI agents and crawlers. However, it is not widely used by AI tools currently.

The new Lighthouse audit checks if the website provides an llms.txt file. If it does, it checks if the file is missing an H1 header, is too short, or doesn't contain any links.

Detecting layout shifts​

It's hard to use a website if content shifts around unexpectedly. In 2020, Google introduced the Cumulative Layout Shift (CLS) metric to measure and report these shifts.

Why does this matter to AI agents? Google's guide explains:

Ensure stable layout. Agents that take screenshots will likely be confused if your website layout is constantly shifting

Ultimately this audit just provides existing CLS score reporting in a different category. An AI agent may interact with your website more quickly than a human visitor, so shifts that occur as content is loading may be more disruptive to an agent.

Test your website and keep it optimized​

Whether you're optimizing your website for performance, SEO, or AI agents, DebugBear provides in-depth reporting on website quality and visitor experience. Identify key issues and get alerted when there's a regression.

Start your free trial today.

Monitor Page Speed & Core Web Vitals

DebugBear monitoring includes:

• In-depth Page Speed Reports
• Automated Recommendations
• Real User Analytics Data

Start Free TrialGo To App