Application Performance Monitoring (APM)What it checks and how to fix it

What it checks

Looks at the rendered homepage for a real-user performance monitoring (RUM/APM) script: New Relic, Datadog RUM, Dynatrace, AppDynamics, Elastic APM, Splunk RUM, SpeedCurve, Pingdom RUM, Raygun RUM or Sentry Performance. It passes when one of them, or the web-vitals library, is found; it warns when the page only calls the browser Performance API by hand, or when nothing is found.

Why it matters

Lab tests like Lighthouse measure one simulated visit; real visitors are on slow phones, distant networks and pages you never tested. Without field data you learn about a slow checkout or a regressed LCP from lost conversions and from Google's Core Web Vitals report weeks later. A RUM tool shows the real distribution of load times per page, device and country, and alerts you when a deploy makes it worse.

How to fix it

Add a real-user monitoring script to every page. If you already use an APM vendor on the backend, enable its browser agent so frontend and backend traces line up.

The lightest option is Google's open-source web-vitals library, sending Core Web Vitals to your own analytics endpoint:

<script type="module">
  import { onCLS, onINP, onLCP } from "https://unpkg.com/web-vitals@4?module";

  function send(metric) {
    navigator.sendBeacon("/vitals", JSON.stringify({ name: metric.name, value: metric.value, id: metric.id }));
  }

  onCLS(send);
  onINP(send);
  onLCP(send);
</script>

With Sentry, performance monitoring is one option of the browser SDK:

Sentry.init({
  dsn: "https://<key>@o0.ingest.sentry.io/<project>",
  integrations: [Sentry.browserTracingIntegration()],
  tracesSampleRate: 0.1
});

Sample a fraction of visits (tracesSampleRate) to keep the cost and the overhead low.