RPAlert Blog

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. ...

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. ...

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: ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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.” ...