Storage is the easiest hosting specification to understand, but it is rarely the first cause of a slow website. Most sites use only part of their available gigabytes. Performance is more often determined by the processing, memory, disk activity and concurrent requests a plan can handle.
At Gigatech, CloudLinux manages these resources per account. This protects the platform and makes plans more predictable. A limit is not a punishment: it describes the capacity available to your account and prevents one user from displacing everybody else.
CPU: how quickly can the server calculate?
The CPU runs PHP, processes templates, compresses data and supports background tasks. WordPress pages with many plugins, complex product filters or heavy calculations need more CPU time than a simple cached page.
Hosting CPU may be expressed as a percentage or a number of cores. One complete modern core can be powerful for a short task, while a website with many concurrent dynamic requests also benefits from parallel headroom. Caching reduces CPU demand because a generated result can be reused.
RAM: your website’s workbench
RAM is temporary working memory for PHP processes, applications and caches. Insufficient memory may stop processes or produce errors. More RAM does not automatically speed up a site when the actual bottleneck is CPU or disk I/O.
A heavy page builder, import, backup or shop operation may briefly need substantial memory. Look at peaks as well as averages. Remove unused plugins and schedule heavy background tasks outside busy periods.
Disk I/O and IOPS: reading and writing
Disk I/O describes how much data can be read from or written to storage per second. IOPS counts individual read and write operations per second. Copying one large file needs throughput, while thousands of small database and cache files may demand many IOPS.
When an I/O limit is reached, CloudLinux throttles processes rather than allowing other accounts to suffer. You may see this during a large backup, malware scan, import or poorly optimised plugin operation. Fast SSD storage helps, while the hosting plan determines the share of that capacity available to the account.
Entry processes and NPROC: how much happens at once?
An entry process roughly represents an active request entering the account to perform dynamic work. It is not the same as visitors: one person may create several requests, while cached files can require almost no dynamic processing. NPROC limits the total processes and threads within an account.
If a site repeatedly reaches concurrency limits, the cause may be legitimate traffic, slow PHP work, a stuck process or bot activity. Buying a larger plan without investigating can postpone the problem instead of solving it.
| Signal | Possible bottleneck | First check |
|---|---|---|
| Dynamic pages are slow | CPU or slow database query | Analyse cache, plugins and queries |
| Errors during import or backup | RAM, I/O or execution time | Review task size and resource history |
| Site stalls during a traffic spike | Entry processes or CPU | Check traffic, bots and cache hit rate |
| Admin is slow while front end is fast | Uncached PHP or database work | Review admin plugins, cron and database |
Bandwidth and transfer are different
Data transfer measures how much information is sent over time. Network bandwidth describes how quickly it can be sent. These differ from disk I/O, although all can affect experience. A video-heavy site may transfer many gigabytes with little PHP work; a compact shop may transfer little data while performing intensive calculations.
Caching changes the calculation
A page cache such as LSCache can turn many dynamic requests into fast cache responses. Redis reduces repeated database work. The same plan can therefore serve more real visitors. Caching still has to be correct: personal pages and carts remain dynamic, and stale content must be purged after updates.
When should you upgrade?
Do not upgrade because of one isolated peak. Review usage over time and identify a pattern. When CPU, memory, I/O or entry processes repeatedly reach the boundary while the application is healthy and properly cached, a larger plan is appropriate. For occasional imports it may be smarter to split or reschedule the task.
- Personal site: little dynamic traffic; caching provides large benefits.
- Business WordPress site: more plugins, forms and administration; extra memory and CPU headroom are sensible.
- Online shop: many personal and database-driven pages; focus on CPU, RAM and concurrency.
- Agency environment: multiple sites and background tasks; isolation, I/O and monitoring become increasingly important.
Not sure which plan fits? Explore our hosting plans and tell us what the site does, expected traffic and likely peaks. The right choice is based on workload, not only disk space.
