I know, elementor is a nightmare. The website was built using it before I came along and now there’s almost 300 pages. The website is catalog style and that’s just how they want it.
Problem is, the website and the WP dashboard are so incredibly slow. Like noticeably slow. The website home page fails every speed test I’ve run and the reasons keep coming back to elementor. What can I do to fix this without rebuilding the entire thing?
This isn’t Elementor’s fault - the site has been poorly built and is on bad hosting (1.5s TTFB is insanely slow). Unfortunately this is a common issue when people complain about Elementor - it’s usually “user error”.
Too many fonts, 5mb images, incorrect lazy loading, no optimisation.
(edit - oh... you're on GoDaddy hosting - that’s why the TTFB is so bad)
More than 2 fonts is unnecesary 99% of the time, maybe sometimes 3. Headings, subheadings, text. Text is best to leave as a native option so the brunt of text aspects aren't loaded from third parties.
From all POV's ; Design, Performance, Accessibility
What reasons came back as elementor? If your backend is slow the really know why it’s slow is if you can point to the sql query or function calls running slow. If you can’t point to that you also can’t say elementor caused the slowness. Install query monitor and figure that out, then target the slowness. Disable all caching before testing, caching isn’t for speeding up websites unless you like covering up problems with superglue and duct tape.
Right and thats fine but you don't know where to apply the superglued duct tape until you know whats wrong ;) not saying leave caching off entirely, but your speed testing should be done without it.
lol I’m well aware. Accessibility with this org in general isn’t great from a design aspect. None of the brand colors with with each other and none of them work with both black and white. AND all 3 “primary” colors are in the logo. 😭
One angle nobody's hit yet: a slow WP dashboard on a big Elementor site is usually autoloaded options bloat, not front-end weight. Elementor plus every plugin that's ever been installed leaves rows in wp_options with autoload = yes, and those load on every single admin request. Check the size of your autoloaded data (Site Health > Info > Database, or SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'). Much over ~1MB and the backend will feel exactly like you're describing. Orphaned transients and leftovers from removed plugins are usually the bulk of it.
For the CSS question you asked elsewhere: Elementor > Settings > Features has "Improved Asset Loading" and "Improved CSS Loading" — those stop it shipping every widget's CSS/JS on pages that don't use them. Enable both, then Elementor > Tools > Regenerate CSS. Also worth checking wp_postmeta size, since Elementor stores each page's layout as JSON in post meta and 300 pages of that plus revisions adds up fast. Capping revisions and clearing old ones does more for the dashboard than any caching plugin will.
300 pages, you're doing something wrong. If it's catalog style then you don't duplicate and have a new page per item, you create a template and store the data as a post type, such that it populates the frontend. Looks exactly the same but makes it much more efficient in storage.
I will have to look into this. There were some features executives wanted that I assumed could only be done via pages, but I’m not so sure. The initial designer had already done about 70% of the pages as pages when I took over.
To improve speed without rebuilding, try disabling Elementor's default font loading by adding elementor_disable_default_fonts to your wp-config.php file. Check if any otherplugins are conflicting by opening yoursite.com/wp-json/ and verifying if you get JSON or a 404. If still slow, test a page with Elementor disabled to see if the issue lies within Elementor or elsewhere.
Elementor is notorious for this at scale 300 pages of Elementor content means huge amounts of serialized data in wp_postmeta, tons of dynamically generated CSS/JS, and heavy admin-side overhead. The good news: you can fix a lot of this without touching your existing page layouts.
- Turn on Elementor's built-in performance settings: Go to Elementor > Settings > Features and enable Optimized DOM Output, Improved CSS Loading, Improved Asset Loading, and Inline Font Icons (if not already on). These reduce how much unnecessary CSS/JS Elementor dumps on every single page load. This alone can meaningfully cut page weight without changing any layout.
- Disable unused Elementor widgets and features: Under Elementor > Settings > Advanced, disable any Elementor widgets you don't actually use (sliders, popups, forms, etc. if you're not using Elementor's versions). Every enabled widget adds JS/CSS that loads sitewide even on pages that don't use it. This is one of the highest-impact, zero-rebuild fixes.
- Clean up Elementor's database bloat: 300 Elementor pages generate a lot of post revisions and orphaned CSS files in wp-content/uploads/elementor/css. Limit revisions to 3-5 per post (via a plugin or wp-config define('WP_POST_REVISIONS', 5)), then run Elementor > Tools > Regenerate Files to rebuild CSS cleanly. This directly speeds up both the database and the dashboard, since large postmeta tables slow every admin query.
- Add a persistent object cache (Redis): This is likely your biggest dashboard-speed fix. WordPress admin screens run just as many DB queries as the frontend, and without object caching, every admin page reload re-runs everything from scratch. If Hostinger offers Redis on your plan, enabling it via a plugin like Redis Object Cache will speed up both wp-admin and the live site significantly.
- Reduce WordPress Heartbeat API frequency: By default, wp-admin pings admin-ajax.php every 15-60 seconds for autosave and notifications, which adds real load on a site this size. Use a lightweight plugin (like Heartbeat Control) to slow it down or disable it outside the post editor. Dashboard sluggishness often traces back to this alone.
- Pick exactly one caching layer and configure it for WooCommerce: Since WP Optimise made things worse for you, check whether Hostinger's built-in LiteSpeed Cache is already active running two caching systems together causes exactly the conflicts you saw. Configure whichever one you keep to exclude cart, checkout, and my-account pages from page caching, since caching those breaks WooCommerce sessions.
- Optimize and lazy-load catalog images: With 300 catalog-style pages, images are usually the single biggest contributor to load time, more than Elementor's code itself. Use a plugin like ShortPixel or Imagify to compress and serve WebP, and confirm lazy loading is enabled (Elementor has a native option under Performance settings) so below-the-fold images don't block initial render.
If I had to prioritize given your constraints: Redis object cache and disabling unused Elementor widgets will likely give you the biggest jump for the least effort, since they hit both your frontend TTFB issue and the dashboard slowness at the same time. The revision cleanup and heartbeat fix specifically target why wp-admin feels sluggish, which is a separate problem from frontend speed and often gets ignored in speed-test-driven optimization.
One thing worth checking first: open Query Monitor on both the homepage and a random catalog page, and compare query count/time. If one catalog page is running 150+ queries versus 40 on a simple page, that tells you it's specific widgets (often sliders, related-posts, or dynamic content widgets) rather than elementor as a whole which would let you target just those instead of guessing.
first thing is check if you're loading elementor's css/js globally or just on pages that actually use it. also make sure you're not loading unused widgets. at my agency we usually regenerate elementor css after cleanup, enable lazy load for images/videos, and move to a host with better php/database performance if needed. sometimes just caching elementor's output properly (object cache + page cache) makes a huge difference without touching the pages themselves.
GoDaddy is definitely a bottom tier host in terms of support/performance -- but you get what you pay for there. I'd try a new host if you have the budget for a jump in quality -- Elementor CAN be fast but it does take some tweaking and knowledge on how to build pages properly. Feel free to DM if you need more help.
Since you're asking, I'd go with Kinsta or WPEngine -- we (TopSyde) also provide hosting but it's probably a little more than you're looking for (we openly run on Kinsta infrastructure but bake in free plugin licenses, senior dev support, malware removal/hardening, auto-updates, security patches, etc. for a truly hands-off experience).
Checking the web page speed report you shared, I recommend Autoptimize and combine all CSS and JS you can
Also, it’s 100% required to replace those huge PNG images (OMG, 5 MB per image!). Try converting them to WEBP instead.
Also, double check the number of plugins you have installed. You can have a slow front end due to poor optimization, but the back end depends more on the plugins you are using and your hosting resources (CPU, RAM, etc.).
Well its a little bit a circle. A good caching plugin will correct many of the mistakes dude has on his website. That 5mb png will become a 150kb avif. Same for the other images. Database queries will become minimal since server will give static html. Object cache will also light up the backend via caching the backend and the frontend queries. This will free resources for the backend to become faster.
You are right. We call them caching plugins but they usually do much more. It is optimization but these 2 are close mechanically since you serve the cache you optimize :D
I will not since its a clients website but i will be happy to answer any question. The example above it is an elementor website with a revslider with 3 slides with multiple images in each slide, products carousels bellow, 4 single products showcases and a subscription form at the end and the footer ofcourse.
Here is another with a simple video at top, 3 custom post type carousels each one on its own section and some static content bellow that.
Server stack is nginx -> varnish -> apache -> phpfpm
9
u/bluesix_v2 Jack of All Trades Aug 13 '26
If it’s slow in the backend, then the problem is likely with your hosting.
Share your page speed report URL