Stack tuning
€490from proposed
- Baseline and before and after timings
- Page cache rules for your platform
- PHP workers, OPcache and Redis
- MySQL settings and slow query review
- One server, one site
Server tuning that makes WordPress, WooCommerce and Magento fly
LiteSpeed cache rules, PHP workers and OPcache, Redis, MySQL and search tuned to your real traffic, with timings measured before and after. For stores and sites that slow down under load. From €490.
from€490excl. VAT 25.5%, one server and one site. proposed
tune a layer
race
As found805 ms
Tuned110 ms
Difference7.3× faster
Page cache HIT after three layers. The tuned request never reaches PHP, Redis or MySQL. For guest pages, cache rules beat raw server power.
Measure my real timingsLayer by layer breakdown
| Layer | As found | Tuned |
|---|---|---|
| CDN | 90 msNo edge: TLS handshake to a distant origin | 90 msAs found, not tuned in this model |
| Web server | 45 msApache prefork with mod_php, no Brotli | 12 msLiteSpeed with HTTP/3 and Brotli |
| Page cache | 0 msNone: every request runs PHP | 8 msLSCache HIT, served from memory |
| PHP | 310 msNo OPcache, two workers queueing | 0 msSkipped: answered by the page cache |
| Redis | 0 msNot installed | 0 msSkipped: answered by the page cache |
| Database | 360 msinnodb_buffer_pool_size at the 128 MB default | 0 msSkipped: answered by the page cache |
| Time to first byte | 805 ms | 110 ms |
Switch layers on for the lower lane, change the request type, then race again. The times are an example model of one store, chosen to show where each layer sits; your own numbers come from measuring your server.
Cache rules: what is cached, for whom, for how long
Speed comes mostly from deciding what must never be cached. These are my starting rules per platform; every site is then tuned to its own traffic and plugins.
WordPress rules plus the store paths.
| What | Cached for | How long | Bypassed or purged when |
|---|---|---|---|
| Product and category pages | Guests with an empty cart | 1 week, purged on change | Purged when price, stock status or the product changes |
| Cart, checkout, my account | Nobody | Never | Bypassed by URL and by the woocommerce_items_in_cart and wp_woocommerce_session_ cookies |
| Mini cart and basket counter | Each visitor | Loaded separately | Pulled in with ESI or a small AJAX request so the page around it stays cacheable |
| Product lookups, sessions, transients | Everyone, in Redis | Until changed | Keeps cart and checkout from waiting on MySQL, the pages no page cache can help |
| Filtered and sorted listings | Guests | Shorter than products | Every filter combination is a new entry, so bots are kept out of filter URLs |
the rule that matters most
The cart cookie. If the cache ignores it, one shopper can be shown another shopper’s basket, or a page that says the basket is empty.
What I tune at each layer, and how I prove it
One layer at a time, on staging first, with the same request timed before and after each change.
- Web serverLiteSpeed or Nginx with HTTP/2 and HTTP/3, Brotli, keep-alive and TLS session reuse. On LiteSpeed, LSAPI process limits matched to the PHP memory budget.
- Page cacheLSCache, Varnish or Nginx FastCGI cache with the rules above: vary on the right cookies, purge by tag, never cache personal pages.
- PHPCurrent supported PHP version, OPcache sized so
opcache.memory_consumptionnever fills, worker count worked out from RAM per worker, slow log on. - RedisPersistent object cache with
maxmemoryand an eviction policy set, separate databases for cache and sessions, hit ratio checked. - MySQL or MariaDB
innodb_buffer_pool_sizesized to the working set, slow query log at one second, missing indexes added, autoloaded options trimmed. - SearchOpenSearch or Elasticsearch for Magento, a search index instead of
LIKEqueries for large WooCommerce catalogues.
web1.example.fisample server
# before: time to first byte, guest product page admin@web1:~$ curl -s -o /dev/null -w 'ttfb %{time_starttransfer}s\n' https://shop.example.fi/product/oak-chair/ ttfb 0.812s # after: page cache rules, OPcache, Redis admin@web1:~$ curl -s -o /dev/null -w 'ttfb %{time_starttransfer}s\n' https://shop.example.fi/product/oak-chair/ ttfb 0.094s admin@web1:~$ redis-cli info stats | grep keyspace keyspace_hits:1843920 keyspace_misses:61377 admin@web1:~$ php -i | grep opcache.memory_consumption opcache.memory_consumption => 256 => 256
Sample output for illustration. Your report shows the same commands run on your own server, before and after.
Fast for one visitor, slow at the sale? Start with a measured baseline.
Get a stack tuning quoteHow a tuning job runs
Nothing changes on the live server until the change has been timed on staging, and every setting is written down.
- 1
Baseline
Time to first byte for key pages from the access logs, slow PHP and SQL logs, memory and CPU at your busiest hour.
- 2
Profile
Find the slowest layer for each request type: guest pages, cart, checkout, search and the admin.
- 3
Tune
One layer at a time on staging: cache rules, PHP workers and OPcache, Redis, MySQL, search.
- 4
Load test
Your peak traffic plus headroom replayed against staging, so the gain holds when the sale starts.
- 5
Report
Before and after timings, every changed setting with its reason, and what to watch next.
When server tuning will not help
I would rather tell you before the job than in the report.
- The slowness is in the browserHeavy scripts, huge images and layout shifts are front-end work. Fast time to first byte will not fix a slow Largest Contentful Paint caused by a 3 MB hero image; speed and Core Web Vitals fixes will.
- One extension does the damageA plugin or module running hundreds of queries per request needs a code fix or replacing. Tuning makes it less bad, not good. I show you which one in the baseline.
- You cannot change the serverOn shared hosting without access to PHP or cache settings, there is little to tune. Moving to a server you control comes first; see server and hosting migration.
Tuning packages
Fixed prices in euros, excluding VAT 25.5%. You keep root, every account and the written list of settings.
Store under load
€890from owner to confirm
- Everything in stack tuning
- Cart and checkout path profiled
- Load test at your peak plus headroom
- Search engine set-up for large catalogues
Tuned and looked after
€149from, per month proposed
- A managed server care plan
- Timings re-checked after updates
- Cache and PHP settings kept current
- Details on the care plan page
If the baseline shows the server is not your bottleneck, I stop there and you pay only for the measurement, with the findings in writing. owner to confirm
Questions about stack tuning
LiteSpeed or Nginx?
Both are fast; the right one depends on your stack. LiteSpeed reads .htaccess, fits cPanel servers and has its own page cache plugins for WordPress, WooCommerce and Magento, but the Enterprise edition needs a paid licence. Nginx suits custom VPS set-ups and Laravel. I tune either and only switch with a measured reason.
Will tuning fix a slow Magento store?
Often a large part of it, not always all. Full-page cache, Redis, OpenSearch, PHP workers and MySQL settings fix server-side slowness. If a module adds hundreds of queries or a block disables the full-page cache, the code needs fixing too. See Magento development; the baseline shows which applies.
Do you need root access?
For full tuning, yes: root or sudo over SSH, with a key I add and you can remove at any time. With only cPanel or hosting-panel access I can still tune page caching, the PHP settings your plan allows, the application and the database, and write down exactly what to ask your host for.
Get a stack tuning quote
Send the site address and which pages feel slow: product pages, cart, checkout or search. You get a written fixed price within one working day.
Prefer email? Write to [email protected]
Pikselipolku is an independent studio and is not affiliated with cPanel, LiteSpeed or any other product named here.