Every plugin on a WooCommerce store runs on checkout unless it deliberately does not, and checkout is the page you cannot cache. So the useful question is not which plugins are good but which are worth their cost on the one page that matters.
This is about categories and how to judge them, instead of a list that will be wrong in six months.
Judge a plugin before installing it
Four checks, and they take a minute.
When was it last updated? Anything untouched for a year will not be patched when a vulnerability is found, and on a store that holds customer data this matters more than usual.
Is it compatible with your WooCommerce version? WooCommerce moves faster than WordPress core, and extensions lag.
How many active installs? More means problems get found by someone other than you.
Do recent support threads get answers? This tells you more than the star rating, which is dominated by people rating the idea in place of the current state.
The categories worth having
Backups. Not optional on a store. A day-old backup means a day of lost orders, so frequency matters more here than on a content site.
Security. One, not three. Login attempt limits, two-factor and file change detection are the features that earn their place. Store security sets out what to enable.
SMTP. The most valuable thing you can add. WooCommerce email through the server's basic mail function lands in spam, and a customer who does not get a confirmation assumes the payment failed.
Caching. Configured to exclude cart, checkout and account pages.
Categories to be careful with
Page builders. Convenient, heavy, and they add work to every page load including checkout.
Anything that adds to checkout. Extra fields, upsells, live shipping quotes. Each is another thing that can fail on the one page where failure costs an order directly.
Analytics and marketing scripts. Frequently loaded on checkout without needing to be. Check what actually runs there.
Multiple plugins doing one job. Two SEO plugins, two caching plugins, two security plugins. They conflict, and the symptoms are confusing rather than obvious.
Free extensions from the WooCommerce ecosystem
Many core capabilities: additional gateways, shipping methods, product types, exist as free official extensions. Prefer these over third-party equivalents when they exist, because they track WooCommerce's own API changes.
A third-party integration for a payment gateway silently stops working when the gateway's API moves. The official one is maintained against it.
Measure what checkout costs
Install a query monitoring plugin and load the checkout page, not the homepage. That tells you which plugins run there and what they cost.
The results are usually surprising. Plugins that have nothing to do with purchasing routinely execute on checkout, and disabling them there is often the largest performance improvement a store can make. There is more in speed optimization.
Never install nulled extensions
Paid extensions redistributed free almost always contain injected code, and the injection is the reason the copy exists.
On a store that holds customer names, addresses and order histories, that is a data breach invited in with full privileges. No security plugin stops it, because you installed it deliberately.
Remove what you stop using
Deactivate and delete. A deactivated plugin still has its code on disk and still needs patching.
The plugin nobody would notice missing is pure risk with no return: those are the ones to remove first.
Check what a plugin is doing to the front end
Every additional plugin has a cost on every page load, and it is measurable before and after installing one.
curl -s https://example.com/ | grep -c '<script'
curl -s -o /dev/null -w '%{time_starttransfer} %{size_download}\n' https://example.com/
curl -s https://example.com/ | grep -oE '(src|href)="[^"]*plugins/[^"]*"' | sed 's|.*plugins/||; s|/.*||' | sort | uniq -c | sort -rn
The last command lists which plugins are loading files on that page. A plugin that only operates in the administration area should not appear there at all, and several do.
Measure the response time before and after installing anything. A plugin adding a tenth of a second to every page is a cost paid by every visitor for a feature used by a few.
Prefer fewer plugins doing more
Five small plugins each solving one problem cost more than one plugin solving five, because the overhead is per plugin rather than per feature.
wp plugin list --status=active --field=name | wc -l du -sh wp-content/plugins/* 2>/dev/null | sort -h | tail -8
Each active plugin is loaded on every request whether or not its feature is used on that page. The count matters more than the size of any individual one.
That is an argument for consolidation and not for accepting a single plugin that does everything. A large plugin loading a great deal of code for a feature you do not use is the same problem in a different shape.
Watch what happens when a free plugin is abandoned
The risk with anything free is not the price but what happens when the author stops maintaining it.
wp plugin list --fields=name,version,update,status wp plugin get PLUGINNAME --field=version 2>/dev/null
A plugin with no update for two years is either finished or abandoned, and the two are indistinguishable until a WordPress or PHP version breaks it.
Check before installing rather than after: when it was last updated, how many sites use it, and whether the author answers questions. A plugin that is central to how the shop works deserves that check more than one that adds a small convenience.
Review the list once a year
Plugins are chosen for a reason that expires. A tool installed for a campaign, a feature that was replaced by something the platform now does natively, or an extension whose author has stopped maintaining it each remain active indefinitely. Read the active list annually and ask, for each one, what would break if it were removed. Where nobody can answer, that is the finding rather than a reason to keep it. Removing what is not used is the cheapest performance and security work available on a shop.