If your site is hosted on a LiteSpeed server with LSCache active, installing a second caching plugin — WP Rocket, W3 Total Cache, WP Super Cache — does not add performance. It creates conflict. Two caching systems trying to serve the same pages simultaneously produce cache invalidation problems, duplicate headers, and debugging nightmares that eat hours.

The specific problem: WP Rocket and W3 Total Cache load their own scripts and initialisation code on every page load, adding PHP overhead even when they are supposed to be reducing it. On a LiteSpeed server where the cache is handled at the server level before PHP ever runs, this overhead is entirely wasted.

Use instead: LiteSpeed Cache (LSCache) plugin only — free, works at the server level, handles caching, minification, image optimisation, and critical CSS in one plugin with zero redundancy

Page builders are one of the most common performance culprits on WordPress sites — not because page builders are inherently slow, but because many of them load their entire library of CSS and JavaScript on every single page, regardless of which elements are actually used on that page.

A page builder that loads 500KB of CSS and 300KB of JavaScript on a simple text-heavy blog post that uses none of its special widgets is adding 800KB of render-blocking resources for zero functional benefit. This shows up directly as poor LCP and high Total Blocking Time (TBT) scores in PageSpeed Insights.

The worst offenders tend to be older, feature-heavy builders that were not architecturally designed with performance in mind. More modern builders have addressed this with conditional asset loading — scripts only load on pages that actually use the relevant elements.

Use instead: Builders with conditional asset loading (Bricks Builder, Kadence Blocks, or the native WordPress block editor for simpler sites). If you are committed to your current builder, enable its “load assets only when needed” option if available — most modern versions have this setting buried in the performance section.

Slider plugins are among the heaviest plugins in the WordPress ecosystem relative to the value they provide. A typical slider plugin loads 100–300KB of JavaScript and CSS on every page it appears on, introduces Cumulative Layout Shift (CLS) while the slider initialises, and often blocks the main thread during the loading sequence — all of which directly damages Core Web Vitals scores.

The performance damage is compounded by the fact that sliders are almost always placed above the fold — in the hero section — which is exactly where the browser is most sensitive to render-blocking resources. The LCP element on many WordPress sites is a slider image, and the slider plugin’s scripts are often the primary reason that image takes so long to render.

There is also substantial evidence from conversion rate research that sliders perform poorly as marketing elements — visitors rarely interact with slides beyond the first one, and the animated, auto-advancing format tends to distract rather than convert.

Use instead: A static hero image with text overlay, built directly in your theme or page builder. Faster, better for LCP, and consistently better for conversion rates than a slider in virtually every A/B test ever run on the subject.

Plugins that embed live social media feeds — Instagram grids, Twitter/X timelines, Facebook page feeds — make external API calls on every page load where the feed appears. These external requests add latency that your server cannot control. If Instagram’s API is slow to respond, your page waits. If Twitter’s embed script takes two seconds to load, that two seconds shows up in your page load time.

Beyond the API latency issue, most social feed plugins load heavy JavaScript libraries, make multiple external DNS lookups, and inject third-party cookies — all of which add measurable overhead and potential GDPR compliance complications.

Use instead: A manually curated grid of screenshots linking to your social profiles, or simply link to your profiles from your site rather than embedding live feeds. The conversion value of a live feed versus a static grid with a “Follow us” link is negligible, and the performance cost is significant.

Typography plugins and theme font managers that load multiple Google Fonts families — or worse, load the same font family multiple times from different sources — are a consistent source of render-blocking requests and Cumulative Layout Shift.

Every Google Fonts request is an external DNS lookup, an external connection, and a file download before the font can be displayed. During that wait, the browser either shows no text (Flash of Invisible Text — FOIT) or shows a fallback font that shifts when the web font loads (Flash of Unstyled Text — FOUT). Both contribute to CLS scores and poor perceived performance.

The specific anti-pattern to avoid: loading four different font weights of the same typeface when only two are actually used on the site. Font subsets add up quickly.

Use instead: Self-host your fonts rather than loading from Google’s CDN — download the font files, upload them to your server, and reference them from your own domain. This eliminates the external DNS lookup and connection overhead entirely. The LiteSpeed Cache plugin can handle Google Fonts localisation automatically.

Not all contact form plugins are equal in performance terms. Some of the most popular form plugins — certain versions of Contact Form 7 being the most commonly cited example — load their JavaScript and CSS files on every single page of your site, regardless of whether that page contains a form. A form plugin loading scripts on your blog posts, your about page, and your 404 page is adding unnecessary overhead to every page load across the entire site.

The fix should be the plugin’s responsibility — loading scripts only on pages where a form actually exists. Some plugins do this correctly. Others do not, and the setting to control it is buried or nonexistent.

Use instead: Fluent Forms or WPForms Lite — both load assets conditionally, only on pages that contain a form. If you are committed to Contact Form 7, install the “CF7 Conditional Fields” or a script manager plugin that lets you restrict where CF7’s scripts load.

Running two SEO plugins simultaneously — Rank Math and Yoast SEO being the most common combination — doubles the SEO-related overhead on every page load. Both plugins generate meta tags, both inject their own scripts, both run their own database queries, and they occasionally conflict with each other’s output in ways that produce duplicate or malformed meta tags.

Beyond the performance cost, two SEO plugins create a management problem — which one’s settings take precedence? Which one’s sitemap should you submit to Google? The confusion alone makes this combination worth avoiding.

Use instead: One SEO plugin. For LiteScaler users, Rank Math is the recommendation — it provides more functionality in the free tier than Yoast and has a lighter performance footprint. Pick one, configure it properly, deactivate and delete the other.

Some image optimisation plugins — particularly older ones — process and compress images on the fly, as they are requested, rather than pre-processing them at upload time. This means every image request triggers a PHP execution to apply compression, which adds server-side processing overhead to every page load that includes images.

On a high-traffic site, this processing overhead compounds significantly. A page with 15 images, each triggering an on-the-fly optimisation routine, is running 15 additional PHP processes for something that should have happened once at upload time.

Use instead: LiteSpeed Cache’s built-in image optimisation — it processes images server-side in batch, converts to WebP automatically, and serves the optimised version from cache. No on-the-fly processing, no additional PHP overhead per request.

Live chat plugins — Tawk.to, Intercom, LiveChat, Drift — almost universally load their scripts on every page of your site, all the time, regardless of whether the chat widget is visible or whether the user is likely to need it. These scripts are typically loaded from third-party CDNs, adding external DNS lookups and connection overhead to every page load.

The Intercom JavaScript bundle alone is over 200KB. Loaded on every page, on every visit, by every user — including users who will never click the chat widget — this is a consistent and meaningful performance cost for a feature that a small fraction of visitors use.

Use instead: Lazy-load your chat widget — load the script only after the page has finished loading, or only when the user scrolls to a certain point or hovers near the chat button. Most chat platforms support this via their advanced embed settings. The chat functionality is unchanged; the performance impact drops to near zero.

Security plugins are necessary — but the configuration matters enormously for performance. Wordfence in particular, configured with real-time traffic scanning and frequent full-site scans running during peak hours, can consume significant server CPU and slow down page responses noticeably.

The specific performance killers: live traffic monitoring that logs every request to a database table (creating constant write operations), full file system scans scheduled during business hours rather than off-peak, and overly aggressive firewall rules that run complex pattern matching on every request.

None of this means security plugins should be avoided — they are genuinely important. It means they should be configured thoughtfully, with scans scheduled for 2–4am, live traffic logging turned off unless you are actively investigating an incident, and firewall rules reviewed to ensure they are not catching legitimate traffic.

Use instead: Keep your security plugin, but reconfigure it. Schedule scans for off-peak hours. Disable live traffic logging unless needed. On LiteScaler, server-level security scanning runs independently of any WordPress plugin — which means the plugin’s scanning is supplementary rather than your primary defence, and you can configure it more conservatively without sacrificing protection.