If you’ve worked with modern front-end frameworks like React, Vue, or plain JavaScript and used the ResizeObserver API, you might have come across the console warning:
“ResizeObserver loop completed with undelivered notifications”
At first glance, this message can be confusing — it sounds like something is broken. But in most cases, it’s not an actual error that breaks your application. Still, understanding why it happens and how to handle it properly is important, especially if you’re building responsive, dynamic interfaces that rely on element resizing.
Let’s break this down in a practical, human way.
What is ResizeObserver?
ResizeObserver is a browser API that allows you to monitor changes to the size of an HTML element. It’s a modern and efficient alternative to older techniques like window.onresize or polling element sizes manually.
For example:
const box = document.querySelector(‘.box’);
const observer = new ResizeObserver(entries => {
for (let entry of entries) {
console.log(‘Size changed:’, entry.contentRect);
}
});
observer.observe(box);
Whenever the .box element’s dimensions change, the callback is triggered with the new size information.
This makes ResizeObserver a powerful tool for responsive layouts, dynamic components, and custom UI behaviors.
So, Why Does the Warning Appear?
The warning “ResizeObserver loop completed with undelivered notifications” usually shows up when the resize callback triggers additional layout changes inside itself.
Here’s what happens under the hood:
- The browser detects a resize event and notifies your ResizeObserver callback.
- Inside the callback, your code might modify the DOM — for example, changing an element’s size or position.
- Those changes cause another resize to be detected.
- But because the browser is still processing the first notification loop, it defers the new one.
Eventually, the browser realizes that some notifications were not delivered during the current cycle — hence the warning.
It’s essentially saying:
“You’ve modified layout properties while processing resize notifications, so I couldn’t deliver all of them in one go.”
It’s not fatal, but it’s a signal that your ResizeObserver callback may be doing too much work or triggering layout thrashing.
Common Scenarios Where This Happens
Here are some real-world examples of when this warning typically appears:
1. React Components Measuring Themselves
Many React developers use ResizeObserver to measure component sizes and trigger re-renders. However, re-rendering within a resize callback can cause the layout to update again immediately — creating a feedback loop.
2. Animations or Transitions on Resize
If you use CSS transitions or JavaScript animations triggered by resize events, the DOM may be changing continuously while ResizeObserver is firing, leading to repeated layout recalculations.
3. Nested Observers or Dynamic Layouts
In complex UIs (e.g., grids, carousels, dashboards), one element’s resize may affect another. If both are being observed, they can trigger each other’s callbacks during the same cycle.
How to Fix or Avoid the Warning
While you can’t fully “turn off” the warning (it’s from the browser, not your code), there are a few strategies to prevent it.
1. Debounce or Throttle Your Resize Logic
Instead of reacting immediately to every resize notification, delay your logic slightly using requestAnimationFrame, setTimeout, or a debounce function.
Example:
const observer = new ResizeObserver(entries => {
requestAnimationFrame(() => {
for (let entry of entries) {
// Safe to update DOM here
updateLayout(entry.contentRect);
}
});
});
Using requestAnimationFrame lets the browser finish its layout updates before you modify anything again, breaking the potential feedback loop.
2. Avoid Mutating Layout Inside the Observer
Whenever possible, use the ResizeObserver to read element sizes, not to change them.
For instance, store the new dimensions in state or a variable, and perform any updates later in your app’s lifecycle (e.g., in a React effect, after rendering).
3. Handle Resize Observations Separately
If multiple elements depend on each other’s sizes, separate their ResizeObservers so they don’t trigger one another’s updates during the same cycle.
You can also batch updates manually:
const resizeQueue = [];
const observer = new ResizeObserver(entries => {
resizeQueue.push(…entries);
requestAnimationFrame(() => {
for (const entry of resizeQueue) {
processResize(entry);
}
resizeQueue.length = 0;
});
});
This approach ensures that all resize notifications are processed safely after the browser’s layout phase.
4. Catch It Gracefully (If Necessary)
If you just want to hide the warning (for example, in a production environment where it’s not helpful to end users), you can wrap your observer logic in a try-catch block.
However, this is not recommended as a primary fix. The warning indicates an underlying layout behavior that’s better addressed by improving your resize handling logic.
Does It Affect Performance?
In small applications, probably not much. But in large-scale interfaces — like dashboards, editors, or data-heavy UIs — frequent resize loops can degrade performance.
Every time the layout is recalculated, the browser must recompute styles, repaint, and sometimes reflow the entire document. When that happens repeatedly in a tight loop, your app can become sluggish.
That’s why paying attention to these warnings matters: not because they’re fatal, but because they point to potential performance bottlenecks.
Best Practices When Using ResizeObserver
Here are some reliable guidelines to use ResizeObserver effectively and avoid unnecessary issues:
- Keep your callback lightweight. Only read layout properties or update cached values. Avoid DOM writes inside it.
- Debounce DOM updates. Use requestAnimationFrame or a short delay before applying layout changes.
- Batch observations. If multiple elements depend on similar data, handle their resize notifications together.
- Disconnect observers when not needed. Always call observer.disconnect() when components unmount or when observing is no longer necessary.
- Avoid circular dependencies. Make sure that layout changes caused by one observer don’t trigger others recursively.
Following these best practices ensures that ResizeObserver works predictably and that your interface remains performant.
Final Thoughts
The “ResizeObserver loop completed with undelivered notifications” message isn’t an error to fear — it’s a warning that helps you write more efficient and stable code.
At its core, this message reminds developers that the DOM’s layout cycle and resize notifications are asynchronous processes. When we interfere with those cycles by modifying layout properties inside an observer callback, the browser delays notifications and shows this message to keep things consistent.
Understanding how and when ResizeObserver fires allows you to structure your UI updates more cleanly — avoiding unnecessary loops, improving performance, and keeping the console clean.
If you treat this message as a helpful signal rather than a problem, it can guide you toward writing better, more maintainable front-end code.