A slow website does not automatically need a larger hosting plan. Sometimes an extension is performing expensive operations; sometimes several requests arrive together and occupy the available resources. To decide what needs changing, you first need to separate processing capacity, memory and concurrent activity.
These hosting resource limits are not interchangeable. More RAM will not necessarily solve a CPU bottleneck, and additional processing capacity will not automatically remove a concurrent request limit. Here is how to interpret them when running a small website.
1. CPU: how much processing work your site can do
CPU is the processing capacity used to execute code and perform other operations attributed to your account. For a dynamic website, that work may include running PHP, generating pages or processing images. Database operations also consume resources, although how they are measured and limited depends on the provider’s infrastructure.
A cached page may require less processing than the same page generated from scratch. This is why two websites with similar traffic levels can have very different CPU usage.
- Brief spikes can occur during updates, imports or file generation.
- Sustained high usage may indicate a continuous workload, inefficient code or automated traffic.
- Slowdowns at the limit may result from processing being throttled, depending on the service configuration.
In web hosting plans, CPU allocations may be expressed as percentages, cores or other units. A percentage alone is not enough for a comparison: ask what it refers to and whether the capacity is shared, reserved or temporarily available.
2. RAM: working memory for active operations
RAM is the working memory used by active processes. A script loads data, objects and libraries into memory while it runs. Tasks such as product imports, image processing and certain extensions may need more memory than displaying a straightforward page.
A script’s memory limit is not necessarily the account’s total memory limit. For example, the PHP memory setting for an individual script and the memory available to all account processes may be separate thresholds. Increasing the first setting does not automatically increase your plan’s resources.
When reviewing RAM usage, consider both the peaks and what caused them. High usage during an occasional import means something different from memory being consistently occupied during normal browsing. Depending on the hosting environment, reaching the limit may cause allocation errors, terminated processes or failed requests.
For a WordPress website, examine active plugins and tasks before assuming the theme is responsible. If you are considering WordPress hosting, check the actual limits and compatibility with your application rather than relying on the plan’s name.
3. Concurrent processes: how many activities can run at once
CPU describes processing capacity, while RAM describes memory. Concurrent process limits determine how many activities can exist or execute at the same time, according to the provider’s definition.
This is a common source of confusion. The total number of account processes, the number of requests entering the application simultaneously and the number of available PHP workers are not the same thing. Reports may list them separately, and each limit can have different consequences.
Why this is not a visitor count
One visitor can generate several requests, some of which may be served from cache or an external service without executing application code. Conversely, a single slow request can occupy an execution slot for longer.
For example, if an external service responds slowly, requests waiting for it may remain active. Your concurrency limit could therefore be reached even without heavy CPU usage. Depending on the configuration, new requests may wait in a queue or receive errors.
Ask exactly what the “concurrent processes” metric measures. A single figure does not tell you how many visitors your website can support.
4. What to look for in resource usage reports
Do not base your decision on one screenshot. Compare the period when problems occurred with a period of normal operation, and check that the charts use the same time zone. Averages can hide short spikes, so reporting resolution matters.
- Usage and limit: identify the unit, the plan’s threshold and the measurement interval.
- Peak and duration: establish whether usage approaches the limit occasionally or persistently.
- Limit events: look for counters showing threshold breaches, throttling or rejected requests, where available.
- Related errors: check application logs and error messages from the same period.
- Scheduled activity: compare peaks with imports, scans, updates and other automated tasks.
- Traffic and requested URLs: look for repeated requests to dynamic pages, forms or login endpoints.
If CPU, RAM and concurrent processes appear to remain within their limits, investigate other possible bottlenecks: disk access, the database, the network or external services. A resource usage report describes only the metrics it measures, not every possible cause of poor performance.
5. What to clarify with your provider before upgrading
Send the exact incident period, the affected pages and any messages you observed. These details are more useful than a general report that your website is slow.
- Which limit was reached, and what evidence is available in the reports?
- How are CPU, memory and concurrency defined for the current plan?
- Do the limits apply to the whole account, each website or each process?
- What happens at the threshold: throttling, queuing or rejection?
- Does the proposed plan increase the specific resource that became insufficient?
- Are there separate limits for the database, disk access or PHP workers?
- Will the change involve migration, configuration changes or a possible interruption?
You can use the contact page to request clarification about GazduireOnline.ro services. If you are considering cloud hosting, check the allocation model and management responsibilities: the service name does not automatically mean unlimited resources.
6. Conclusion: upgrade to address an identified bottleneck
A sound decision starts with measurement, moves on to controlled checks and only then reaches plan selection. Keep a backup before making important changes and, where possible, test in a separate environment.
- Record when the problem occurs and which operation triggers it.
- Correlate CPU, RAM and concurrency with errors and activity during that period.
- Review resource-intensive extensions, caching and overlapping scheduled tasks, changing one thing at a time.
- Ask for confirmation of the limits and compare the resource you need with the new plan’s allocation.
- Repeat the measurements after the change under conditions that are as similar as possible.
The aim is not to keep every chart as low as possible, but to understand what limits your website’s operation. That gives you a practical basis for choosing between optimisation, rescheduling tasks and adding resources, rather than treating an upgrade as a universal fix.
