DEV Community: nosyos

Most LCP Fixes Come Down to One Image

nosyos — Thu, 16 Apr 2026 14:00:00 +0000

A Next.js app with next/image on every image component. Lighthouse image audit: no issues. LCP: 4.2 seconds. The hero was a CSS background-image. next/image doesn't touch those. Nobody had checked what the LCP element actually was.

Find your LCP element before you do anything else

This is the step most people skip. They add next/image, run Lighthouse, see green checkmarks on the image audit, and wonder why LCP is still slow.

Open Chrome DevTools, run Lighthouse, and look at what it marks as the LCP element. If it's a background-image set via CSS, the browser can't preload it the same way it handles a real <img> tag, and it won't get early fetch priority. Move it to an <img> element. This one change has fixed more LCP problems than anything else I've seen.

`fetchpriority="high"` is doing more work than most developers realize

The browser assigns fetch priority based on what it finds during the initial HTML parse. Images discovered late — inside components that render after hydration, or below the fold at first scan — get normal or low priority. By the time the browser decides to fetch them, the LCP window is already closing.

For your LCP image, you want the fetch to start as early as possible.

<img
  src="/hero.webp"
  fetchpriority="high"
  width={1200}
  height={600}
  alt="..."
/>

In Next.js, the priority prop on next/image sets this automatically and also injects a preload link into <head>:

<Image
  src="/hero.webp"
  priority
  width={1200}
  height={600}
  alt="..."
/>

Don't use priority on more than one or two images per page. Telling the browser everything is urgent means nothing is.

next/image defaults will silently hurt your LCP

next/image lazy-loads by default. That means if your LCP image is rendered via next/image without priority, the browser is intentionally delaying its fetch until the image is about to enter the viewport.

I've seen this cause regressions on otherwise well-optimized pages. The format is correct, the dimensions are explicit, Lighthouse scores are green — but LCP is 300ms slower than it should be because someone forgot priority. It doesn't throw a warning. It just quietly loads late.

For any image that could be the LCP element on any viewport — hero images, above-the-fold product shots, article cover images — set priority. Default to it rather than remembering to add it.

Explicit dimensions are non-negotiable

A browser that doesn't know an image's dimensions reserves no space for it. When the image loads, content shifts. That's a CLS problem, not just a performance one — it makes the page feel broken to users even if the load time is acceptable.

next/image will warn you when dimensions are missing. Every other <img> in your codebase that doesn't go through next/image should have explicit width and height set too. It takes ten seconds and prevents a class of layout bugs entirely.

Format: stop overthinking it

WebP is 25–35% smaller than JPEG at equivalent quality. AVIF is another 20–30% on top of that. next/image serves AVIF to browsers that support it and falls back to WebP automatically — you don't need to configure anything.

The format switch matters, but once you're serving WebP, the gains from AVIF are marginal compared to getting fetchpriority right on the LCP element. Fix the priority first.

Optimizing once isn't enough

Lighthouse confirms the fix on your machine. It doesn't tell you whether it holds under real conditions — actual devices, varied networks, CDN behavior on cold loads.

Measuring from real users is the only way to know:

new PerformanceObserver((list) => {
  const lcp = list.getEntries().at(-1)?.startTime;
  if (lcp) sendMetric({ metric: 'LCP', value: lcp, page: location.pathname });
}).observe({ type: 'largest-contentful-paint', buffered: true });

The harder problem is that optimizations regress. A new developer adds a hero image without priority. Someone replaces an <img> with a CSS background. The LCP you fixed at 1.6s quietly climbs back to 3.2s after the next deploy, and nobody notices until a user mentions it. If you want to catch that within minutes rather than days, I built RPAlert for exactly this — it handles the LCP monitoring and alerting layer for React apps, collecting field data from real browsers and posting to Slack or Discord when thresholds are crossed. Worth setting up after you've done the optimization work, so the gains actually stick.

The fix is almost always the same: find the LCP element, make it a real <img> tag, set fetchpriority="high", give it explicit dimensions. Everything else is secondary.

Catching React Performance Regressions Before Your Users Do

nosyos — Tue, 14 Apr 2026 14:04:00 +0000

Three hours after a deploy, someone posts a screenshot in Slack. One-star review. App "takes forever to load." You check Lighthouse — fine. You check Sentry — no errors. The regression started the moment you deployed. Nobody knew until a user complained.

This is the normal state of affairs for most teams, and it's not hard to fix.

The first 30 minutes are the cheapest

Performance regressions don't announce themselves. They show up in production under conditions you can't fully replicate: real devices slower than your dev machine, networks that drop in and out, CDN cache misses on fresh deploys.

The first 10–30 minutes after a deploy are when regressions are cheapest to fix. You can just roll back. By the time a support ticket arrives, you're already hours into the impact window and the fix is a proper investigation, not a revert.

Why your existing tools miss this

Lighthouse CI runs against staging with synthetic conditions. It won't catch regressions that only appear under real network speeds or with production data volumes. A LCP that went from 1.8s to 3.2s doesn't throw an exception — Sentry has nothing to report. APM tools tell you about backend latency, not what's happening in the browser.

The shared blind spot: real users on real devices. None of these tools will fire when your LCP degrades after a deploy.

LCP is what to watch

For deploy regressions specifically, LCP is the right metric. It's the best proxy for perceived load speed, and it's where most regressions surface first. Long Tasks are the clearest signal of render bloat. FCP is a useful early warning.

The browser has a native API for all of this:

const lcpObserver = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lcp = entries[entries.length - 1].startTime;

  if (lcp > 2500) {
    // don't batch threshold crossings — send immediately
    sendMetric({ metric: 'LCP', value: lcp, page: location.pathname });
  }
});
lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

This runs in every user's browser. The question is what you do with the data. A minimal pipeline:

React app → PerformanceObserver → batch POST every 30s (immediate on threshold cross)
→ your API → threshold check → Discord/Slack alert

The batching distinction matters. Routine measurements can queue up — there's no reason to POST on every LCP reading. But when something crosses a threshold you care about, you want it sent immediately, not held for the next batch window.

For the alert destination: email gets buried. If your team is in Discord or Slack, that's where it should go. Someone needs to see it within five minutes of the regression starting.

What the alert loop actually looks like

You deploy at 2pm. At 2:03, a Discord message arrives: LCP exceeded 2.5s on /checkout, three minutes after the last deploy. You open the diff, find a new image component missing loading="lazy", fix it, deploy the hotfix by 2:15.

Fifteen minutes of degraded performance.

Without the alert: the first signal is a support ticket at 4:30pm. You dig through Sentry — nothing, because no exceptions were thrown. You run Lighthouse locally — looks fine, warm cache. You eventually find the image issue around 6pm. Four hours of impact instead of fifteen minutes.

The alert doesn't prevent the regression. It collapses the time between "regression exists" and "someone is fixing it."

Building vs. not building this

The pipeline above isn't complicated to build. It's also not that complicated to maintain — until the edge cases around batching logic, threshold tuning, and webhook routing start to accumulate.

If you'd rather skip building it, I built RPAlert for exactly this reason — it handles the PerformanceObserver setup, threshold logic, and Discord/Slack routing. Install the SDK and wrap your root layout:

npm install rpalert-sdk

import { RPAlertProvider } from "rpalert-sdk/react";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <RPAlertProvider apiKey="YOUR_API_KEY">
          {children}
        </RPAlertProvider>
      </body>
    </html>
  );
}

LCP, FCP, CLS, Long Tasks — all measured from that point. Alert fires when thresholds are crossed. There's a free tier if you want to verify the pipeline end to end before committing.

One thing worth being clear about: RPAlert isn't a Sentry replacement. Sentry tells you why something broke. RPAlert tells you when to go look at Sentry. Different jobs, and they work well together.

The goal isn't zero regressions — that's not realistic in any active codebase. The goal is making sure you find out before your users do.

What the React Compiler Quietly Skips

nosyos — Thu, 09 Apr 2026 14:09:00 +0000

React Compiler 1.0 went stable in October 2025. Half the tutorials I saw declared useMemo dead. It's not — and on most existing codebases, the compiler will silently skip the components you most want it to optimize.

The compiler handles one thing

Re-render performance. It's a build-time plugin that analyzes your components and inserts memoization automatically, without you writing it.

The genuinely useful part: it can memoize values in code paths after an early return, which manual useMemo can't do.

function Component({ isAdmin, data }) {
  if (!isAdmin) return null;
  const processed = expensiveTransformation(data); // compiler memoizes this
  return <Chart data={processed} />;
}

What it doesn't touch: first render cost, Long Tasks from large list renders, expensive one-time computations on mount. None of that changes.

Silent bailouts

When the compiler encounters code it can't safely analyze — mutating props, reading mutable refs during render, class instances with internal state — it skips the component entirely. No warning. No error. It just leaves that component unoptimized and moves on.

This is the part that catches people off guard. You enable the compiler expecting your most expensive component to benefit, and nothing changes. The compiler bailed on it without telling you.

The diagnostic is in React DevTools. Successfully compiled components show a "memo ✨" badge. Check your heaviest components first. If the badge isn't there, that's your answer.

Most existing codebases have violations

The compiler works well on clean, pure function components with immutable data. Greenfield Next.js apps tend to fit. Existing apps often don't.

Patterns that cause silent skips:

// Direct mutation during render
function BadComponent({ items }) {
  items.push(newItem); // skipped
  return <List items={items} />;
}

// Mutable ref read during render
function AlsoProblematic({ inputRef }) {
  const value = inputRef.current; // skipped
  return <div>{value}</div>;
}

// Class instance methods
function WithClassInstance({ model }) {
  const label = model.getFormattedLabel(); // compiler can't track internal state
  return <span>{label}</span>;
}

None of these are bugs. Your app won't break. But the compiler won't help them.

Before enabling the compiler on an existing codebase, run the ESLint plugin first. eslint-plugin-react-hooks with recommended-latest includes compiler rules. The violation count is a rough proxy for actual benefit. High violation count means the compiler will spend most of its time bailing out.

useMemo isn't dead

There's still one category where manual memoization is the right call: useEffect dependencies that need guaranteed reference stability.

function Component({ userId }) {
  const options = useMemo(() => ({
    headers: { 'X-User-Id': userId }
  }), [userId]);

  useEffect(() => {
    fetchData(options);
  }, [options]);
}

The compiler's own docs call useMemo and useCallback valid escape hatches for this. The mental shift is from reaching for them by default to reaching for them when you have a specific reason. That's a real improvement — just not elimination.

For existing code with lots of manual memoization, don't rush to remove it. The docs explicitly recommend leaving it in place for now. Removing it can change the compiler's output in ways that don't surface until something re-renders unexpectedly.

Roll it out on a subset first

Next.js 15+ supports annotation mode, which only compiles files that opt in:

// next.config.js
const nextConfig = {
  experimental: {
    reactCompiler: {
      compilationMode: 'annotation',
    },
  },
};

'use memo'; // top of each file you want compiled

export function MyComponent() {
  // compiler applies here
}

One thing worth following: pin the exact compiler version with --save-exact. The React team has said memoization behavior may change in minor versions. Auto-upgrading and then debugging unexpected re-render changes is not a good use of a morning.

What to write going forward

New components: write them without manual memoization. Pure functions, no mutations during render, and the compiler handles it.

Existing components: run ESLint first, check the DevTools badges after enabling, and don't touch working useMemo/useCallback calls until you have a concrete reason.

For components doing genuinely heavy work — large list renders, expensive data transformations — the compiler helps with unnecessary re-renders, but the underlying cost is still there. Those still need virtualization, useTransition for non-urgent updates, or Web Workers for off-thread computation.

The compiler is a real improvement, particularly for deeply nested trees where unnecessary re-renders compound. It raises the floor for everyone. It just doesn't replace thinking about where the expensive work actually is.

Why Your App Feels Fast in Staging and Slow in Production

nosyos — Tue, 07 Apr 2026 14:05:00 +0000

A Lighthouse score of 95 on staging doesn't mean your users will see that. It means your machine, on your network, with your warm cache, hit that number once.

The gap between staging and production isn't random bad luck. It has predictable causes that almost every team hits in the same order.

You're not testing on anything like a real device

The biggest one. Most web developers work on hardware that's two to three times faster than the median device visiting their app. React component trees that reconcile in 40ms on a MacBook Pro take 180ms on a mid-range Android phone from 2022. That's not a small difference — it crosses the line between "feels fast" and "feels like something is wrong."

CPU throttling in DevTools gets you closer. It's not the same. A simulated 6x slowdown doesn't capture memory pressure, thermal behavior, or how the GPU pipeline behaves on constrained hardware. Test on a physical mid-range Android device at least once per feature that touches render-heavy components. This is the most reliable signal you have. Everything else is an approximation.

BrowserStack works if you don't have a device. It's slower to iterate but it's still a real device.

Cold cache is a different product

When you're iterating on staging, you've hit that URL dozens of times. The browser cache is warm. The CDN has every asset hot. Your service worker is running.

Your users don't have any of that on their first visit. The first visit is what determines whether they stay or leave, and it's exactly the scenario you never test.

Cold cache isn't just slower — the loading sequence is different. Resources that appear instant in your workflow take seconds the first time. Font requests that look like they resolve immediately actually block layout. Preconnect hints that feel redundant do real work on a cold visit.

Run your staging tests in an incognito window with cache disabled. It's not a substitute for real-user data but it surfaces the worst offenders immediately.

Staging data doesn't tell you how your components scale

Staging databases are seeded for developer convenience: enough data to see the UI, not enough to stress it. A list component that renders 50 items smoothly in staging might be rendering 5,000 in production, and nobody noticed because the test data never revealed it.

React re-renders scale with data. A component tree that's fine at 50 records creates Long Tasks at 500. You don't need to copy production data — synthetic data at realistic scale is enough. But it has to be realistic scale.

Third-party scripts you forgot about

Analytics, chat widgets, A/B testing tools, tag managers. In staging they're often disabled, sandboxed, or absent entirely. In production they load fully, compete for main thread time, and contribute to LCP delays in ways that never show up in local testing.

Run your production URL through WebPageTest with mobile throttling enabled and look at the waterfall. You'll see scripts you forgot were there. For each one, the question is simple: what breaks if this doesn't load? If the answer is "nothing visible to users," question whether it belongs.

Measure from real browsers, not synthetic tests

This is where most teams underinvest.

Lighthouse runs in a controlled environment on a single configuration. It's useful for catching regressions in a CI pipeline. It is not telling you what your actual users experience.

PerformanceObserver runs in your users' browsers and gives you the real distribution:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lcp = entries[entries.length - 1].startTime;

  fetch('/api/metrics', {
    method: 'POST',
    body: JSON.stringify({ metric: 'LCP', value: lcp, page: location.pathname }),
  });
}).observe({ type: 'largest-contentful-paint', buffered: true });

Add this to production. Not staging. The data you want is from real users on real devices on real networks. Once you have it, performance stops being a feeling and becomes something you can track across deploys.

The deploy window is where this matters most. A CSS change that pushes your LCP element below the fold, or a new image that wasn't optimized, can move your p75 LCP from 1.8s to 3.5s overnight. If you're only checking periodically, you'll find out from a user complaint. If you're watching the real-user data, you'll know within an hour of deploying.

The PerformanceObserver approach above works if you have somewhere to send the data and something watching the thresholds. If you'd rather not build and maintain that alerting layer yourself, RPAlert does exactly this for React apps — install the SDK, wrap your component, set your LCP threshold, and it posts to Slack or Discord within 60 seconds of a regression. There's a free tier if you want to try it on a single app first.

Three things worth doing this week

Check your LCP element on your main pages. Verify it's WebP, has fetchpriority="high", and has explicit dimensions. Twenty minutes, fixes the most common issue.

Add the PerformanceObserver snippet to production and log to your existing analytics. Just having the data changes what gets prioritized in your next sprint.

Run your production URL through WebPageTest once with a mobile throttling preset. Look at what loads, in what order, and what you've forgotten about.

The compounding problem with performance is that each change seems fine in isolation, in the environment where it was built. Production is the only place where all of it adds up at once. Measuring there isn't an advanced optimization — it's the baseline for knowing what's actually happening.

Long Tasks Are Quietly Killing Your React App's Performance

nosyos — Thu, 02 Apr 2026 14:02:00 +0000

Here's something that doesn't get talked about enough: your React app can have great LCP and FCP scores, pass all your Lighthouse checks, and still feel sluggish to use.

The culprit is usually Long Tasks.

What's a Long Task?

The browser's main thread handles everything — parsing HTML, running JavaScript, responding to user input, painting pixels. It can only do one thing at a time.

A Long Task is any task that occupies the main thread for more than 50 milliseconds without a break. While a Long Task is running, the browser can't respond to anything else. Click a button during a Long Task? Nothing happens — until the task finishes.

50ms might sound short, but human perception starts noticing unresponsiveness around 100ms. Any Long Task over that threshold will feel broken to a user.

Why React Makes This Easy to Get Wrong

React renders synchronously by default (outside of concurrent features). When you trigger a state update, React processes the entire component tree update in one go. If that update is expensive — lots of components, heavy computations, large lists — it becomes a Long Task.

The tricky part: this doesn't show up in unit tests. It doesn't throw an error. It doesn't affect your Lighthouse score in a way that's obvious. It just makes your app feel slow.

Some common patterns that create Long Tasks in React apps:

Rendering large lists without virtualization

// If `items` has 500+ entries, this creates a Long Task on every render
function ItemList({ items }) {
  return (
    <ul>
      {items.map(item => <ExpensiveItem key={item.id} item={item} />)}
    </ul>
  );
}

Expensive computations in render

function Dashboard({ rawData }) {
  // This runs on every render, blocking the main thread
  const processed = rawData.reduce((acc, row) => {
    return heavyTransformation(acc, row);
  }, {});

  return <Chart data={processed} />;
}

State updates that cascade through large component trees
A single setState at the top of a deeply nested tree can trigger hundreds of re-renders in one synchronous block.

How to Detect Long Tasks

The browser exposes this through PerformanceObserver:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Long Task detected:', {
      duration: entry.duration,       // how long it ran (ms)
      startTime: entry.startTime,     // when it started
      attribution: entry.attribution, // which script caused it (limited support)
    });
  }
});

observer.observe({ type: 'longtask', buffered: true });

Run this in your production app for a day and look at the output. If you're seeing regular Long Tasks over 100ms — especially clustering around user interactions or page loads — you have a real problem.

One thing worth knowing: entry.attribution gives you some information about what caused the task, but browser support varies and the data is often vague. It'll tell you it was a script, but not always which function.

For more precise attribution, the Chrome DevTools Performance panel is your best friend. Record a session, look for the red triangles at the top of the flame chart — those are Long Tasks. Click into them and you'll see exactly which functions ran.

Fixing Long Tasks

There's no single fix. The approach depends on what's causing the task.

For expensive renders: useMemo

function Dashboard({ rawData }) {
  // Only recalculates when rawData changes
  const processed = useMemo(() => {
    return rawData.reduce((acc, row) => heavyTransformation(acc, row), {});
  }, [rawData]);

  return <Chart data={processed} />;
}

useMemo doesn't prevent Long Tasks on the first render, but it prevents them from happening again unnecessarily.

For large lists: virtualization

Libraries like react-window or @tanstack/virtual only render the rows visible in the viewport. If you have more than a couple hundred items in a list, this is almost always worth doing.

import { FixedSizeList } from 'react-window';

function ItemList({ items }) {
  return (
    <FixedSizeList height={600} itemCount={items.length} itemSize={50} width="100%">
      {({ index, style }) => (
        <div style={style}>
          <ExpensiveItem item={items[index]} />
        </div>
      )}
    </FixedSizeList>
  );
}

For non-urgent updates: useTransition (React 18+)

function SearchPage() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  function handleSearch(value) {
    setQuery(value); // urgent — update input immediately

    startTransition(() => {
      setResults(searchItems(value)); // non-urgent — can be interrupted
    });
  }

  return (
    <>
      <input value={query} onChange={e => handleSearch(e.target.value)} />
      {isPending ? <Spinner /> : <ResultsList results={results} />}
    </>
  );
}

useTransition tells React that the update inside startTransition is low priority. React can interrupt it if something more urgent comes in (like another keystroke). This is particularly effective for search-as-you-type patterns.

For truly heavy work: move it off the main thread

If you're doing something computationally expensive that can't be memoized — parsing a large dataset, running a sorting algorithm on thousands of items — consider a Web Worker:

// worker.ts
self.onmessage = (e) => {
  const result = heavyComputation(e.data);
  self.postMessage(result);
};

// component
const worker = new Worker(new URL('./worker.ts', import.meta.url));

worker.onmessage = (e) => {
  setResult(e.data); // runs on main thread, but the computation didn't
};

worker.postMessage(largeDataset);

Web Workers don't have access to the DOM, so this only works for pure computation. But when it applies, it's the cleanest solution — zero Long Task, because the work literally doesn't happen on the main thread.

The Connection to INP

If you've looked at your Core Web Vitals recently, you might have noticed INP (Interaction to Next Paint) — the metric that replaced FID in 2024. It measures how long it takes the page to respond to user interactions.

Long Tasks are the primary cause of bad INP. When a user clicks and there's a Long Task in progress, the browser queues the input event and processes it after the task finishes. If that task runs for 200ms, your INP for that interaction is 200ms+ — in the "needs improvement" range.

Fixing Long Tasks improves INP directly.

Monitoring This in Production

DevTools is great for debugging a specific session, but it won't tell you how often Long Tasks are happening for real users across different devices.

The PerformanceObserver code above works in production. A few things worth tracking:

Count of Long Tasks per page load — is this happening on every visit or just edge cases?
Duration — are they 60ms or 400ms? The severity matters
When they happen — during initial load, or triggered by user interactions?

If Long Tasks spike after a deploy, that's a signal something in the new code is blocking the main thread. Having an alert set up for unusual Long Task counts is worth it — it's the kind of regression that's easy to introduce and hard to notice until users start complaining.

This is actually what pushed me to build RPAlert — I kept finding out about Long Task spikes and LCP regressions from users instead of catching them myself. It handles the PerformanceObserver setup and sends a Discord alert when thresholds are crossed, so you don't have to build the plumbing yourself.

That's the gist of it. Long Tasks aren't glamorous, but they're one of the most direct causes of "this app feels slow" complaints — and they're largely invisible without instrumentation. Worth adding to your monitoring stack.

Core Web Vitals Explained: What They Are, How to Measure Them, and Why They Matter for React Apps

nosyos — Tue, 31 Mar 2026 14:00:00 +0000

If you've seen the term "Core Web Vitals" and kept scrolling, this article is for you.

It's not just SEO jargon. These three metrics are the clearest signal we have for whether a web app feels fast to a real user — and they're measurable directly from your React code.

This article covers what the three metrics actually mean, how to measure them without any external tools, and what to do when they're bad.

What Are Core Web Vitals?

Core Web Vitals are three metrics defined by Google to measure user experience from a loading and interactivity perspective. They're based on real user data, not synthetic benchmarks.

The three metrics:

Metric	Measures	Good threshold
LCP — Largest Contentful Paint	Loading speed	≤ 2.5s
FCP — First Contentful Paint	Time to first visible content (supporting metric, not a Core Web Vital)	≤ 1.8s
CLS — Cumulative Layout Shift	Visual stability	≤ 0.1

There's a fourth metric worth knowing: INP (Interaction to Next Paint), which replaced FID (First Input Delay) in 2024. INP measures how responsive the page feels when you click or type. We'll cover it briefly at the end.

LCP — Largest Contentful Paint

What it measures: How long until the largest visible element on screen finishes loading.

This is usually a hero image, a large heading, or the main content block. Whatever takes up the most screen real estate "above the fold."

Why it matters: LCP is the closest single metric to "when does this page feel loaded." Users don't think in milliseconds — they think "did it load or not." LCP is when the answer flips from "no" to "yes."

What causes bad LCP:

Large, unoptimized images (the most common cause)
Render-blocking JavaScript or CSS that delays the page from painting
Slow server response times (TTFB)
Third-party scripts loading before your content

How to measure it in code:

const lcpObserver = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  // Use the last entry — LCP can be updated as more content loads
  const lastEntry = entries[entries.length - 1];

  console.log('LCP:', lastEntry.startTime, 'ms');
  console.log('Element:', lastEntry.element); // Which element triggered it
});

lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

Good: ≤ 2.5s

Needs improvement: 2.5s – 4.0s

Poor: > 4.0s

FCP — First Contentful Paint

What it measures: How long until the browser renders the first piece of DOM content — any text, image, or non-white canvas element.

Why it matters: FCP is a leading indicator. A slow FCP almost always means a slow LCP. If FCP is bad, users are staring at a blank screen, which is the worst user experience possible — worse than a slow load, because users don't even know if anything is happening.

What causes bad FCP:

Render-blocking resources (CSS and JS that pause HTML parsing)
Server-side rendering issues
Heavy JavaScript bundles that need to parse before anything renders

How to measure it:

const fcpObserver = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.name === 'first-contentful-paint') {
      console.log('FCP:', entry.startTime, 'ms');
    }
  }
});

fcpObserver.observe({ type: 'paint', buffered: true });

Good: ≤ 1.8s

Needs improvement: 1.8s – 3.0s

Poor: > 3.0s

CLS — Cumulative Layout Shift

What it measures: How much the page layout shifts unexpectedly after it starts loading.

You've experienced this. You're reading an article, an ad loads above the paragraph you're on, and everything shifts down. You accidentally click the ad. That's a layout shift — and CLS measures how much of this happens across the full page lifecycle.

Why it matters: Layout shifts erode user trust instantly. They also cause accidental clicks, which is particularly bad on e-commerce and form pages.

What causes bad CLS:

Images and videos without width and height attributes set
Ads, embeds, or iframes without reserved space
Dynamically injected content above existing content
Web fonts loading and causing text to reflow (FOIT/FOUT)

How to measure it:

let clsValue = 0;

const clsObserver = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only count shifts that happen without user interaction
    if (!entry.hadRecentInput) {
      clsValue += entry.value;
      console.log('Current CLS:', clsValue);
    }
  }
});

clsObserver.observe({ type: 'layout-shift', buffered: true });

Good: ≤ 0.1

Needs improvement: 0.1 – 0.25

Poor: > 0.25

How These Metrics Relate to Each Other

Understanding the sequence helps:

Navigation starts
    ↓
FCP fires — first pixel of content rendered
    ↓
LCP fires — largest content element rendered
    ↓
Page becomes interactive
    ↓
CLS accumulates throughout — tracks all layout shifts

In practice: if FCP is bad, LCP will be bad too. If FCP is fine but LCP is bad, the issue is usually the main content (an image, a large element) taking too long. CLS is independent — a page can have great LCP and terrible CLS.

Measuring in Your React App: A Complete Setup

Here's a minimal but complete implementation that collects all three metrics and logs them:

// utils/web-vitals.ts

type MetricName = 'LCP' | 'FCP' | 'CLS';
type MetricReport = {
  name: MetricName;
  value: number;
  rating: 'good' | 'needs-improvement' | 'poor';
};

function getRating(name: MetricName, value: number): 'good' | 'needs-improvement' | 'poor' {
  const thresholds = {
    LCP: [2500, 4000],
    FCP: [1800, 3000],
    CLS: [0.1, 0.25],
  };

  const [good, poor] = thresholds[name];
  if (value <= good) return 'good';
  if (value <= poor) return 'needs-improvement';
  return 'poor';
}

export function initWebVitals(onMetric: (metric: MetricReport) => void) {
  // LCP
  new PerformanceObserver((list) => {
    const entries = list.getEntries();
    const last = entries[entries.length - 1];
    const value = last.startTime;
    onMetric({ name: 'LCP', value, rating: getRating('LCP', value) });
  }).observe({ type: 'largest-contentful-paint', buffered: true });

  // FCP
  new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      if (entry.name === 'first-contentful-paint') {
        const value = entry.startTime;
        onMetric({ name: 'FCP', value, rating: getRating('FCP', value) });
      }
    }
  }).observe({ type: 'paint', buffered: true });

  // CLS
  let clsValue = 0;
  new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      if (!(entry as any).hadRecentInput) {
        clsValue += (entry as any).value;
        onMetric({ name: 'CLS', value: clsValue, rating: getRating('CLS', clsValue) });
      }
    }
  }).observe({ type: 'layout-shift', buffered: true });
}

Usage in your React app:

// App.tsx or main.tsx
import { initWebVitals } from './utils/web-vitals';

initWebVitals((metric) => {
  console.log(`${metric.name}: ${metric.value} (${metric.rating})`);
  // Send to your analytics endpoint, logging service, etc.
});

The Measurement Gap: Local vs. Production

Here's the part that most tutorials skip.

Lighthouse and DevTools give you synthetic measurements — they simulate a specific device and network condition in a controlled environment. This is useful for relative comparisons ("did my change make it better or worse?"), but it doesn't tell you what real users experience.

Real users have:

Older devices with slower CPUs
Variable network conditions (3G, congested WiFi)
Many browser tabs open
Cold cache (no previous visit to your site)

The only way to know your real-world Core Web Vitals is to measure in production, from real browsers. The code above does exactly that — it runs in your users' browsers and captures their actual experience.

What you do with those measurements is a separate question. At minimum, log them somewhere. Ideally, set up alerting so you know when they degrade — particularly after deploys.

Quick Wins for Each Metric

If you're seeing bad numbers, here's where to start:

Bad LCP?

Check if the LCP element is an image — if so, add fetchpriority="high" to it
Convert images to WebP format
If using Next.js, switch to next/image
Check TTFB — if your server responds slowly, everything else suffers

Bad FCP?

Identify and remove render-blocking CSS/JS
Inline critical CSS
If using SSR, check that your server isn't doing too much work before sending HTML

Bad CLS?

Add explicit width and height to all images and videos
Reserve space for ads and dynamic embeds with CSS min-height
Avoid inserting content above existing content after page load

What About INP?

INP (Interaction to Next Paint) replaced FID in March 2024. It measures how quickly the page responds to user interactions — clicks, taps, keyboard input.

Good threshold: ≤ 200ms

The most common cause of bad INP in React apps is expensive state updates that block the main thread. If you're seeing high INP, Long Tasks are usually the culprit — something is blocking the browser from responding to user input.

We'll cover Long Tasks in depth in the next article.

Summary

Core Web Vitals aren't just for SEO. They're the most concrete way to measure whether your app feels fast to a real user.

The three metrics tell a story:

FCP: Does anything appear quickly?
INP: Does the page respond to interactions?
CLS: Does the layout stay stable while loading?

FCP is worth tracking too — it's a leading indicator for LCP — but it's a supporting metric, not a Core Web Vital.

Monitoring Past Performance vs. Alerting Real-Time Issues: What React Teams Are Missing

nosyos — Fri, 27 Mar 2026 23:34:06 +0000

Tuesday you deploy. Thursday your LCP climbs from 1.2s to 2.8s. Friday the reviews start coming in. Your monitoring dashboard shows the spike clearly — it just waited until you opened it to tell you.

That's the gap. Not a tooling failure exactly. More of a category error.

What monitoring tools are actually built for

Datadog, New Relic, your APM of choice — these are built for historical analysis. What happened over the past week, which pages are consistently slow, where the backend bottlenecks are. That's genuinely useful work, and they do it well.

What they're not designed for: telling you that something is wrong right now, minutes after it started. The data aggregation that makes historical analysis accurate also introduces latency. By the time a threshold alert fires in most APM tools, your users have already been in the slow experience for 10–20 minutes.

Error trackers have the same gap from the other direction. Sentry is excellent at catching exceptions. A LCP that degraded from 1.8s to 3.5s after a deploy doesn't throw an exception. Nothing fires.

The question your tools can't answer

"Did the deploy I just pushed make the app slower for real users right now?"

That's a different question from "what does our performance look like historically" or "are there errors in production." It needs a different data source — real browsers, in real time — and a different output: an alert somewhere your team will see it within minutes, not a dashboard someone has to remember to check.

The measurement layer is straightforward with the browser's native API:

new PerformanceObserver((list) => {
  const lcp = list.getEntries().at(-1)?.startTime;
  if (lcp && lcp > 2500) {
    sendMetric({ metric: 'LCP', value: lcp, page: location.pathname });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

This runs in your users' browsers and gives you real field data. The rest — threshold logic, batching, webhook routing to Slack or Discord — is buildable but accumulates edge cases fast.

I kept rebuilding this same pipeline across different projects, which is why I built RPAlert. SDK install and a provider wrapper:

import { RPAlertProvider } from "rpalert-sdk/react";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <RPAlertProvider apiKey="YOUR_API_KEY">
          {children}
        </RPAlertProvider>
      </body>
    </html>
  );
}

LCP, FCP, CLS, Long Tasks — all measured. Alert fires to Discord or Slack when thresholds are crossed.

This doesn't replace what you already have

RPAlert isn't a Sentry or Datadog replacement. Sentry tells you why something broke. Datadog tells you what happened over time. RPAlert tells you when to go look at both of those.

The alert is the smoke detector. The investigation still happens with the tools you already have.

Historical monitoring and real-time alerting answer different questions. If your current stack only answers one of them, you're going to keep finding out about performance regressions from your users.