Free Elementor Website Health Check
Paste the address of any Elementor page and this reads what the builder actually output: how many sections and widgets it took to make, how much CSS was generated, which performance settings are switched on, and what all of that weighs. If the page is not built with Elementor, the report says so and nothing here counts against it.
What this checks
Elementor detection: whether the page is built with Elementor at all, which version, and whether Pro is loading on the front end.
CSS print method: whether Elementor is serving styles as cacheable external files or writing the whole lot into every page.
Generated stylesheets: how many separate Elementor CSS files the page pulls in, and what they weigh between them.
Performance features: which of Improved CSS Loading, Improved Asset Loading, inline SVG icons, and background lazy loading are switched on.
Containers or sections: whether the page uses flexbox containers or the older section, column, and inner-section structure.
Widget count and variety: how many widgets render on the page and how many distinct widget types it takes, since each type ships its own styles.
Expensive widgets: carousels, loop grids, animated headlines, and other widgets that cost far more than they look.
Wrapper bloat: total elements on the page versus widgets on screen, which is an honest measure of how deeply things are nested.
Fonts, icons, and animations: Google Font families requested, icon libraries loaded, and how much of the page starts invisible, waiting to animate in.
What it all costs: server response time, document size, request count, render-blocking files, and the measured weight of your images.
What a healthy Elementor build looks like
A well-built Elementor page and a badly built one look identical to the person who commissioned them. The difference is in the markup, and it is enormous. Two pages showing the same six sections can differ by 300KB of CSS, 2,000 DOM elements and two seconds on a phone, entirely because of choices made in the editor that nobody was ever asked about.
The healthy version has a shape you learn to recognise. Styles arrive as external files the browser caches once for the whole site. Layout is containers rather than towers of nested columns. Widget types number in the teens rather than the forties. Icons are inline SVG instead of an entire icon font, and the kit asks for two font families rather than seven because the theme is quietly loading its own.
This report measures each of those from the page itself, so the conversation stops being about taste and starts being about numbers. "It feels slow" is hard to act on. "Your CSS is 380KB inline, you have 4,900 elements rendering 62 widgets, and you are loading two icon fonts" is a to-do list.
The settings that make the biggest difference
Before anyone touches a single page, go through Elementor's own settings. This costs nothing, takes ten minutes, and on a neglected site is worth more than a week of tidying layouts. Every one of these lives in the WordPress admin under Elementor. The most important is the CSS Print Method at Elementor → Settings → Advanced. Set it to "External File". On "Internal Embedding", Elementor writes the entire page's styles into the HTML document, so none of it is cacheable and every visitor downloads all of it again on every page they open. Switching to External File and clearing the cache is a one-click change and the safest speed win on the whole build. Then Elementor → Settings → Features, where the experiments live. Improved CSS Loading serves each widget's styles only on pages that use that widget, instead of shipping the rules for every widget Elementor owns. Optimized DOM Output strips a layer of the wrapper markup the builder generates. Improved Asset Loading stops Swiper loading on pages with no carousel and the dialog library loading where there is no popup. Inline Font Icons turns icons into SVG. Turn them on one at a time, clear the cache, and check a template-heavy page after each — these change when assets load, so a site with unusual custom code deserves the caution. While you are in there, look at the widget list under Features and switch off everything the site does not use. A site that has never used a Lottie animation, a reviews widget or an NFT widget is still registering all of them. Turning them off shortens the editor panel and cuts what Elementor has to consider on every page load.
- Elementor → Settings → Advanced → CSS Print Method: External File.
- Elementor → Settings → Features: Improved CSS Loading on.
- Elementor → Settings → Features: Optimized DOM Output on.
- Elementor → Settings → Features: Improved Asset Loading on.
- Elementor → Settings → Features: Inline Font Icons (SVG) on.
- Elementor → Settings → Features: switch off every widget the site never uses.
- Clear the page cache afterwards, and regenerate the Elementor CSS from Tools → Regenerate CSS & Data.
Containers, not sections — and not four levels of columns
The old Elementor structure was section, then column, then widget, with inner sections when you needed to nest. It worked, and it produced a great deal of markup: every layout decision was another wrapper. Flexbox Containers replaced all of it with one element that does the job of three, and the difference on a real page is usually somewhere between a third and half the DOM gone.
This report tells you which structure the page uses. If it is still sections, build everything new with containers — the switch is at Elementor → Settings → Features → Flexbox Container. Do not convert the whole site in one sitting. Converting an existing page is a rebuild of that page rather than a toggle, so the sane approach is to do it when a page is next redesigned anyway.
The deeper problem is nesting, and it is a habit rather than a setting. Somebody wants a button in the middle of a section, so they add an inner section, then a column, then another inner section to get the padding right, then a column inside that for the button. Four levels of wrapper to centre one element. The browser has to build, style and lay out every one of them, on every visit, on a phone. Alignment settings on the parent container do the same job with none of the elements, and once you have seen the elements-per-widget figure in this report you will not build it the other way again.
Fonts, icons and animations: the three quiet costs
Fonts first, because it is the most common and the least visible. Elementor has Global Fonts under Site Settings, and most themes have their own typography settings too. Set the fonts in one place and forget the other, and the site loads both stacks — your two chosen families from the kit, plus whatever the theme was shipped with, none of which appears on screen. Seven font families where two would do, all on the critical path. Set every typeface in Elementor → Site Settings → Global Fonts, make sure the theme is not also loading its own, and then consider self-hosting them and setting Google Fonts to "Disabled" under Elementor → Settings → Advanced.
Icons next. Out of the box, drawing six little tick marks pulls in the whole of Font Awesome — a stylesheet plus font files, render-blocking, downloaded in full whether the page uses six glyphs or six hundred. Inline Font Icons under Elementor → Settings → Features writes each icon as an SVG directly into the markup and stops loading the font entirely. For a page with a handful of icons that is pure saving with no visual difference at all. Watch for a second library arriving from the theme, because two icon fonts for the same twelve icons is a thing we find weekly.
Animations last. Entrance animations are the ones set under Advanced → Motion Effects on a widget, and they work by hiding the element until it scrolls into view. That means the content is deliberately unreadable until the browser decides to reveal it, the layout moves while somebody is reading, and the page feels like it is still loading long after it has finished. Strip them from anything above the fold and from body copy. If you want them at all, keep them for one or two deliberate moments well down the page.
What this health check cannot see
Everything here is read from the public front end of one page. The tool does not log into your WordPress admin, so it cannot list your plugins, read your Elementor settings screen directly or see anything in the editor. What it reports about your settings is inferred from what the output looks like — if the CSS is inline, the print method is Internal Embedding; if widget styles arrive per widget, Improved CSS Loading is on. That inference is reliable, but it is inference.
It does not run JavaScript, so widgets that build themselves in the browser are invisible to it, and it cannot tell you which CSS rules the browser ends up applying — only how many arrive. The unused-CSS finding is an indicator built from the ratio of styles sent to widget types present, and the report says as much rather than dressing it up as a measurement. It also cannot measure Core Web Vitals, because those happen on a device it is not on.
And it cannot tell you whether the page is any good. Whether the offer is clear, whether the layout leads anywhere, whether the copy is worth reading — that needs a person. This finds the mechanical faults in the build, which is the part that is objectively true and the part most people never get a straight answer about.
Questions people ask
Is Elementor slow?
Elementor adds overhead. That is honest, and it is unavoidable: any visual builder generates wrapper markup and CSS that a hand-coded page would not have, and an Elementor page will never be quite as light as the same page built in a good block theme.
But almost every slow Elementor site we look at is slow because of how it was built, not because of Elementor. The CSS print method was left on Internal Embedding. The layout is five levels of nested columns. Two icon fonts and six font families are loading. Twelve of the widgets are carousels. None of that is the plugin's doing, and all of it is fixable without leaving Elementor. A disciplined Elementor build on decent hosting loads perfectly well.
Should I move off Elementor?
Usually not, and certainly not as a first move. Migrating off a builder means rebuilding every page, and a rebuild costs far more than turning on four settings and flattening the worst layouts. Do the cheap work first and measure again.
The case for moving is worth making when you are redesigning anyway, when nobody on the team needs a visual editor, or when the site is large enough that the per-page overhead is genuinely the bottleneck after everything else has been fixed. Moving because a forum said Elementor is bloated, on a site whose real problem is a 5MB hero image, is an expensive way to not solve anything.
What is a good widget count for one page?
There is no hard limit, but a normal service or landing page lands somewhere between 30 and 70 widgets across maybe 15 to 20 widget types. Past roughly 120 widgets, you are usually looking at a page that repeats itself, and past about 30 distinct widget types, you are shipping the styles for far more of Elementor than you are using.
Variety costs more than volume. Forty instances of the same heading widget are cheaper than forty different widget types, because each type brings its own rules. If two widgets draw the same card in slightly different ways, standardise on one, and you cut the CSS without changing the design.
What is the CSS Print Method and which one should I use?
It is the setting at Elementor → Settings → Advanced that decides where your generated styles go. "Internal Embedding" writes them into the HTML of every page, so nothing can be cached and every visitor downloads the lot on every page view. "External File" writes them to cacheable CSS files fetched once and reused across the site.
Use External File. There is essentially no case for the other one on a live site, and the switch takes one click plus a cache clear. If the report says your CSS is inline, this is the first thing to change.
Will turning on the Elementor experiments break my site?
Rarely, but it is worth doing carefully rather than all at once. Improved CSS Loading and Improved Asset Loading change when styles and scripts load, which can expose a third-party add-on that was relying on Elementor loading everything everywhere. Turn one on, clear the cache, then check a page with a carousel, a page with a popup, and a theme-builder template.
If something looks wrong, switch that one experiment back off, and the site is exactly as it was. Take a backup first, as with any change, and do it on a quiet afternoon rather than the morning of a campaign.
Is this Elementor health check free?
Yes. There is no account, no card, and nothing to install on your site. A fair-use limit stops the tool from being run as a bulk scanning service, and that is the only restriction on it.
Do I have to give you my email address?
Not for the score, the category breakdown or the first fixes. The rest of the fix list asks for an email, which is how the tool pays for itself. You are asked once, and never again on the same browser.
Does this change anything in my Elementor site?
No. It requests your page the way a visitor does and reads the markup that comes back. It never logs into WordPress, never opens the editor, never touches your settings and never writes anything. Nothing in your Elementor build is altered by running it.
Want your Elementor site rebuilt properly rather than replaced?
We spend most weeks inside Elementor builds: flattening nested sections, moving to containers, getting the CSS out of the document and the icon fonts off the page. Send us the address and we will tell you whether it is a settings afternoon or a rebuild, and what each would cost.
