1. Baseline LCP, CLS, and INP on home, collection, product, and cart.
2. Prefer Online Store 2.0 sections and remove unused JSON template sections.
3. Use image_url / image_tag with width and height; compress hero posters.
4. Audit apps that inject sitewide scripts and keep them off templates that do not need them.

More notes: https://devdiy.com

A budget is a ceiling, not a shopping list

A plugin budget is the maximum front-end cost you will accept on a given template before you stop adding features. It is not a list of plugins you hope to install. For a typical store I write it down as three numbers, measured on a cold mobile load:

• Largest Contentful Paint, in seconds
• Total transfer size of the document plus the scripts that came with plugins
• How many of those scripts the template does not need in order to function

Those numbers can differ by template. A homepage hero and a checkout form should not share a ceiling just because they share a theme.

Why templates diverge

WooCommerce already splits the store into templates: the shop archive, the single product, the cart, checkout, and my account. Plugins rarely respect that split. A review widget, a currency switcher, and an upsell carousel often enqueue their assets on every page just in case. The archive pays for the product-page gallery. Checkout pays for social share buttons that belong on a blog post.

Before you add another extension, open the template you actually care about and record what is already there. If the single product page is already near its ceiling, the next plugin does not belong on that template, even if it would be harmless on the cart.

How to set the ceilings

Start from the template that makes money, not from the homepage. For most stores that is the single product page and checkout.

1. Load each template once on a mid-range phone profile, with the cache cold, and write down LCP and transferred kilobytes.
2. Set aside anything that is not the store: the theme header, analytics, and chat. What remains is the plugin cost.
3. Pick a ceiling a little above today's number, not an aspirational number copied from someone else's case study. A ceiling you already miss is not a budget.
4. When a new plugin needs to ship, decide which templates may load it. If the product page is full, the feature stays off that template, or it replaces something that is already there.

Replacement is the part people skip. A budget that only grows is a wish. If a new size guide has to live on the product page, something else on that page has to leave: a related-products block, a second review plugin, or an unused variation swatch library.

What to measure before the install

You do not need a lab for the first pass. The browser network panel, filtered to the document and to scripts, is enough. Note three things:

• Which request paints the largest element. On a product page that is usually the main image, sometimes a banner injected above it.
• Which scripts arrive after that paint and do not change it.
• Which of those scripts are identical on the cart, where they do nothing useful.

If the largest element is an image the theme already serves, another plugin will not improve LCP. It can only compete with it. Measure that before you add the plugin, not after a week of meaning to look at speed.

A practical split

This split has held up on ordinary stores that still use a normal theme:

The checkout row is intentionally short. A late script there hurts completion more than it helps merchandising.

When the budget is already blown

If a template is over its ceiling, do not start with another performance plugin. Remove or load conditionally. Many WooCommerce add-ons have a setting for loading assets only on product pages, and a few lines in a small custom plugin can dequeue the rest with the template conditionals WooCommerce already gives you. Conditional loading is the budget. Minifying a script the cart never needed is not.

I keep a short note of these ceilings next to the store's plugin list, in the same place I track which extensions are actually in use. Shop AI WP is where that store-side bookkeeping lives for this project: which extension is on which template, and what it is allowed to cost. The point of the note is the decision, not the tool. If the product page is full, the next idea waits.

A closing check

Before the next install, answer four questions in writing:

1. Which template is this for?
2. What is that template's LCP and transfer size today?
3. What leaves if this ships?
4. Does checkout stay untouched?

If you cannot answer them, you do not have a plugin budget yet. You have a plugin pile, and the product page is paying for all of it.

This note is the field version of that pass. A longer checklist lives with the rest of our WordPress playbooks in the plugin conflict troubleshooting guide. Use the sequence below when you need it in your head before you touch the site.

Name the failure before you touch a plugin

Write down three facts before you deactivate anything.

First, what the visitor or editor was doing. Examples that are specific enough to retest: “Checkout after choosing local pickup.” “Block editor, inserting a form.” “wp-admin, Plugins screen, immediately after the last update.”

Second, what the page actually returns. A PHP fatal printed in the HTML, a 500 from the host, a 200 page with a blank main column, a console error about a script that failed to load, or a REST response that says rest_forbidden or simply times out. Third, what changed in the last day. A plugin update, a theme update, a PHP version bump, a new must-use plugin from the host, or a cache purge that finally revealed an old error. If you cannot name the change, look at each plugin’s last-updated time and the host’s backup or file-change log. Guessing “it must be the SEO plugin” spends the only calm hour you have.

Also note whether the failure is front end only, admin only, or both. Admin-only failures often involve a dashboard widget, a security plugin rewriting admin-ajax.php, or an optimizer concatenating scripts that the block editor expects to load one by one. Front-end-only failures more often involve cache, page builders, and script deferral.

Work on a copy, or make production boringly reversible

The clean path is a staging copy with the same PHP version, the same active plugins, and object cache turned off so you are not debugging a stale object. If you do not have staging, do not improvise on production with twenty toggles. Do this instead.

Take a host backup or a snapshot you know how to restore.

If the site is a fatal white screen, rename the suspected plugin directory over SFTP, from plugin-name to plugin-name.off, rather than clicking Deactivate. The plugins screen may not load, and a rename is the same as deactivation for anything that is not a must-use plugin.

Keep a text file of every directory you renamed and every option you changed. The rollback is that list, read backwards. A conflict hunt that cannot be undone is how a small JavaScript error becomes a lost afternoon and a stale checkout page sitting in a full-page cache.

Turn on a log you can read

On staging, or for a few minutes on production if you have no copy, enable logging without printing errors to visitors:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Reload the failing URL once. Read wp-content/debug.log from the bottom. You want the first fatal or warning that names a plugin path, not the cascade of notices that follow it. Typical lines look like a Cannot redeclare fatal that mentions two plugin paths, an allowed-memory fatal inside an autoloaded options scan or a page builder, or a call to an undefined function after one plugin assumed another would load first.

If the log is silent and the browser console is loud, you are in script territory: a deferred jQuery, two copies of a library, or a consent manager blocking a payment iframe. Those will not show up as PHP fatals. Keep both logs.

Bisect the plugin list

Do not disable plugins one by one from the top of the screen. Bisect.

Note the full active list, including version numbers if the failure started after an update. Deactivate half of the non-essential plugins. Leave anything required to reach the failing screen. For a checkout bug, leave WooCommerce and the payment gateway that owns the button. For an editor bug, leave the block plugin that owns the screen you are testing.

Retest the exact action you wrote down at the start. Clear any page cache between tests, or you will “fix” a cached 500 and then watch it come back. If the bug disappears, the culprit is in the half you turned off. Split that half again. If the bug remains, the culprit is in the half still on, or it is in the theme, a must-use plugin, or a drop-in such as object-cache.php, advanced-cache.php, or db.php.

Must-use plugins and drop-ins do not appear as normal toggles. Check wp-content/mu-plugins and those three filenames. Hosts inject cache and security code there. Rename a drop-in only after you know the host can recreate it. On some plans the object-cache drop-in is how Redis is connected, and removing it changes performance even when it is not the bug.

A binary search of 24 plugins is about five tests, not 24. That matters when each test includes a cache purge and a real checkout, not a glance at the homepage.

Swap the theme only as a control

After the plugin bisect, switch to a default theme such as Twenty Twenty-Five on staging. If the bug vanishes, the theme’s functions.php, a bundled extension, or a template override is part of the collision. If it stays, stop blaming the theme and go back to the plugin pair you isolated.

Theme tests on production are user-visible. Do them on staging, or accept a minute when the homepage wears a default theme, and put the original theme back before you leave the session.

Patterns that show up more than they should

A few pairs cause the same ticket every month.

Cache plugin plus script optimizer. One plugin combines JavaScript, the other defers it, and a form or the block editor loads scripts out of order. The symptom is a button that does nothing, or a console line that a WordPress global is undefined. Turn minification and deferral off before you reinstall the form plugin.

Security plugin plus a builder or membership plugin. A firewall rule blocks admin-ajax.php or a REST route the builder needs. Saves spin, or the editor reports an invalid nonce on a page that was valid a minute ago. Read the security plugin’s block log for the exact route before you loosen PHP settings or disable nonces.

Two SEO or schema plugins. Both print a JSON-LD block, or both register the same sitemap rewrite. You get duplicate meta, a sitemap that 404s, or a canonical that points at the wrong host after a migration. One plugin should own titles, sitemaps, and schema.

Page cache plus a cart or login cookie. The cache ignores the cookie and serves a logged-out page to a logged-in editor, or serves one visitor’s cart fragments to the next. Exclude cart, checkout, account, and any URL that sets a session cookie.

When you find the pair, decide which plugin owns the job. Two plugins should not both minify, both send mail, or both emit schema. Pick one, write down why, and leave the other inactive rather than half-configured.

Confirm the fix, then write the one-line cause

Re-enable everything you turned off except the conflicting feature. Retest the original action, an ordinary page view, and the Updates screen. If you changed PHP settings or disabled a drop-in, say so in the same note so the next person does not “fix” it back.

The note your future self needs is one sentence. For example: “Checkout fatal was Plugin A 4.2 redeclaring a helper that Plugin B 1.9 already defined. Left B active, rolled A back to 4.1, and reported it to the A author.” Without that sentence, the next update repeats the outage and nobody remembers which half of the bisect mattered.

If the vendor ships a fix, update on staging, retest the same three actions, then update production inside a window where you can still restore the snapshot. Do not clean up unrelated plugins in the same change. One change, one result, one line in the log.

Plugin conflicts are ordinary maintenance, not a verdict on the site. A log you can read, a backup you can restore, and a binary search will find the pair faster than a forum thread that starts with “I tried everything.” Keep this sequence next to your deploy notes, and run it the same way the next time an update lands badly.