WordPress performance optimization can backfire when multiple optimization layers modify the same CSS. In one Divi performance project, a site started with a GTmetrix D / 54% score and a high Cumulative Layout Shift (CLS) of 0.603. The initial audit identified several possible performance opportunities, but the most important verified issue turned out to be a conflict between WP Rocket Remove Unused CSS and Divi’s final header styling.
Freshy tested the optimization changes on staging first. After isolating the CSS conflict and disabling Remove Unused CSS, the staging site reached a GTmetrix A and browser testing showed CLS dropping from 0.603 to approximately 0.006. The final configuration kept Divi Static CSS, WP Rocket caching and minification, delayed/deferred JavaScript, RocketCDN, and the existing Vimeo hero enabled. The approved changes were then deployed to production and a live GTmetrix test was run.
Issue background
A WordPress site built with Divi had a weak GTmetrix result:
- Grade: D.
- Performance: 54%.
- Largest Contentful Paint: 846 ms.
- Total Blocking Time: 468 ms.
- Cumulative Layout Shift: 0.603.
The LCP was already relatively strong. The larger concerns were layout instability, blocking JavaScript, and a heavy page payload.
The initial audit identified several possible areas for improvement, including:
- Font-related layout shifts.
- A large Vimeo background video.
- Third-party JavaScript from marketing tools.
- Potential duplicate analytics delivery.
- Overlapping CSS optimization between Divi, WP Rocket, and other performance tooling.
- Homepage-only assets and large media files.
Rather than changing production immediately, Freshy was asked to implement reasonable improvements on staging first and stay within a tightly limited performance-optimization window.
Diagnosis
The original GTmetrix analysis showed that CLS was the most obvious user-experience problem.
The audit attributed measured movement to several parts of the page, including the hero, headings, and header. That initially made font loading and layout dimensions reasonable suspects.
The site also had several optimization systems active at the same time, including:
- WP Rocket.
- Divi Static CSS.
- Divi’s own CSS optimization behavior.
- Other performance tooling that had previously handled critical CSS.
During staging implementation, Freshy isolated the most important practical conflict: WP Rocket’s Remove Unused CSS feature was interfering with Divi’s final header styling.
That is an important distinction. Remove Unused CSS was intended to improve page performance, but on this site it changed when or how required Divi styles became available. The result was a visible layout shift in the header.
The optimization target therefore changed from “turn on every available performance feature” to “keep only the combination that produced a stable final layout.”
Resolution steps
The documented implementation was:
- Review the GTmetrix bottlenecks. Freshy prioritized CLS, TBT, and the large initial page payload rather than focusing on LCP, which was already comparatively strong.
- Work on staging first. Performance settings were changed away from production so the team could compare visual behavior and metrics safely.
- Test the overlapping CSS optimization stack. The site was using both Divi-specific styling optimization and WP Rocket optimization, so Freshy tested which combinations remained visually stable.
- Disable WP Rocket Remove Unused CSS. This was the key verified fix because the feature conflicted with Divi’s final header styling and contributed to the large CLS measurement.
- Keep Divi Static CSS enabled. Divi’s generated static CSS remained part of the final configuration.
- Keep WP Rocket caching and minification enabled. The goal was not to disable WP Rocket completely, only the conflicting Remove Unused CSS feature.
- Keep delayed and deferred JavaScript enabled. JavaScript optimization remained part of the final staging configuration.
- Keep RocketCDN enabled. CDN delivery remained active after the optimization pass.
- Keep the Vimeo hero intact. Although the original audit identified the video as a major payload opportunity, the final documented implementation did not remove it.
- Retest staging after the configuration changes. The staging GTmetrix grade improved from D / 54% to A.
- Verify layout stability in the browser. CLS dropped from 0.603 to approximately 0.006 in browser testing.
- Deploy the approved changes to production. After internal review confirmed that the front-end experience remained intact, Freshy pushed the performance configuration live on September 25.
- Run a live GTmetrix check. A production GTmetrix test was completed after deployment.
The original audit also recommended work such as self-hosting and preloading fonts, reducing third-party JavaScript, consolidating analytics tags, optimizing additional media, and changing the initial video-loading strategy. The final task comments do not document each of those recommendations as completed, so they should be treated as audit findings rather than confirmed implementation details.
Final outcome
The staging optimization produced a substantial measurable improvement without removing the site’s existing Divi design or Vimeo hero.
The verified staging results were:
- GTmetrix improved from D / 54% to A.
- CLS dropped from 0.603 to approximately 0.006.
- Divi Static CSS remained enabled.
- WP Rocket caching, minification, delayed/deferred JavaScript, and RocketCDN remained enabled.
- WP Rocket Remove Unused CSS was disabled because it conflicted with Divi’s final header styling.
The changes were then deployed to production, and Freshy ran a new live GTmetrix test after launch.
The broader lesson is that WordPress performance optimization is not about enabling every optimization setting at once. Divi, WP Rocket, CDNs, marketing scripts, and other performance tools can all modify the page-loading pipeline. A feature that improves one metric in isolation may create layout instability or visual regressions when combined with another system.
If your Divi site has a high CLS score or becomes visually unstable after enabling WP Rocket Remove Unused CSS, contact Freshy. Our WordPress team can test the optimization stack on staging, isolate conflicting settings, and improve performance without sacrificing the final layout.
