Performance guide · Sheffield
Sheffield: find the slow query before you buy a bigger plan
Catalogue sites do not get slow evenly. One query, on one template, at one point in the growth curve — and the whole site gets blamed.
The short answer
On a catalogue or specification-heavy site the bottleneck is almost always a specific query on a specific template, not the server as a whole. Find it with the slow query log or a request profiler before you spend anything, because a missing index is free and a bigger plan is not.
HostingFast runs NVMe storage behind LiteSpeed caching from London, with per-site PHP versions, SSH and — on the top shared tier — PHP X-Ray on CloudLinux Pro to trace live requests and name the call that is costing you.
By the HostingFast team · Reviewed 15 August 2026
24/7
Answers at any hour
1-click
WordPress deploy
Free
TLS, auto-renewing
Daily
Backups, every plan
A buyer here arrives at the site already knowing the grade, the tolerance and the part number. The site's only job is to find one row in a large table and render it before they lose patience, which is a database problem wearing a web page.
So this page is ordered around the query rather than the theme: what to measure per template, where the time actually goes, what the plan gives you to work with, and how to prove that the index you added helped.
Catalogue pages are a database problem
A brochure page is a document. A catalogue page is a query — often several, with joins across product meta, and often one per facet the visitor ticks. Add enough filters and a page that was fine at two hundred products becomes unusable at four thousand without anything else changing.
So the first diagnostic is query count and query time on the specific template, not a site-wide average. Two templates on the same site can differ by an order of magnitude, and averaging them hides exactly the one you need to fix.
Find the slow one before you buy anything
Use the tools in order of effort: a query monitor on a staging clone to get the count, the slow query log to catch the outliers, and EXPLAIN on the offender to see whether it is using an index or scanning the table. Most catalogue problems end at a missing index on a meta key.
On the top shared tier, PHP X-Ray on CloudLinux Pro profiles live requests in production and attributes the time to a specific call, which is the difference between a diagnosis and a fortnight of bisecting plugins.
How much of a catalogue can the cache cover
More than people expect. Category and product pages are logged-out reads and cache cleanly, so a LiteSpeed hit serves them without loading PHP at all. Check with the x-litespeed-cache header across a sample of real product URLs rather than the home page.
What resists caching is faceted search, because each filter combination is a distinct URL and most of them are requested once. Limit the facets that generate cacheable URLs, exclude the rest deliberately, and make sure a crawler cannot wander into a million combinations of them.
Change one thing, measure again, keep the number
Baseline the template. Add the index. Re-measure with the same tool from the same connection. If the number did not move, put it back — an unused index is not free, it costs you on every write.
Keep a short log of what you changed and what it bought. Six months later, when the site slows again, that log is the difference between a targeted fix and starting from scratch.
Enough database headroom to work with
Storage is NVMe on every tier, which is where a query that has to touch disk gets its time back, and the plans state their database allowances plainly — 25 MySQL databases on the entry tier, 50 in the middle, 100 at the top of shared.
Daily backups restore from the panel in minutes, so trying an index on production and reverting it is a five-minute decision rather than a risk assessment.
- .co.uk registered and renewed alongside the plan
- NVMe storage under every database, on every tier
- Per-site PHP version switching from the control panel
- Daily backups with self-service restores
Why HostingFast
Standard on every plan
NVMe under the database
Query work that touches disk is where NVMe earns its place, and it is standard on every tier rather than reserved for the expensive ones.
Live request profiling
PHP X-Ray on CloudLinux Pro at the top shared tier traces production requests and attributes time to a call, so you fix a cause.
Stated database allowances
25, 50 or 100 MySQL databases depending on tier — a number you can plan a catalogue build against rather than a vague promise.
Caching that covers product pages
Logged-out category and product URLs cache cleanly at server level, so the bulk of catalogue traffic never reaches PHP.
Safe experiments
Staging copies plus daily restores from the panel mean an index or a schema change can be tried and reverted the same afternoon.
Support at any hour
Engineers on shift around the clock, with a first reply inside two hours and inside one when a site is down.
Quick Start
From order to online
- 1
Baseline the template
Measure the specific catalogue page, not a site average. Record query count, query time and TTFB before touching anything.
- 2
Catch the outlier
Read the slow query log, then EXPLAIN the worst offender to see whether it is using an index or scanning the table.
- 3
Fix it on staging
Add the index on a clone, re-run the identical measurement, and only promote the change if the number actually moved.
- 4
Contain the facets
Decide which filter URLs are cacheable and which should never be crawled, so search engines are not generating work you never intended.
Built In
Loaded onto every plan
- Query count and time measured per template, never as a site average
- Slow query log read before any capacity decision
- Faceted search URLs deliberately excluded from crawling
- Cache hit ratio sampled across real product URLs
- Staging environments for testing changes before they ship
- Per-site PHP version switching from the control panel
- A daily backup, so trying an index on production stays a five-minute decision
- NVMe SSD storage on every tier, not just the expensive ones
- Human support on duty every hour of every day
- 99.9% uptime as the target, monitored around the clock
Frequently Asked
What people ask us most often
Our catalogue was fine last year and is slow now. What changed?
Almost always the row count rather than the code. A query that scans a table is tolerable at two hundred products and hopeless at four thousand, and nothing about the page announces the moment it crossed over. EXPLAIN the query behind that template; if it reports a full scan on a meta key, an index will usually return the page to where it was.
Is faceted search worth caching?
Partly. Cache the combinations people actually use and exclude the rest, because most filter permutations are requested once and would only fill the cache with entries nobody reads. Just as importantly, stop crawlers from exploring the whole permutation space — otherwise you are paying to generate pages for a robot.
How many databases do I get?
25 MySQL databases on the entry tier, 50 in the middle and 100 on the top shared plan, with NVMe storage underneath all of them. If a catalogue build needs more than that, the same account upgrades in place with no migration and no downtime.
Can I try an index on the live site?
You can, and the backup makes it reversible — daily backups restore from the panel in minutes. The better habit is still to try it on a staging clone with the same data volume first, because an index that helps reads costs you something on every write, and a small table will not reveal that trade-off.
Keep reading
Web Hosting in Oslo
Norwegian audiences, .no, and the northern European round trip in numbers.
Web Hosting in Istanbul
Turkish connections, and what 30-60 ms means for a catalogue that must feel instant.
Bundled Domain, Checked
Hosting that bundles the first year of a domain, and what to check before you buy.
WHMCS License
A WHMCS licence for running your own billing, priced without an upsell path.
Web Hosting
cPanel hosting on NVMe behind LiteSpeed, with SSL, migration and a year-one domain.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Diagnose it, then decide.
NVMe under every database, live request profiling on the top shared tier, and staging copies to prove a change before it ships.
View WHMCS License plans