Fix INP in Elementor: Settings, Widgets and Scripts That Matter

Why do Elementor sites fail INP?

Elementor INP problems are rarely caused by Elementor alone. They are caused by everything that has to run when a visitor interacts with an Elementor page: the builder’s scripts, the widgets on that page, third-party widgets, icon fonts, and the work needed to update a large, nested DOM. Interaction to Next Paint, or INP, is good at 200ms or less at the 75th percentile, as explained in the INP on WordPress guide. When a click, tap, or key press has to wait behind a long JavaScript task, the browser cannot paint the next frame promptly, and the interaction feels slow even if the page loaded quickly. That is why an Elementor INP fix starts with the traced interaction, not with a global setting.

For background, see Google’s Interaction to Next Paint guide.

Start with the interaction, not with a setting. A slow menu, tab, accordion, popup, form, or slider is a symptom. The cause is usually one of these: too much JavaScript loading and running on the page, a long task triggered by the interaction itself, a large DOM update, or a third-party script that competes for the main thread at exactly the wrong moment. That is also why a caching plugin alone does not fix INP. Caching helps loading; it does not make a busy main thread free.

How to find the slow interaction with DevTools

Use Chrome DevTools on a staging copy, with the same page and the same interaction a visitor would use. Open the Performance panel, start a recording, repeat the slow interaction once, then stop the recording. Look for the interaction in the trace, then look at the long tasks, event handlers, style and layout work, and script names underneath it. The trace should tell you which component is responsible: an Elementor widget script, a third-party widget, a form handler, a popup script, or a script that was never needed for that interaction at all.

Change one thing at a time and repeat the same interaction. If you disable five things at once, you will not know which change mattered. For a wider view of what is slow on the page, the Query Monitor tutorial shows how to inspect what WordPress is actually doing behind a page. And for measurement tools in general, see the best WordPress speed test tools. Results must be measured on your own site with field data; do not rely on a single lab run or on a number quoted for somebody else’s site.

Which Elementor experiments help?

On an Elementor site, open Elementor, then Settings, then Features, and review the performance-related features available in your installed version. The names below are the ones to look for, but do not assume every switch is still present. Recent Elementor releases have made some of these features permanent and removed their switch, so if a switch is missing it is already in core. Check your installed version, enable only what your version still offers as an option, and test after each change.

• Inline Font Icons: loads icons as inline SVG instead of an icon font file, which can reduce font-related work and unused icon assets on pages that use only a few icons.
• Improved CSS Loading: loads widget CSS in a more targeted way, rather than loading styles for widgets that are not on the page.
• Improved Asset Loading: reduces the JavaScript and CSS loaded by Elementor on pages where a feature is not used, so interactions compete with less background work.
• Optimized DOM Output: reduces wrapper elements in Elementor markup, which helps keep the DOM smaller and DOM updates cheaper.
• Flexbox Container: replaces the older section and column structure with a more flexible container layout, with fewer nested wrappers when a page is built that way from the start.
• Grid Container: adds a grid-based container layout, useful for structured layouts that would otherwise need several nested sections and columns.
• Lazy Load Background Images: defers background images that are not needed immediately, so the browser has less competing work during initial load and early interactions.

These features are worth turning on where your version still offers them, but they are not a substitute for removing heavy widgets. An optimized DOM still suffers if a single interaction triggers a large re-render, and leaner CSS still suffers if a third-party widget runs a long task on every click. Treat the features as the foundation, then fix the specific interaction the trace points to.

Which widgets add the most JS?

Widgets that animate, listen, validate, or re-render content are the usual suspects. Sliders and carousels initialise on load, keep timers and touch handlers running, and update slides, captions, and navigation on every change. Forms validate input, handle conditional fields, and submit or display messages, all inside the interaction. Popups load content, trap focus, animate in, and often load extra scripts even when the popup is only shown after a click. Third-party widgets are a particular risk because they can add their own libraries, fonts, and tracking on top of Elementor’s own code, and they are easy to add to many pages without noticing the cost.

Tabs, accordions, toggles, galleries, and animated headings are not automatically bad, but they become a problem when they are stacked on one page, when every instance loads its script whether it is used or not, or when an interaction forces a large part of the page to re-render. Ask a simple question for each widget: does this page need it, does this interaction need it, and what happens if it is removed or replaced with a lighter native alternative?

DOM bloat: sections and columns versus containers

Older Elementor pages built with sections, columns, and inner sections can produce deep, nested markup. Every extra wrapper is another node the browser must style, lay out, and update, and a single interaction can become more expensive when it has to walk or repaint a large tree. Containers, used well, flatten that structure. They do not automatically fix a page that was built with heavy widgets, and converting a complex page is not a one-click job, so prioritise the pages with the worst interactions first and rebuild or simplify those layouts rather than converting everything at once.

Icon fonts and Google Fonts

Icon fonts load a whole font file even when a page uses a handful of icons, and Google Fonts add extra requests, stylesheets, and font files that compete with the interaction path. Keep the icon set lean, use inline SVG icons where that is practical, limit Google Fonts to the families and weights actually used, and avoid loading several display fonts for decoration. A lean font setup will not by itself fix a long JavaScript task, but it removes unnecessary work from pages where INP is already tight. The choice of theme matters here too: a lightweight base means less to fight against, which is why the best WordPress themes and fastest lightweight WordPress themes guides are worth reading before rebuilding a heavy Elementor layout.

Fixes ranked by impact

Work in this order, and measure after each step on your own site with field data:

1. Fix the traced interaction first. Reduce the work inside the click handler, split long tasks, and give immediate visual feedback before slow work runs.
2. Remove or replace the heaviest widgets on the worst pages. Sliders, popups, forms, and third-party widgets come first when the trace points to them.
3. Enable the Elementor performance features your version still offers. If a switch is missing, it is already in core; move on instead of chasing it.
4. Flatten the DOM on the worst pages. Simplify nested sections and columns, and use containers for new layouts.
5. Cut icon and font weight. Use inline SVG icons where practical and keep Google Fonts to what the design actually uses.
6. Delay third-party scripts that are not needed for the interaction. Chat, tracking, and marketing scripts should not compete with a menu, form, or popup click. If delaying a script breaks the feature, that script needs a different loading strategy, not a blind delay.

Be sceptical of broad claims about Core Web Vitals and page builders. The Core Web Vitals 2026 myth-bust is a useful check against rumours that promise a single setting will fix every site. INP is measured from real user interactions, so the only reliable proof is your own field data after a change, over a proper reporting window.

Common Questions

Frequently Asked Questions

Clear, honest answers about Elementor INP, widgets, experiments, and DOM weight.