Disk Space, Bandwidth, RAM and CPU in Hosting: What Each Does
Disk space, bandwidth, RAM, CPU and inodes explained in plain English, with examples of which limit your website will hit first and how to spot it.
Hosting plans list resources in a way that sounds precise but rarely explains what they mean for your site. Storage is easy to picture; memory and CPU are not. This guide covers each resource, what consumes it, and which one your website will probably run into first.
Disk space (storage)
Disk space is where your files live: web pages, images, uploads, databases, and email messages. It is the easiest resource to understand because it only grows when you add something.
What uses it: media uploads are usually the biggest item, followed by backups stored on the same account, email, and log files. Core CMS files are small by comparison.
Disk type matters too. SSD and NVMe storage are much faster than traditional hard drives for the many small reads a CMS performs. When comparing plans, the type of storage often matters more than a few extra gigabytes.
Inodes (file count)
An inode is a record for each file or folder. Plans sometimes cap the total. Sites with huge numbers of tiny files, such as thumbnails, cache files or long-unread email, can hit this cap while plenty of disk space remains. If your control panel shows an inode count, check it every few months.
Bandwidth (data transfer)
Bandwidth is the amount of data sent from your server to visitors over a month. Every page view downloads the HTML, images, scripts and styles. A heavy page viewed by many people uses more.
Do not confuse this with port speed, which is how fast data can move at a given moment. Most small sites never come close to a bandwidth cap, and offloading images and scripts to a CDN reduces transfer from your own server considerably; read about our CDN option.
Quick estimate: average page weight multiplied by monthly page views gives a rough monthly transfer. A 2 MB page viewed 10,000 times is about 20 GB. Real numbers vary with caching, so treat it as an upper-bound sketch.
RAM (memory)
RAM holds whatever the server is actively working on right now: running PHP processes, database queries in progress, caches. Unlike storage, memory is used only while requests are being processed.
Insufficient RAM does not show up as "full". It shows up as slowness, 500 errors, or processes being killed. A WordPress site with many plugins and several visitors at once needs more memory than the same site with one visitor. On shared plans, RAM is limited per account; on a VPS, it is a guaranteed, fixed amount, and swap space is not a substitute for real memory.
CPU
The CPU does the actual calculation: generating pages from PHP, running database queries, compressing responses. CPU use spikes when many uncached requests arrive at once, or when a heavy plugin runs a scheduled task. Plans express it as cores, a percentage, or CPU seconds. Caching is the most effective way to cut CPU load, because a cached page is simply served rather than regenerated.
PHP workers and processes
Many hosting stacks limit how many PHP requests can run in parallel for an account. If every worker is busy, the next visitor waits. This is why a site can feel slow under moderate traffic even when CPU and RAM look fine. Slow database queries and external API calls occupy workers longer.
Which limit will you hit first?
| Site type | Likely first bottleneck |
|---|---|
| Static brochure site | Practically none |
| Photography portfolio | Disk space and page weight |
| WordPress blog with plugins | PHP workers, then RAM |
| Online shop | CPU, RAM and database performance |
| Mailbox-heavy business | Disk space and inodes from email |
How to see what you are using
Your control panel normally shows disk usage and bandwidth. Plesk, which is included in every Zebra Hosting plan, has statistics and resource information; the knowledge base explains where to find them. If your plan does not display CPU or memory usage, a sudden pattern of slow loads at busy times is the best sign you are near a limit.
What to do when you hit a limit
- Identify which resource is the constraint rather than guessing.
- Remove waste: old backups, unused themes and plugins, oversized images.
- Add caching and a CDN.
- If the site still needs more, move to a plan with higher limits or a VPS.
Reading a resource table
When a provider lists resources, look for what is guaranteed and what is a maximum. A "burst" allowance is fine for occasional spikes, but sustained load should fit within the baseline. Also check that email is counted in your storage, since many accounts discover that mailboxes fill the disk long before the website does. A good habit is to review usage every quarter and delete old backups, unused themes and abandoned test installs.
Sizing with Zebra Hosting
Because every plan has clear resources and an upgrade path, you can begin with what you need today and move up as measurements justify it. Browse the hosting plans and, if you are unsure how your site's numbers compare, send us the details through the contact page.
