When a business owner tells us “Elementor is slow” or “Elementor keeps breaking”, we open the editor and almost always find the same handful of build problems. The tool is rarely the issue. The way the site was put together usually is.
We build every WordPress site in Elementor, so we’re not neutral. But we also take over a steady stream of Elementor sites built by other people, and these are the faults we fix again and again. If you’re comparing builders before you commit, our Elementor vs Gutenberg comparison covers the broader trade-offs.
Before you change anything below, make a copy of the site to work on. A staging site is the right place for this kind of clean-up.
1. Containers inside containers inside containers
What we find: a simple section with a heading, a paragraph and a button, wrapped in five or six layers of containers (or old-style sections, inner sections and columns). Often each layer has its own padding, so changing the spacing means hunting through every level to work out which one is responsible.
Why it hurts: every layer is extra HTML the browser has to build and lay out. On a long page it adds up, and it makes the site painful to edit. Mobile layouts get especially fragile because a setting on layer three overrides the one on layer five.
The fix: rebuild the worst sections with flat containers using flexbox or grid. A typical “image beside text” block needs one parent container and two children, not six. If the site still uses sections and columns, convert gradually, starting with the homepage and your top landing pages. Don’t try to convert the whole site in an afternoon.
A quick test: open the Navigator panel on your homepage. If you have to scroll through dozens of nested items to find one button, that page needs work.
2. Styling every widget by hand instead of using globals
What we find: forty slightly different blues. Headings set to 34px on one page, 36px on another, 2.2em on a third. Global Colours and Global Fonts either empty or ignored.
Why it hurts: you can’t rebrand, tweak or even fix a contrast problem without editing every page. Inline styles applied directly to a widget override the global settings, so changing the global does nothing on those widgets and the owner concludes the site is broken.
The fix: set up a proper palette and type scale in Site Settings (primary, secondary, text, accent, plus a couple of neutrals; H1 to H6 and body sizes). Then work through the site and reset widgets back to the globals. On a 20 page site this is a solid day’s work, and it pays for itself the first time anyone wants a change.
When you open a widget, a style that’s linked to a global shows the global’s name. A raw hex value or a hand-typed size means it’s been overridden.
3. Images uploaded straight from the camera
What we find: a 6000px wide, 8MB hero photo, displayed at 1400px. Team photos at 4MB each. A logo saved as a huge PNG with a transparent background.
Why it hurts: this is the single most common reason a small business site is slow on mobile data. And there’s plenty of patchy mobile coverage once you’re out past the main towns, in the hinterland behind Byron or up the valleys past Kyogle.
The fix: resize before uploading. For a full-width hero, around 1920px wide is plenty; for content images, 1200px or less. Export as WebP or a well-compressed JPG. Use SVG for logos and icons where you can. Then run an image optimisation plugin over the existing library to catch what’s already there. Elementor’s own image widget has a size setting, so pick a sensible size there too instead of “Full”. Run the page through PageSpeed Insights before and after, and the image warnings should drop off the list.
4. Add-on packs installed for one widget
What we find: three or four Elementor add-on plugins, each with 50 to 100 widgets, installed because someone wanted a single fancy accordion or a timeline. Sometimes two packs that do the same thing.
Why it hurts: every add-on loads its own scripts and styles, often on every page whether the widget is used or not. They add update risk, because each one has to stay compatible with each Elementor release. And when a developer abandons a pack, every page using its widgets is stuck.
The fix: list every add-on widget actually in use. (Most add-ons have a widget manager or usage screen; failing that, search the page content.) Replace what you can with Elementor’s native widgets, many of which have caught up since those packs were installed. Remove the rest of the pack. Where you genuinely need an add-on, keep one, turn off the widgets you don’t use in its settings, and use Elementor’s Element Manager to hide native widgets you’ll never use so the panel is tidier for whoever edits next.
5. Headings chosen for size, not structure
What we find: the logo set as an H1 on every page, then three more H1s in the hero. Section labels like “Welcome” and “Our services” as H2s with the real content as plain paragraphs. Footer column titles as H2s. Or every heading set to H2 because that was the size the designer wanted.
Why it hurts: screen readers use headings to navigate, so a muddled structure makes the page hard to use for people who rely on them. Search engines use headings to understand what a page is about. A page where the only H1 is “Welcome” says very little.
The fix: each page gets one H1 that says what the page is (“Electrical services in Ballina”, not “Welcome”). Sections are H2s, sub-points are H3s. Use the Heading widget’s HTML Tag setting to set the level, and the typography settings to set the size. Those two things are separate for a reason. Small decorative labels above headings (“WHAT WE DO”) should be a paragraph or a span, not a heading.
6. Mobile left on autopilot
What we find: the desktop layout looks great. On a phone the hero text is 64px and wraps into seven lines, the padding is 120px top and bottom, and the “Call us” button is below three screens of scrolling.
The fix: switch to the mobile view in the editor and go through every section. Reduce heading sizes and padding for tablet and mobile, check column stacking order, and make sure the phone number and main call to action are near the top. Fix sizes at the global level first, then deal with individual exceptions.
7. Theme Builder conditions that conflict
What we find: two header templates both set to “Entire Site”, or a single post template that applies to pages as well. The owner edits one header and nothing changes because the other one wins.
The fix: open Theme Builder and review the display conditions for every template. Delete unused templates instead of leaving them in draft. One header per condition, named clearly (“Header: main”, “Header: landing pages”).
8. Updating everything on the live site at once
What we find: a site that broke after someone clicked “update all” on WordPress, Elementor, Elementor Pro, three add-ons and the theme in one go, with no recent backup.
The fix: take a backup, update in a sensible order, and check the site between steps. Better still, test on staging first, or put the site on a care plan where someone else runs the updates and checks. Staging is the slowest option and the only one where a bad update doesn’t cost you a day of enquiries.
Where to start
If your site has several of these, don’t try to fix everything at once. Our usual order is images first (fast, safe, biggest speed gain), then globals, then headings, then nesting on your top pages, then add-on clean-up. Each step makes the next one easier.
Not sure which of the eight your site suffers from? A second pair of eyes on the build is a quick WordPress and Elementor fix job, so send us the address. And if a clean rebuild turns out cheaper than the repairs, that’s the kind of Elementor web design work we do every week.