The No-BS WordPress Speed Optimization Guide for Founders

Start by removing work your platform does not need. Do not start by buying another speed plugin.

I’m Chris, founder of Directorism. I’ve personally sped up hundreds of WordPress directories and marketplaces. This WordPress speed optimization guide explains what I inspect first, how we find the real bottleneck, and what I would require before calling the job finished.

A fast homepage is not enough. Providers still need to edit listings, customers need to book, and your team needs a usable dashboard. A green GTmetrix score does not prove those actions are fast.

Use this guide to decide what to fix first, what can wait, and what to ask your developer. The opening checklist is for founders; the later sections are a technical reference. No rebuild or theme change is assumed.

Run our free performance audit for a first look at your site’s speed. Enter your URL, preview the findings and get the full report by email.

It’s a starting point, not a complete diagnosis. It cannot identify slow backend plugins or test private dashboards and logged-in bookings. A good public score doesn’t mean everything is fast.

Start here: your first five checks

My first audit is the plugin list. My first fix follows the evidence. On a mature site, removing redundant plugins and replacing a proven slow dependency can remove substantial wasted work. On a lean site, a large image, missing cache or overloaded server may matter more.

1. Name the slow action. Opening a listing, changing a filter, submitting a booking and editing the dashboard are different tests. Record the URL and whether the user is logged in.
2. Give each plugin a job. Write one sentence explaining why it is needed. Mark duplicates and features you no longer use.
3. Check theme dependencies. Keep Elementor, WooCommerce and required addons when your theme, templates or payment flow depends on them.
4. Ask for two kinds of evidence. PageSpeed Insights or GTmetrix for browser loading; Code Profiler or Query Monitor for slow WordPress requests.
5. Agree one safe test with your developer. Use staging: a separate copy of the site with live payments, customer emails and webhooks disconnected. Compare the same action before and after, including whether it still works.

What you should have at the end: one reproducible complaint, a shortlist of plugins to investigate, and a safe first test. Not a shopping list.

Choose the section you need:

• Which fixes come first
• Plugins to remove, replace or restrict
• How to find slow plugins
• When WP Rocket and Perfmatters fit
• Checks before calling the job finished

Why a directory can be fast until someone logs in

A full-page cache reuses ready-made HTML. That works well for public pages shared by visitors. A personalized dashboard or booking request often needs fresh WordPress and database work instead.

Caching the homepage does not fix a slow booking request. Profile the request, remove unnecessary work and optimize what remains. Logged-in users can still benefit from object caching, PHP OPcache and cached images, CSS and JavaScript. “Cache plugins fix everything” and “caching does nothing for members” are both wrong.

Required theme plugins are not automatically bloat. For Listeo, Voxel, MyListing or another directory stack, check the theme’s documentation and the actual templates before removing dependencies. Keep the features your business needs; remove work the site does not use.

The S-tier WordPress performance fixes

This is our default audit order, not a universal diagnosis. S+ means the first place we inspect on a mature, plugin-heavy site. Measurements from the slow business journey always override the list.

• S+ and S: inspect early because they often remove the most wasted work.
• A: high-impact when the evidence points there.
• B and C: useful supporting or finishing work, rarely the whole diagnosis.

What “fast” actually means

A fast WordPress site responds quickly across its important public and logged-in journeys. It shows the main content promptly, responds to interactions, keeps the layout stable, generates uncached pages without long waits, and completes business actions without errors.

No single score describes all of that.

PageSpeed Insights provides Lighthouse lab tests and, when enough eligible real-user samples exist, field data. A missing field report does not mean the site passed. A lab score helps diagnosis; it is not a substitute for user evidence.

GTmetrix adds a request-by-request browser waterfall that makes large files, third-party calls, render-blocking work, and poor request order easier to inspect. It is a diagnostic view, not a Google ranking report.

Current Core Web Vitals

These values come from Google’s Core Web Vitals definition. FID is no longer a Core Web Vital; INP replaced it.

The terms founders need

• LCP (Largest Contentful Paint): how quickly the main visible image or content block appears.
• INP (Interaction to Next Paint): how quickly the page visibly responds after a visitor clicks, taps, or types.
• CLS (Cumulative Layout Shift): how much the page jumps around while loading.
• TTFB (Time to First Byte): how long it takes from requesting a page until the browser receives the first byte, including connection and server time.
• Autoload: WordPress settings loaded into many requests, whether a page needs them or not.
• WP-Cron and Action Scheduler: systems that run background work such as emails, imports, renewals, and cleanup jobs.
• OPcache: a PHP cache that avoids recompiling the same code on every request.
• APM (Application Performance Monitoring): profiling that shows where server-side time is spent.

Core Web Vitals matter, but do not turn them into SEO superstition. Google says a perfect score does not guarantee rankings and relevance remains more important. Aim for a genuinely good experience, not a ceremonial 100. See Google’s page experience guidance.

Benchmark the journeys that run the business

Test the homepage, but also test:

• Category, archive, and search results
• Single listings, providers, and products
• Filters, sorting, maps, and location search
• Registration and login
• Listing submission and profile editing
• Booking, enquiry, quote, cart, and checkout
• Customer and provider dashboards
• WordPress admin screens used by the team
• Imports, emails, webhooks, and scheduled jobs

If the homepage is cached but the provider dashboard is generated for every request, they are different performance systems.

Where the delay comes from

The layers interact. Slow HTML can delay discovery of images and scripts; assets already cached or served by a CDN may not share that server delay. Excess JavaScript can delay rendering even after an image downloads. A plugin can be light on public pages and expensive in admin or checkout.

Plugin cleanup: our S+ first audit on mature sites

Do not optimize for plugin count. Optimize for useful work. One expensive plugin can matter more than many small ones. An unused plugin can also add little measurable runtime cost; removing it is still maintenance, but do not invent a speed gain.

The practical question is:

What business function does each plugin own, where does it run, what work does it add, and is something else already doing the same job?

Write down what each plugin does

If nobody can explain the business function, investigate before keeping it. Where two tools duplicate the same work, choose one. Coordinated cache layers are different: they can serve distinct purposes.

How to find slow WordPress plugins without guessing

Do not condemn a plugin because it appears on somebody's blacklist. A useful WordPress plugin performance audit measures what each candidate costs on the route that is actually slow.

The developer or site maintainer should run these tools on staging. The founder's job is to require comparable evidence, protect the business-critical journeys, and approve the tradeoff before a feature is removed.

Before replaying a form, booking, checkout or scheduled job, isolate staging from live payments, customer emails, webhooks and external integrations. Use test payment keys and test recipients. A copy of production is not automatically safe to exercise.

1. Run PageSpeed Insights on representative public URLs. Its field data summarizes the previous 28 days, so check whether it describes that URL or the whole origin. Use repeated Lighthouse lab runs to diagnose the current route.
2. Open the same URLs in GTmetrix and inspect the waterfall. Find the largest scripts, styles, images, fonts, redirects, and third-party requests, then trace each one back to its owner.
3. On staging, run Code Profiler against the exact uncached frontend page, backend screen, cron event, AJAX action, form, or checkout request that is slow. The free edition compares plugin and theme PHP cost; Pro adds script, method/function, query, remote-call, and detailed file-operation profiling.
4. Use Query Monitor when you need request-level evidence about queries, hooks, PHP errors, HTTP calls, and the component responsible.
5. Deactivate, configure, or replace one candidate on staging, clear the relevant caches, and repeat the same test. The before/after comparison decides whether it was a bottleneck.

Code Profiler and browser tools answer different questions. Code Profiler measures server-side PHP execution. PageSpeed Insights and GTmetrix measure what the browser receives and does. Neither proves that a plugin is always slow, and no single run describes every page, login state, cache state, or traffic level.

Our rule: use profiling to find a suspect, then use a controlled before-and-after test to confirm the cause. The largest timing bar is not automatically the best removal target.

The overlap patterns we inspect first

1. Multiple page caches. WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, host cache, and Cloudflare full-page cache can overlap. Every layer needs a scope, purge path, and exclusion policy.
2. Multiple CSS/JavaScript optimizers. WP Rocket, Perfmatters, Autoptimize, LiteSpeed Cache, host tools, and theme settings may all offer minification, defer, delay, unused CSS, or file combination. Do not let two tools rewrite the same assets.
3. Multiple lazy-load or image systems. WordPress core, WP Rocket, Perfmatters, ShortPixel, Imagify, Optimole, Jetpack, a CDN, and the theme may all touch formats, resizing, lazy loading, or CDN rewrites.
4. Multiple database cleaners. Three schedulers deleting revisions and transients create more maintenance work, not a better strategy.
5. Duplicate analytics, pixels, chat, consent, reviews, and maps. These often arrive through plugins, Tag Manager, theme settings, and hard-coded snippets simultaneously.
6. Theme features duplicated by plugins. Sliders, related content, forms, schema, breadcrumbs, icons, sharing, and popups are common examples.
7. Leftovers from removed plugins. Check remaining tables, options, scheduled events and mu-plugins. Leftover data is not automatically a performance problem; establish what still loads or runs before cleaning it.

What we most often remove, replace, or restrict

Finding five to ten plugins to remove, consolidate or replace has been a recurring pattern in my optimization work, not a quota for your site.

This is an audit shortlist, not a ranking of the slowest plugins. Product names alone do not establish cost. Keep a necessary feature; configure, restrict or replace its implementation when measured performance justifies it.

You do not need to audit every name here. Find the tools your site uses, then take the relevant questions to your developer.

Keep standard Elementor and WooCommerce when your theme, templates or working business features require them. They are not part of this removal shortlist. The target is unnecessary addons, duplicated features and systems doing a small job with an oversized implementation.

Page builders and visual extras

• All third-party Elementor addon packs: remove unused packs. Keep only the packs and widgets required by working templates. Check Essential Addons, Ultimate Addons, Unlimited Elements, Premium Addons, Happy Addons and ElementsKit. Disable unused elements where supported and test the layouts before removal.
• Elementor Pro: keep required templates, forms, dynamic content or other Pro features. If nothing depends on it, test removal before cancelling a license needed for updates or other sites.
• Slider Revolution: replace it for simple heroes. Use a static headline and optimized image instead of a full slider system. Preserve required interactions when replacing a more complex implementation.
• NextGEN Gallery: replace it for ordinary galleries. Use native gallery blocks and a focused lightbox if needed. Keep it only when the business uses its advanced gallery management, proofing or sales features.

Business features

• Jetpack: not in our recommended stack. Our recommendation is to replace it, not keep an all-purpose suite for a handful of features. Use focused plugins, hosting services or small, maintained functions for the jobs you actually need. Move required security, backups and content delivery to tested replacements before removing it.
• WPML / String Translation: not in our recommended stack. We recommend an alternative such as TranslatePress for multilingual builds, with compatibility and performance testing against the actual directory or marketplace. For an existing WPML site, plan the replacement: preserve translations, language URLs, SEO metadata and booking or checkout behaviour before switching. This is a migration, not a deactivate-and-install shortcut.
• The Events Calendar / Pro: replace it when you only need a basic event list. Use a simple listing template for dates and descriptions. Keep it only when required recurrence, calendar views or ticket integrations justify it; test the actual slow view and event volume.
• LearnDash: replace it when you only need protected articles. Keep a full LMS only for required features such as progress tracking, quizzes, enrolment and reporting.
• BuddyPress: remove it if you only need ordinary accounts. Do not carry activity streams, groups and messaging that the business does not use. Check theme dependencies before removal.
• bbPress: remove abandoned forum functionality. Preserve useful discussion content and URLs first. Keep it for a forum your business actually uses.
• Relevanssi: remove it when native or existing external search already meets your needs. If its improved search is required, keep the index focused on useful content.

Tracking, scanning and background work

• Broken Link Checker, local mode: scan on demand or off-server instead of continuously crawling from your own hosting.
• WP Activity Log: retain needed security and audit evidence. Limit unnecessary events and set a retention policy.
• WP Statistics: remove it when it duplicates analytics you already use. If self-hosted analytics is a deliberate requirement, keep it and aggregate or expire detail you no longer need.
• MailPoet: remove it when another system already handles the same email work. Transfer subscribers, consent records and active automations, and verify delivery before removal.
• Redirection: keep needed redirects; limit 404 and redirect logs nobody uses. Verify migrated rules before removing a duplicate plugin.
• Query Monitor: use it to diagnose problems. Its collection adds overhead; disable it after the investigation unless ongoing diagnostics justify it.

Optimization tools

• Overlapping optimizers: give WP Rocket, Perfmatters, LiteSpeed Cache, W3 Total Cache, Autoptimize, host tools and Cloudflare distinct jobs. Avoid duplicate asset rewriting. Multiple cache layers need coordinated exclusions and purging.

Wordfence and UpdraftPlus are not removal recommendations. Preserve security and recoverable backups. Verify equivalent coverage, off-site backups and a successful restore before removing a duplicate control.

Our exclusion of Jetpack and WPML is a Directorism stack recommendation, not a claim that every installation is slow or every alternative is faster. TranslatePress also needs performance and compatibility testing. Vendor documentation supports the audit checks, not a universal slowest-plugin ranking. See the linked sources under Primary references.

Do not bulk-deactivate this list. Test one candidate at a time, including the features and data that depend on it.

A custom PHP function is not automatically faster, safer, or easier to maintain. Keep site-specific business logic in a small documented plugin or mu-plugin where practical, test it, and assign an owner.

Remove a plugin safely

1. Confirm its business function and data owner.
2. Capture a baseline on the routes where it runs.
3. Check tables, options, scheduled events, shortcodes, blocks, webhooks, and integrations.
4. Deactivate it on staging.
5. Clear every relevant cache.
6. Retest public and logged-in flows, emails, webhooks, checkout, and admin.
7. Compare the profile and browser waterfall.
8. Only then remove it and its confirmed orphaned data.

Never use “delete all orphaned data” as a blind speed technique. Orphan detection is imperfect, ownership can be obscure, and the gain may be zero.

Load scripts only on pages that need them

A form plugin may be necessary on one page and wasteful everywhere else. A map may belong on search and listing pages but not the blog. WooCommerce assets may be unnecessary on editorial pages.

The cleanest fix is for the plugin or theme to enqueue assets only where needed. Otherwise use tested custom dequeue logic or a route-level asset manager.

Perfmatters Script Manager can disable scripts and styles everywhere, by URL, post type, user state, or device. Testing mode lets administrators preview rules. MU mode can also suppress plugin hooks, queries, and inline assets, but it is more powerful and belongs on staging first. Device-specific rules require a cache that varies by device; otherwise, a shared page cache can serve the wrong asset set, so do not use device rules.

Script Manager targets frontend pages, not scripts in WordPress admin. It is not the fix for every slow dashboard or background job.

Do not disable files from names alone. Test dependencies and the complete interaction. A payment, booking, search, consent, or authentication script may appear unused until someone clicks.

When WP Rocket and Perfmatters fit

Neither product is magic. Both can be excellent with a defined role.

WP Rocket: page caching and loading improvements

WP Rocket is a strong default when a site needs an approachable layer for page caching, preload, browser caching, compression, CSS/JavaScript optimization, lazy loading, fonts, and related delivery work.

Use it when the host does not already provide adequate page caching, public pages represent meaningful traffic, and the team can test dynamic exclusions and frontend compatibility.

Do not add it merely to have another “speed plugin.” Some managed hosts already own page caching. WP Rocket may still provide frontend optimization there, but its responsibility must be documented.

For WooCommerce, keep Cart, Checkout, and My Account dynamic. WooCommerce’s official caching guidance also documents customer session cookies. Directory dashboards, listing submission, bookings, personalized search, membership pages, and nonce-dependent flows need equivalent care.

Perfmatters: control what loads and where

Perfmatters is strongest as a surgical layer. Script Manager, route-specific controls, Delay JS, Remove Unused CSS, font/media settings, WordPress bloat controls, and database tools help when the problem is unnecessary work rather than missing page cache.

Use it when plugins load assets on irrelevant routes, you need controlled Script Manager testing, or a page cache already exists at the host, plugin, or edge layer.

Can they run together?

Yes, with a responsibility map:

Use one owner per transformation, and explicitly coordinate layered caches. If WP Rocket owns Remove Unused CSS, disable it in Perfmatters. If Perfmatters owns Delay JS because its exclusions are easier to control, disable WP Rocket’s version. Origin page cache, a reverse proxy, and an edge cache can coexist, but their scope, cache keys, exclusions, purging, and invalidation must agree. Document every decision so the next developer does not turn everything back on.

For WooCommerce with WP Rocket, WooCommerce’s linked guidance recommends avoiding JavaScript file minification. Treat that as a compatibility precaution, not proof that minification always breaks checkout. Test changes against the exact store and payment flow.

What about LiteSpeed Cache and Autoptimize?

LiteSpeed Cache can be the right primary cache on a LiteSpeed/OpenLiteSpeed stack. Autoptimize can be useful for frontend assets when another layer owns page caching. Host tools can be correct when tightly integrated with server caching.

The product matters less than ownership. Do not install WP Rocket on a good LiteSpeed stack because a listicle called it “best.” Do not keep Autoptimize rewriting the same files as WP Rocket or Perfmatters. Do not enable every host, Cloudflare, theme, and plugin toggle at once.

Diagnostic tools, not more permanent optimizers

Query Monitor is our first diagnostic plugin for slow dynamic WordPress requests. It adds a small amount of timing and memory overhead, so use it deliberately and disable it on production when the investigation ends or during unusually heavy operations.

Code Profiler is useful when the first question is specifically, “Which plugin or theme is consuming PHP time on this request?” Run it on staging and repeat representative profiles before assigning cost.

WordPress speed optimization guide: the no-BS audit order

1. Protect the site

• Verify current file and database backups.
• Use staging where the problem can be reproduced.
• Isolate that staging copy from live payments, customer emails, webhooks and external integrations. Use test payment keys and test recipients before replaying bookings, checkout or scheduled jobs.
• Record WordPress, PHP, theme, plugin, cache, CDN, and DNS state.
• List the business-critical journeys.
• Decide how every risky change rolls back.

Do not bulk-update plugins, change hosting, add Cloudflare, and tune JavaScript in one measurement window. You will not know what helped or broke.

2. Define the complaint

“The site is slow” is not a test. Write something reproducible:

A logged-out mobile visitor opens a listing from Lisbon search. The main image appears late, the map blocks scrolling, and the enquiry modal responds slowly on first interaction.

Record the URL, user state, device, location, cache state, exact action, and whether it is slow or failing.

3. Split HTML time from browser time

• Slow initial HTML: investigate cache, hosting, PHP, hooks, queries, remote APIs, and jobs.
• Fast HTML but late usability: investigate images, JavaScript, CSS, fonts, rendering, and third parties.
• Slow click/form: inspect the AJAX, REST, GraphQL, or admin-ajax request it triggers.

4. Profile the responsible layer

Use Code Profiler for plugin/theme PHP-cost comparisons and Query Monitor for request-level WordPress evidence. WP-CLI’s profile command can stage bootstrap, main query, and template work; it is a separate package when not already installed. Use APM for intermittent production-only backend delays.

Caching: define what is safe to reuse

Verify cache hits through response headers or provider signals. Compare a miss and hit. Use two isolated browser sessions as different users to check for cross-user leakage in the tested personalized journeys and cache states.

Exclude customer-specific HTML routes such as login, password reset, account, cart, checkout, payment return, booking state, dashboards, listing editing, and personalized search from full-page and edge caching. Keep webhook endpoints outside page caching. Treat nonce-bearing pages separately: cache them only when nonce lifetime, cache lifetime, user context, and invalidation are coordinated. These routes can still benefit from safe lower-level layers such as OPcache, persistent object cache, browser asset caching, and CDN caching for static assets.

Remove work before delaying it

Use this order:

1. Remove the feature if the business does not need it.
2. Remove the duplicate implementation.
3. Stop assets loading on irrelevant routes.
4. Replace an unusually heavy dependency when justified.
5. Defer code that can run after parsing.
6. Delay code that can wait for interaction.
7. Minify what remains only when the platform and compatibility tests support it.

High-cost candidates include maps, chat, reviews, consent, advertising, reCAPTCHA, sliders, animation libraries, social feeds, heatmaps, and duplicate analytics.

When delaying JavaScript, test the first click on menus, filters, consent, cart, date pickers, modals, and forms. A page can look correct and fail on interaction.

Images: fix the pipeline, not one media library

The likely LCP image should be discoverable from the initial HTML response, correctly sized, responsive, compressed, and not lazy-loaded when above the fold. Use WebP or AVIF where the workflow supports it. Add preload or fetch priority only when evidence identifies the image as critical. Google’s LCP guidance explains why early discovery matters.

For provider uploads, define maximum dimensions, formats, generated variants, compression, cropping, original-file retention, and abandoned-media cleanup. A marketplace cannot rely on every provider uploading a perfect image.

Database and background work

Database cleanup is not “delete every revision and transient.” Find data and work that slows the affected request.

Review large autoloaded options and identify owners before changing anything. WordPress Site Health’s autoload test is the current reference.

Look for slow or repeated queries, uncapped result sets, missing indexes, excessive metadata joins, synchronous remote calls, and plugins querying routes that do not use them. Redis or Memcached can help repeated work; it does not make a bad query good.

For WP-Cron and Action Scheduler, inspect overdue and failed actions, runaway rescheduling, queue growth, backups/imports at peak time, and jobs processing too much per batch. Fix the producer. Deleting the queue only hides it.

Hosting: change it when evidence points there

Upgrade or move when CPU, memory, storage, database, or PHP workers saturate under normal traffic; requests queue after application cleanup; the platform lacks current PHP, OPcache, backups, monitoring, or cache controls; or origin distance harms dynamic users.

Do not migrate because an affiliate benchmark named a “fastest host.” A migration can change DNS, cache, PHP, extensions, filesystem, email, cron and database behavior. Plan rollback and acceptance tests. Improve the current WordPress implementation before assuming a rebuild is necessary; our platform assessment guide is for the separate decision about genuine architectural limits.

Directory, marketplace, and WooCommerce traps

• Search/maps: separate database query time from map rendering. Do not load every marker and full listing payload at once.
• Dashboards: they are commonly uncached and depend on PHP, queries, APIs, and object cache.
• Bookings: availability can multiply queries by provider, service, location, and slot. Never trade correctness for a score.
• Checkout: exclude customer-specific HTML from full-page and edge caching, then test gateways, tax, shipping, coupons, emails, and return URLs. Safe lower-level caches can remain.
• Imports: batch them away from peak traffic; measure memory, locks, queues, image generation, and cache purges.

WooCommerce High-Performance Order Storage can improve order-data architecture, but verify extension compatibility using the official HPOS documentation.

Acceptance criteria

Evidence

• Before and after use the same URL, device, location, login, and cache condition.
• Use repeated runs or a median, not the best screenshot.
• Separate field data from lab data.
• Distinguish initial HTML, browser work, and dynamic actions.

Functionality

• Navigation, search, filters, maps, registration, login, and account actions work.
• Listings, forms, consent, email, webhooks, bookings, cart, checkout, and payments work where applicable.
• No cross-user leakage appears in the tested personalized journeys and cache states.
• Admin and scheduled operations remain usable.

Performance and maintenance

• The original complaint measurably improves under comparable conditions.
• Public cacheable pages show verified hits.
• The LCP resource is found promptly and not accidentally lazy-loaded.
• Cache, plugin, purge, exclusions, and regression tests are documented.

What to ask your developer for

Ask for a short handoff with three things:

1. The cause: evidence from the page or action that was slow, not just the homepage.
2. The change: what was removed, reconfigured or replaced, and why the business does not lose a needed feature.
3. The result: comparable before-and-after timings, working bookings and payments, and a rollback plan.

That is a useful performance handoff. A screenshot of a green score alone is not.

Final rule

The best WordPress performance stack is the smallest stack that removes unnecessary work, caches safe output, loads necessary assets only where needed, and keeps every business journey correct.

WP Rocket can be an excellent cache and delivery owner. Perfmatters can be an excellent precision layer. Neither decides which plugin is redundant, which journey matters, or whether the optimized site still runs the business. That is the real work.

Want a genuinely faster site? Put a WordPress performance specialist on it.

Slow pages, heavy images, plugin bloat, inefficient caching and an overloaded database all add up. We investigate what’s holding your directory or marketplace back and tackle the underlying problems.

Our packages cover performance diagnosis, plugin auditing, image optimization, database cleanup and safe caching—with advanced options for CDN configuration, rendering improvements, server tuning and monitoring.

Measurable before-and-after results, checks on the functionality your business depends on, and support after delivery.

Find the right performance optimization package for your site →

Primary references

The original technical review used the official sources below on August 26, 2026. On September 13 we rechecked the key caching, Core Web Vitals, LCP, Code Profiler, Elementor, Jetpack, calendar, WPML and Script Manager guidance. The tier order and keep/replace decisions are practitioner judgment, not comparative plugin benchmarks.

• WordPress performance optimization
• WordPress caching
• WordPress plugin management and uninstall
• WordPress plugin development best practices
• WordPress guidance on theme functions versus plugins
• PageSpeed field and lab data
• Google page experience and Core Web Vitals in ranking systems
• Core Web Vitals thresholds
• GTmetrix waterfall chart
• Largest Contentful Paint optimization
• WooCommerce caching guidance
• WooCommerce High-Performance Order Storage
• WP Rocket features
• Perfmatters Script Manager
• Cloudflare cache documentation
• Jetpack module controls
• Query Monitor
• Code Profiler
• Elementor optimized asset loading
• Essential Addons element controls
• Slider Revolution performance and loading controls
• The Events Calendar performance guidance
• WPML performance checklist
• TranslatePress performance and compatibility settings
• Broken Link Checker local and cloud scanning
• WP Activity Log performance guidance
• WP Statistics data retention
• MailPoet sending and database performance
• Redirection database tables
• NextGEN Gallery plugin and changelog
• UpdraftPlus resource usage and scheduling
• WooCommerce plugin and theme conflict testing
• WP-CLI profile command
• WordPress Site Health autoload test