Shop archives are the heaviest pages on a store — many products, each with price, stock, variations and images, often with filters layered on top. They are also the least cacheable, because prices and stock must be current. Speeding them up means making the queries cheaper rather than simply caching harder.
Before you buy, one quick look
Read-only. Run a category page through PageSpeed Insights, then run a single product page for comparison.
Category slow, product fine — the archive query is the problem, which is what this fixes.
Both slow — it is site-wide rather than shop-specific, and Core Web Vitals remediation is the better fit.
That comparison tells us which service you actually need.
Slow shop & archive page optimization
Shop and category pages are slow to load. We find what is expensive about them and fix it, without breaking filtering or stock accuracy.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Category pages slow, product pages fine | This fix covers it |
| Whole site slow | Core Web Vitals remediation |
| Slow only with filters applied | This fix covers it |
| Admin slow rather than the front end | Slow admin dashboard fix |
| Variable products slow specifically | Variable product performance at scale |
What you are seeing
- Category and shop pages taking seconds to load
- Filtering or sorting making it dramatically worse
- Pages with many products noticeably slower than small ones
- The site feeling fine until you reach the shop
- Slowness worsening as the catalogue has grown
Common causes
- Product queries running without appropriate indexes
- Variation data loaded for every product in the listing
- Filter plugins running expensive queries on every request
- Images served at full size and scaled by the browser
- Caching disabled across the shop because of stock accuracy concerns
What we do
- Take a full backup before touching anything
- Profile the archive request and find where the time is actually spent
- Optimise the queries behind product listings and filters
- Reduce what is loaded per product to what is displayed
- Apply caching that is safe for price and stock accuracy
- Measure before and after on the same pages, and confirm stock stays correct
What is included
- Measurably faster shop and category pages, with before and after figures
- Filtering and sorting optimised alongside
- Caching applied where it is safe and excluded where it is not
- The pre-fix backup, kept for 30 days
Not included
- Full site performance work, which is a separate service
- Replacing your filter plugin, though we say if it is the cause
- Hosting upgrades, though we say if that is the honest answer
- Design changes to the shop layout
Questions about this fix
Can you not just cache the pages?
Not safely, on their own. Cached archives show stale prices and stock, which causes overselling and customer complaints. The fix is making the queries cheap enough that caching becomes an optimisation rather than a necessity.
It got slower as I added products. Is that inevitable?
No. Well-indexed queries scale well; poorly indexed ones degrade sharply past a few thousand products. If yours fell off a cliff at a certain size, that is an indexing problem and it is fixable.
My filter plugin is the problem, is it not?
Often it contributes. Filters run additional queries per request and some do it inefficiently. We measure rather than assume, and if the plugin is genuinely the cause we say so and suggest what to do.
Will this help my Core Web Vitals?
For shop pages, yes, and those are often the ones failing. If your product and content pages are also slow, that is a broader problem and the full remediation service is the right one.
Would splitting products across more categories help?
A little, since it reduces how many products a single archive query has to handle, but it's a minor lever compared to the query and indexing work this actually does — worth doing alongside it, not instead of it.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.