Divi Core Web Vitals for WooCommerce

In Divi the LCP element is frequently a fullwidth header or hero module whose image is set as a CSS background, not an <img> tag. Backgrounds cannot take fetchpriority or a preload as easily, so the browser discovers them late, and Divi's dynamic CSS can sit in the critical path while it is generated. On product pages the gallery image competes with render-blocking theme CSS. The goal is to make the true LCP asset a real, preloadable image and clear the CSS that blocks it.

• Serve the hero as a real <img> with fetchpriority="high" instead of a CSS background where possible
• Ensure Divi dynamic CSS is cached and not regenerated on each request
• Replace slider modules above the fold with a static section
• Reserve header height so the LCP image is not pushed by late CSS

Divi still ships jQuery and its own et-core / builder scripts, and every interactive module — toggles, tabs, accordions, the mobile menu, filterable grids — attaches handlers on top of it. When a shopper taps a variation selector or opens the menu, those long tasks run behind Divi's boot code and any marketing tags, and INP suffers. The interactions that matter are on category and product templates, so measure there.

• Remove Divi modules that are unused on revenue templates rather than just hiding them
• Defer analytics, chat and remarketing so they do not block the first tap
• Test add-to-cart, variation selectors and the mobile menu under CPU throttling
• Avoid stacking a page-builder popup plugin on top of Divi's own scripts

Divi's fade-in and slide animation options move content as it enters, background-image sections without a reserved height collapse and jump on mobile, Google Fonts loaded by the theme cause a late reflow, and a sticky header can shift the first product row. Turn off entrance animations on commercial templates, set explicit heights on background sections, and preload the primary font so text does not swap.

A tuned Divi homepage can hide weak category and product pages built from the same modules. Test the homepage, a shop/category archive, a product page and the cart-to-checkout handoff separately under mobile throttling. Compare cached and uncached responses, inspect the long-task timeline, and confirm which Divi modules and plugins actually run on each revenue template.

Divi ships frequent updates and new modules, and its flexibility invites feature creep: over months a store accumulates modules, animations and third-party Divi packs, and each addition quietly enlarges the DOM and the script it hydrates. That is why a Divi store that passed Core Web Vitals last year can fail today with no obvious cause. Treating performance as a recurring check rather than a one-time fix — re-auditing after major Divi updates and before adding a new module pack — keeps the theme from drifting back into the red. And if that maintenance burden keeps growing, it is itself a signal that the builder layer, not any single module, is the ceiling.

• Divi's frequent updates and new modules invite feature creep
• Accumulated modules and packs enlarge the DOM over time
• Re-audit after major updates and before adding module packs
• A rising maintenance burden is itself a migration signal

If caching the dynamic CSS, cutting modules and fixing images still leaves LCP, INP or CLS weak on important mobile templates, the shortcode-and-jQuery architecture is the limit. A Next.js storefront keeps WooCommerce as the backend for products, orders and checkout while giving the pages shoppers see a smaller performance budget and a rendering model that does not depend on builder markup.