DEV Community: Shrey Saraswat

"Frontend Performance in 2026: The Techniques That Actually Move the Needle Now"

Shrey Saraswat — Tue, 29 Sep 2026 07:44:01 +0000

Most "frontend performance" checklists still read like it's 2021: split your bundles, compress your images, use a CDN.

All still true.

None of it explains why a site can pass Lighthouse and still feel janky the moment someone clicks something.

That gap exists because the metric that actually measures "does this feel responsive" changed.

Interaction to Next Paint (INP) replaced First Input Delay as an official Core Web Vital back in March 2024, and as of early 2026 it's still the metric most sites fail — reporting puts INP as the most commonly-missed Core Web Vital, with a large share of sites still over the 200ms threshold.

FID only measured the delay before the browser started processing your first click.

INP measures every interaction on the page — clicks, taps, key presses — and reports the worst one.

You can't game a single data point anymore.

That shift changes what "performance work" should mean in practice.

This isn't a rehash of the code-splitting/image-optimization basics — it's what's actually new or newly relevant on top of that foundation.

The old checklist still matters, briefly

Skip this section if you've already got these covered.

If not, do them first — nothing below replaces them:

Code splitting — React.lazy() + Suspense, or Angular's lazy-loaded feature modules. Don't ship the whole app on first load.
Image optimization — WebP/AVIF, srcset for responsive sizing, lazy-load offscreen images.
Render-blocking resources — inline critical CSS, defer/async non-critical JS, font-display: swap.
Caching + CDN — hashed filenames so aggressive caching is safe, serve static assets from an edge, not your origin.

These are still correct.

They're also table stakes — most competent frontend teams already do them.

What follows is where the actual gains are hiding in 2026.

1. Diagnose INP with the Long Animation Frames API, not guesswork

The old Long Tasks API told you that something blocked the main thread for 50ms+.

It didn't tell you what — was it a script, a style recalculation, layout?

The Long Animation Frames (LoAF) API exposes that breakdown: script attribution, style/layout duration, and which specific function was responsible.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Blocking duration:', entry.blockingDuration);

    for (const script of entry.scripts) {
      console.log(script.name, script.duration, script.invoker);
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

If you've been trying to fix INP by guessing which component is slow, this replaces the guessing with an actual attribution trail. Chromium supports it; check current browser coverage before you build tooling around it exclusively.

2. Cut main-thread work with selective hydration

A big source of poor INP in component-heavy apps isn't one slow interaction — it's the sheer amount of JavaScript competing for the main thread before the page ever becomes interactive. Islands architecture (Astro, Qwik, and increasingly meta-frameworks built on React/Vue) addresses this directly: most of the page ships as static HTML, and only the components that actually need interactivity hydrate — and only when they're needed, not all at once on load.

The practical version of this in a React app you're not rewriting: audit what's actually interactive above the fold. A hero section with a static image and heading doesn't need to hydrate before a click handler three screens down does. If your framework supports partial or deferred hydration, that's real INP budget back.

3. Tell the browser what actually matters with `fetchpriority`

Browsers guess resource priority based on tag type and position. Sometimes the guess is wrong — a below-the-fold image loads before your actual LCP candidate. The fetchpriority attribute overrides that guess:

<img src="/hero.avif" alt="Product dashboard" fetchpriority="high" />
<img src="/footer-logo.svg" alt="Partner logo" fetchpriority="low" loading="lazy" />

It's a one-line change with a direct effect on LCP when your hero image was competing with less important requests. Check current support on Can I Use before relying on it as your only LCP fix — treat it as a targeted correction, not a substitute for actually optimizing the image itself.

4. Stop rendering what nobody can see

content-visibility: auto tells the browser to skip layout and paint work for off-screen content until it's about to become visible, while still reserving space so layout doesn't shift:

.long-list-item {
  content-visibility: auto;
  contain-intrinsic-size: 0 200px; /* estimated size, prevents CLS */
}

For long lists, comment sections, or any page with a lot of below-the-fold DOM, this cuts initial rendering cost without touching your component logic. It's a CSS-only performance win, which is rare enough to be worth calling out. Browser support has broadened over the last couple of years — verify current coverage for the browsers your users actually run.

5. Speculative navigation: prerendering before the click

The Speculation Rules API lets the browser prefetch or fully prerender a page before the user clicks the link, based on rules you define:

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

On a prerendered navigation, the next page can feel instant — the browser already rendered it in a hidden tab.

Two honest caveats: it's explicitly a multi-page-application technique (it targets full document navigations, not SPA route changes), and it's still limited availability — Chromium-based browsers only, not Baseline yet.

If you run a content site, blog, or traditional MPA, it's worth testing. If you're a SPA shipping client-side routing, this doesn't apply to you the way code-splitting does.

6. Audit your bundle instead of guessing what's heavy

Tree-shaking and dependency audits aren't new, but the habit of actually looking still gets skipped under deadline pressure. Run a visualizer before you assume you know what's bloating the bundle:

npx vite-bundle-visualizer

# or for webpack
npx webpack-bundle-analyzer stats.json

The recurring surprise is always the same shape: one dependency pulled in for a single utility function, sitting at 30–40kb gzipped. You don't know that until you look at the treemap.

Trade-offs worth being upfront about

Technique	Where it helps	Where it doesn't
LoAF API	Diagnosing why INP is bad	Doesn't fix anything by itself — it's a diagnostic tool
Selective hydration	Component-heavy apps with a lot of non-interactive content	Requires framework support; not a drop-in for existing React SPAs
`fetchpriority`	Correcting a wrong LCP-candidate guess	Doesn't help if the image itself is unoptimized
`content-visibility`	Long pages with lots of off-screen DOM	Needs a reasonable `contain-intrinsic-size` estimate or you'll get CLS instead
Speculation Rules	Multi-page apps, content sites	Doesn't apply to SPA client-side routing; Chromium-only today

None of these replace the fundamentals. They're what's left to optimize once code splitting, image formats, and caching are already handled — which is exactly the point where a lot of teams stop, because the easy wins are gone and the next layer requires knowing these exist.

A quick checklist

Have you measured INP with real user data (CrUX, RUM), not just lab Lighthouse scores?
Do you know which interactions are slow, or are you guessing? (LoAF API answers this)
Is everything above the fold actually necessary to hydrate immediately?
Does your LCP image have fetchpriority="high" and skip loading="lazy"?
Have you looked at a bundle visualizer in the last quarter, or are you assuming you know what's in there?

Worth discussing

If you're on a multi-page site, have you tried the Speculation Rules API yet — and did it actually feel instant, or did prerendering cost outweigh the win?

And for anyone dealing with INP specifically: what turned out to be your actual bottleneck once you looked, versus what you assumed it would be?

A Practical Guide to React's New : What Actually Animates (and What Doesn't)

Shrey Saraswat — Wed, 23 Sep 2026 11:18:25 +0000

React 19.3 shipped on npm on September 9, 2026, and it quietly stabilized something a lot of us have wanted for years: a native way to animate UI changes without reaching for a third-party library.

What `<ViewTransition>` actually is

It's a component that wraps part of your UI and tells React: "when this changes, animate it using the browser's native View Transition API instead of just swapping the DOM."

import { ViewTransition, useState, startTransition } from 'react';

function Panel() {
  const [showItem, setShowItem] = useState(false);

  return (
    <>
      <button
        onClick={() => {
          startTransition(() => {
            setShowItem((prev) => !prev);
          });
        }}
      >
        {showItem ? '➖' : '➕'}
      </button>

      {showItem && (
        <ViewTransition>
          <Details />
        </ViewTransition>
      )}
    </>
  );
}

Toggle showItem, and instead of the panel just popping in and out, it cross-fades. No CSS animation library, no manual onExit juggling.

React decides which kind of animation to run based on how the tree changed:

enter — the <ViewTransition> gets added
exit — it gets removed
update — its children change style or content
share — a named moves from one place to another

The rule that trips people up

Here's the part most quick-recap posts gloss over: <ViewTransition> doesn't animate every update.

It only animates changes caused by:

startTransition
a <Suspense> reveal
useDeferredValue

A plain setState call inside a regular event handler won't trigger the animation — it just updates immediately, the same as always. This is deliberate. React treats "urgent" interactions (typing, dragging, anything that needs to feel instant) differently from "non-urgent" ones (navigating, revealing content), and only the latter get animated.

So if you wrap something in <ViewTransition> and nothing happens, the first thing to check isn't your CSS — it's whether the state update is actually wrapped in startTransition.

Customizing animations by cause: `addTransitionType`

A single piece of state can change for different reasons that should animate differently. Classic example: a carousel. Clicking "next" should slide left-to-right; clicking "previous" should slide the other way — even though both actions just update the same currentSlide number.

addTransitionType lets you attach a label to the cause of the update:

function nextSlide() {
  startTransition(() => {
    addTransitionType('next');
    setCurrentSlide((c) => c + 1);
  });
}

function previousSlide() {
  startTransition(() => {
    addTransitionType('previous');
    setCurrentSlide((c) => c - 1);
  });
}

Then map each type to a different animation:

<ViewTransition
  enter={{ next: 'from-right', previous: 'from-left' }}
  exit={{ next: 'to-left', previous: 'to-right' }}
>
  <Page />
</ViewTransition>

React also exposes the transition type as a browser view transition type, so you can scope the actual animation in plain CSS using :active-view-transition-type(...) instead of inline objects, if you'd rather keep the animation logic out of your components.

Where it gets genuinely interesting: Suspense

This is the part that made me actually want to try it. You can wrap a <Suspense> boundary in <ViewTransition> and animate the swap from fallback to real content:

<ViewTransition>
  <Suspense fallback={<Loading />}>
    <Component />
  </Suspense>
</ViewTransition>

You can even use it to coordinate image and font loading — wrapping an <img> and a @font-face declaration in <ViewTransition><Suspense> means React waits for both to be ready before revealing them together, instead of letting them flicker in independently as they finish.

But the default behavior has a rough edge. If you just wrap a Suspense boundary like above, every reveal animates — including ones where the content was already cached and should just appear instantly. That feels like the app got slower, not smoother.

The fix is to be explicit about what should and shouldn't animate:

<ViewTransition update="auto" default="none">
  <Suspense fallback={<Fallback />}>
    <Component />
  </Suspense>
</ViewTransition>

This gives you three rules worth keeping in mind whenever you combine <ViewTransition> with Suspense:

Fallbacks should appear immediately, without animation — the loading state shouldn't feel delayed
The swap from fallback to final content should animate — that's the actual payoff
Content that's already cached and doesn't suspend should appear immediately, without animation

Skip that last one and you'll animate things that were never actually loading, which just reads as unnecessary lag to the user.

Common mistakes to watch for

Mistake	What happens	Fix
Forgetting `startTransition`	Nothing animates, state just updates instantly	Wrap the update in `startTransition`
Animating every Suspense reveal	Cached content feels artificially slow	Use `update="auto" default="none"`
Using `<ViewTransition>` for React Native	It's DOM-only for now	Native/other-platform support isn't there yet
Expecting it to replace all animation libraries	It only animates transition-triggered changes	Keep a library for hover states, gestures, and non-transition micro-interactions

Should you adopt it now?

Honestly — probably, for the cases it's built for. It's stable, it requires no build step or extra dependency, and it's built on a real web standard rather than a JS-computed animation loop. If you're currently hand-rolling enter/exit animations with useEffect and CSS classes, this replaces that machinery directly.

Where I'd hold off: if you're deep into a library like Framer Motion for complex gesture-driven interactions (drag, spring physics, layout animations outside of React's transition model), there's no reason to rip that out.
<ViewTransition> solves a specific, narrower problem — animating mounts, unmounts, and content swaps tied to state transitions — not general-purpose animation.

A quick checklist

Is the state update wrapped in startTransition (or a Suspense reveal / useDeferredValue)?
Does this update need different animations depending on cause? → use addTransitionType
Are you animating a Suspense boundary? → set update="auto" default="none" to avoid animating cached content
Do you actually need a full animation library for this interaction, or does <ViewTransition> cover it?

Worth discussing

Has anyone here actually shipped <ViewTransition> in production yet? I'm curious whether the Suspense-fallback behavior needed more tuning than the docs suggest, and whether you kept an existing animation library around alongside it or dropped it entirely.

DEV Community: Shrey Saraswat

"Frontend Performance in 2026: The Techniques That Actually Move the Needle Now"

The old checklist still matters, briefly

1. Diagnose INP with the Long Animation Frames API, not guesswork

2. Cut main-thread work with selective hydration

3. Tell the browser what actually matters with fetchpriority

4. Stop rendering what nobody can see

5. Speculative navigation: prerendering before the click

6. Audit your bundle instead of guessing what's heavy

Trade-offs worth being upfront about

A quick checklist

Worth discussing

A Practical Guide to React's New : What Actually Animates (and What Doesn't)

What <ViewTransition> actually is

The rule that trips people up

Customizing animations by cause: addTransitionType

Where it gets genuinely interesting: Suspense

Common mistakes to watch for

Should you adopt it now?

A quick checklist

Worth discussing

3. Tell the browser what actually matters with `fetchpriority`

What `<ViewTransition>` actually is

Customizing animations by cause: `addTransitionType`