DEV Community: nosyos

INP Is Not Just a Faster FID

nosyos — Thu, 07 May 2026 14:28:00 +0000

I once spent an afternoon cutting a click handler from 80ms down to 18ms. Clean, fast, properly debounced. The INP score didn't move.

The handler wasn't the problem. The browser couldn't even start the handler for 190ms after the click — a long task was running at exactly the wrong moment. All that optimization was irrelevant.

INP splits an interaction into three phases. Most React developers know one of them.

The three-phase model

Every INP interaction goes through:

Input delay — the time from when the user interacts to when the browser can start processing the event. This is blocked by whatever is already running on the main thread.
Processing time — the time your event handlers actually execute.
Presentation delay — the time from when handlers finish to when the browser renders the visual update. This is where React's reconciliation and paint happen.

The total of these three is what INP measures for each interaction. The worst interaction in a session becomes the score.

Optimizing processing time — the only phase most developers think about — is the right move when processing time is actually the bottleneck. It often isn't.

Input delay is the one that surprises people

Input delay is not caused by your handler. It's caused by whatever was running on the main thread the moment the user clicked.

A React app rendering a large list after a search query completes. A useEffect running a synchronous calculation on new data. A timer callback that scheduled itself to run every few seconds and happens to fire during an interaction. Any of these can generate 100–300ms of input delay that has nothing to do with the click handler the user triggered.

The Chrome UX Report attribution for a slow INP event will tell you which phase is taking the most time. If input delay is more than 50ms, handler optimization is the wrong direction.

To see the breakdown in your own data:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType !== 'event' || entry.duration < 200) continue;

    console.log({
      interaction: entry.name,
      inputDelay: entry.processingStart - entry.startTime,
      processingTime: entry.processingEnd - entry.processingStart,
      presentationDelay: entry.duration - (entry.processingEnd - entry.startTime),
    });
  }
}).observe({ type: 'event', durationThreshold: 100, buffered: true });

Run this for a week on production. Look at the breakdown. A high inputDelay on a specific page tells you there's a long task running during that page's normal usage cycle — and that's the thing to fix, not the handler.

Breaking up the tasks that cause input delay

The fix for input delay is reducing the size of long tasks so the browser has gaps to process input.

scheduler.yield() is the cleanest way to do this. It pauses execution and lets the browser handle any pending input before continuing:

async function processLargeDataset(items: Item[]) {
  const results: Result[] = [];

  for (let i = 0; i < items.length; i++) {
    results.push(expensiveTransform(items[i]));

    // Every 50 items, yield to let the browser breathe
    if (i % 50 === 0) {
      await scheduler.yield();
    }
  }

  return results;
}

Without the yield, a 1,000-item dataset processed in one shot becomes a multi-hundred-millisecond long task that blocks input. With it, the browser gets a chance to handle clicks between chunks. INP stays low even while the work is ongoing.

scheduler.yield() is available in Chrome and Edge. For broader support, setTimeout(0) works as a fallback, though the browser may batch it less aggressively.

Presentation delay and the React render cost

Presentation delay is the third phase — from when handlers finish to when the screen actually updates. This is React's territory.

A click handler that calls setState and returns immediately still has to wait for React to reconcile and the browser to paint before the interaction is complete from INP's perspective. If reconciliation is expensive, presentation delay climbs.

This is where useTransition belongs — not as a general "make things faster" tool, but specifically to defer reconciliation work that doesn't need to block the visual acknowledgment of an interaction. The handler returns quickly, the browser paints a loading state or an immediate visual change, and then React reconciles the heavier update separately.

Reading LoAF attribution in production

The Long Animation Frames API — covered briefly in the previous article — becomes genuinely useful when you start reading its scripts attribution in a production context.

Each LoAF entry includes a list of scripts that contributed to the slow frame, with source locations and durations:

new PerformanceObserver((list) => {
  for (const frame of list.getEntries()) {
    if (frame.duration < 100) continue;

    for (const script of frame.scripts) {
      sendMetric({
        page: location.pathname,
        frameDuration: frame.duration,
        scriptSource: script.sourceURL,
        scriptFunction: script.sourceFunctionName,
        scriptDuration: script.duration,
        invokerType: script.invokerType, // 'event-listener', 'user-callback', etc.
      });
    }
  }
}).observe({ type: 'long-animation-frame', buffered: true });

invokerType tells you whether the script was triggered by an event listener, a setTimeout, a Promise callback, or something else. Filtering by invokerType: 'event-listener' on a specific page shows you exactly which handlers are contributing to slow frames during interactions — with function names and source URLs.

This replaces a lot of the guesswork involved in reproducing INP issues locally. Slow interactions often don't reproduce in DevTools because the lab environment doesn't have the same background tasks, cache state, and concurrent timers as production.

Where to look first

Check inputDelay in the event timing breakdown before touching handler code. If input delay is the dominant phase, look for long tasks running during the page's usage cycle — not just during load.

If presentation delay is high on a specific interaction, that component's reconciliation cost is the target. Start with React DevTools Profiler on that specific action before generalizing.

Processing time being the bottleneck is the most straightforward case — and also the least common in practice.

FID Is Dead. What INP Means for Your React App.

nosyos — Tue, 05 May 2026 14:02:00 +0000

In March 2024, Google replaced First Input Delay with Interaction to Next Paint as an official Core Web Vital. FID is gone. INP is what matters now — and most React apps that were passing before are failing under the new standard without anyone realizing it.

What was wrong with FID

FID measured how long the browser took to respond to the very first user interaction on a page. Click a button, FID measures the delay before the browser started processing that click. Just the first one. Just the start of processing, not the time until anything actually happened on screen.

In practice, FID was easy to pass and bad at catching real responsiveness problems. A page could have an excellent FID score while every subsequent click — after the page was fully loaded and the user was actually using it — took 600ms to respond. FID had nothing to say about that.

What INP actually measures

INP measures the full interaction latency for all interactions throughout the entire page session, not just the first. It captures the delay from when a user interacts (click, tap, keyboard input) to when the browser finishes rendering the visual response.

The threshold: Good is under 200ms. Needs Improvement is 200–500ms. Poor is over 500ms.

The shift matters because it exposes a category of problems FID never touched. Long-running JavaScript that doesn't affect first-load responsiveness but blocks the main thread during normal usage. React state updates that trigger expensive re-renders mid-session. Event handlers that do too much synchronous work before returning control to the browser.

A React app with heavy component trees, lots of context consumers, and synchronous state updates can have a perfectly acceptable LCP and a terrible INP. Under FID, nobody would have noticed.

Where React apps tend to fail INP

The most common causes in React specifically:

Synchronous state updates that cascade. A click handler updates state, which triggers a re-render of a large subtree, which blocks the main thread while React reconciles. If that reconciliation takes 300ms, the user sees a 300ms delay before anything on screen changes. The React Compiler helps here by reducing unnecessary re-renders, but it doesn't reduce the cost of renders that need to happen.

Unoptimized event handlers. An onClick that does validation, makes a synchronous API call via a cached store, updates multiple pieces of state, and then re-renders — all before returning — is an INP problem waiting to be found.

useTransition is the right tool for expensive updates that don't need to block the interaction response:

const [isPending, startTransition] = useTransition();

function handleClick() {
  // This part runs immediately — updates the UI to acknowledge the interaction
  setButtonState('loading');

  // This part is deferred — React schedules it without blocking
  startTransition(() => {
    setFilteredResults(computeExpensiveFilter(data));
  });
}

The interaction response — acknowledging that something happened — is immediate. The expensive computation happens without blocking the input.

Third-party scripts running during interactions. An analytics script that fires on every click event and does synchronous work is adding to your INP whether you wrote it or not.

The Long Animation Frames API

Alongside INP, browsers shipped the Long Animation Frames API (LoAF) as a more precise replacement for Long Tasks.

Long Tasks measured any main thread task over 50ms. LoAF measures animation frames that take over 50ms to render, with richer attribution — it tells you which scripts, which event handlers, and which rendering work contributed to the slow frame.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry.scripts shows which scripts contributed to the slow frame
    console.log('Slow frame:', entry.duration, 'ms');
    console.log('Scripts:', entry.scripts);
  }
}).observe({ type: 'long-animation-frame', buffered: true });

The scripts array in each entry is the part that changes the debugging workflow. Instead of knowing "something ran too long on the main thread," you know exactly which function in which file was responsible. This is significantly faster to diagnose than working backward from a Long Tasks timeline in the Performance panel.

Speculation Rules: prefetching gets declarative

The Speculation Rules API lets you declare prefetch and prerender rules directly in HTML, without JavaScript:

<script type="speculationrules">
{
  "prerender": [
    { "where": { "href_matches": "/product/*" }, "eagerness": "moderate" }
  ]
}
</script>

prerender goes further than prefetch — it fully renders the page in a hidden tab, so navigation is instant. eagerness: "moderate" triggers prerendering when the user holds the pointer over a matching link for 200ms (or on pointerdown if that happens sooner), not immediately on page load.

For Next.js apps, the router already handles prefetching via <Link>, but Speculation Rules gives you declarative control for non-Next.js apps or edge cases the router doesn't cover.

Measuring INP from real users

INP can't be meaningfully measured with synthetic tests. Lighthouse doesn't measure it in a way that reflects real interaction patterns — it simulates a few interactions, not the full session. The only honest INP measurement is from actual users doing actual things.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'event' && entry.duration > 200) {
      sendMetric({
        metric: 'INP_candidate',
        value: entry.duration,
        target: (entry.target as Element)?.tagName,
        page: location.pathname,
      });
    }
  }
}).observe({ type: 'event', durationThreshold: 100, buffered: true });

This captures interaction events over 100ms — the candidates that might become your INP score. Logging the target element tells you which UI components are the source of slow interactions, which is where the optimization work starts.

If you're already monitoring LCP in production, adding INP measurement to the same pipeline is straightforward. I built RPAlert to handle this for React apps — it tracks Web Vitals including INP from real browsers and alerts via Slack or Discord when thresholds are crossed. Given that INP is now an official ranking signal and most React apps haven't tuned for it, catching regressions as you work toward improvement is worth having in place.

What to prioritize now

Measure your INP first. Add the PerformanceObserver above to production and collect a week of data. Look at which interactions are the worst offenders and which pages they're on. The distribution will tell you where to focus.

Audit your event handlers. Find click and input handlers that do significant synchronous work and identify which ones can be wrapped in useTransition.

Switch from Long Tasks to LoAF in your monitoring if you're already collecting Long Task data. The attribution is better and the LoAF data supersedes Long Tasks for debugging.

Check your INP score in Chrome UX Report (via PageSpeed Insights or Search Console) for a baseline. If you're in the "Needs Improvement" or "Poor" range, it's affecting your search ranking today.

The FID-to-INP transition isn't just a metric rename. It's a change in what "responsive" means for a passing grade. A React app that passed Core Web Vitals before March 2024 might be failing now without any code having changed. Worth checking.

Performance Improvements Don't Last. Here's Why

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

A team spends a sprint optimizing LCP. Numbers improve. Six months later the app is slower than before the work started. Nobody made a single decision to make it slower. It just accumulated.

This is the normal trajectory without structural changes. Individual optimizations decay. Culture doesn't.

Why the gains disappear

Performance degrades through ordinary work. A developer adds a new dependency. A designer hands off a 1.4MB hero image and nobody checks the size. Marketing adds a tag via the tag manager. A component gets a useEffect with a missing dependency that triggers extra renders. Each change is small, reviewed individually, and ships fine.

The problem is that performance review doesn't happen at the same granularity as code review. Code gets scrutinized line by line. Performance gets checked periodically, if at all, by whoever remembers to run Lighthouse.

The improvements you made six months ago are gone not because someone undid them, but because the process that created the degradation in the first place was never changed.

Performance budgets only work with enforcement

A performance budget is a threshold: bundle size under 200KB, LCP under 2.5s, no new Long Tasks over 150ms. Most teams that try budgets define them and then don't enforce them, which means they don't exist.

A budget without automated enforcement is a suggestion. The only budget that changes behavior is one that fails a CI check and blocks a merge.

Bundlesize and Lighthouse CI both integrate into GitHub Actions and can fail a PR when thresholds are crossed:

# .github/workflows/performance.yml
- name: Lighthouse CI
  uses: treosh/lighthouse-ci-action@v10
  with:
    urls: |
      https://staging.yourapp.com
    budgetPath: ./budget.json
    uploadArtifacts: true

// budget.json
[
  {
    "path": "/*",
    "timings": [
      { "metric": "largest-contentful-paint", "budget": 2500 }
    ],
    "resourceSizes": [
      { "resourceType": "script", "budget": 300 }
    ]
  }
]

When a PR exceeds the budget, the check fails. The developer sees it before merge, not after deployment. This is the only version of a performance budget that actually works.

Start with thresholds loose enough that you're not blocking everything immediately. Tighten them incrementally as the baseline improves. The goal at the start is to prevent regression, not to hit an ideal number.

Code review needs a performance lens

Most teams review code for correctness, readability, and security. Performance is rarely on the checklist, which means expensive patterns ship unnoticed.

A few things worth adding to your review process:

New dependencies should trigger a bundle size check. bundlephobia.com takes 30 seconds and shows exactly what a package adds to your bundle before you commit to it. A 40KB dependency that only uses two functions is worth questioning.

Components that render lists should be reviewed for scale. A list component that works with 50 items in staging might create Long Tasks at 500. If it's not using virtualization and the data could grow, flag it.

Images added to the codebase should have explicit dimensions and a format check. If someone commits a PNG larger than 100KB for a UI element, that's worth a comment.

None of this requires a formal checklist. It requires one or two engineers who know to look for it and normalize asking the question in review.

Make performance data visible to everyone

Performance stays one engineer's problem when only one engineer can see the data. The moment your LCP numbers appear somewhere the whole team looks — a Slack channel, a dashboard on a shared screen, a weekly metric in the team standup — it becomes a shared concern.

The practical version: route your performance alerts to a channel where the whole team is present. When a deploy causes an LCP regression and a Slack message appears in #engineering, everyone sees it. The developer who shipped the change sees it. The product manager sees it. It becomes a team metric rather than an infrastructure metric.

I built RPAlert partly for this reason — the Slack and Discord integration means performance regressions surface in the same place where the team already communicates. It's a small thing that changes who feels responsible for the numbers.

The same logic applies to your analytics dashboard. If LCP trends are buried in a monitoring tool that only two people have logins for, performance will remain two people's concern.

Designers and PMs are part of this

Performance problems that originate outside the engineering team can't be fixed purely by engineers. A design system that specifies large, uncompressed images as the standard will produce large, uncompressed images at every launch. A product process that doesn't include performance review before shipping a feature will produce features that haven't been evaluated for performance impact.

The lowest-effort version of this: add performance to your definition of done. Before a feature ships, someone confirms the LCP element on affected pages hasn't gotten worse. Not a full audit — a single check. If it fails, it's a bug, same as a broken form submission.

With designers specifically: the conversation is usually easier than expected once the data exists. Showing a designer that their 2MB hero image is causing a 1.2s LCP increase for mobile users is more persuasive than a general request to "optimize images." Specific numbers change specific behavior.

The learning investment pays off asymmetrically

A single lunch-and-learn session where you walk the team through opening Chrome DevTools, running a Lighthouse audit, and interpreting the results changes how people work for months. Developers who've never looked at a performance waterfall start noticing things during their own testing. Designers start asking about image format before handing off assets.

The return on two hours of internal education is disproportionate to the investment. It doesn't require bringing in an outside expert or building a curriculum. It requires one person who knows the tools well enough to show them to the rest of the team.

Culture isn't a process you implement. It's the accumulated effect of small structural changes: enforcement that makes the budget real, review habits that catch expensive patterns early, visibility that makes performance everyone's number. The teams with consistently fast apps didn't get there through heroic optimization sprints. They just made it harder for the app to get slower without someone noticing.

Slow Pages Cost Money. Here's How to Prove It.

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

Performance work stalls not because engineers don't care, but because the business case is vague. "The app feels faster" doesn't unlock budget. "We reduced LCP by 800ms and checkout conversion went up 12%" does.

The teams that get sustained investment in performance are the ones who learned to speak in numbers that matter to stakeholders. Here's how to build that argument.

The numbers that already exist

You don't need to run your own study. The data is well-established at this point:

Google's research on Core Web Vitals found that sites meeting the "Good" threshold for LCP see 24% fewer abandoned page loads compared to sites in the "Poor" range. Deloitte found that a 0.1s improvement in mobile site speed correlates with an 8% increase in conversions for retail sites. Vodafone saw a 31% increase in sales after a 31% improvement in LCP.

These aren't cherry-picked outliers. The pattern holds across industries: slower pages lose users at predictable rates, and the loss scales with how slow the experience is.

The most direct way to frame it for a non-technical stakeholder: every 100ms of additional load time costs some percentage of your conversions. The exact number varies by industry, audience, and baseline speed, but the direction is never ambiguous.

How to calculate your own cost

Generic industry statistics are useful for initial buy-in. Your own data is what closes the argument.

Start with what you have. Most teams have analytics that show page load time alongside conversion or retention metrics. Segment your users by LCP performance bucket — "Good" under 2.5s, "Needs Improvement" 2.5–4s, "Poor" over 4s — and compare conversion rates across those groups.

If your checkout conversion rate for users with LCP under 2.5s is 4.2% and for users with LCP over 4s it's 2.8%, the math becomes concrete. If 20% of your traffic is in the "Poor" bucket and you process 10,000 checkouts per month, closing that gap is worth roughly 280 additional conversions per month at whatever your average order value is.

This isn't a controlled experiment — there are confounding variables, slower devices correlate with other demographic factors, and so on. But it's directionally correct and it's your data, which is far more persuasive to a leadership team than a Deloitte study about retail sites.

The cost of a regression is easier to calculate than the cost of being slow

Here's the argument that often lands faster: quantify what a performance regression costs, then show what it costs to not catch one quickly.

A deploy that increases LCP by 1.5s across your checkout flow and sits undetected for 4 hours: take your hourly transaction volume, apply the conversion rate delta you measured above, and multiply. For a moderately busy e-commerce site, a 4-hour regression can mean tens of thousands of dollars in lost revenue. That number is exact, not an estimate, because you have the actual transaction data from that window.

The ROI argument for monitoring then writes itself. If catching a regression in 10 minutes instead of 4 hours saves $30,000, the cost of whatever tooling enables that is trivially justified.

Measuring before and after is non-negotiable

The most common failure mode in performance projects: teams do the work, don't have the data to prove it made a difference, and can't justify the next round of investment.

You need real-user measurements before you start any optimization, during the work, and continuously afterward. Not Lighthouse scores — those measure synthetic conditions on a controlled machine. Field data from actual users, segmented by page and device type.

PerformanceObserver gives you this without a third-party dependency:

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

Sending deviceMemory alongside the metric lets you segment by device class — low-memory devices are a good proxy for slower hardware. The performance gap between your p50 and p75 users is often where the business impact lives.

Once you have this instrumented, connect it to your analytics. LCP by page, by device, over time. When you ship an optimization, you'll see the distribution shift in the data. That shift is your ROI evidence.

For the alerting side — catching regressions before they become hours-long revenue events — I built RPAlert to handle the threshold monitoring and Slack/Discord notification layer. The "cost of a 4-hour regression" calculation I described above is exactly the argument for having that kind of alerting in place: the monitoring cost is fixed and small, the regression cost is variable and potentially large.

How to frame this for stakeholders

Engineers tend to present performance work as a technical improvement. Stakeholders hear "we made some things faster." The same work framed as "we identified that 18% of our users are experiencing load times that reduce checkout conversion by 1.4 percentage points, and we have a plan to move them into the Good tier" lands differently.

A few framings that work:

Revenue at risk: "X% of sessions have LCP over 4s. Based on our conversion data, this segment converts at Y% vs Z% for fast sessions. At our current volume, that's approximately $N/month in lost revenue."

Regression cost: "Our last deploy regression ran for 4 hours before we caught it. Based on transaction volume during that window, the estimated revenue impact was $N. We're proposing monitoring that would have caught it in under 10 minutes."

Competitive framing: Run WebPageTest on your main competitors. If you're 1.2s slower on mobile than your closest competitor, that's a meaningful talking point in a room where people think about market share.

KPIs worth tracking continuously

LCP p75 by page — the 75th percentile is what Google uses for Core Web Vitals thresholds, and it's the right target because it represents your slower users, not the median.

Regression frequency and MTTR (mean time to resolution) — how often you have regressions and how quickly you fix them. This makes the monitoring ROI argument over time.

Conversion rate by performance bucket — LCP Good vs. Needs Improvement vs. Poor, segmented from your analytics. This is the number that connects engineering work to business outcomes.

None of these require expensive tooling to start. They require making the measurement a consistent practice, which is the harder organizational problem.

The teams that make performance a sustained priority aren't the ones with the most engineering time or the biggest budgets. They're the ones who connected their performance metrics to the numbers the business already cares about. That connection starts with measuring the right things from the right place — real users, in production, continuously.

Testing on Fast Wi-Fi Is Not a Performance Test

nosyos — Thu, 23 Apr 2026 14:06:00 +0000

Testing on Fast Wi-Fi Is Not a Performance Test

Tags: #react #performance #webdev #javascript

Most performance testing happens on a MacBook Pro, over a fast home or office connection, with a warm browser cache. Then you deploy and wonder why the numbers are different in production.

The gap isn't mysterious. You were never testing what your users experience.

What your local setup hides from you

Three things consistently make local testing optimistic:

Your CPU is fast. A React component tree that reconciles in 30ms on your development machine can take 150ms on a mid-range Android phone from two years ago. JavaScript execution time scales with CPU speed, not network speed. Throttling your network doesn't help here.

Your cache is warm. You've loaded the page dozens of times during development. The browser has cached your fonts, your CSS, your JS bundles. A first-time visitor has none of that. Cold cache loads can be 2–3x slower than what you see after the third reload.

Your connection is fast and stable. Office and home wifi is typically 50–200Mbps with low latency. A user on 4G in a building with poor signal might be getting 5Mbps with 200ms latency. The same 300KB JavaScript bundle takes 0.4s on your connection and 3.2s on theirs.

Chrome DevTools throttling: useful, not sufficient

DevTools lets you simulate slower network conditions and CPU performance from the Network and Performance panels. This is genuinely useful for catching obvious regressions. It's not a substitute for real-device testing.

For network throttling, the built-in presets are a reasonable starting point:

"Fast 3G": ~1.5Mbps download, 40ms latency — approximates a decent mobile connection
"Slow 3G": ~400Kbps download, 200ms latency — approximates a poor signal or congested network

To add CPU throttling alongside network throttling, open the Performance panel and set the CPU throttle multiplier before recording. 4x slowdown is a reasonable approximation of a mid-range phone; 6x for lower-end devices.

The limitation: CPU throttling in DevTools is a multiplier applied to your existing hardware. A 6x slowdown on a fast Mac still doesn't fully reproduce the memory pressure, thermal constraints, or GPU pipeline behavior of a real low-end device. It's a direction, not a destination.

WebPageTest gives you closer to the real thing

WebPageTest runs tests on actual devices and actual network connections, not simulations on your hardware. The free tier at webpagetest.org lets you test from real locations against real mobile device profiles.

A few settings that matter:

Set the test location to somewhere geographically relevant to your users. Latency scales with distance. Testing from a US East Coast location when half your users are in Southeast Asia will give you unrealistically fast numbers.

Use a mobile device profile. The "Motorola G (gen 4)" or similar mid-range Android preset is a reasonable proxy for the median visitor to most consumer apps.

Enable "First View" only initially — it's the cold cache scenario, which is what new users experience and what you most need to optimize for.

The waterfall view is where the value is. Look at what loads, in what order, what blocks what. Third-party scripts that seem fast locally often appear as long blocking requests here. Fonts that you never notice on your warm-cache machine show up as early blocking resources. It's the closest thing to watching a real user load your page.

Lighthouse: right tool, often wrong setup

Lighthouse is easy to run, well-documented, and measures the right things. It's also commonly run in a way that undermines its usefulness.

Running Lighthouse on localhost — against your dev server, with hot module reloading active — gives you numbers that have nothing to do with production. Run it against your production or staging URL.

Running it on a fast connection without throttling gives you numbers your slowest users will never see. The default Lighthouse settings in Chrome DevTools apply simulated throttling automatically; if you're running it via the CLI, check your throttling configuration.

Running it once and treating the number as stable is also a mistake. Lighthouse results vary by 10–15% between runs on the same page due to background processes and timing variations. Run it three times and take the median.

The ceiling on simulation

Every simulation tool has the same ceiling: it's running on your infrastructure, with your hardware, and making assumptions about user conditions that may not match reality.

The only way to know what your actual users experience is to measure it from their browsers. PerformanceObserver gives you real field data:

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 distribution of real-user LCP is almost always wider than what your local tests suggest. The p75 is what matters for Core Web Vitals — the 75th percentile user's experience, not the median. That user might be on a slow connection in a weak signal area, and your simulation never represented them.

Once you have real-user data, you also get deploy-time regression detection. If a change you shipped moves the p75 LCP from 1.9s to 3.1s, you want to know within minutes. I built RPAlert specifically for this — it monitors LCP and Long Tasks from real browsers and sends a Slack or Discord alert when thresholds are crossed. The simulation tools tell you what might happen; real-user monitoring tells you what did.

Use DevTools throttling to catch things before they ship. Use WebPageTest to get a more honest picture of production conditions. Use real-user measurement to know what's actually happening. They're not substitutes for each other — they answer different questions at different points in the development cycle.

Where to Start with React Performance

nosyos — Wed, 22 Apr 2026 14:00:00 +0000

You've probably already tried something. Added useMemo in a few places. Run Lighthouse. Checked the bundle size. Maybe split a route or two.

And the app still feels slow.

The issue is usually not the optimization — it's that the mental model came later, or never. Performance work done without a clear picture of what you're measuring is mostly guesswork. Some of it sticks. A lot doesn't.

The articles below are ordered so that each one gives you something concrete before you move to the next. They're not meant to be read in a weekend. Work through one, apply it to your actual app, then come back.

Understand what the browser measures before you touch anything

Before profiling, before optimizing, read Core Web Vitals Explained.

LCP, INP, CLS — these aren't SEO checkboxes. They're the closest thing we have to a standardized measurement of how fast your app feels to a real user. The article walks through what each metric actually captures, how to read them in a React app, and which thresholds matter in practice. If you've skimmed the MDN page and moved on, this will fill in the gaps that MDN skips.

Find your LCP element before you do anything else

Lighthouse will show green image audits while your LCP sits at 4.2 seconds. I've seen it. The culprit was a CSS background-image used for the hero. next/image doesn't touch those. Nobody had checked which element was actually being measured.

Most LCP Fixes Come Down to One Image is about exactly this: the diagnosis step most developers skip. You cannot fix LCP reliably until you know what element the browser is treating as "largest." That's the only point of this article, and it's worth the ten minutes.

Two sources of drag that don't show up in your component tree

You fix the hero. LCP improves. The page still feels sluggish during interaction. This is usually long tasks — JavaScript work that blocks the main thread long enough for users to notice.

Long Tasks Are Quietly Killing Your React App's Performance explains what they are, where to find them in DevTools, and why React apps are particularly prone to generating them. Read this before you reach for any scheduler-level fixes.

Then read The Scripts You Didn't Write Are Slowing Down Your App. Analytics tags, chat widgets, tag managers firing pixels for campaigns that ended months ago — these all compete for main thread time. The engineering team usually has no idea how many are running or what they cost. This article gives you the tools to find out.

Your development environment is not your production environment

This one is short. Read Why Your App Feels Fast in Staging and Slow in Production, then look at how you've been profiling. CPU throttling, real network conditions, cold cache behavior — the article is a checklist you can run against your current setup immediately.

Don't assume the React Compiler handles everything

If you're on React 19 or thinking about the compiler, What the React Compiler Quietly Skips covers what it does and doesn't automate. Side effects, context, components with non-deterministic output — these are still your problem. The article is specific enough to be useful without being alarmist about it.

Stop letting fixed problems come back

Performance regressions are quiet. A dependency updates, a feature ships, and the LCP you worked to fix climbs back above three seconds. Nobody notices until a user says something.

Catching React Performance Regressions Before Your Users Do is about wiring performance checks into CI so regressions surface before merge. It's the step most teams skip because it feels like overhead — until they've been burned once.

CI catches regressions in test conditions. But production is different. Monitoring Past Performance vs. Alerting Real-Time Issues draws the line between historical analytics and real-time alerting. Most teams have one and assume it covers both. It doesn't.

If you'd rather not build the alerting layer yourself, RPAlert detects LCP degradation in production and sends a notification to Slack or Discord within 60 seconds. There's a free tier, and setup is one npm install and a component wrapper. It's not a replacement for understanding your metrics — but once you understand them, you'll want to know the moment they break.

Read in this order

Eight articles. Try each concept against your own app before moving to the next. Doing it that way, this sequence will teach you more about production React performance than most tutorials manage in twice the length.

The Scripts You Didn't Write Are Slowing Down Your App

nosyos — Tue, 21 Apr 2026 14:24:00 +0000

I once audited a page where nearly 40% of the main thread blocking time came from a tag manager firing scripts that the engineering team didn't know were still active. Analytics from a vendor they'd switched away from. A heatmap tool from a trial nobody cancelled. A pixel for an ad campaign that ended months ago.

Nobody wrote those scripts. They accumulated.

What third-party scripts actually cost you

The performance impact happens in two places: network and main thread.

On the network side, each script is an additional HTTP request, often to a slow external domain with no SLA on response time. A single chat widget might make 4–6 requests before it's ready. On a slow connection, this shows up in your waterfall as a long chain of blocking or near-blocking resources.

On the main thread, third-party scripts run JavaScript. That JavaScript competes with your React app for CPU time. A script that takes 80ms to parse and execute on a fast development machine might take 350ms on a mid-range Android phone. Every millisecond it holds the main thread is a millisecond your app can't respond to user input or complete a render.

The combination of late network requests and CPU-heavy execution is why third-party scripts are so good at pushing LCP. The browser is waiting on resources it didn't know it needed, while the main thread is occupied with someone else's code.

Find out what's actually running

Before you optimize anything, run your production URL through WebPageTest with a mobile throttling preset and look at the waterfall. Sort by domain. You'll see every request, grouped by origin.

The question to ask for each third-party domain: does the engineering team know this is here, and what breaks if it doesn't load?

Chrome's Coverage tab gives you the JavaScript utilization angle — how much of each loaded script is actually executed on the page. A script that's 90% unused is paying full network and parse cost for very little value.

The surprises are usually in the tag manager. If your site uses Google Tag Manager or a similar tool, open it and look at what's configured. Marketing and analytics teams often have direct access and add tags without engineering review. The list is rarely what anyone expects.

Stop loading scripts at the worst possible time

Most third-party scripts don't need to be ready before your app is interactive. Analytics doesn't need to fire before the user can click anything. Chat widgets don't need to be loaded before the hero image is painted.

The default behavior — scripts in <head> without async or defer — blocks HTML parsing entirely. This is almost never what you want for third-party code.

async loads the script in parallel with parsing, but executes it as soon as it downloads, which can still interrupt parsing at a bad moment. defer loads in parallel and waits until parsing is complete before executing. For most analytics and tracking scripts, defer is the right default.

For scripts that are truly non-critical — chat widgets, feedback tools, anything that doesn't affect the initial render — load them after hydration:

useEffect(() => {
  const script = document.createElement('script');
  script.src = 'https://third-party-widget.com/widget.js';
  script.async = true;
  document.body.appendChild(script);
}, []);

This pushes execution entirely past React's initial render and hydration cycle. The widget loads when it loads. Your LCP doesn't wait for it.

In Next.js, the Script component handles this with the strategy prop:

import Script from 'next/script';

// afterInteractive: loads after hydration, good for analytics
<Script src="https://analytics.example.com/script.js" strategy="afterInteractive" />

// lazyOnload: loads during browser idle time, good for chat widgets
<Script src="https://widget.example.com/chat.js" strategy="lazyOnload" />

beforeInteractive exists for scripts that genuinely need to be ready before the page is usable. For third-party code, that's almost never true.

Tag managers are the hard part

A tag manager with unrestricted access is effectively a way for non-engineers to inject arbitrary JavaScript into production. The scripts themselves might be fine individually. The problem is the total: 8 tags that each take 50ms to execute is 400ms of main thread time that engineering had no visibility into.

Audit the tag manager on a regular schedule. Not annually — quarterly at minimum. For each tag: who owns it, what it does, and what happens if it's removed. Treat it like a dependency review. Tags accumulate the same way npm packages do, and they're harder to spot because they're not in the codebase.

Two practical rules that help: require engineering sign-off before any new tag is added, and set a network budget threshold that triggers a review if total third-party bytes cross it. Neither is bureaucratic overhead — they're the minimum to prevent the page you ship from drifting away from the page you tested.

The problem doesn't stay solved

You optimize the loading strategy, audit the tag manager, remove the stale scripts. A month later, marketing adds a new analytics tool. Another month, a new A/B testing SDK. Each addition seems small in isolation.

Measuring this from real users catches it before it accumulates. Adding the PerformanceObserver for Long Tasks gives you a signal when a new script is hitting the main thread harder than expected:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      sendMetric({ metric: 'LongTask', duration: entry.duration, page: location.pathname });
    }
  }
}).observe({ type: 'longtask', buffered: true });

If you want that signal to reach you automatically when a new script causes a regression — without manually checking dashboards — I built RPAlert to handle this. It monitors LCP and Long Tasks from real browsers and sends a Slack or Discord alert when thresholds are crossed. It's caught more than a few cases where a new marketing tag quietly pushed LCP past the threshold right after it was deployed.

The engineering team usually gets blamed when the app is slow. The scripts that actually caused it were added by someone else, through a tool that didn't require a code review. Getting visibility into that layer is half the work.

Most LCP Fixes Come Down to One Image

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

Originally published at rpalert.dev/blog

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

Originally published at rpalert.dev/blog

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

Originally published at rpalert.dev/blog

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.

Have you enabled React Compiler yet? What's been your experience so far?

Why Your App Feels Fast in Staging and Slow in Production

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

Originally published at rpalert.dev/blog

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.

What's the biggest performance gap you've seen between staging and prod?

Long Tasks Are Quietly Killing Your React App's Performance

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

Originally published at rpalert.dev/blog

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.

Have you ever caught a Long Task spike in production? Would love to hear how you found it.

DEV Community: nosyos

INP Is Not Just a Faster FID

The three-phase model

Input delay is the one that surprises people

Breaking up the tasks that cause input delay

Presentation delay and the React render cost

Reading LoAF attribution in production

Where to look first

FID Is Dead. What INP Means for Your React App.

What was wrong with FID

What INP actually measures

Where React apps tend to fail INP

The Long Animation Frames API

Speculation Rules: prefetching gets declarative

Measuring INP from real users

What to prioritize now

Performance Improvements Don't Last. Here's Why

Why the gains disappear

Performance budgets only work with enforcement

Code review needs a performance lens

Make performance data visible to everyone

Designers and PMs are part of this

The learning investment pays off asymmetrically

Slow Pages Cost Money. Here's How to Prove It.

The numbers that already exist

How to calculate your own cost

The cost of a regression is easier to calculate than the cost of being slow

Measuring before and after is non-negotiable

How to frame this for stakeholders

KPIs worth tracking continuously

Testing on Fast Wi-Fi Is Not a Performance Test

Testing on Fast Wi-Fi Is Not a Performance Test

What your local setup hides from you

Chrome DevTools throttling: useful, not sufficient

WebPageTest gives you closer to the real thing

Lighthouse: right tool, often wrong setup

The ceiling on simulation

Where to Start with React Performance

Understand what the browser measures before you touch anything

Find your LCP element before you do anything else

Two sources of drag that don't show up in your component tree

Your development environment is not your production environment

Don't assume the React Compiler handles everything

Stop letting fixed problems come back

Read in this order

The Scripts You Didn't Write Are Slowing Down Your App

What third-party scripts actually cost you

Find out what's actually running

Stop loading scripts at the worst possible time

Tag managers are the hard part

The problem doesn't stay solved

Most LCP Fixes Come Down to One Image

Find your LCP element before you do anything else

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

next/image defaults will silently hurt your LCP

Explicit dimensions are non-negotiable

Format: stop overthinking it

Optimizing once isn't enough

Catching React Performance Regressions Before Your Users Do

The first 30 minutes are the cheapest

Why your existing tools miss this

LCP is what to watch

What the alert loop actually looks like

Building vs. not building this

What the React Compiler Quietly Skips

The compiler handles one thing

Silent bailouts

Most existing codebases have violations

useMemo isn't dead

Roll it out on a subset first

What to write going forward

Why Your App Feels Fast in Staging and Slow in Production

You're not testing on anything like a real device

Cold cache is a different product

Staging data doesn't tell you how your components scale

Third-party scripts you forgot about

Measure from real browsers, not synthetic tests

Three things worth doing this week

Long Tasks Are Quietly Killing Your React App's Performance

What's a Long Task?

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