A converted page can be just as fast as one built by hand — or noticeably slower, depending on a few choices made during and after conversion.
Prefer native widgets over HTML blocks
The single biggest factor. A page dropped into one large HTML widget carries its entire original stylesheet with it, including rules for elements that are not on the page. Native components mode produces real widgets whose styles Elementor generates and caches per page, so you ship far less unused CSS — and you get an editable page as a bonus.
Decide what to do with the original stylesheet
Keeping inline styles is useful during conversion, because it is what allows class-based styling to be measured correctly. But once the widgets carry their own settings, the leftover CSS block at the top of the page is often redundant. Try removing it and check the layout — if nothing shifts, you have just deleted a chunk of dead weight.
Images deserve the most attention
- Upload real images to the Media Library rather than embedding data URLs. A Base64 image cannot be resized, cached separately or lazy-loaded, and it inflates the page HTML itself.
- Let WordPress serve responsive sizes rather than forcing one large size everywhere.
What the image optimisation option actually does
This one is narrower than its name suggests, and knowing the boundaries saves you expecting something it will not do.
It only runs in high-fidelity mode, and only on Base64 data images — PNG, JPEG or WebP — that are larger than roughly 135KB. Those get decoded, scaled down so their longest side is at most 2560px, and re-encoded. The result view reports how many were processed and how much was saved.
What it does not do: it does not touch images referenced by URL, because those are files on a server that the tool has no business rewriting. And in native components mode it does not run at all — Base64 images there become labelled empty slots for you to fill from the Media Library, which is the better outcome anyway.
So the honest summary is that this option rescues one specific situation: a high-fidelity import of a page whose images were all inlined, usually one generated by an AI tool. If your images are proper URLs, the option is irrelevant and the real optimisation happens where it should — in your Media Library, with WordPress generating responsive sizes.
Watch the nesting depth
Deep container trees are not just awkward to edit — each level is another DOM node and another set of generated CSS rules. If the Structure map shows a depth of seven or eight, simplify the source or set a copy root deeper in the tree. Flatter output is both faster and easier to maintain.
Fonts
A converted page names whatever fonts the source used. If those are not fonts your site already loads, either register them properly or switch to site typography so the page uses fonts you are already serving. What you want to avoid is loading a second font family for one imported section.
Re-add behaviour natively
Scripts are stripped during conversion, which is a good thing for performance as well as safety. When you rebuild sliders, tabs or counters, use Elementor’s own widgets rather than pasting third-party scripts back in — they are already part of the bundle you are loading.
Why a converted page is not automatically bloated
There is a reasonable worry that an automated conversion will bury the page in settings, and that all those settings become CSS. Two things keep that from happening.
First, responsive values are written only where they differ from desktop. A container with the same padding at every width gets one padding value, not three. On a page with sixty widgets that is the difference between a lean stylesheet and one carrying two-thirds redundant rules.
Second, wrappers that provably do nothing are removed rather than converted. Every Container that survives is a real <div> with its own generated rules, so dropping the ones with no styling effect removes both a DOM node and its CSS.
What none of that can fix is source markup that was deep to begin with. The converter mirrors your HTML; it does not redesign it. A seven-level source produces a heavy page no matter how carefully each level is handled, which is why flattening at the source is worth more than any post-import tidying.
Measure, then tidy
Run the page through a speed test before and after your clean-up pass. Usually the wins come from three places: removing the redundant stylesheet block, replacing oversized images, and flattening an over-nested tree. None of them take long, and together they typically account for most of the difference.
Watch the right numbers. Total page weight and Largest Contentful Paint respond to the image work. Cumulative Layout Shift responds to images getting explicit dimensions — a placeholder you filled from the Media Library has them, a Base64 image often does not. And the DOM node count, which most reports show and most people skip past, is the one that tells you whether the nesting is under control.