Conrad monitoring

Train

Front-end monitoring

Core Web Vitals (LCP, INP, CLS) with their thresholds and fixes, real user monitoring with Grafana Faro versus Lighthouse, sampling and consent, TTFB on a server-rendered site, and tracing a click from the browser to the database.
Web VitalsInteraction to Next PaintGrafana Faro

From the Grafana Faro part of your Monitoring note.

Know

  • LCP (Largest Contentful Paint): when the largest image or text block appears; good at 2.5 s or less. Fix with cached HTML, a CDN hero image in the right size, fetchpriority="high", never lazy-loaded.
  • INP (Interaction to Next Paint): from a click, tap or key press until the next frame is painted, looking at the slowest interactions of the visit; good at 200 ms or less. Fix with less JavaScript, lazy hydration, split long tasks, fewer third-party scripts. It replaced FID in March 2024.
  • CLS (Cumulative Layout Shift): how much content jumps; good at 0.1 or less. Fix with image dimensions, reserved space for ads and banners, matching font fallbacks.
  • All three are judged at the 75th percentile of real visits.
  • TTFB: navigation start to the first byte of HTML, including DNS, TLS, the CDN and server time; good under about 800 ms; LCP can never be faster.
  • Real user monitoring (Grafana Faro): Web Vitals, errors and timings from real browsers, sampled (for example 10%) and only after consent. Lighthouse is lab data, for CI and debugging; Google ranks on field data.
  • Tracing from the front end: Faro starts a trace and adds traceparent to fetch calls to your own APIs (allowed in CORS); OpenTelemetry on the server continues it down to the database; everything lands in Tempo.

Fact check of your notes

Gotcha· INP is about the next paint, not only the JavaScript

INP runs from the interaction until the browser paints the next frame: the wait before the handler can run (a busy main thread), the handler itself, and the rendering after it. It reports roughly the worst interaction of the visit, not the first one or an average.

Exercise

Exercise
  • Open a large shop's product page with the Performance panel and find the LCP element, the longest interaction and any layout shifts; say what you would change.
  • Add the web-vitals library to a Nuxt app, log LCP, INP and CLS to the console with their attribution, and make each one worse on purpose to see it move.

Be able to say

Be able to say· Explain LCP, INP and CLS in one minute.

"LCP is when the biggest image or text block shows up, on a shop usually the product image; good is under 2.5 seconds, and it comes down to a fast server response and a prioritised, well-sized hero image. INP is how fast the page visibly reacts to clicks across the whole visit; good is under 200 milliseconds, and the enemy is long JavaScript tasks, from hydration or third-party scripts. CLS is how much the layout jumps; good is under 0.1, fixed by reserving space for images, ads and banners. All three are measured on real users at the 75th percentile."

Be able to say· Why measure real users if we already have Lighthouse?

"Lighthouse is one simulated load on one device, which is great for catching regressions in CI but says nothing about real phones and networks, and Google ranks on real-user data. So we run a small script like Grafana Faro on a sample of sessions, only after consent, and get Web Vitals, errors and timings from real visits, and with tracing, a slow click can be followed into the backend."

Your notes

Open in Notes

Nothing yet. Notes filed here show up on this page and the section overview.

Metrics, logs and traces

The three kinds of monitoring data and when to use each, the path from a pod to a Grafana dashboard with Alloy, Loki, Mimir and Tempo, structured logs, Prometheus metric types, exposing metrics from Nitro, percentiles, distributed tracing, and what to alert on.

Load testing

Load testing a storefront with k6 — smoke, load, stress, spike and soak tests, realistic journeys and URL mixes, thresholds, and what to watch while the test runs.