Slow WooCommerce or Magento shop? I’ll find what’s holding it back.
I review the server and the shop, Magento or WooCommerce, on whatever hosting you use, not only AWS. You get a list of changes with the expected effect of each. To start, the shop’s address and a few sentences on when it slows down are enough. I ask for access to the hosting panel or the server only once we have agreed the price.
Or email jacob@codelevel.pl.
I reply within 1 business day.
When it makes sense
- The shop is fine during the day, but slows down in the evening or falls over during a sale or an ad campaign.
- Your developer says it is the hosting, and the host says it is the shop. I check both and show what is really slowing it down.
- Your host’s only answer is a bigger plan, and nobody has checked what is actually using the resources.
- The basket, search or admin panel is clearly slower than the home page.
- The shop got slower after an update or a new plugin or extension, and nobody knows what changed.
What I check
In short: I check whether the server runs out of CPU or memory at peak times, whether the database is clogged, whether pages are stored and reused instead of being built from scratch on every visit, and whether something in the background eats resources just when customers arrive. The details, for your developer:
- PHP-FPM and OPcache. The number of workers against the server’s memory, and whether OPcache has enough room so code isn’t recompiled on every request.
- The database and slow queries. MySQL or MariaDB settings, the slow query log, missing indexes, and tables bloated with logs, sessions and background jobs; in WooCommerce also HPOS and the options loaded on every request (autoload in
wp_options). - Cache: Redis, Valkey, Varnish. Where sessions and the application cache live, and whether Varnish is worth it for your traffic.
- Full-page cache. Whether product and category pages get cached at all, and what keeps flushing the cache.
- CDN and images. Image sizes and formats, cache headers on static files, and whether the CDN really takes load off the server.
- Cron and indexers. Magento reindexing, WP-Cron and Action Scheduler in WooCommerce: background work that likes to run exactly when customers are shopping.
- Plugins and extensions. Which of them put the most load on the server on every request, and whether they can be set up lighter or replaced.
- Hosting limits. CPU, memory, process count and disk I/O. At peak times a shop often hits these limits before it runs out of CPU.
- Bot traffic. How many requests come from crawlers and scrapers walking through category filters. Every filter combination is a new address the cache has never seen, so the server builds the page from scratch.
I measure server response times on a few key pages before and after the changes, so you see the effect in numbers, not just as a feeling.
What you get
A report with a list of changes, ordered from the ones that do the most for the least risk. For each one I note what to expect, such as a faster server response on category pages or fewer 502 errors at peak, and whether it can be done on your current hosting.
If the current hosting is not enough, I tell you which server you need and what it costs a month before you move anything. I can make the changes myself or hand them to your developer or your hosting company. I can also look after the server afterwards, as part of maintenance.
Access to the shop and your customers’ data
- I work on a separate account of my own in the hosting panel or on the server, never on your password. When the work is done, you delete it with one click.
- Your shop’s database holds your customers’ data, so before we start we sign a data processing agreement (Article 28 GDPR). An NDA too, if you want one.
- Before I change anything, I take a backup and agree a time with you outside peak hours and sales.
- I make changes after the review only once you say yes, at the hourly rate, or your developer makes them.
- I do not look at orders or customer data. What interests me is what loads the server, not who bought what.
More on how I work and how I handle access.
An example
I moved a Magento shop from shared hosting to AWS with no downtime. Pages load about 3× faster: it gained Varnish as a full-page cache, Redis, a separate database, search and a CDN. The goal there was scalability and resilience to failure, so the hosting bill went up. Not every shop needs a move like that; often the fixes fit on the current server. The full story.
Next step
Tell me what the shop runs on (Magento or WooCommerce, which hosting) and when it slows down. I’ll say whether a review makes sense and what it will cost; you get a fixed amount in writing before I start. If the problem looks minor, I’ll say so straight away. The review price is on the pricing page.
Is the shop down right now? Write with URGENT in the subject. Incident help costs EUR 80 per hour on working days and EUR 110 per hour in the evening until 22:00 and at weekends, minimum 2 hours.
Describe your situation in a few sentences
I will reply with questions, or straight away with a proposal and a price.
Or email jacob@codelevel.pl.
I reply within 1 business day.