How to Speed Up Long Elementor Pages with content-visibility

What Is content-visibility and What Problem Does It Solve?

Under normal conditions, the browser builds the page and prepares all of its parts for display. This is almost unnoticeable on a short page, but on a long Elementor template with dozens of containers, widgets, background effects, and complex styles, the cost can become significant.

The value content-visibility: auto tells the browser that the contents of a particular element do not need to be fully processed temporarily if it is far outside the viewport. When the user scrolls closer to that element, the browser prepares it for display.

The property works at the CSS level and does not remove content from the page. Text, images, and markup remain available in the HTML, so this is not the same as hiding content with display: none. However, the effect depends on the browser, page structure, and the amount of work performed by each section.

• The amount of work required during the initial construction of a long page is reduced.
• Lower sections may not be painted until the user scrolls toward them.
• The property is especially useful for long pages with repeated blocks and complex widgets.
• The method does not automatically eliminate resource loading: images, scripts, and fonts still need to be optimized separately.

How to Add a Class to Elementor Sections

First, identify the sections or containers located below the first screen. You do not need to add the class to every individual element; in most cases, it is enough to assign it to large logical page blocks.

Open the required section or container in the Elementor editor and find the CSS class field in the Advanced settings. Add the class lazy-section without a leading dot. The dot is needed only in the CSS selector, not in the Elementor field.

Start with a few lower sections instead of applying the rule to the entire page immediately. This makes it easier to notice potential height changes, animation problems, or horizontal and vertical jumps.

• Do not add the class to the header, main menu, hero block, or first visible screen.
• Be careful with sections containing anchors, navigation targets, or elements that must be available immediately.
• If the page is built with containers, assign the class to the outer container that covers a complete block.
• After saving, clear the Elementor cache, plugin cache, and CDN cache if they are being used.

CSS for Deferred Rendering

Add the rule in Elementor Custom CSS, the child theme's CSS file, or another location used by the site for custom styles. The exact menu item may vary depending on the configuration and Elementor version, so make sure the style is actually added to the published page.

.lazy-section {
  content-visibility: auto;
  contain-intrinsic-size: 600px;
}

Why Is contain-intrinsic-size Needed?

When the browser temporarily does not process a section's contents, it still needs to estimate how much space that section occupies on the page. contain-intrinsic-size provides an approximate placeholder size. In the example, 600px is not a required standard; it is a starting value that should be adjusted to the actual height of your blocks.

If sections usually have very different heights, one fixed size may be inaccurate. A value that is too small can cause noticeable position changes while scrolling, while a value that is too large can leave too much empty space. Test the page with real content and adjust the estimate when necessary.

• Smaller values can be used for short sections.
• Large blocks with galleries, cards, or substantial text may need a larger placeholder.
• This is an approximate height, not an instruction to set the section's actual height.

A Safe Option with a Fallback Rule

Modern browsers support content-visibility, but this optimization should not be the only thing you rely on for critical visual presentation. If a browser does not apply the property, the regular CSS styling should still remain correct. Do not use display: none as a fallback, because it hides the content and may change the page's behavior.

.lazy-section {
  content-visibility: auto;
  contain-intrinsic-size: 600px;
}

/* Other section styles remain unchanged */

Which Blocks Should Not Use This Rule?

content-visibility: auto works best for secondary content that users will see after scrolling. Blocks that create the first impression or participate in initial navigation should generally be left without this class.

Do not apply the rule to the hero section, logo, header, menu, main heading, important call to action, or other content in the first screen. Deferring the processing of these elements can complicate Largest Contentful Paint measurement or affect perceived loading speed.

You should also be cautious with widgets that run JavaScript immediately after loading, including sliders, maps, forms with dependent fields, tabs, accordions, and interactive filters. After the browser defers a section, a script may calculate its dimensions incorrectly or initialize the component with a delay.

• The hero block and main first-screen content.
• The header, menu, and elements used for immediate page navigation.
• Forms, carts, calculators, and other critical interactive components.
• Sections with animations when their logic depends on initial dimensions.
• Blocks targeted by anchors if their position or height becomes unstable after navigation.

How to Check the Result After Implementation

Do not check only the Lighthouse score; also test the page's real-world behavior. Open the page in private browsing mode or after clearing the cache, because a cached version can hide errors.

First, scroll from the beginning to the end on both a smartphone and a computer. Check whether jumps, empty areas, delayed text rendering, or broken animations appear. Also test anchor navigation, refreshing the page in the middle of a long document, and opening the menu.

Then compare the page before and after the changes in Lighthouse or PageSpeed Insights. Look beyond the overall score and review loading time, LCP, Cumulative Layout Shift, interaction performance, and long JavaScript tasks. If the improvement is not noticeable, the cause may not be section painting but heavy scripts, images, or fonts.

• Test the mobile version separately, since resource limitations are usually more noticeable there.
• Compare the same testing conditions across several runs rather than relying on one random result.
• Make sure the CSS loads on the published page, not only in the editor.
• Check the browser console for JavaScript errors after adding the rule.
• If jumps appear, increase contain-intrinsic-size, split large sections, or remove the class from the problematic block.

Common Mistakes and Limitations of the Method

The most common mistake is adding lazy-section to every section without testing. Deferred rendering is not a universal speed switch: it can help on a long page, but it may not change the result on a short landing page.

Another issue is expecting content-visibility to reduce the size of all loaded resources. CSS does not compress images, remove unused JavaScript, or replace lazy loading for media. If lower blocks contain heavy images, optimize them separately by using suitable dimensions, modern formats, and correctly configured deferred loading.

You should also avoid blindly combining multiple optimization tools that change script execution order or the DOM structure. After each change, test forms, popups, galleries, videos, and responsive behavior.

• Do not use the property as a replacement for media and JavaScript optimization.
• Do not evaluate the effect only by the Lighthouse score.
• Do not leave the approximate height untested across different screen sizes.
• Do not add the class to critical first-screen elements.
• If the effect is negative, remove the class from the specific section instead of necessarily abandoning the approach across the entire page.