A hosting plan specification is a list of ceilings: how much disk the account may use, how much data it may transfer out, how many files it may hold, and how much processor and memory it may take at any one moment. Most of those ceilings never bind on a small site. The two that do are the file count and the number of things your site tries to do at the same time.
Plan pages are ordered the wrong way round for that. Storage sells. The numbers printed largest on a specification list are the ones that were cheapest for the host to make large, and they are not the ones your site will run into first.
The Two Halves of a Plan Page
Every specification list mixes two kinds of number, and they behave nothing alike.
The first half is capacity: storage, monthly transfer, and how many domains, mailboxes and databases you may create. These are counted once and compared against a total. They are cheap for a host to hand out, because a number in a database costs nothing until somebody uses it, and most accounts use a fraction of what they were sold.
The second half is runtime: processor share, memory, simultaneous processes, script execution time. These are measured while your site is answering a request. They are the expensive half, because they are the part a host cannot oversell without every account on the machine feeling it. That is also why they are printed smaller, further down, in units nobody has an intuition for. If you want the reasoning on why one plan costs several times another, what paying for hosting actually buys you is its own subject.
Read the second half first. It is where the answer is.
Storage: Measure It, Do Not Guess It
Disk space is the specification people fixate on, and it is almost never the one that runs out. A WordPress install with a theme, thirty plugins and a few hundred posts usually lands in single-digit gigabytes, unless somebody is uploading video.
What people forget is that storage on a hosting account is not just the web root. Email counts. Databases count. So do the backups your own plugin writes into a folder inside the site it is backing up, which is the most common way an account fills up: the backup grows, the next backup includes the previous one, and the account doubles every week until it stops.
Measure yours from a shell:
du -sh public_html
du -sh public_html/wp-content/uploads
Then look at the database separately, because du on the web root does not see it. Any host that gives you phpMyAdmin will show you the size of each database on its front page.
Do not pay for storage headroom. If your measured total is a couple of gigabytes, a plan offering twenty times that is not offering you anything you can use, and the extra you are paying for it would buy more of the runtime half, which is the half that will actually stop you.
Bandwidth Is the Number Least Likely to Stop You
Monthly transfer, sometimes called bandwidth, is the total volume of data sent out of the account in a billing period. The arithmetic is not hard: average page weight multiplied by monthly pageviews, plus whatever files people download.
Run the numbers once and the fixation usually dies. A site averaging two megabytes a page and serving fifty thousand pageviews a month moves roughly a hundred gigabytes. Fifty thousand pageviews is a lot of traffic for a small business site, and transfer is the allowance the industry has been most willing to make generous, which is why it so rarely turns out to be the binding constraint.
Transfer becomes a real constraint in two situations, and they are worth naming because they are the ones people get caught by: hosting large media files directly, such as video or high-resolution photography sets, and being scraped or hotlinked by somebody else. Check the logs first. Somebody else serving your images from their pages is a bandwidth problem with a fix that costs nothing, and it looks identical to growth until you go and read where the requests came from.
What Is an Inode, and Why Does It Run Out First?
An inode is a filesystem record. Every file and every directory on the account consumes one, and the size of the file does not matter: a zero-byte file and a gigabyte file cost one inode each.
This is the limit that surprises people, because nothing on a plan page prepares you for it and nothing in your site's appearance predicts it. A modern web project can carry an enormous number of small files. A node_modules directory left in the web root after a build runs to tens of thousands. Page cache plugins write one file per cached URL. Every email you keep is a file. Each of these is invisible in a storage figure and expensive in inodes.
Count yours:
find public_html -xdev | wc -l
find public_html -xdev -type d | wc -l
If the number is large and you do not know why, the usual culprits are a cache directory that never expires, a development dependency folder that was uploaded by accident, and a plugin logging one file per event.
CPU, Memory, and Concurrent Processes
Here is where the specification stops describing a quantity and starts describing your site's behavior under load.
CPU allowance is a share of processor time, usually expressed as a percentage of a core or as a quota per period. Memory is how much RAM your processes may hold at once, which is separate from PHP's own memory_limit directive. The PHP setting caps a single script; the account limit caps everything running at that instant, together.
Concurrent processes, sometimes called simultaneous connections or entry processes, is the ceiling that produces the failures people misdiagnose as a slow server. It counts how many requests the account may have in flight at once. Say the limit is high enough for ordinary traffic and one uncached database query starts taking four seconds. Requests arrive faster than they complete. They stack. Within a minute the account is at its process ceiling and new visitors get an error page telling them the account has reached a resource limit, while your own test in another browser tab loads instantly because it hit the cache.
That failure mode is the honest reason to move up a tier. It is also why "my site is slow" and "my site has outgrown its plan" are different diagnoses, and worth separating before you buy anything. The signs that a site has outgrown shared hosting show up in how the site fails under load, well before they show up in a usage graph.
"Unlimited" Describes a Billing Policy, Not a Machine
No machine is unlimited. The disk in the server has a size, and so does everything else in it.
What the word actually means is that the host has chosen not to meter that resource per account, and has instead written the real constraint into the acceptable use section of its terms. Typically that section says the resource is provided for the operation of a normal website, and that file storage unrelated to the site is out of scope. The limit did not disappear. It moved from a number you could plan against into a clause somebody else interprets.
An unmetered allowance is usually fine, and for an ordinary website it is one less thing to think about. What it changes is where you have to look. When a plan says unlimited, the specification you care about has moved into the terms and conditions, and the runtime numbers are the only figures left on the page carrying information.
Translate Your Site Into These Units Before You Buy
Half an hour of measurement makes every plan page legible. Do it in this order.
- Total the disk.
du -shon the web root, plus the database sizes from phpMyAdmin, plus your mailboxes. Write down one number in gigabytes. - Count the files.
find public_html -xdev | wc -l. If it is startling, find out why before you use it as a requirement. - Estimate transfer. Pageviews from your analytics multiplied by average page weight from your browser's network panel. Add downloads.
- Find your peak concurrency. Your access log holds this. Count requests in the busiest minute of a normal week and divide by sixty for a rough requests-per-second figure, then multiply by your average response time in seconds. That product is roughly how many processes you need in flight.
Step four is the one people skip, and it is the one that determines whether a plan works. Storage you can always add later.
Here is a real specification list from this site, rendered live rather than typed, so you can see how the halves sit next to each other on an actual plan:
A Glossary to Hold Next to Any Plan Page
| Line item | What it counts | How to measure yours | Likely to bind? |
|---|---|---|---|
| Storage, disk space | Bytes used by files, mail and databases | du -sh, plus database sizes |
Rarely, unless you host media or nested backups |
| Bandwidth, monthly transfer | Data sent out of the account per billing period | Pageviews times page weight | Rarely |
| Inodes, file count | Filesystem records: one per file and one per directory | find public_html -xdev \| wc -l |
Often, and usually without warning |
| CPU allowance | Share of processor time | Your host's usage graph over a busy week | On dynamic sites with weak caching |
| Memory | RAM held by all your processes at once | Peak usage in the host's statistics | On plugin-heavy applications |
| Concurrent processes | Requests in flight simultaneously | Busiest-minute request rate times response time | Yes, this is the usual ceiling |
| Databases, mailboxes, domains | How many you may create | Count what you run today, add room for one more | Only if you host several sites |
Where to Start
Take the four measurements. Then read plan pages from the bottom up: if the runtime numbers on a plan comfortably exceed what your busiest minute needs, the capacity numbers above them are almost certainly fine, and a bigger storage figure on a competing plan is not a reason to choose it.
If you are buying a first plan and have nothing to measure, buy the smallest one that meets the runtime specification and expect to move up once. That is cheaper than guessing high, and it gives you real numbers to plan the next decision with. BestPaidHosting publishes the full line item list on each of its shared hosting plans, and the definition of shared hosting covers what you are sharing and with whom.