TL;DR
Non-composited animations create a slow, stuttering user experience by forcing the browser into a cycle of inefficient work, which frustrates users and hurts key business metrics. To fix this, you should replace inefficient CSS properties like width or left with the high-performance transform and opacity properties, which allow for smooth animations that don’t bog down the website.
Your users aren’t impatient. They are frustrated.
Frustrated by interacting with a website that feels laggy and stuttering.
That’s why you see higher bounce rates and rage clicks. And that’s why you see the “Avoid non-composited animations” warning in your PageSpeed Insights report.
But what exactly are non-composited animations, and how can they impact your site’s performance so much? In the following lines, you will learn all of that and how to fix them.
Let’s dive in.
Test NitroPack yourself
What Are Non-Composited Animations?
Simply put, a non-composited animation is an inefficient animation that forces a web browser to do an excessive amount of work, resulting in a slow, stuttering, and “janky” experience for the user.
Imagine you are an artist creating a cartoon of a bird flying across a landscape.
A non-composited animation is like having to redraw the entire scene, the bird, the clouds, the mountains, everything, for every single frame of the bird’s movement. Because you have to recalculate and repaint everything from scratch each time, the process is incredibly slow and labor-intensive. If you can’t draw fast enough, the bird’s movement will look choppy and unnatural.
This is what happens when a website uses inefficient CSS properties for animations, like changing width, height, margin, or top. The browser is forced to “redraw the entire scene” constantly, which slows everything down.
An alternative method would be to draw the landscape on one sheet of paper and the bird on a separate, clear piece of plastic that you can lay on top.
This is a composited animation. To make the bird fly, you don’t have to redraw anything. You simply slide the clear plastic sheet with the bird on it across the background. The movement is effortless, fast, and perfectly smooth.
This is the efficient method, which uses properties like transform and opacity, but more on that later.
Now, let’s dive a little deeper into how non-composited animations affect your site’s performance.
The Negative Impact of Non-Composited Animation on Your Performance and Business
The “Avoid non-composited animations” warning is more than just a technical suggestion. It’s a direct alert that a specific element on your page is creating a performance bottleneck.
The bad news is that this bottleneck has a cascading effect, hurting your:
- Performance scores
- Frustrating your users
- Damaging your business goals.
Here’s how:
Blocking the browser’s main thread
To understand the problem, you need to know how a browser turns code into the interactive webpage a visitor sees.
The central actor in this process is the browser’s main thread.
Think of it as the single, primary worker responsible for every critical task, including parsing code, executing all the JavaScript that makes a site dynamic, and responding to every user interaction like a click or a scroll.
When the main thread needs to visually construct or update the page, it runs a sequence called the rendering pipeline. This involves three key steps:
- Layout: Calculating the size and position of all page elements.
- Paint: Drawing the pixels, colors, and text for those elements.
- Composite: Assembling all the finished visual layers onto the screen.
This is where a non-composited animation becomes a major performance bottleneck.
When an animation uses inefficient CSS properties like margin or width, it forces the main thread to run through that entire, labor-intensive pipeline for every single frame of the animation.
The main thread gets stuck in an endless and demanding cycle of “recalculate layout, repaint everything, repeat,” preventing it from performing its other critical duties.
The result is an unresponsive interface where clicks and scrolls are ignored, causing the stuttering “jank” that makes a site feel broken and unprofessional.
Which leads to the next issue…
Poor performance metrics and Core Web Vitals
Using performance testing tools like PageSpeed Insights and GTmetrics, you can actually measure this constant main thread blockage. Apart from getting some warnings, you will see a drop in the following performance metrics:
- Interaction to Next Paint (INP): This Core Web Vital measures your site’s responsiveness to user interactions. Because a non-composited animation monopolizes the main thread, the browser is delayed in processing a user’s click or keypress. This delay results in a poor INP score, signaling to performance tools that your page is frustratingly slow to react.
- Cumulative Layout Shift (CLS): CLS measures visual stability. Non-composited animations often change an element’s geometry or position (like animating width or margin), which can cause other content on the page to shift unexpectedly. This jarring movement is precisely what the CLS metric is designed to penalize, leading to a lower score and a worse user experience.
- Total Blocking Time (TBT): TBT is a direct measurement of how long the main thread was blocked, preventing user input from being handled. Since non-composited animations fill the main thread with long, unavoidable rendering tasks, they are a primary cause of high TBT. A high TBT is a clear indicator that your site’s interactivity is being compromised.
But while we all strive for excellent performance metrics, failing them isn’t the worst part.
There’s a much higher cost of offering laggy experience…
Frustrated users and lost business
You only get one chance to make a good first impression. When a user’s first interaction with your site is met with lag, the damage is immediate:
- Higher Bounce Rates: Many users won’t tolerate this friction. If the page feels unresponsive, they will simply give up and leave (bounce) before your content or products have a chance to load.
- Rage Clicks and Frustration: As we discussed, a blocked main thread leads directly to user frustration, which can be measured in analytics as “rage clicks.” A frustrated user is not going to convert, sign up, or return to your site in the future.
- Lost Sales: Laggy experience means untrustworthy. And when they can’t trust your business, they won’t buy from you.
Ultimately, the technical issue of a non-composited animation translates directly into a business problem: a poor user experience that costs you traffic, leads, and sales.
But you can turn things around and fix it. Here’s how…
How to Fix The “Avoid Non-Composited Animations” Warning in WordPress
Fixing this warning involves changing the CSS properties you use to create animations. Instead of using properties that force the browser to recalculate the layout and repaint the screen, you will use properties that are handled efficiently by the computer’s graphics processor (GPU).
Stick to compositor-only properties (transform and opacity)
The most effective way to avoid non-composited animations is to only animate two specific CSS properties: transform and opacity.
- The
transformproperty lets you modify the coordinate space of an element to move, rotate, or scale it without affecting the layout of other elements. It uses functions liketranslateX()to move an element horizontally,scale()to resize it, androtate()to turn it. - The
opacityproperty controls the transparency of an element. It accepts a value from 0 (completely transparent) to 1 (completely opaque).
Because these two properties don’t interfere with the geometry of other elements, they can be handled efficiently by the computer’s graphics processor (GPU), which prevents them from blocking the main thread. This results in perfectly smooth animations that don’t cause “jank.”
Let’s look at a practical example of animating a box to slide in from the side.
❌ Don’t: Animate layout properties like left
This code animates the left property, which forces the browser to recalculate the layout for every frame, leading to poor performance.
.box {
position: relative;
left: -100%;
animation: slide-in-bad 1s forwards;
}
@keyframes slide-in-bad {
100% {
left: 0;
}
} ✅ Do: Animate the transform property
This code achieves the exact same visual effect by animating transform. This is highly efficient and will not block the main thread.
.box {
transform: translateX(-100%);
animation: slide-in-good 1s forwards;
}
@keyframes slide-in-good {
100% {
transform: translateX(0);
}
} And here’s a quick reference for which properties to use for common animations:
| Animation Goal | ❌ Don’t Use (Inefficient) | ✅ Do Use (Efficient) |
|---|---|---|
| Move an Element | top, right, bottom, left, margin | transform: translate(x, y); |
| Resize an Element | width, height, padding | transform: scale(n); |
| Rotate an Element | (No direct inefficient property) | transform: rotate(ndeg); |
| Fade In/Out | (No direct inefficient property) | opacity: 0...1;Export to Sheets |
Give the browser a heads-up with will-change
For animations that might still be a bit choppy, you can give the browser a performance hint using the will-change CSS property.
This property tells the browser which properties you intend to animate on an element. By knowing this in advance, the browser can perform optimizations, such as promoting the element to its own compositor layer, so that its animation doesn’t affect the rest of the page.
Here is how you would apply it to an element you plan to animate:
.animated-element {
/* This tells the browser to get ready to animate transform and opacity */
will-change: transform, opacity;
} Important Caveat: Don’t Overuse will-change
While will-change is a powerful optimization, it should be used sparingly. Promoting an element to a new layer consumes system memory. Applying this property to too many elements can actually slow your site down, especially on devices with limited memory.
Best Practice
will-change to elements that have complex animations or are causing noticeable performance issues. Do not apply it to every element on your page.
Frequently Asked Questions
Where do I find this CSS code in my WordPress site?
The animation CSS is typically located in one of three places. Start looking in this order:
- Your Theme’s Settings or Stylesheet: Many themes include built-in animations. Check your theme’s options first. If you can’t find a setting, the code is in the theme’s main stylesheet (style.css).
- A Plugin’s Stylesheet: If the animation is part of a slider, a gallery, or another special feature, the code is likely coming from the plugin that creates it.
- Your Page Builder: If you use a page builder like Elementor or Divi, you likely added the animation in the element’s “Advanced” or “Animation” settings.
If the code is in your theme or a plugin’s stylesheet, the best way to change it is to override it by adding the corrected code to the “Additional CSS” section in the WordPress Customizer (Appearance > Customize > Additional CSS).
How do I identify which specific element is causing the warning?
Performance tools like PageSpeed Insights will often show you the CSS selector of the problematic element (e.g., .hero-banner .slide-in). To find this on your site:
- Open your webpage in the Chrome browser.
- Right-click anywhere on the page and select “Inspect” to open the Chrome DevTools.
- Press Ctrl + F (on Windows) or Cmd + F (on Mac) to open a search bar within the code panel.
- Paste the selector from your performance report into the search bar.
- As you search, the browser will highlight the corresponding HTML element in the code. Hovering over that line of code will highlight the visual element on your webpage. Now you know exactly which banner, image, or section is causing the issue.
What if my theme or a plugin is causing the animation? Can I fix it without coding?
Your first step should be to check its settings for an option to disable or change the effect, as many page builders allow you to switch from an inefficient animation like “Slide In” to an efficient one like “Fade In.” If no such setting exists, you can do this by identifying the element’s CSS selector using your browser’s inspect tool and then adding the corrected CSS—using efficient transform and opacity properties.
Is it safe to add will-change in the WordPress Customizer’s “Additional CSS” field?
Yes, it is completely safe. The “Additional CSS” field in the Customizer is the recommended place for all users to add custom CSS snippets like this. It will not break your site, and the changes will be preserved even when you update your themes and plugins.