Done-for-you OpenCart speed work: caching, database, images, and hosting sorted against a real Core Web Vitals target. Fixed price after a paid audit.
Base scope of work — applies to all tiers. See the tier comparison below for hours and SLA specifics.
We profile the store, the queries, and the host, then hand you a written list of what is slow and why, ranked by impact.
Full-page and object caching enabled and tuned, using OpenCart 4's native cache or a tested extension on OpenCart 3.
Missing indexes added and slow queries fixed, so a large catalog stops dragging on every filter and search.
Images compressed and lazy-loaded, CSS and JavaScript merged or deferred so the theme stops blocking the first paint.
Move to PHP 8 with OPcache, correct memory limits, and a host that can actually serve your traffic.
PageSpeed Insights and field-data reports so the improvement is measured, not claimed.
Transparent process — you always know what stage we're at and what comes next.
A small fixed fee to profile the store and hosting. You get a written diagnosis and a fixed quote, and the audit fee comes off the job if you go ahead.
We price the whole optimization up front against a target LCP and TTFB, so there is no open-ended hourly meter.
We make the changes on a copy of your store, measure, and only push live once the numbers move and nothing broke.
We re-measure on the live store with real traffic and send the before and after report.
Scope transparency — no surprises in the monthly report.
Access we require — passed via secure channel (1Password / Bitwarden).
Most jobs run from $300 for a small store that mainly needs caching and image work, up to about $1,200 for a large catalog that needs database tuning and a host move. The paid audit gives you the exact figure before you commit, and its fee comes off the job.
It depends on how slow it starts and why. A default OpenCart 3 store on decent hosting usually drops from five or six seconds to under two. If the host is the limit, the gain is bigger once we move it. The audit gives you a realistic target, not a sales number.
We work on a staging copy and test every change before it goes live, so your extensions and checkout keep working. If a specific extension is itself the cause of the slowness, we flag it and suggest a lighter replacement rather than quietly disabling it.
Not always. Plenty of stores get fast on their current host once caching and the database are sorted. But if your time to first byte is over a second before OpenCart even runs, no tuning fixes that, and we will recommend a move. The new host is your bill; the migration is on us.
OpenCart 4 has native caching that makes some of this easier, but OpenCart 3 can be made just as fast with a tested cache extension and the same database and asset work. If you are on an old 3.x and thinking of upgrading anyway, we fold that into the plan.
Yes. The audit is exactly that: a written, ranked list of what is slow and how to fix it. Some clients take that and do the work in-house, others hand the whole thing back to us. Either is fine.
A slow OpenCart store loses orders in a way you can measure. Google’s field data says most people give up on a page that takes over three seconds, and OpenCart on default settings routinely takes longer than that. The upside: OpenCart is slow for a short, predictable list of reasons, and every one of them is fixable. We quote the whole job as a fixed price after a paid audit, so you know the cost and the target before we touch anything. It is part of our OpenCart services line.
It is rarely one thing. On the stores we audit, the slowness usually stacks up from four or five of these:
We find which of these apply to your store before we quote, because fixing the wrong one is how agencies end up billing you twice.
Speed work has an order, and the order matters. We start at the server and database, because a fast front end on a slow host is lipstick. Then caching, then assets, then the theme. In practice that means: enable and tune full-page and object caching (native on OpenCart 4, or a tested extension on 3.x), add the database indexes the catalog is missing, move you to PHP 8 with OPcache if you are still on 7.x, compress and lazy-load images, and defer or merge the CSS and JavaScript the theme dumps into the head. If the host is the bottleneck we move you first, because nothing else shows up in the numbers until we do.
We optimize against Core Web Vitals, not a vanity score in one tool. The targets we hold ourselves to on a normal catalog store: largest contentful paint under 2.5 seconds on mobile, time to first byte under 0.5 seconds, and a store that stays fast once real traffic and a full cart hit it. You get before and after reports from PageSpeed Insights and real field data, so you are not taking our word for it. One OpenCart 3 store we did recently went from a 6.1 second LCP to 1.9 on the same hosting, off caching, indexes, and image work alone.
Sometimes the honest answer is that your $4 shared plan is the problem and no amount of tuning saves it. When that is the case we say so on the audit call and point you at a $5 to $15 cloud host that solves most of it, instead of selling you optimization hours to paper over a hosting problem. If the store is also just old and creaking, it can be cheaper to upgrade or migrate it than to keep patching, and we will tell you that too. For the on-page side that speed feeds into, our OpenCart SEO guide covers the basics you can do yourself.
If a slow store is really an aging OpenCart 3 install, an upgrade to OpenCart 4 can beat tuning the old one.
Once the store is tuned, a full-page cache locks the gains in. See the OpenCart cache module we install and how it drops server response time to around 200ms.
If we do not hit the speed target we quoted against, we keep working at no extra charge until we do, or refund the optimization fee. The audit tells us the target is realistic before you commit.
