Your 300-page Elementor site got slow: what is worth fixing

Slow is not the same problem at 30 pages and at 300

A small Elementor site that loads slowly usually has one cause: an oversized hero image, a bloated theme, a shared host having a bad afternoon. Find it, fix it, done.

A three hundred page site is a different animal. It has been built by several people over several years, it carries a stack of third-party widget addons, and its templates are reused everywhere, so one heavy header is not one problem, it is three hundred problems. The instinct at that size is to conclude that Elementor itself is the problem and price up a rebuild.

Before anyone prices a rebuild, it is worth knowing that a large part of the speed you are missing is sitting in Elementor's own settings, switched off, and that the reason it is switched off is usually that switching it on can break things. Both halves matter.

What is switched off right now?

Elementor keeps its speed features in two places, and the split matters because one of them holds features that are still experimental.

In the Performance tab, stable and ready to turn on:

Optimized Image Loading: Improves performance by applying fetchpriority="high" on LCP images and loading="lazy" on images below the fold.

Optimized Gutenberg Loading: Dequeues unused Gutenberg block editor scripts and styles.

Lazy Load Background Images: Improves page loading speed by applying lazy loading to all background images except the first one.

• Improve performance features, Elementor Help Center, updated 19 June 2026

In the Features tab, mixed. Inline font Icons is stable and renders icons as inline SVG "without loading the Font-Awesome and the eicons libraries and their related CSS files and fonts", per the same page. Element Caching and Optimized Control Loading are still marked experimental.

On a site that nobody has audited since launch, several of these are off. That is the cheap half of the work: measurable gains, no design changes, no rebuild.

Is Element Caching the big win?

It is the biggest single lever on a page-heavy site, and it is also the one that can put the wrong customer's name in front of a visitor. Both facts come from Elementor's own documentation.

What it does:

With Element Caching, when widgets are rendered on the server the HTML output is stored in the database. This way, the next time the element appears, it is drawn from the database instead of being rerendered. This significantly reduces the server's memory usage and reduces the Time To First Byte (TTFB) for visitors.

• Speed up page loading with Element Caching, Elementor Help Center, updated 19 June 2026

And the warning that sits directly underneath it:

Element Caching cannot be used on elements that contain dynamic tags or any other type of dynamic information, such as shortcodes, which present custom data to visitors. For example, a widget that displays the visitor's name. To make sure that Element caching is only used when needed, the feature is inactive by default. You should only activate caching on static elements - those without dynamic tags.

• Speed up page loading with Element Caching, Elementor Help Center

Read that as a rule for large sites: caching is per element, and the decision has to be made per element. A widget that greets the visitor by name, shows their cart, prints a shortcode from another plugin, or renders anything that differs between two people must stay uncached. Cache it and every visitor gets whichever version was rendered first.

Two structural details, from the same page. Containers, Grid Containers, Off Canvas, Sections, Columns and Inner Sections "are automatically cached and their status cannot be changed". And cache clearing is not per element:

Clearing the cache is done at the site level so all your elements will have their cache cleared in the same interval.

• Speed up page loading with Element Caching, Elementor Help Center

The interval lives in Elementor > Settings > Performance, in the Element Cache Expiration field. On a site where some sections change weekly and others never change, one interval has to serve both.

Why didn't asset loading help as much as promised?

Because it only covers Elementor's own code, and a three hundred page site is rarely built from Elementor's own code alone.

The feature loads only what a page actually uses, and the documentation lists concrete savings: Lightbox and Screenful libraries at around 20KB, the Dialog library at 11KB, Share links at 3KB, all skipped on pages that do not need them. Then comes the boundary:

This feature only applies to Elementor Core widget handlers (JS files), and the Swiper library in Elementor and Elementor Pro instances. 3rd party addons may cause potential conflicts if they have not optimized their plugins to use this feature properly.

• Improved Asset Loading, Elementor Help Center

This is the single most useful sentence for a large site, because large sites are where the addons accumulate. If half your pages are built with widgets from two or three third-party packs, the optimisation applies to a shrinking share of what actually loads, and it may fight with the addons that were not built for it.

Counting your widget packs is therefore a diagnostic step, not housekeeping.

What actually gets fixed for a fixed price

1. Audit which speed features are off, then turn on the stable ones on a staging copy: image loading, background image lazy loading, Gutenberg dequeuing, inline font icons. One at a time, checking pages between each.
2. Map the dynamic elements before touching Element Caching. Anything with a dynamic tag, a shortcode, or per-visitor content goes on a do-not-cache list first. The list is the deliverable that makes caching safe.
3. Enable caching on the static majority: headers, footers, section backgrounds, marketing copy that changes quarterly. On a site where the same template renders three hundred times, this is where TTFB improves.
4. Set a cache expiration the site can live with, remembering it applies site-wide.
5. Inventory the third-party widget packs. Every pack that is not optimised for improved asset loading is both a performance cost and a compatibility risk. Sometimes two packs do the same job and one can go.
6. Clear files and data after the changes, which Elementor documents as the step that makes edits take effect and resolves stale cached styling. Back up first: "Always back up your site before clearing your files and data."
7. Re-measure the same pages you measured at the start. Not the homepage alone: the heaviest template, a long archive, and one page that uses the addon widgets.

That is a bounded piece of work with a known shape, and it is the kind of thing a fixed-price fix is for. Nothing in it changes how the site looks.

Where the point of no return is

Some sites cannot be fixed this way, and it is fairer to say so early than to bill for a month of tuning first. The signals:

• The site is dynamic all the way down. If most sections carry dynamic tags or shortcodes, Elementor's own rule keeps them out of the cache, and the biggest lever is unavailable by design.
• The addons outnumber the core widgets. When most of what renders comes from third-party packs, asset loading optimisation stops applying to most of the page, and every pack update is a new compatibility event.
• Templates were copied instead of reused. Three hundred pages built from forty near-identical one-off templates cannot be improved centrally: each fix has to be repeated forty times, and it will be repeated again next year.
• Nobody can safely clear the cache. If clearing files and data is scary because the last time it happened something visibly broke, the underlying problem is not speed, it is that the site's styling depends on stale artefacts.
• The measurement never gets better than the host. If the server is slow on a plain page with no Elementor content, the ceiling is the hosting, and no feature toggle moves it. Worth ruling this out early, the same way you would when the site is down and the host says everything looks fine: test something the builder is not involved in, then compare.

When two or more of these are true, tuning buys a few weeks and the site is back where it started after the next round of edits. A rebuild of the templates, not of the content, is usually the honest recommendation.

What we would not do

• Turn on every experiment at once to show a fast number. Experimental features are labelled that way by Elementor, and Element Caching in particular is documented as capable of producing "unexpected results" on the wrong element.
• Cache a widget without checking what it renders. The cost of getting this wrong is not a slow page, it is one visitor seeing another visitor's data.
• Recommend a rebuild before measuring. The features above are free and often off. Anyone quoting a rebuild without first checking which of them are enabled is quoting the expensive option first.

When to hand it over

If the site is yours, the templates are shared, and the dynamic parts are easy to list, the checklist above is a good weekend and you keep the money.

Hand it over when the site earns money continuously and cannot be experimented on during business hours, when nobody left at the company knows which widgets are dynamic, or when the last person who touched performance made it worse and nothing was written down. That is scoped work: audit what is off, list what cannot be cached, turn things on in a safe order, measure the same pages before and after, and say plainly if the answer is a template rebuild rather than another round of tuning.

Sources

• Improve performance features - Elementor Help Center, updated 19 June 2026. Which features are stable, which are experimental, and where each lives.
• Speed up page loading with Element Caching - Elementor Help Center, updated 19 June 2026. How caching stores widget HTML, the dynamic-content warning, automatically cached elements, site-level expiration.
• Improved Asset Loading - Elementor Help Center. Library sizes saved and the third-party addon boundary.
• Clear Files & Data - Elementor Help Center, updated 20 January 2026. When to clear, how, and the backup warning.