DEV Community: nosyos

Streaming SSR Is Not a Free LCP Win

nosyos — Tue, 26 May 2026 14:01:00 +0000

Streaming SSR sounds like an obvious win. Instead of waiting for all server-side work to finish before sending any HTML, Next.js starts sending the page immediately and streams the rest as it becomes ready. Users see content sooner. LCP improves.

Except it doesn't always. The improvement depends entirely on where your LCP element lives in the component tree.

What streaming actually does

Without streaming, the server waits until the full page is rendered before sending the first byte of HTML. With streaming, Next.js sends an initial shell immediately, then flushes additional HTML chunks as Suspense boundaries resolve.

export default async function ProductPage({ params }) {
  // This data is needed for the shell — it blocks the initial response
  const category = await getCategory(params.categoryId);

  return (
    <div>
      <CategoryHeader category={category} />
      {/* This Suspense boundary streams in separately */}
      <Suspense fallback={<ProductListSkeleton />}>
        <ProductList categoryId={params.categoryId} />
      </Suspense>
    </div>
  );
}

CategoryHeader is in the shell — it arrives with the first response. ProductList streams in after its data resolves. The browser can start rendering and displaying the header while the product list is still loading on the server.

This genuinely helps perceived performance. The page feels interactive earlier because something meaningful is visible sooner. Whether it helps LCP depends on what that "something" is.

LCP only improves if the LCP element is in the shell

The browser measures LCP against when content actually appears on screen. If your LCP element — the hero image, the main heading, the product photo — is inside a Suspense boundary, the browser can't render it until that chunk streams in. Streaming didn't make it arrive faster. It just deferred other content.

I added Suspense boundaries to a product page expecting LCP to improve. It got worse by 400ms. The hero image was inside the product Suspense boundary, waiting for the same data that was blocking the page before. The browser couldn't start fetching the image until the streamed chunk arrived with the <img> tag. Streaming had delayed the only thing that mattered for LCP.

The rule is straightforward: the LCP element must be in the initial shell, or in a Suspense boundary that resolves before anything else. Everything else can stream in afterward.

Suspense boundary placement is the whole game

Designing a streaming page means deciding what goes in the shell and what gets deferred. The shell should contain:

The LCP element — always
Navigation and layout structure
Above-the-fold content that's cheap to fetch

Everything that's slow to fetch, personalized, or below the fold is a candidate for a Suspense boundary.

export default async function ProductPage({ params }) {
  // Fast query — product basics needed for LCP
  const product = await getProductBasics(params.id);

  return (
    <div>
      {/* Hero image is in the shell — LCP element renders immediately */}
      <ProductHero image={product.heroImage} title={product.name} />

      {/* Slow queries — personalized, below the fold */}
      <Suspense fallback={<ReviewsSkeleton />}>
        <ReviewSection productId={params.id} />
      </Suspense>

      <Suspense fallback={<RecommendationsSkeleton />}>
        <PersonalizedRecommendations userId={params.userId} />
      </Suspense>
    </div>
  );
}

getProductBasics fetches only what the shell needs — title, hero image, price. The slow queries for reviews and personalized recommendations happen in parallel behind their Suspense boundaries. The hero image is in the shell, so the browser can start loading it with the first response.

This requires splitting what was probably one database query into two: a fast query for above-the-fold data and a deferred query for everything else. That's the real cost of streaming — not technical complexity, but discipline about which data the shell actually needs.

Preloading resources before they stream

A hero image inside the shell still has to be fetched after the HTML arrives. On slow connections, that fetch adds meaningfully to LCP.

The <link rel="preload"> tag in the shell tells the browser to start fetching the image immediately, in parallel with parsing the rest of the HTML:

export default async function ProductPage({ params }) {
  const product = await getProductBasics(params.id);

  return (
    <>
      <link
        rel="preload"
        as="image"
        href={product.heroImage}
        fetchpriority="high"
      />
      <ProductHero image={product.heroImage} title={product.name} />
      {/* ... */}
    </>
  );
}

Next.js flushes <link> tags in the <head> before the body content. The browser sees the preload hint before it encounters the <img> tag in the shell, so the fetch starts earlier. For large images on slow connections, this can move LCP by several hundred milliseconds.

Measuring LCP on streaming pages

Lighthouse doesn't simulate streaming. It loads the page and measures LCP against the fully rendered result, which means it can't tell you whether your shell is arriving fast or whether streaming is actually helping.

Field data from real users is the only measurement that captures streaming behavior. A streaming page where the shell is fast will show LCP concentrated at a low value in the distribution. A streaming page where the LCP element was accidentally put inside a Suspense boundary will show LCP spread across a wide range — fast for users with low server latency, slow for everyone else.

Watching LCP in production after changes to Suspense boundaries is essential. A boundary that seemed like an obvious improvement in development — where all database queries complete in under 5ms — can significantly delay LCP in production where the queries take 80ms.

LCP regressions from streaming changes are subtle. They don't always show up in aggregate metrics immediately, because the regression often only affects users on slower connections or in regions with higher server latency. RPAlert alerts on LCP threshold crossings from real browsers within 60 seconds — the kind of segmented, real-user signal that catches these regressions before they appear in a weekly CrUX report. Given that streaming bugs tend to be environment-specific, having a production alert is the difference between catching a regression on Tuesday and noticing it the following Monday.

The mental model that makes streaming work

Streaming is a tool for getting the right content to the browser at the right time. The shell should be fast and contain what users immediately see. Suspense boundaries should contain what's slow, personalized, or below the fold.

When that split is done correctly, streaming genuinely improves perceived performance and often improves LCP. When the LCP element ends up on the wrong side of a Suspense boundary, streaming adds latency without improving anything the user notices.

The questions to ask before adding a Suspense boundary: what is the LCP element on this page, and is it going to be in the shell? If not, restructure the data fetching before restructuring the component tree.

React Server Components Don't Make Your App Fast by Default

nosyos — Thu, 21 May 2026 14:05:00 +0000

A Next.js app migrated from Pages Router to App Router. RSC throughout, use client pushed to the leaves. Lighthouse score went up. LCP in production got worse by 800ms.

The component tree was fetching data. Each server component called its own database query. They ran sequentially — one couldn't start until its parent finished. What was previously one getServerSideProps call became eight round trips before the page could render.

RSC reduces client JavaScript. That part works exactly as advertised. What it doesn't do is make data fetching faster, or eliminate the server-side work that now determines when your HTML actually arrives.

What RSC actually changes

Server components stay on the server. Their code never ships to the browser, they don't get hydrated, and anything they import doesn't touch the client bundle. For components that are genuinely static — content that renders from data and never responds to user interaction — this is a real win. The JavaScript savings from the previous article compound here: pushing use client to the leaves is how you maximize the RSC benefit.

Bundle size reduction is real. But LCP is determined by when the HTML arrives, not by how much JavaScript the client downloads afterward. If server components are slow, TTFB is slow, and LCP is slow — regardless of how small the client bundle is.

The waterfall that App Router makes easy to create

Pages Router's data fetching model had a structural advantage it rarely got credit for: getServerSideProps ran once, in one place, before the page rendered. Everything the page needed came from one function.

With RSC, each component can fetch its own data. This sounds cleaner — components are self-contained, colocated with their data requirements. The problem is that React renders the component tree top to bottom, and a child component's data fetch can't start until its parent has rendered and the child has mounted on the server.

// ParentComponent fetches its data first
async function ParentComponent() {
  const parent = await db.query('SELECT * FROM parent WHERE id = ?', [id]);
  return <ChildComponent parentId={parent.id} />;
}

// ChildComponent can't start until ParentComponent finishes
async function ChildComponent({ parentId }) {
  const children = await db.query('SELECT * FROM children WHERE parent_id = ?', [parentId]);
  return <>{/* render */}</>;
}

Two queries, sequential. If each takes 40ms, that's 80ms added to TTFB before the waterfall. Nest three or four levels of components that each need data, and you're looking at 200–400ms of sequential database round trips added to every page render.

This is the App Router waterfall. It's easy to create, easy to miss in development where database latency is near zero, and immediately visible in production.

Fetching in parallel

The fix is to hoist data fetching to the component that needs all the data, or to run independent queries in parallel:

async function ProductPage({ productId }: { productId: string }) {
  // These run in parallel — Promise.all starts both immediately
  const [product, reviews, inventory] = await Promise.all([
    db.products.findById(productId),
    db.reviews.findByProduct(productId),
    db.inventory.getStock(productId),
  ]);

  return (
    <>
      <ProductHeader product={product} />
      <InventoryStatus inventory={inventory} />
      <ReviewList reviews={reviews} />
    </>
  );
}

Three queries, one round trip's worth of latency. The child components receive data as props and render without fetching anything themselves.

This trades component colocation for speed. Sometimes that's the right tradeoff. For a page where TTFB matters — which is most pages — it usually is.

For queries that genuinely can't be parallelized because they depend on each other's results, React.cache at least prevents duplicate fetches across a single render when multiple components request the same data:

import { cache } from 'react';

const getUser = cache(async (userId: string) => {
  return db.users.findById(userId);
});

// Both components call getUser — only one database query executes
async function Header({ userId }) {
  const user = await getUser(userId);
  return <nav>{user.name}</nav>;
}

async function Sidebar({ userId }) {
  const user = await getUser(userId);
  return <aside>{user.role}</aside>;
}

cache deduplicates within a single request. It doesn't cache across requests — that's what unstable_cache or a proper caching layer handles.

TTFB is the new LCP bottleneck

With Pages Router, slow getServerSideProps was obviously the bottleneck because it was the one place data fetching happened. With App Router, the bottleneck is distributed across the component tree and harder to trace.

The signal to look for: LCP correlates with server response time in your field data, not with client-side metrics. If p75 LCP improves when you filter to users with fast connections, that's a client-side problem. If it's high regardless of connection speed, the server is slow.

Measuring TTFB separately from LCP in your RUM data makes this visible. If TTFB is 600ms and LCP is 650ms, the client is fine — the server is the problem.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'navigation') {
      sendMetric({
        ttfb: entry.responseStart - entry.requestStart,
        page: location.pathname,
      });
    }
  }
}).observe({ type: 'navigation', buffered: true });

Tracking TTFB per page in production shows which routes have server-side performance problems. A product listing page with high TTFB is a data fetching problem. A marketing page with high TTFB is a different problem — probably server cold starts or lack of caching.

Where RSC genuinely helps

RSC is the right model for components that render server-side data without needing client interactivity. Static product descriptions, server-rendered markdown, navigation built from a CMS — these belong on the server. Moving them there reduces the client bundle and eliminates hydration cost, and that's a real performance improvement.

What RSC doesn't do is make database queries faster, fix slow APIs, or reduce TTFB if your data fetching is sequential. The performance benefit of RSC is realized at the component boundary — it removes cost on the client. Everything upstream of that boundary is still your problem.

The next article in this series covers streaming SSR — the actual mechanism that lets Next.js send HTML before all the server-side data is ready, and where it genuinely helps LCP versus where it creates new problems to manage.

Most of Your Client JavaScript Exists to Hydrate Pages Users Already See

nosyos — Tue, 19 May 2026 14:06:00 +0000

There's a window between when a Next.js page finishes painting and when users can actually interact with it. Buttons look clickable. Links look followable. Nothing responds. The page is there — the HTML arrived, the browser rendered it — but the JavaScript hasn't finished running yet.

That window is hydration. And most of the JavaScript your app sends to the browser exists to get through it.

What hydration costs

The server renders HTML and sends it. The browser paints it immediately — that's your LCP. Then the browser downloads your JS bundle, parses it, compiles it, and runs it. React walks the entire DOM, compares it to the virtual DOM, and attaches event listeners to every interactive element. Only then is the page actually usable.

The time between LCP and Time to Interactive is the hydration tax. On a fast connection and a modern laptop it's barely noticeable. On a mid-range Android phone on 4G, it can be two to four seconds.

To see your own numbers: in Chrome DevTools Performance panel, record a page load and find the gap between the LCP marker and the point where long tasks stop. That gap is roughly what hydration is costing your users.

The `use client` boundary problem

Next.js App Router lets you keep components on the server by default. The moment you add use client, that component and everything it imports gets bundled for the client and hydrated.

The mistake I see most often is adding use client to a layout or wrapper component because one child needs it:

// This ships the entire subtree to the client
'use client';

import { Header } from './Header';
import { StaticContent } from './StaticContent'; // doesn't need to be a client component
import { InteractiveWidget } from './InteractiveWidget'; // this is the only reason for 'use client'

export function PageLayout({ children }) {
  return (
    <>
      <Header />
      <StaticContent />
      <InteractiveWidget />
      {children}
    </>
  );
}

StaticContent and Header are now client components. They'll be included in the JS bundle and hydrated, even if they never use state, effects, or event handlers.

The fix is to push use client as far down the tree as possible — to the component that actually needs it:

// Server component — no bundle cost, no hydration
import { Header } from './Header';
import { StaticContent } from './StaticContent';
import { InteractiveWidget } from './InteractiveWidget'; // 'use client' lives inside this file

export function PageLayout({ children }) {
  return (
    <>
      <Header />
      <StaticContent />
      <InteractiveWidget />
      {children}
    </>
  );
}

InteractiveWidget still ships to the client because it needs to be interactive. But Header and StaticContent stay on the server. Their HTML arrives pre-rendered and nothing hydrates them.

This is the single highest-leverage change in most Next.js App Router migrations I've seen. Auditing use client placement before reaching for any other optimization is worth doing first.

Finding what's actually in your bundle

The Next.js bundle analyzer shows what's in each chunk. Add it to next.config.js:

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

module.exports = withBundleAnalyzer({});

Run ANALYZE=true npm run build and look at the client bundle. Two things to look for: large dependencies that are imported inside use client components but don't actually need browser APIs, and server utilities that accidentally got pulled into the client graph.

A date formatting library that ended up in the client bundle because it was imported in a use client component that could have been a server component — I've found this more than once. Moving the component to the server removes the library from the client bundle entirely.

Code splitting reduces bundle size, but it doesn't help if what you're splitting is still fully hydrated. Smaller chunks load faster; that's real. But if every chunk is loaded and hydrated on every page, the gain is limited.

Deferring hydration for below-the-fold content

Content the user can't see immediately doesn't need to be hydrated immediately. React's lazy with Suspense defers both the download and the hydration:

import { lazy, Suspense } from 'react';

const HeavyDashboardWidget = lazy(() => import('./HeavyDashboardWidget'));

export function Dashboard() {
  return (
    <div>
      <AboveTheFoldContent />
      <Suspense fallback={<WidgetSkeleton />}>
        <HeavyDashboardWidget />
      </Suspense>
    </div>
  );
}

The widget's JavaScript isn't downloaded or hydrated until React renders that Suspense boundary. For content far down the page, wrapping it in a lazy-loaded component with an IntersectionObserver trigger defers hydration until it's actually scrolled into view — though this adds complexity that's only worth it for genuinely heavy components.

The simpler version — just using lazy without the intersection observer — already helps because the browser prioritizes loading and hydrating above-the-fold content first.

What this looks like in production

LCP and TTI moving in opposite directions is a signal that hydration cost has gotten out of hand. LCP improves because you're serving fast HTML from the server. TTI stays high because you're still sending a large client bundle to hydrate it.

Measuring LCP is straightforward. TTI is harder — it's not a Core Web Vital and it doesn't appear in CrUX. The proxy metric is INP on early interactions: if users are clicking buttons within the first few seconds of loading and seeing high INP, the page probably wasn't fully hydrated yet when they tried.

The next article looks at what Server Components actually change about the bundle and hydration picture — and where they don't help as much as the marketing suggests.

What Field Data Tells You That Lighthouse Can't

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

A Lighthouse 95 on a marketing page. CrUX showing 68% of real users experiencing "Poor" LCP. Both measuring the same URL.

The page was getting most of its traffic from users in Southeast Asia on mid-range Android devices over 4G. Lighthouse was running on a simulated Moto G4, but with a fast local network and a warm server. The simulated device wasn't the problem — the network conditions and server geography were.

This is the gap that field data closes. Lighthouse tells you what's possible in a controlled environment. Field data tells you what's actually happening.

Start with what you already have

Before building anything, check the Chrome UX Report. PageSpeed Insights shows CrUX data for any URL with enough traffic — real-user LCP, INP, and CLS distributions, broken down into Good / Needs Improvement / Poor buckets. Google Search Console's Core Web Vitals report shows the same data aggregated by page group.

CrUX has two limitations worth knowing. It only includes URLs that Chrome users have visited with usage reporting enabled, so low-traffic pages won't appear. And it's aggregated over a 28-day rolling window, which means a regression you shipped last week might not fully show up for another three weeks.

For most teams, CrUX is the right first stop. If your CrUX data looks fine, synthetic testing is probably sufficient. If it doesn't — or if you don't have enough traffic to appear in CrUX — you need your own RUM pipeline.

The web-vitals library is the right foundation

The web-vitals library handles the attribution and calculation details that the raw PerformanceObserver API leaves to you. It reports the same values Google uses for CrUX, which matters when you're trying to correlate your internal data with what's affecting your search ranking.

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function sendToAnalytics(metric) {
  fetch('/api/vitals', {
    method: 'POST',
    body: JSON.stringify({
      name: metric.name,
      value: metric.value,
      rating: metric.rating,        // 'good' | 'needs-improvement' | 'poor'
      attribution: metric.attribution,
      page: location.pathname,
      navigationType: metric.navigationType,
    }),
    keepalive: true,
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

The /attribution import is the important part. metric.attribution for INP includes the interaction target, the event type, and the three-phase breakdown — input delay, processing time, presentation delay — that tells you where the time was lost. For CLS, it includes the element that shifted and how far. This attribution data is what makes field measurements actionable rather than just decorative.

keepalive: true on the fetch ensures the request completes even if the user navigates away before it finishes.

Segment before you draw conclusions

Raw averages hide almost everything. A p75 LCP of 2.4 seconds looks fine — until you split by device type and see that desktop users are at 1.1s and mobile users are at 3.8s. Or split by page and find that 90% of the bad INP scores are concentrated on one product listing page.

The minimum useful dimensions to capture with every metric:

Page path (not the full URL — strip query strings and dynamic segments)
Connection type (navigator.connection?.effectiveType — gives you "4g", "3g", "2g", "slow-2g")
Device memory (navigator.deviceMemory — rough bucketing into low/mid/high)

function getDeviceContext() {
  return {
    connection: (navigator as any).connection?.effectiveType ?? 'unknown',
    memory: (navigator as any).deviceMemory
      ? (navigator as any).deviceMemory <= 2 ? 'low' : 'high'
      : 'unknown',
  };
}

navigator.connection and navigator.deviceMemory are Chrome-only and non-standard, but they're available for the large share of your users on Chrome where the data is most useful. Treat unknown as a valid bucket rather than an error.

With connection type as a dimension, "mobile users have worse LCP" becomes "mobile users on 3G have worse LCP, but mobile users on 4G are on par with desktop" — and that's a different optimization problem.

The metrics you're not collecting yet

INP is reported once per page session — the worst interaction in the session. That's the metric Google uses, but for debugging you want to know which specific interactions are bad, not just the worst one.

The web-vitals library's onINP callback includes attribution for the worst interaction. For catching the long tail, collecting individual slow interaction events separately is more useful:

onINP((metric) => {
  sendToAnalytics({
    ...metric,
    // attribution.interactionTarget is the CSS selector of the element
    interactionTarget: metric.attribution.interactionTarget,
    interactionType: metric.attribution.interactionType,
  });
});

interactionTarget gives you the CSS selector of the element the user interacted with. When you see the same selector appearing repeatedly in your slow INP data, you've found the component to fix.

From measurement to alerting

Collecting data answers "how bad is it." Alerting answers "when did it get worse."

A performance regression that appears in your RUM data on Tuesday might not surface in a weekly review until Friday. By then it's been affecting real users for three days and the deployment that caused it is buried under subsequent changes.

The gap between measurement and alerting is where most RUM setups fall short. Teams collect the data, build a dashboard, and check it periodically. They're doing monitoring — looking at history — rather than alerting.

Setting up threshold alerts on your p75 values — LCP over 2.5s, INP over 200ms, CLS over 0.1 — against a rolling window of real user data catches regressions close to when they happen. If you'd rather not build and maintain that alerting layer, RPAlert handles it for React apps: it collects Web Vitals from real browsers and sends a Slack or Discord notification within 60 seconds of a threshold crossing. The free tier covers one app, which is enough to see whether the alerting model is useful before committing to it.

What to do with the data

Field data changes the sequence of performance work.

Without it: pick metrics to optimize based on Lighthouse scores and engineering intuition, ship improvements, re-run Lighthouse, hope.

With it: look at where real users are experiencing the worst scores, segment to find the specific pages and conditions, fix those, watch the field data improve.

The third article in this series noted that CLS is slow to debug because the shifts depend on network timing and server conditions that don't exist locally. The same is true for INP on low-memory devices and LCP on slow connections. Lab data can't replicate those conditions reliably. Field data is the only measurement that captures them.

Running the web-vitals instrumentation in production for a week generates enough data to prioritize the rest of the work in this series. That's where to start.

Why CLS Is Harder to Fix in React Than You Think

nosyos — Tue, 12 May 2026 14:14:00 +0000

CLS is the only Core Web Vital that tends to get worse as a product matures. Every component you lazy-load, every feature flag that conditionally renders content, every third-party widget you add — each one is a potential layout shift. LCP and INP can be improved incrementally. CLS requires you to think about rendering order before you write the component.

That's what makes it frustrating. The fix is usually architectural, not a one-line change.

Why CLS behaves differently

LCP and INP have clear causes you can trace in DevTools. CLS shifts can happen at any point during a page's life, from any element, triggered by content the browser wasn't expecting to have to reflow around.

The browser assigns each shift a score based on the fraction of the viewport that moved and how far it moved. Shifts that happen within 500ms of a user interaction don't count — those are expected. Everything else does.

Setting width and height on images is table stakes. It helps, but it's not where React apps usually fail CLS.

Hydration layout shift

This is the one that catches Next.js developers off guard.

Server-rendered HTML is delivered with one set of dimensions and content. React hydrates on the client, and if the hydrated output differs from the server HTML — even slightly — the browser has to reflow. That reflow is a layout shift.

The most common trigger is content that depends on something only available in the browser: window.innerWidth, localStorage, a cookie, a user preference stored in context. If a component conditionally renders based on any of these, the server renders one version and the client immediately replaces it.

// This causes a hydration layout shift every time
function Sidebar() {
  const [isExpanded, setIsExpanded] = useState(
    typeof window !== 'undefined'
      ? localStorage.getItem('sidebar') === 'expanded'
      : false  // server always renders collapsed
  );

  return <aside style={{ width: isExpanded ? 280 : 64 }}>{/* ... */}</aside>;
}

The server renders a 64px sidebar. The client immediately expands it to 280px. Everything to the right shifts left by 216px. CLS score spikes.

The fix is to defer that client-only render until after hydration, so the shift doesn't happen against already-painted content:

function Sidebar() {
  const [mounted, setMounted] = useState(false);
  const [isExpanded, setIsExpanded] = useState(false);

  useEffect(() => {
    setIsExpanded(localStorage.getItem('sidebar') === 'expanded');
    setMounted(true);
  }, []);

  // Render a placeholder with fixed dimensions until mounted
  if (!mounted) {
    return <aside style={{ width: 64 }} aria-hidden />;
  }

  return <aside style={{ width: isExpanded ? 280 : 64 }}>{/* ... */}</aside>;
}

The placeholder has the same dimensions as the default state. The shift from 64px to 280px happens after useEffect, which means it happens after paint — and the browser waits for user interaction before that can affect CLS meaningfully.

The broader principle: any component that renders differently on server vs client needs a stable placeholder with matching dimensions. If you can't give it stable dimensions, defer it entirely with dynamic(() => import('./Component'), { ssr: false }) in Next.js.

Font loading reflow

A font swap causes a layout shift when the fallback font and the web font have different metrics — different character widths, line heights, or letter spacing. The text reflows to fit the new font, and anything below it shifts.

font-display: swap is often recommended because it avoids invisible text. The tradeoff is exactly this: visible text that then shifts. For body text at small sizes the shift is usually small enough to ignore. For large headings, a font swap can move substantial content.

size-adjust closes most of the gap by scaling the fallback font to match the web font's metrics:

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;
}

@font-face {
  font-family: 'CustomFontFallback';
  src: local('Arial');
  size-adjust: 104%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Getting the values right requires some trial and error against your specific font. The fontaine library automates this for Next.js and Nuxt apps — it generates the adjusted fallback declarations based on the actual font metrics. Next.js 13+ does this automatically for Google Fonts loaded via next/font.

If you're not using next/font for custom fonts, you're probably generating more CLS from font swaps than you realize.

Dynamic content that pushes existing content

Notifications, cookie banners, chat widgets, promotional bars — anything that inserts itself above or around existing content after the initial render is a layout shift.

The browser doesn't penalize shifts that happen within 500ms of a user interaction, but it does penalize shifts triggered by data loading, lazy component mounting, or timeouts. A toast notification that appears 2 seconds after page load and pushes content down by 60px is a CLS event.

The consistent fix is to reserve space before the content loads:

function NotificationBanner() {
  const { data: notification } = useNotification();

  // Reserve 60px whether or not there's a notification
  return (
    <div style={{ minHeight: 60 }}>
      {notification && <Banner message={notification.message} />}
    </div>
  );
}

The alternative — animating new content in using transform instead of position changes — avoids CLS entirely because transforms don't affect layout. A banner that slides in from off-screen doesn't move existing content.

// Shifts content — CLS event
<Banner style={{ position: 'relative', top: showBanner ? 0 : -60 }} />

// Doesn't shift content — no CLS
<Banner style={{ transform: `translateY(${showBanner ? 0 : -60}px)` }} />

The transform version renders the element in document flow at its full height from the start, so no other element ever has to reflow around it appearing.

Skeleton screens done wrong

Skeleton screens are supposed to prevent CLS by holding space for incoming content. They cause CLS when the skeleton dimensions don't match the content that replaces them.

A skeleton that renders a single line for what turns out to be a three-line text block. A card placeholder that's 180px tall for a card that renders at 220px. A list skeleton that shows five items when the API returns eight.

// This skeleton will cause a shift if the actual card is taller
function CardSkeleton() {
  return <div style={{ height: 180, background: '#eee', borderRadius: 8 }} />;
}

// Better: match the content structure, not just the height
function CardSkeleton() {
  return (
    <div style={{ padding: 16 }}>
      <div style={{ height: 20, width: '60%', background: '#eee', marginBottom: 8 }} />
      <div style={{ height: 16, width: '90%', background: '#eee', marginBottom: 4 }} />
      <div style={{ height: 16, width: '75%', background: '#eee' }} />
    </div>
  );
}

The second version matches the structural shape of the content, not just its total height. When the real card renders, the reflow is minimal because the block-level structure is already close to correct.

Dynamic-length content — variable-height text, user-generated content, lists without a fixed item count — is genuinely hard to skeleton correctly. In those cases, the better tradeoff is often SSR with Suspense streaming so the content arrives already rendered, rather than trying to skeleton something you can't predict.

Measuring which elements are causing shifts

The layout-shift entry type in PerformanceObserver gives you the shifted elements and their contribution to the score:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue; // skip user-triggered shifts

    for (const source of entry.sources) {
      console.log({
        score: entry.value,
        element: source.node?.nodeName,
        previousRect: source.previousRect,
        currentRect: source.currentRect,
      });
    }
  }
}).observe({ type: 'layout-shift', buffered: true });

source.node is the actual DOM element that shifted. previousRect and currentRect show where it was and where it ended up. In practice, a few elements account for most of the CLS score — this surfaces them without needing to reproduce the shift in DevTools.

Running this in production for a few days will tell you which components are responsible and which pages are most affected. The shifts that happen consistently on high-traffic pages are the ones worth fixing first.

CLS is slow to debug because shifts often depend on network timing, font loading, and server response — conditions that don't exist in local development. Measuring from real users is the only reliable way to know where your score is actually coming from.

The next article in this series covers field data collection in depth: what RUM gives you that Lighthouse can't, and how to build a measurement pipeline that makes debugging CLS, INP, and LCP from production tractable.

Community patterns from production

A few additional patterns from the comments, all caught with PerformanceObserver:
Bilingual length variance — Russian content runs ~25–30% longer than English on average, causing EN single-line strings to wrap in RU. Rendering layout calculations against the longer-language baseline eliminates the locale-toggle shift.
YouTube embeds — Reserve aspect ratio before the iframe loads:

css.youtube-embed-wrapper {
  position: relative;
  padding-bottom: 56.25%;
  overflow: hidden;
}
.youtube-embed-wrapper iframe {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
}

Translation cache hydration — If translations are lazy-loaded on locale toggle, warm the cache eagerly on page load instead. The first fetch on toggle is where the shift lands.
— via @arvavit

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.

DEV Community: nosyos

Streaming SSR Is Not a Free LCP Win

What streaming actually does

LCP only improves if the LCP element is in the shell

Suspense boundary placement is the whole game

Preloading resources before they stream

Measuring LCP on streaming pages

The mental model that makes streaming work

React Server Components Don't Make Your App Fast by Default

What RSC actually changes

The waterfall that App Router makes easy to create

Fetching in parallel

TTFB is the new LCP bottleneck

Where RSC genuinely helps

Most of Your Client JavaScript Exists to Hydrate Pages Users Already See

What hydration costs

The use client boundary problem

Finding what's actually in your bundle

Deferring hydration for below-the-fold content

What this looks like in production

What Field Data Tells You That Lighthouse Can't

Start with what you already have

The web-vitals library is the right foundation

Segment before you draw conclusions

The metrics you're not collecting yet

From measurement to alerting

What to do with the data

Why CLS Is Harder to Fix in React Than You Think

Why CLS behaves differently

Hydration layout shift

Font loading reflow

Dynamic content that pushes existing content

Skeleton screens done wrong

Measuring which elements are causing shifts

Community patterns from production

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

The `use client` boundary problem