Javascript

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

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

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

Monitoring and Alerting Are Different Jobs. Most React Teams Only Have One. Tags: #react #performance #webdev #javascript 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. ...