Most people try to fix a slow Elementor website by installing an optimisation plugin. Then a second one, because the first did not help. Then a caching plugin on top of that. Three plugins later the site is slower than it started and nobody knows which setting broke the layout.
Speed work is diagnosis first. Here is the order we actually go in.
1. Find out what is slow before changing anything
“The site is slow” is not a problem you can fix. “The homepage takes 4.1 seconds because a 3 MB hero image loads before anything else” is. Run the page through a waterfall tool and read the timeline rather than the score. You are looking for three things: the largest file, the request that blocks everything after it, and how long the server took to send the first byte.
If the first byte takes over a second, no amount of image compression will save you. That is a hosting or database problem, and it gets solved somewhere else entirely.
2. Images are usually most of the weight
On a typical Elementor build, images are 60 to 80 per cent of the page weight. The common causes are boring and easy to fix:
- A 4000px hero photo uploaded straight from a phone or a stock site, displayed at 1400px.
- PNG used for photographs, where WebP would be a fraction of the size.
- Background images set in Elementor, which are not lazy-loaded the way content images are.
- A slider with six full-size slides, all loading on first paint.
Resize before uploading, convert to WebP, and make sure only the first visible image loads eagerly. This step alone often halves the page weight, and it does not require a single new plugin.
3. Count your plugins honestly
Plugin count on its own is not the metric. Plugin cost is. One well-built plugin loading nothing on the front end is harmless. One page-builder addon pack loading its entire CSS and JavaScript bundle on every page, including pages that use none of its widgets, is not.
Deactivate plugins one at a time on a staging copy and re-measure. You will usually find that two or three of them account for most of the front-end overhead. Some of what they do can be replaced with twenty lines of PHP in a snippet, which loads nothing extra at all.
4. Elementor’s own settings matter
Elementor ships with several performance features that are off by default on older sites. Improved CSS loading, optimised DOM output, inline font icons and lazy-loaded background images all reduce what the browser has to download and parse. Turn them on one at a time and check the layout after each one, because a site built years ago can depend on the old behaviour.
Also worth checking: how many nested containers a section really needs. A hero built from six stacked containers where two would do produces a deeper DOM, and a deep DOM is slower to render on mid-range phones.
5. Caching comes last, not first
Caching hides slow pages, it does not make them fast. That matters because logged-in users, cart pages and anything dynamic will not be cached, and those are often the pages that need to be quick. Fix the underlying weight first, then add caching so the fixed version is served quickly.
6. The database nobody looks at
On a site that has been running for a few years, the wp_options table often carries thousands of autoloaded rows left behind by plugins that were removed long ago. Every single page load reads them. Post revisions, expired transients and orphaned metadata add to it. Cleaning this up will not show in a page-weight report, but it shows in server response time.
What we do not promise
We do not promise a specific PageSpeed score. Scores move with the tool, the test location and the network, and chasing a number often means breaking something that mattered more, like the layout or a working form. What we do is find the actual bottleneck, fix that, and show you the before and after.
If your Elementor site is slow and you would rather not spend a weekend guessing, have a look at what performance work involves or send us the URL and you will get a straight answer on where the time is going.
Add comment