RC Model Shop Direct

RC Model Shop Direct is one of the UK's leading specialist hobby retailers, based in Normanton, West Yorkshire. Their online store carries over 9,000 products - RC cars, drift cars, buggies, trucks, tanks, boats, planes, drones, and an enormous range of spare parts and hop-ups from more than 130 brands.

As the business had grown, so had the complexity behind the website. What had once been an acceptable user experience was becoming noticeably sluggish - particularly on shop and category pages. The team reached out to us to find out why, and fix it.

The Problem

The first thing we do on any performance job is dig into the actual data rather than guess. Using server-side profiling tools, we identified the exact database query responsible for the slowdown.

Every time a visitor loaded a shop or category page, the site was running an expensive background calculation to count how many products matched each filter option - things like battery type, motor size, vehicle scale, skill level, and so on. On a store with thousands of products and a huge range of technical specifications, this was a genuinely costly operation: it was scanning over 50,000 rows in the database on every single page load, adding over a tenth of a second of server processing time every time.

That might not sound dramatic in isolation. But this calculation wasn't running once - it was being triggered by every filter widget active on the page. There were 15 of them.

Every page load. Every visitor. Every category. Fifteen separate triggers of the same expensive query, all stacking up.

To make things worse, some of those filters had very little practical value - one covered a specification that applied to only a tiny fraction of the entire product range. Others duplicated information already visible through the category navigation. The site was paying a heavy performance price for filters that most customers would never use.
There was also no caching in place to soften the blow. Every visit was hitting the database fresh.

What We Did

We approached the rebuild in stages, so the live store stayed fully operational throughout.

Stage 1 - Cut the dead weight

We reviewed all 15 filters against real customer behaviour data and product coverage across the catalogue. Filters with minimal interaction, low product coverage, or that duplicated existing navigation were removed entirely. The number of active filters was reduced from 15 to 4, each scoped to show only on the category pages where they were actually relevant.

Stage 2 - Fix the root cause at code level

Removing filters reduced the problem significantly, but we went further. We implemented a code-level fix that stops the expensive product count calculation from running on every page load altogether. Instead, those counts are now recalculated in the background during quiet periods - keeping the filter figures accurate without the server having to crunch through 50,000 database rows every time someone browses the shop.

This was built as a lightweight, always-on code snippet that can't be accidentally switched off, and doesn't interfere with any other part of the site.

Stage 3 - Sort out the configuration

A full audit of the site's settings turned up several areas where the configuration was adding unnecessary database calls. The filtering behaviour was reconfigured to stop triggering redundant count refreshes every time a customer clicked a filter. Lazy loading was properly enabled across product grids to reduce initial page weight.

Stage 4 - Database health

We ran a full review of the database tables most affected by the performance issues, checking index coverage and making sure query execution was taking the most efficient path available. We also cleaned up the WordPress options table, which had accumulated years' worth of orphaned data from old plugins and theme changes - a common source of hidden slowdown that's easy to overlook.

Stage 5 - Caching

Finally, a proper caching setup was put in place. Shop pages and category pages are now cached effectively, meaning repeat visitors and search engine crawlers aren't hitting the database at all for standard page loads. Cache exclusion rules were set correctly for the basket and checkout, so the shopping experience remains accurate.

The Outcome

The results were immediate. The per-page database penalty that had been firing 15 times on every shop page load was eliminated from the front-end entirely. Server response times dropped noticeably and server CPU load was down significantly.

The product count figures in the remaining filters continue to display correctly - customers still see accurate numbers, they just load faster because the calculation happens in the background rather than on demand.

Why This Matters for SEO

Page speed isn't just a user experience issue - it directly affects search rankings. Google's Core Web Vitals are an established part of its ranking algorithm, and shop pages are exactly the pages where performance problems like this do the most damage.

A faster site means:

• Better Core Web Vitals scores and improved organic rankings
• Lower bounce rates as pages load quickly for visitors arriving from search
• More efficient crawling - Google can index more of your catalogue in each crawl session
• Stronger mobile performance, which matters because Google ranks based on the mobile version of your site

Every pound invested in SEO or paid search works harder when it's landing on a fast, technically sound website.

The Lesson

This project is a good example of what happens when a successful e-commerce store outgrows its original setup. The site had been well-built - but the natural growth of the business, more products, more brands, more specifications, had pushed it beyond what the original architecture was designed to handle.

More filters didn't mean a better shopping experience. Fifteen attribute filters firing expensive database queries on every page load was actively hurting the store in speed, server cost, and user experience. Four well-placed, relevant filters is a far better outcome for customers and for performance alike.

If your WooCommerce store is showing signs of the same kind of strain - slow shop pages, server spikes, or declining Core Web Vitals scores - we'd be glad to take a look. Get in touch with the team at Wakefield Website Design.