How to improve WordPress performance with WP Rocket and Divi

WordPress performance problems often come from several overlapping issues rather than one single bottleneck. In this case, a Divi site had a heavy homepage, overlapping optimization plugins, inefficient caching, large hero images, render-blocking resources, and costly third-party scripts. By tuning WP Rocket, removing WP-Optimize, validating WP Cloud caching, resizing images, reducing hidden homepage content, and carefully delaying JavaScript, the site improved from a GTmetrix grade of C to A. Largest Contentful Paint dropped from 3.6 seconds to 2.0 seconds, while Total Blocking Time fell from 284 milliseconds to 67 milliseconds.

Issue background

A WordPress site had been consistently testing in the poor performance range, raising concerns about user experience and Core Web Vitals.

Initial performance testing showed several likely contributors:

• Caching was not fully optimized.
• Render-blocking CSS and JavaScript delayed the initial page render.
• Fonts were loading inefficiently.
• The homepage was approximately 5.8 MB and generated around 120 requests.
• Large hero images increased page weight.
• Hidden homepage content was still loading even when it was not visible.
• Third-party scripts added CPU and network overhead.

The site also used multiple performance-related tools at the same time, including WP Rocket and WP-Optimize, creating the possibility of overlapping optimization behavior.

Diagnosis

The performance review showed that the slowdown was distributed across caching, frontend assets, media, page complexity, and third-party JavaScript.

WP Rocket was installed but not fully configured. At the same time, WP-Optimize was also active. Running multiple plugins that manage caching, minification, or database optimization can produce conflicts, duplicate work, or inconsistent results.

The site’s WP Cloud cache integration also needed to be reviewed and updated so the hosting-level cache could continue acting as the primary page-cache layer.

Divi added another complication. Aggressively delaying JavaScript could produce better benchmark scores, but delaying the wrong slider dependencies caused the hero content to load only after user interaction. That created a clear tradeoff between a higher synthetic score and a worse perceived experience.

The homepage itself was also carrying unnecessary weight. Hidden content was still being rendered and downloaded, and oversized hero media increased Largest Contentful Paint.

Third-party scripts remained another significant cost. The review specifically considered:

• AudioEye
• Hotjar
• LinkedIn tracking
• Google Tag Manager
• ZoomInfo
• Gravity Forms
• Google reCAPTCHA

These scripts were not all removed. Instead, the strategy was to delay them where business requirements allowed while preserving critical functionality.

Resolution steps

1. Establish a performance baseline. Capture the GTmetrix grade, Performance score, LCP, TBT, CLS, and Fully Loaded time before making changes.
2. Work in staging first. Test all caching and JavaScript changes away from production so layout or functionality regressions can be identified safely.
3. Configure WP Rocket properly. Tune caching, minification, JavaScript delay, lazy loading, and preload behavior based on the site’s real frontend dependencies.
4. Remove WP-Optimize. Avoid overlapping cache and optimization plugins when WP Rocket and WP Cloud are already handling the relevant layers.
5. Validate WP Cloud caching. Confirm that the hosting cache integration is current and operating as expected.
6. Resize oversized hero images. Reduce image dimensions and file sizes so the LCP asset can load more quickly.
7. Use compressed modern image formats. Maintain optimized WebP assets and avoid replacing them with unnecessarily large uploads.
8. Remove hidden homepage content. Delete or restructure content that loads even though visitors never see it.
9. Delay non-critical JavaScript. Push third-party and lower-priority scripts later in the loading sequence where possible.
10. Add precise Divi exclusions. Exclude only the slider and hero dependencies that break when delayed instead of disabling JavaScript delay broadly.
11. Prioritize the LCP asset. Preload the actual first hero image and exclude that one image from lazy loading.
12. Reduce font overhead. Load only the font families, weights, and styles actually used by the design.
13. Review third-party scripts individually. Delay AudioEye, Hotjar, LinkedIn, Google Tag Manager, ZoomInfo, and reCAPTCHA where the site’s requirements allow.
14. Load reCAPTCHA only when needed. Avoid loading Gravity Forms reCAPTCHA assets across unrelated pages when the form workflow permits conditional loading.
15. Warm the cache before benchmarking. After a cache purge, preload the site and run GTmetrix more than once. Use a warmed result for comparison.
16. Perform full functional QA. Test navigation, forms, responsive layouts, sliders, animations, and other interactive components before deployment.
17. Deploy the tested configuration. Move the staging changes to production only after the site behaves correctly.
18. Monitor both lab and field metrics. Use GTmetrix for repeatable before-and-after testing, while allowing time for Google Core Web Vitals field data to refresh after production changes.

The most important optimization tradeoff involved JavaScript delay. A more aggressive configuration could produce a higher benchmark score, but if the hero slider did not render until the user interacted with the page, the resulting experience was worse. The final configuration therefore prioritized perceived speed and functional stability over a perfect synthetic score.

Final outcome

The optimized staging site improved significantly before the same changes were deployed to production.

The documented before-and-after GTmetrix results were:

• GTmetrix grade: C → A
• Performance: 56% → 89%
• Structure: 91% → 97%
• Largest Contentful Paint: 3.6s → 2.0s
• Total Blocking Time: 284ms → 67ms
• Cumulative Layout Shift: 0 → 0
• Fully Loaded: 9.9s → 2.0s

The production deployment retained WP Rocket as the primary optimization plugin alongside WP Cloud caching, while WP-Optimize was removed. Critical Divi and slider dependencies were excluded from aggressive JavaScript delay, hero media was optimized, and unnecessary content weight was reduced.

The remaining recommendations focused on continued third-party script reduction, font cleanup, leaner homepage content, and retesting after future plugin, theme, tracking, or content changes.

The key lesson is that WordPress speed optimization works best as a coordinated stack. Caching, media, JavaScript, fonts, page-builder complexity, and third-party scripts all need to be tuned together, and the best configuration is the one that improves both measured performance and the real experience of using the site.

For help optimizing WP Rocket, improving Divi performance, or troubleshooting slow WordPress pages, contact Freshy.