Measure before installing another plugin
Start with a repeatable baseline. Test the same URL on mobile and desktop, note whether field data is available, and record the largest problems shown by PageSpeed Insights or browser DevTools. Performance scores can fluctuate, so look for patterns rather than chasing one perfect number.
The most useful first question is where the delay occurs: server response, image delivery, render-blocking CSS, JavaScript execution, third-party scripts or layout instability.
- Test the homepage and one important inner page.
- Record LCP, CLS and the main Lighthouse opportunities.
- Check whether a slow response begins before the page reaches the browser.
Fix the server and cache layer first
If Time to First Byte is consistently slow, front-end minification will not solve the root problem. Check PHP version, available resources, object caching, page caching and whether the site is bypassing cache for pages that could be cached.
WooCommerce, membership and logged-in sites need more careful cache rules because dynamic pages should not be treated like static brochure pages.
- Confirm full-page cache works for public pages.
- Avoid caching cart, checkout and account responses incorrectly.
- Review PHP workers or CPU constraints if dynamic requests queue under load.
Optimize the largest visible assets
Hero images are common LCP candidates. Serve an appropriately sized modern format, avoid loading a huge desktop source on a small phone and do not lazy-load the image that must appear immediately above the fold.
Set explicit width and height attributes so the browser can reserve layout space. This also helps prevent CLS when images load.
- Compress large JPEG/PNG assets.
- Use WebP or AVIF where your stack supports it reliably.
- Keep the LCP image discoverable in the initial HTML when possible.
Reduce plugin and JavaScript cost
A plugin count by itself is not a performance diagnosis. One plugin can be heavier than twenty small ones. Use a staging site or controlled tests to identify components that add expensive database queries, large scripts or network calls.
Delay or remove third-party scripts that do not need to run before a user interacts. Chat widgets, heatmaps and advertising scripts can become dominant performance costs.
- Remove unused plugins instead of leaving them disabled indefinitely.
- Avoid duplicate optimization plugins fighting over the same cache or minification layer.
- Load scripts only on pages that need them when practical.
Keep the database proportionate
Autoloaded options, expired transients, revisions and large log tables can slow admin and uncached requests. Clean only what you understand and take a database backup first.
Database optimization should not be used as a generic button-click routine on a live store. Identify the large tables and confirm whether a plugin still depends on them.
- Back up before deleting data.
- Inspect unusually large options or plugin tables.
- Schedule maintenance rather than running heavy cleanup during peak traffic.
Measure again in the same conditions
After each meaningful change, repeat the same test URLs. Compare field data over time and lab diagnostics immediately. Document what improved and what stayed the same; this prevents stacking more changes on top of an unproven assumption.
Performance work is successful when users get a faster, more stable site without breaking checkout, forms, login or analytics.
- Retest mobile first.
- Verify forms and ecommerce flows after caching changes.
- Monitor Search Console Core Web Vitals rather than assuming one lab result represents every user.
Use the related free tools for diagnosis, or describe the specific website problem in the project form. Keep passwords out of the enquiry.
Discuss a focused project ↗