Why shared hosting will not hold a store
Opselis
A ranking pack promises WooCommerce and PrestaShop. You get an LVE cage: a slice of CPU, a shared disk and a neighbour’s MySQL. How to measure the limit and when to leave for your own VM.
Shared hosting from a comparison site is a pack: domain, mailbox, cPanel or DirectAdmin, PHP and MySQL on a host with hundreds of other accounts. The offer promises WooCommerce or PrestaShop in a few clicks. What you buy is an LVE limit: CPU, RAM, I/O, entry processes, inodes. That is not a core nobody else touches. Checkout, the indexer and a campaign peak need a steady CPU quantum and a database a neighbour does not eat. The tools are the Resource Usage panel and cart TTFB, not stars in a ranking.
What this model is for
A shared account fits a brochure site, a blog and low traffic. One Apache or LiteSpeed serves many sites. The price is low because CPU, disk and MySQL are overcommitted. A store has a different profile. PHP holds a worker for the request. InnoDB holds a buffer. Cron and the indexer want I/O in the background. A 100 percent CPU limit in the panel is often a fraction of one vCPU with throttling. Past the LVE cap the request gets a 508 or waits. A neighbour who runs a backup or an XML import raises await on the same volume. You see a slow cart. They stay inside their limit.
Magento Open Source on such an account usually will not stand up properly: no Redis or OpenSearch, cron cut short, too few workers. WooCommerce and PrestaShop will start. At a few dozen parallel checkouts they fail on the process limit and on the shared database.
How CPU and I/O sharing works
CloudLinux or an analogue cages the account. CPU is a percent of a physical core, not a dedicated core. Past the limit the scheduler cuts you off, it does not hand you a free EPYC. RAM is overcommitted, then host swap or an account OOM. I/O has a cap on MB/s and operations. Entry processes say how many PHP workers may run at once. Inodes count files, not gigabytes. A catalogue with photos and an image cache burns inodes before disk space.
MySQL often sits on a separate shared host. max_connections and innodb_buffer_pool are shared. A neighbour’s slow SELECT holds a lock, your checkout waits. You cannot restart mysqld. You cannot move a table to another volume.
You do not have root. lscpu and vmstat are missing, or they show the host, not your cage. Steal time from the cheap VPS note is not even visible here. The vendor panel draws 40 percent CPU. The cage is already throttling.
How to check and when to leave
In cPanel: Metrics, Resource Usage. CPU, I/O, entry processes and RAM for the last 24 h, in campaign hour, not at night. Entry processes at 80 to 100 percent on ordinary traffic disqualify the account for a store. php -i or the panel: memory_limit, max_execution_time. Magento wants 2 GB and cron every minute. An account with 128 MB and cron every 30 minutes will not hold the index.
Measure TTFB on /checkout and on a filtered listing, with cache and without. A homepage on a CDN says nothing. If you cannot install Redis, Varnish and a separate database, you do not add a cache plugin. You change the model: a VPS with a named CPU family, a VM on Proxmox or an instance in the cloud. Stack care: ecommerce. When you have root: Linux commands. Escalation when the store is down: support queue.