Site Slowness and Resource Limits

What your hosting plan actually limits, what happens when you reach each limit, and how to work out whether a slow site is a resource problem or a code problem.

"My site is slow" and "my site has run out of something" feel the same from the outside and have almost nothing in common underneath. This guide separates them: first what the limits genuinely are, then how to diagnose actual slowness.

First, Is It Slow or Is It Broken?

Slow means pages load, eventually. Broken means they do not.

If you are getting error pages rather than slow pages, stop here and go to HTTP Error Codes. A 500, 502 or 504 has a specific cause and a specific fix, and none of them are "upgrade the plan".

If the site is unreachable rather than slow, go to Website Not Loading.

What Your Plan Actually Limits

Four things, and it is worth knowing which is which because they behave very differently when you reach them.

Storage. How much disk your files and databases use. Measured daily.

Bandwidth. How much data your visitors download over a month.

Number of sites. How many separate sites you can run on the plan.

CDN access. Whether the CDN is available at all, and how much traffic may be served from the edge each month.

Your specific allowances depend on your plan. The current figures for every plan are shown side by side under Billing, then Change plan, which is also the honest place to compare rather than a number typed into a help article that can drift. See Upgrading Your Plan.

Storage and CDN usage on the site Overview

What Happens When You Reach Each One

This is the part people worry about, and the answers are less dramatic than expected.

Storage. Disk usage is measured daily and shown on the site's Overview page. As it climbs, you get an insight warning you, escalating as it gets closer to full. See Insights.

Number of sites. This one is enforced at the point of creation. Try to create a site beyond your plan's allowance and you get a clear message saying the plan is at capacity, with the option to upgrade or add another plan. Nothing existing is affected.

CDN eligibility. Enabling the CDN on a plan that does not include it returns a plain "not included on your plan" message with an upgrade link. There is no partial or degraded mode. See Enabling the CDN.

CDN bandwidth. This one has real, well-designed behaviour worth understanding:

At 80% of your monthly edge allowance, you get an email.
At 100%, the edge is paused for the rest of the month. Your site stays online and keeps serving normally, straight from the origin, it just is not edge-cached any more.
Edge serving resumes automatically at the start of the next month.
You are never billed past the cap without knowing about it.

So the worst case is that your site becomes as fast as it was before you turned the CDN on. Nothing goes offline.

Managed WordPress and WooCommerce bandwidth works as a soft cap. You are notified as you approach it and again when you pass it, and any excess is handled as a metered overage rather than the site being cut off.

Exceeding a storage or bandwidth allowance does not suspend your site. Suspension on this platform is a billing state, not a resource one. See Account Suspended and Failed Payment.

What Is Not Limited Per Plan

Two things people expect to find and will not.

There is no per-site CPU or memory quota on web hosting plans. Your plan does not allocate you a number of cores.

You are not competing with your neighbours for PHP capacity. Each site runs in its own isolated pool of PHP worker processes. A busy site next door cannot exhaust the workers your site needs. That isolation is real, and it is why "someone else's site is slowing mine down" is almost never the explanation on this platform.

What does apply is a per-request limit: how much memory a single request may use, and how many seconds it may run. Those are yours to set. See PHP Extensions and Settings.

Where to See Your Usage

Storage, on the site's Overview page.
CDN bandwidth, also on the Overview page once the CDN is enabled, and on the site's Kapsule CDN tab.
Warnings, through Insights and by email. See Insights.
Build minutes and bandwidth for Orbit projects, on the Orbit usage page. Orbit has its own quite different limits, including a spending cap. See Orbit Plan Limits and Orbit Spending Caps.

Actually Making a Slow Site Faster

In order of return on effort. Work down the list rather than jumping to the bottom.

1. Turn On Caching

The single biggest win, every time. Serving a stored copy of a page is orders of magnitude cheaper than rebuilding it for every visitor.

Go to Websites, the site, WordPress, then Caching. Object caching is available across the WordPress-family plans, and full page caching on the managed plans. See Site Caching.

Note that some paths are deliberately never cached: admin pages, login, cart, checkout and account pages. Caching a checkout page would show one customer another customer's basket, so this is not configurable and should not be.

2. Enable the CDN

Caching puts the copy in one place. The CDN puts it near your visitors. Biggest effect if your audience is not in the same country as your server. Requires an eligible plan and your own custom domain. See Enabling the CDN.

3. Move to a Newer PHP Version

A real, measurable difference for no work at all. Test on staging first. See Changing PHP Version.

4. Fix Your Images

Consistently the largest thing on a slow page. A photo straight off a phone can be several megabytes and be displayed at 400 pixels wide. Resize before uploading, and use a modern format.

5. Audit Your Plugins

Every plugin that runs work on every request costs you on every request. Deactivate one at a time and measure. Delete what you are not using rather than leaving it deactivated. See WordPress Plugins.

6. Find the Actual Slow Thing

Stop guessing and measure:

The APM tab on WordPress sites shows which requests are slow. See Site Performance.
The slow query log, available from the WordPress health tools, shows which database queries are the problem.
The PHP slow log captures what a request was doing when it took too long.
Error logs show anything failing quietly and being retried. See Error Logs.

7. Then, and Only Then, Consider More Resources

If caching is on, the CDN is on, PHP is current, images are sane, and the profiler says the work is genuinely necessary, then you have outgrown the plan and moving up is the right call. See Upgrading Your Plan.

Doing this step first is how people end up paying more for a site that is still slow, because an unoptimised site on a bigger plan is an unoptimised site.

When It Is Time for a Server

Shared hosting is the right answer for the large majority of sites. Move to a cloud or dedicated server when you need software the platform does not provide, root access, non-standard services, or predictable dedicated capacity for something genuinely heavy. See Cloud Servers and Choosing an Architecture.