CSS gradient performance: do gradients slow a site down?

Good CSS gradient performance is the normal case: a static gradient does not slow a website down in any way you could notice. It is a line of text, so there is nothing to download, nothing to decode and nothing to wait for. Gradients cost a little paint time, like every other colour on the page. Slow pages come from a few specific patterns built on top of gradients: large blurs, repaints while scrolling and animations that repaint every frame. This guide shows which is which and how to check your own page.

Loading: gradients versus images

background: linear-gradient(135deg, #1e1b4b, #7c3aed 55%, #f472b6); is 67 characters. It arrives inside your stylesheet, needs no extra request, and renders sharp at any size and pixel density. An image background needs its own request, has to be decoded before it can be drawn, and has to be large enough for big, high-density screens.

So for simple and moderately layered backgrounds, CSS wins on loading every time. Images still make sense when the background is genuinely complex, such as a painterly mesh gradient with many colour points or a photographic texture. Then the trade is file weight for visual richness, and it is often worth it.

Painting: what a gradient costs on screen

To show a gradient, the browser calculates a colour for every pixel it covers: that is painting. The work grows with the painted area, the number of stacked gradient layers and any effects on top. For a static background it happens once, and the result is reused while you scroll or interact, unless something invalidates it.

The real risks: blur, fixed backgrounds and animation

Large blurs. filter: blur() and backdrop-filter sample many surrounding pixels for every pixel, and the work grows with both the blur radius and the area. A blurred gradient that is painted once is usually fine. A backdrop-filter over content that scrolls underneath has to be recomputed as that content moves, which is where glassmorphism interfaces tend to stutter on modest phones.

Fixed backgrounds. background-attachment: fixed keeps a background still while the page scrolls, which can force it to repaint on every scroll step. If you want a gradient that stays put, a position: fixed element behind the content is usually cheaper, because the browser can move it as a separate layer.

Animation. Moving background-position or animating colour stops through @property repaints the element every frame. On a button that is trivial. On a full-screen hero, it is continuous work for as long as the page is open, which shows up as heat and battery drain on phones.

/* repaints the whole hero every frame */
.hero--costly {
  background: linear-gradient(120deg, #1e1b4b, #7c3aed, #f472b6);
  background-size: 300% 300%;
  animation: pan 12s ease-in-out infinite alternate;
}

/* the browser can usually just move a finished layer */
.hero--cheap::before {
  content: "";
  position: absolute;
  inset: -50%;
  z-index: -1;
  background: conic-gradient(#1e1b4b, #7c3aed, #f472b6, #1e1b4b);
  animation: turn 40s linear infinite;
}

@keyframes pan { to { background-position: 100% 50%; } }
@keyframes turn { to { transform: rotate(1turn); } }

The CSS animated gradient guide has the full set of techniques, from cheapest to most flexible.

Layers and will-change

Promoting an element to its own compositor layer, with will-change: transform or an active transform animation, is what makes cheap animation possible. It is not free: each layer holds its own bitmap in graphics memory, roughly width × height × 4 bytes at device pixels. One oversized layer for a hero background is fine. Dozens of promoted cards, each with its own gradient layer, can use more memory than they save in paint time. Add will-change to the elements that actually animate, not as a blanket rule.

How to measure gradient performance

1. 1

   Turn on paint flashing

   In Chrome DevTools, open the Rendering panel and enable Paint flashing. Anything that flashes green while nothing should be changing is repainting.

2. 2

   Record a Performance trace

   Record a few seconds of scrolling or idle animation in the Performance panel. Look at how much of each frame is spent in paint and whether frames are dropped.

3. 3

   Throttle the CPU

   Use the Performance panel's CPU throttling to simulate a slower device. A hero that is smooth on a fast laptop can struggle on a mid-range phone.

4. 4

   Check the Layers panel

   See how many compositor layers exist and how much memory they use. Unexpectedly many layers usually means will-change is overused.

5. 5

   Test the real device

   Finish on an actual phone. Heat and battery drain from constant animation are easy to miss on a desktop.

web.dev's guide to rendering performance explains the pipeline behind these tools: style, layout, paint and composite. Knowing which stage your gradient triggers tells you whether it is cheap.

A performance checklist for gradients

• Use CSS gradients for simple and layered backgrounds; images only when the look genuinely needs them.
• Keep blur radii modest, and avoid backdrop-filter over large scrolling areas.
• Replace background-attachment: fixed with a fixed-position layer.
• Animate transform or opacity, not background-position, on large areas.
• Slow, ambient animations can stop entirely for reduced motion users.
• Add grain as a small tiled image, not a live SVG filter on a big element; see CSS noise texture.
• Measure before and after with paint flashing and a Performance recording.