V3 vs V4 performance benchmarks on the same site

The test setup

Most V3 vs V4 comparisons you find online are useless. Someone builds a page in V4, runs PageSpeed once, and declares victory. That tells you nothing because the comparison has no control, no repeated measurements, and no accounting for variables outside Elementor's control.

We wanted better data. So we set up a controlled test and measured over 30 days.

Both sites use the same hosting: a Cloudways server (2GB RAM, DigitalOcean, Amsterdam datacenter). Same theme (Hello Elementor). Same images (all WebP, properly sized, served from the same origin). Same content on every page. Same plugins: Elementor Pro, WP Rocket (same configuration), and nothing else.

The only difference: Site A is built with V3 widgets. Site B is built with V4 atomic elements. Same layouts, same content, same styles. Three page types: a homepage (hero, features, testimonials, CTA), a services page (text-heavy, 8 sections), and a contact page (form, map embed, FAQ accordion).

We ran PageSpeed Insights on each page every day for 30 days using the PageSpeed API. We also collected data from WebPageTest (Dulles, VA, mobile 4G preset) weekly. Chrome UX Report data takes 28 days to populate, so we checked CrUX at the end of the test period.

The raw numbers

Here are the median values across 30 days of daily measurements. Mobile results, since that is where Elementor performance differences show up most.

Homepage

Metric	V3	V4	Delta
LCP	2.8s	2.1s	-700ms
FCP	1.8s	1.3s	-500ms
INP	185ms	170ms	-15ms
CLS	0.09	0.03	-0.06
TTFB	420ms	415ms	-5ms
DOM nodes	1,847	612	-67%
CSS transferred	342KB	47KB	-86%
JS transferred	285KB	271KB	-5%
PageSpeed score	68	85	+17

Services page

Metric	V3	V4	Delta
LCP	2.4s	1.9s	-500ms
FCP	1.6s	1.2s	-400ms
INP	140ms	132ms	-8ms
CLS	0.05	0.02	-0.03
DOM nodes	2,105	743	-65%
CSS transferred	338KB	52KB	-85%
PageSpeed score	72	88	+16

Contact page

Metric	V3	V4	Delta
LCP	2.1s	1.7s	-400ms
FCP	1.5s	1.1s	-400ms
INP	210ms	195ms	-15ms
CLS	0.12	0.05	-0.07
DOM nodes	1,523	498	-67%
CSS transferred	335KB	38KB	-89%
PageSpeed score	65	82	+17

What the numbers tell us

LCP improved consistently

Across all three page types, LCP dropped by 400-700ms. That is meaningful. For the homepage, it is the difference between passing the 2.5s threshold (good) and failing it. For agencies who care about Core Web Vitals as a ranking signal, this improvement alone could justify migration for underperforming sites.

The LCP improvement comes from two places: less CSS blocking render and fewer DOM nodes to lay out before the largest content element paints. Both are direct consequences of V4's architectural changes.

CSS reduction is dramatic

85-89% less CSS, depending on page type. This is the single biggest measurable difference. V3 loads CSS for every registered widget type (90+ with Pro), while V4 loads CSS only for the element types present on the current page. On our test pages, that meant ~340KB vs ~45KB.

For context: 300KB of CSS takes about 150ms to parse on a mid-range mobile phone. Eliminating that parsing time directly reduces FCP and LCP.

INP barely moved

INP (Interaction to Next Paint) measures how fast the page responds to user input. V4 improved it by 8-15ms. That is statistically real but functionally invisible. Both versions were within the "good" range (under 200ms) on most pages.

INP is driven by JavaScript execution, and V4 does not significantly change the JavaScript architecture. The Elementor frontend JS is similar in both versions. If you have INP problems, V4 will not fix them. Look at your third-party scripts instead.

CLS improved more than expected

CLS dropped by 0.03-0.07 across page types. The contact page saw the biggest improvement (0.12 to 0.05). We did not expect this, but the reason is straightforward: fewer DOM nodes means fewer elements involved in layout recalculation. V3's wrapper divs participate in layout even though they are invisible, and any late-loading content causes more elements to shift.

TTFB was unchanged

TTFB (Time to First Byte) was nearly identical. This makes sense. TTFB measures server response time, and V4 does not change anything on the server side. If your TTFB is slow, that is a hosting problem, not an Elementor problem, and no Elementor version will fix it.

DOM size comparison in detail

The DOM node reduction was 65-67% across all page types. To put this in context:

• Google flags pages with more than 1,500 DOM nodes as potentially problematic
• All three V3 pages exceeded 1,500 nodes (the services page hit 2,105)
• All three V4 pages stayed under 750 nodes

On the V3 homepage, Elementor's own markup (wrappers, containers, classes) accounted for roughly 1,200 of the 1,847 total DOM nodes. The actual content (headings, paragraphs, images, buttons) was about 650 nodes. That means 65% of the DOM was structural overhead from Elementor's rendering.

On the V4 homepage, Elementor's atomic element markup was about 150 nodes, with content comprising the remaining 462 nodes. Structural overhead dropped from 65% to 25% of total DOM. That is the core engineering win of V4 atomic.

Where the benchmarks mislead

These benchmarks are accurate but potentially misleading because the test conditions are unrealistic. Here is what our controlled test leaves out:

No third-party scripts. Our test sites run only Elementor and WP Rocket. A production site typically loads Google Analytics, Meta Pixel, maybe a chat widget, a cookie consent banner, and one or two marketing scripts. Those scripts add 300KB-1MB of JavaScript. On a site with that much third-party JS, Elementor's DOM and CSS improvements are still real, but they contribute a smaller percentage of the total page weight.

Decent hosting. Our test server had 420ms TTFB. Many shared hosting plans deliver 800-1,500ms TTFB. When your server takes 1.2 seconds to even start sending the HTML, the 500ms LCP improvement from V4 gets partially absorbed into wait time.

Optimized images. We used properly sized WebP images. If a production site serves unoptimized 3MB PNGs for hero images, the hero image download time dominates LCP regardless of how clean the DOM is.

No complex plugins. WooCommerce, LearnDash, BuddyPress, and other complex plugins add their own DOM nodes and scripts. V4 reduces Elementor's contribution, but it cannot reduce what other plugins output.

What the benchmarks actually tell you

V4 atomic is measurably faster than V3 at the rendering layer. The improvement is real, consistent, and reproducible. On a well-optimized site where Elementor's output is a significant portion of the total page weight, the improvement will be visible in PageSpeed scores and may be perceptible to users.

On a poorly optimized site where Elementor's DOM is a small fraction of the total page problems, V4 helps but you will not notice it until you fix the bigger issues first. Fix your images, fix your hosting, audit your plugins, then measure the V4 difference. The improvement is there, but it can be hidden behind larger problems.

The biggest takeaway from 30 days of measurement: V4 consistently reduces Elementor's performance footprint by 65-85% (depending on the metric). Whether that translates to a noticeably faster site depends entirely on what else is happening on the page.

For the benchmark pages themselves, Snapelement V4 components were used to build the test sections. The components use only native V4 atomic elements, so the performance numbers reflect real-world V4 component usage, not synthetic test markup.