How CSS Properties Affect Website Performance

A website can load quickly and still feel slow. Scrolling may stutter, animations may drop frames, or hovering over a card may briefly freeze the interface. When this happens, developers often begin by investigating JavaScript, image size, or network requests. However, the problem can sometimes come from a visual effect that appears harmless in the stylesheet.

I encountered this while working on a video-streaming interface. Each video preview displayed an enlarged, blurred version of its thumbnail in the background. The effect looked good and performed normally when only a few previews were present. As users interacted with more videos, however, scrolling and transitions became noticeably less smooth.

After reviewing the carousel configuration, recent code changes, memory behaviour, and video lifecycle, we isolated the blur effect. Removing it produced an immediate and repeatable reduction in GPU activity.

That experience changed how I evaluate CSS. A property is not expensive simply because it appears on a performance list. Its cost depends on the area it affects, how often it changes, how many elements use it, and which stage of the browser’s rendering pipeline it triggers.

This guide explains that relationship in detail so you can identify expensive CSS without removing every shadow, animation, or visual effect from your design.

How the Browser Turns CSS Into Pixels

When the browser receives a page, it does more than read the stylesheet and display the result. It combines HTML and CSS into structures that determine what should appear, where it should appear, and how it should be drawn.

A simplified rendering pipeline looks like this:

HTML and CSS
      ↓
Style calculation
      ↓
Layout
      ↓
Paint
      ↓
Compositing
      ↓
Pixels on the screen

Not every update passes through every stage. That distinction explains why changing one property can be significantly more expensive than changing another.

Style Calculation

During style calculation, the browser determines which CSS rules apply to each element and calculates its final styles.

For example:

.product-card.featured:hover {
  background: #fff7ed;
}

When the card gains or loses its hover state, the browser recalculates the relevant styles.

The cost of style calculation depends less on whether one selector looks complicated and more on how many elements may be affected. Changing a class high in a large DOM tree can invalidate styles for many descendants.

Consider:

.dark-theme .dashboard-card {
  background: #111827;
  color: #f9fafb;
}

Adding .dark-theme to a high-level container may require the browser to recalculate styles across a substantial part of the page. That may be completely acceptable when switching themes once, but it becomes a problem if a similar large-scale change occurs repeatedly during scrolling or animation.

Modern browsers optimise selector matching aggressively. Replacing every descendant selector with a class is unlikely to rescue an otherwise slow page. Large DOM trees and frequent style invalidation are usually more meaningful problems.

Layout

After styles are calculated, the browser determines the size and position of elements. This stage is called layout.

Properties such as the following can affect layout:

width
height
padding
margin
top
left
right
bottom
font-size
line-height
display
grid-template-columns
flex-basis

Changing the width of a container may change the width of its children. Text may wrap onto additional lines, which changes the element’s height and moves everything below it.

A single CSS change can therefore create a chain of recalculations.

Suppose a sidebar expands from 60 to 240 pixels:

.sidebar {
  width: 60px;
  transition: width 300ms ease;
}

.sidebar.is-open {
  width: 240px;
}

During the animation, the browser may repeatedly recalculate the sidebar, the main content area, wrapped text, and nearby components.

At 60 frames per second, the browser has approximately 16.7 milliseconds to process each frame. If layout, paint, JavaScript, and other work exceed that budget, the animation can stutter.

Paint

Once the dimensions and positions are known, the browser draws visual details such as:

• Colours
• Text
• Borders
• Images
• Shadows
• Gradients
• Filters
• Masks

This is the paint stage.

A small static shadow on one button is usually inexpensive. The same shadow, repeated across hundreds of cards and animated during scrolling, creates substantially more work.

The size of the painted area is important. Painting a 32 × 32-pixel icon is very different from repainting a full-screen overlay.

Compositing

Browsers may place parts of the page into separate composited layers. These layers can then be moved, faded, or combined to produce the final frame.

Properties such as transform and opacity can often be updated during compositing without recalculating layout or repainting the element.

That makes them useful for animations—but not free. Large layers use memory, and promoting too many elements can place additional pressure on the GPU.

The goal is not to force every element onto its own layer. It is to avoid unnecessary work in earlier rendering stages when the same visual result can be produced more efficiently.

Case Study: When filter: blur() Slowed a Video Interface

The video platform used a blurred thumbnail as a decorative background behind the active preview.

A simplified version looked like this:

.video-preview__background {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
  filter: blur(40px);
  transform: scale(1.15);
  opacity: 0.7;
}

The scale() prevented the softened edges of the image from becoming visible after the blur was applied.

Nothing about the component initially looked alarming. It was one background image and a common visual treatment. The issue emerged when several factors combined:

• The blurred image covered a large area.
• Multiple preview components were mounted during the session.
• Background images changed with the selected video.
• The carousel moved while blurred layers were present.
• The blur radius was relatively large.
• The interface ran for extended periods.

Our first assumption was that the carousel or video preview logic was creating the slowdown. We reviewed Swiper settings, component updates, video cleanup, and recent JavaScript changes. Those checks did not fully explain the pattern.

The useful signal came from comparing the same interaction with and without the blur.

In the monitoring environment used during the investigation, the GPU reading stayed around 42–70 without the effect and rose to approximately 130 when the blurred backgrounds were active.

Those numbers are not a universal benchmark or necessarily percentages. GPU measurements vary by browser, operating system, device, and monitoring tool. The meaningful result was the controlled difference: removing the effect consistently reduced rendering pressure and made interaction smoother.

Why Blur Became Expensive

A blur calculates each output pixel using information from neighbouring pixels. The larger the radius, the wider the surrounding area involved in the calculation.

The cost also grows with the number of pixels being processed. A blur(20px) effect on a small avatar and the same effect on a full-width video background do not have equal cost.

The blur was not problematic because the property itself was “bad.” It became problematic because it combined:

Large surface area
× High blur radius
× Several elements
× Frequently changing content

That is the more useful way to assess a CSS effect.

What Could We Do Instead?

The cheapest option would be to remove the blur entirely, but performance optimisation does not always require abandoning the design.

A lower-cost version could reduce the affected area and radius:

.video-preview__background {
  position: absolute;
  inset: 8%;
  object-fit: cover;
  filter: blur(16px);
  transform: scale(1.08);
  opacity: 0.55;
}

Another option is to generate a small blurred thumbnail before it reaches the browser. A low-resolution image can produce a similar background effect with less runtime processing.

.video-preview {
  background:
    linear-gradient(
      rgb(15 23 42 / 35%),
      rgb(15 23 42 / 85%)
    ),
    url("/images/preblurred-thumbnail.webp")
      center / cover no-repeat;
}

Other practical alternatives include:

• Keeping only the active preview’s blurred layer mounted
• Removing the effect when the component leaves the viewport
• Replacing the blur with a gradient based on the thumbnail’s dominant colours
• Reducing the effect on smaller or lower-powered devices
• Using a static blurred asset when the source image does not change

The right solution depends on whether the effect contributes enough visual value to justify its cost.

CSS Properties That Trigger Layout Work

Properties affecting geometry are not inherently harmful. Websites need widths, margins, grids, and typography. The problem usually comes from changing them repeatedly.

Moving Elements With top and left

This animation changes the element’s layout position:

.notification {
  position: relative;
  left: 0;
  transition: left 300ms ease;
}

.notification.is-visible {
  left: 24px;
}

The same movement can generally be created using transform:

.notification {
  transform: translateX(0);
  transition: transform 300ms ease;
}

.notification.is-visible {
  transform: translateX(24px);
}

The transformed version can often remain in the compositing stage.

Expanding Elements With width

Imagine an animated search field:

.search-input {
  width: 180px;
  transition: width 250ms ease;
}

.search-input:focus {
  width: 320px;
}

Changing the width may affect neighbouring elements and cause text or containers to reflow.

If the design allows it, reserve the full layout width and visually scale the input:

.search-wrapper {
  width: 320px;
}

.search-input {
  width: 100%;
  transform: scaleX(0.5625);
  transform-origin: right;
  transition: transform 250ms ease;
}

.search-input:focus {
  transform: scaleX(1);
}

This is not a perfect replacement. Scaling also scales the text and border during the animation, which may look wrong. Sometimes animating width is the correct design choice.

The improvement is not “replace width everywhere.” It is “avoid animating layout when the visual result can be achieved without it.”

Animating Height for Expandable Content

Developers commonly want to animate an accordion from height: 0 to height: auto. Since auto cannot always be interpolated as expected, implementations often measure the content height with JavaScript and animate an explicit value.

That can be acceptable for one accordion. It becomes expensive when many sections resize simultaneously and shift large portions of the page.

Alternatives include:

• Animate only the active section.
• Keep the duration short.
• Avoid continuously reading and writing layout values.
• Use a discreet reveal rather than a large animated expansion.
• Use modern layout features where supported and appropriate.
• Measure whether the animation causes noticeable layout work.

Layout is not forbidden. Repeated full-page layout during interaction is what needs attention.

Properties That Increase Painting Cost

Some visual effects do not change geometry but require the browser to repaint pixels.

Shadows

A basic shadow is rarely a serious problem:

.card {
  box-shadow: 0 4px 16px rgb(15 23 42 / 12%);
}

A more complex shadow increases the painted area and calculation:

.card {
  box-shadow:
    0 8px 24px rgb(15 23 42 / 18%),
    0 24px 60px rgb(15 23 42 / 14%),
    inset 0 1px 0 rgb(255 255 255 / 25%);
}

Even this may be fine on a few static cards. The risk increases when it is:

• Repeated across a large grid
• Applied to large containers
• Animated continuously
• Combined with transparency
• Changed during scrolling or pointer movement

Animating a shadow’s blur and spread can be more expensive than moving an element with a static shadow.

Instead of:

.card {
  transition: box-shadow 250ms ease;
}

.card:hover {
  box-shadow: 0 24px 70px rgb(15 23 42 / 30%);
}

Consider combining a simpler shadow with a small transform:

.card {
  box-shadow: 0 8px 24px rgb(15 23 42 / 14%);
  transform: translateY(0);
  transition: transform 250ms ease;
}

.card:hover {
  transform: translateY(-4px);
}

The second version still creates depth without animating a large blurred region.

backdrop-filter

Glassmorphism often uses:

.navigation {
  background: rgb(255 255 255 / 15%);
  backdrop-filter: blur(24px);
}

Unlike a normal blur applied to the element itself, backdrop-filter processes the content behind the element.

If the background changes during scrolling, video playback, or animation, the browser may need to update the effect repeatedly.

A fixed navigation bar with backdrop-filter can therefore be more expensive than it appears because a large part of the page moves behind it.

A simpler alternative is:

.navigation {
  background: rgb(255 255 255 / 92%);
  border-bottom: 1px solid rgb(15 23 42 / 8%);
}

If the glass effect is important, keep its area and blur radius limited and test it during real scrolling—not only on a static screenshot.

Gradients, Masks, and Clipping

Static gradients are usually manageable, but large animated gradients can cause repeated painting:

.hero {
  background: linear-gradient(
    120deg,
    #7c3aed,
    #2563eb,
    #06b6d4
  );
  background-size: 300% 300%;
  animation: gradient-shift 8s linear infinite;
}

This full-width animated background may continually repaint even when the user is not interacting with it.

Complex clip-path shapes, masks, blending, and layered transparency can create similar problems when animated or applied to large elements.

These effects are best treated as enhancements. Keep the underlying design functional and attractive without depending on them.

Why transform and opacity Usually Perform Better

Consider a modal that appears by changing its position and opacity:

.modal {
  transform: translateY(16px);
  opacity: 0;
  transition:
    transform 200ms ease,
    opacity 200ms ease;
}

.modal.is-visible {
  transform: translateY(0);
  opacity: 1;
}

The browser can often animate these properties by moving and blending an existing composited layer.

The alternative might animate top, change visibility through layout, or recalculate several dimensions.

That does not mean transform and opacity are always free.

A full-screen 4K image promoted to a layer consumes more memory than a small button. Fifty simultaneously animated layers can overwhelm a device even when every animation uses “safe” properties.

Transparent layers can also become expensive when several overlap and the browser must blend them for every frame.

Use compositor-friendly properties when they provide the correct visual behaviour, then confirm the result with browser developer tools.

The Correct Way to Use will-change

will-change lets the browser know that a property is expected to change:

.carousel-track.is-preparing {
  will-change: transform;
}

This may help the browser prepare a composited layer before the animation starts.

The common mistake is treating it as a permanent acceleration switch:

/* Do not do this */
.card,
.button,
.image,
.modal,
.carousel,
.sidebar {
  will-change: transform, opacity;
}

Each prepared layer can consume memory. Promoting many elements may create more overhead than the original animation.

Use will-change only when:

1. A real animation problem has been measured.
2. The element is expected to change soon.
3. The hint is applied shortly before the change.
4. It is removed when the animation ends.

Browsers already use their own heuristics to optimise rendering. will-change should be an exception, not part of every component’s default CSS.

How CSS Properties Affect Core Web Vitals

CSS performance is not limited to frame rate. Styles can also influence Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint.

Largest Contentful Paint

CSS is render-blocking by default. The browser normally needs the required stylesheet before it can display styled content.

A large CSS bundle can delay LCP when it contains:

• Styles for pages not currently displayed
• An entire component library when only a few components are used
• Repeated utility rules
• Several font declarations
• Third-party theme files
• Late-loading hero styles

CSS can also delay the LCP element directly.

Consider:

.hero-content {
  opacity: 0;
  animation: reveal 1s ease 800ms forwards;
}

Even if the hero content is ready, the animation intentionally keeps it invisible for 800 milliseconds and then fades it over another second.

A less damaging version might be:

.hero-content {
  animation: reveal 300ms ease both;
}

Or the entry animation can be removed from the main LCP element while retained for smaller decorative elements.

Background images can also delay discovery because the browser may not know about them until the CSS is downloaded and parsed. If a hero image is meaningful content and likely to become the LCP element, an HTML <img> or <picture> often provides better loading control.

Cumulative Layout Shift

CSS contributes to CLS when the browser cannot determine how much space content requires before it loads.

A common example is an image with no dimensions:

<img src="product.webp" alt="Running shoe">

Before the image loads, the browser may initially assign it no height. Once its dimensions are known, surrounding content moves.

Reserve the aspect ratio in HTML:

<img
  src="product.webp"
  alt="Running shoe"
  width="800"
  height="600"
>

Then keep it responsive:

img {
  max-width: 100%;
  height: auto;
}

The same principle applies to video players, iframes, advertisements, and dynamically loaded components.

.video-player {
  aspect-ratio: 16 / 9;
}

Fonts can also create shifts when the fallback font and downloaded web font use different character dimensions. The line lengths, wrapping, and block height may change when the final font appears.

Use a suitable fallback and consider font metric overrides when necessary:

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
  size-adjust: 98%;
}

The correct adjustment depends on the actual fonts. Do not copy a percentage without comparing their metrics.

Interaction to Next Paint

INP measures how quickly the page visually responds to user interactions.

JavaScript is often the main contributor to slow interactions, but CSS can add substantial rendering work after the event.

Suppose selecting a filter changes the widths, positions, and visibility of hundreds of product cards. The event handler may finish quickly, yet the browser still needs to recalculate styles, perform layout, repaint the grid, and composite the result.

From the user’s perspective, the interaction is not complete until the next frame appears.

CSS-related INP problems commonly involve:

• Expanding large sections
• Changing many element classes at once
• Animating layout properties
• Repainting full-screen effects
• Updating complex grids
• Running several transitions after one input
• Combining DOM measurement and style changes repeatedly

Optimise the total interaction, not only the JavaScript execution time.

Improving Long-Page Rendering With Containment

Long feeds, documentation pages, and dashboards may contain large sections that are not initially visible.

content-visibility can allow the browser to skip layout and paint for offscreen sections:

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 700px;
}

The intrinsic size gives the browser a placeholder while the content is not rendered. Once the section has been displayed, auto allows the browser to remember the measured size.

This can reduce initial rendering work on long pages, but the placeholder estimate matters. If the actual section is 1,400 pixels high and the estimate is 300 pixels, the page may shift when the real content is rendered.

Containment can also isolate an independent component:

.dashboard-widget {
  contain: layout paint;
}

This tells the browser that layout and painting inside the widget can be treated as more independent from the rest of the page.

Containment can change visual behaviour. Paint containment may clip shadows, tooltips, menus, or focus indicators that extend beyond the component. Test the complete interaction before using it broadly.

A Better Process for Finding Expensive CSS

Optimisation should start with a reproducible problem, not a list of properties to remove.

Reproduce One Slow Interaction

Choose a specific behaviour:

• Scroll through the video list.
• Open the sidebar.
• Hover over the product cards.
• Expand the accordion.
• Move through the carousel.
• Switch between dashboard tabs.

Avoid measuring several actions together because it becomes difficult to connect the result to one cause.

Record the Interaction

Use the browser’s Performance panel to record the behaviour.

Inspect:

• Recalculate Style
• Layout
• Paint
• Composite Layers
• Long frames
• Dropped frames
• Layout-shift records
• Main-thread work

The Layers and Rendering panels can help identify large composited areas, paint flashing, and layer boundaries.

Disable One Suspected Rule

Developer tools allow individual CSS declarations to be toggled without rebuilding the application.

For example, disable:

filter: blur(40px);

Repeat the exact same interaction.

If performance improves, restore the property and try a smaller value. If nothing changes, the blur was probably not the primary cause.

This controlled comparison is much more reliable than assuming the property is expensive because an article says so.

Reduce the Expensive Dimension

Once the cause is confirmed, identify what makes it expensive:

• Is the element too large?
• Is the effect repeated too many times?
• Is the radius excessive?
• Does it remain active outside the viewport?
• Does it change every frame?
• Can it be pre-rendered?
• Can the animation use another property?
• Can fewer elements update together?

The best optimisation often preserves the effect while reducing its scope.

Test on Real Devices

A design may remain at 60 frames per second on a development laptop and struggle on an older Android phone.

Test with:

• Lower-powered mobile hardware
• Different pixel densities
• Chrome, Firefox, and Safari
• CPU throttling
• Reduced-motion preferences
• Long sessions
• Real data volumes

A component tested with six cards may behave differently with 600.

CSS Performance Best Practices That Actually Matter

Keep the stylesheet delivered during initial load as small as practical. Remove styles that no longer belong to active pages and avoid loading large third-party themes for one component.

Use transform and opacity for motion when they produce the correct design. Do not force them into cases where scaling or transparency breaks usability.

Treat filters, backdrop filters, masks, and large shadows as performance-budget decisions. Test them based on their real size and frequency.

Reserve space for images, video players, advertisements, and dynamically inserted content. This prevents the browser from moving existing content after the resource arrives.

Use fonts intentionally. Every family, style, and weight adds another potential request and may change layout when loaded.

Stop animations when they leave the viewport, and respect reduced-motion preferences:

@media (prefers-reduced-motion: reduce) {
  .video-preview__background,
  .floating-decoration,
  .animated-gradient {
    animation: none;
    transform: none;
  }
}

Most importantly, measure the interface rather than optimising CSS in isolation. A page can contain blur and shadows while performing well. Another can contain almost no visual effects and still be slow because it repeatedly lays out thousands of elements.

When redesigning an existing website, performance should be evaluated alongside visual quality rather than after every layout and effect has been approved. Professional website redesign services can help connect design decisions with Core Web Vitals, accessibility, responsive behaviour, and frontend maintainability.

Frequently Asked Questions

Which CSS Properties Affect Performance the Most?

Properties that repeatedly trigger layout or paint deserve the most attention. Common examples include animated dimensions and positions, large filters, backdrop filters, complex shadows, masks, and changing full-screen backgrounds.

Is filter: blur() Always Bad for Performance?

No. A small static blur may have little noticeable impact. Problems are more likely when the radius is large, the affected area is large, several elements use it, or the underlying content changes frequently.

Why Are transform and opacity Recommended for Animations?

Browsers can often update them during compositing without recalculating layout or repainting the element. This usually reduces main-thread rendering work, although large or numerous composited layers can still consume significant memory.

Does will-change Make Every Animation Faster?

No. It gives the browser an optimisation hint and may prepare a separate layer. Applying it unnecessarily can increase memory use and layer-management overhead. Use it only for measured problems.

Are Complex CSS Selectors Slow?

They can add work in very large or frequently changing DOM trees, but modern browsers optimise selector matching. Large DOM size, broad style invalidation, and expensive layout or painting are often more important.

Do CSS Transitions Perform Better Than JavaScript Animations?

Not automatically. CSS gives the browser more control, but the animated property still matters. A CSS transition of width may trigger more rendering work than a JavaScript animation using transform.

Can CSS Affect Interaction to Next Paint?

Yes. An interaction may trigger style recalculation, layout, painting, and compositing after its event handler runs. Updating many elements or animating layout properties can delay the next visible frame.

How Can CSS Affect Largest Contentful Paint?

Large render-blocking stylesheets, late hero styles, background-image discovery, web fonts, and entry animations that keep the main content invisible can all delay when the LCP element appears.

How Do I Know Whether a Property Triggers Layout or Paint?

Record the interaction in browser developer tools and inspect the rendering events. Browser behaviour can change, so an observed trace is more reliable than relying entirely on a static property list.

Should All Visual Effects Be Removed on Mobile?

No. Start by testing real lower-powered devices. Reduce or remove only effects that create measurable problems or offer little value relative to their cost.

Our Final Words

CSS performance is not about writing visually plain websites. It is about understanding what the browser must do to produce each design decision.

The blur issue in our video interface did not come from using an unusual or unsupported property. It came from applying an expensive pixel effect to large, changing areas across several components. Once that relationship was measured, we could consider smaller radii, fewer active layers, pre-generated assets, and simpler alternatives.

When an interface feels slow, follow the rendering path. Ask whether the change triggers style calculation, layout, paint, or compositing. Record one interaction, disable one rule, and repeat the test.

That process will tell you far more than a generic list of “fast” and “slow” CSS properties, and it allows you to keep the visual details that genuinely improve the experience.