Hosting owns the first byte. Everything after it belongs to the site. That line settles most arguments about whether a slow page is the host's fault, and it is worth being precise about, because the two halves are fixed in completely different places and money spent on the wrong half buys nothing at all.
Open the network tab in a browser, load the page, and look at the first request in the list. The time before the first byte of that response arrives is the host's half: the network trip, the web server, the PHP process, the database. Everything after it, images, stylesheets, fonts, third-party scripts, is the site's half. If the first byte arrives in 180 milliseconds and the page is still assembling four seconds later, a larger plan will change nothing, and anybody who sells you one has not looked.
The host's half, in the order it bites
Distance
Nothing on a price list beats physics. A round trip between Istanbul and Frankfurt is tens of milliseconds; between Istanbul and Sydney it is hundreds, and a browser makes several round trips before it has a page at all. Our own KVM hardware is in Istanbul, which is the shortest path to an audience in Türkiye and the region. The right choice is the one nearest the people who will actually use the site, which is not always the one nearest you. If the audience is genuinely spread across continents, that is what a content delivery network is for: it does not make the origin faster, it puts copies closer.
The web server, and how it runs PHP
Shared hosting here runs LiteSpeed with LSAPI rather than Apache with a CGI handler. On a single request with nobody else on the machine the difference is modest. It shows up on concurrency, which is the case that actually matters: the point at which requests start waiting for a free worker rather than for the database. A site that is fine when you test it and slow when it is busy is usually describing exactly this.
The resources the plan reserves
CloudLinux puts every account in its own container with its own processor and memory allowance. That is what stops the busy site next door from becoming your afternoon, and it also means your own ceiling is a published number rather than a mood. The entry plans here carry 2 cores and 2 GB; the business plans go up to 8 cores and 16 GB. When a site reaches its ceiling, requests queue, and the symptom is a page that is quick at three in the morning and slow at eight in the evening. That pattern is the clearest signal there is that the plan is the problem, and you can see it in the resource usage display in cPanel rather than having to infer it.
Disk
NVMe is on most price lists now, which has made it a weaker signal than it was. It is real, and it shows on database work and on anything that opens hundreds of small files, which is most PHP applications on a cold cache. It will not rescue a query with no index on it. If your slow page is slow because of one query, the disk underneath it is not the lever.
The site's half, which is usually the larger one
In the order we see them cause problems:
- Images. A photograph straight off a phone, uploaded at full resolution and displayed in a box 400 pixels wide, is the single most common reason a page is slow. Resize before uploading and serve a modern format.
- Plugins. Each one is code that runs on every request. Thirty plugins to deliver a contact form and a cookie banner is a performance decision, whether it was made deliberately or not.
- Third-party scripts. Analytics, chat widgets, tag managers, fonts loaded from somewhere else. Each one is a request to a server you do not control, and a slow one holds up your page while your own server sits idle.
- No caching. Rendering the same page from the database for every visitor is work you are choosing to repeat. A caching layer is usually the single largest improvement available on a content managed site.
- Queries without indexes. The one that gets worse as the site succeeds, and the one no plan upgrade fixes permanently.
Shared, virtual or dedicated, and which actually fixes what
Shared hosting is the right answer when the ceiling is the problem and the stack is not: you want more processor and memory and you do not want to administer a machine to get them. A virtual server is the right answer when something you need lives below the control panel: a specific runtime, a daemon that stays running, a database version of your choosing. A dedicated server is single tenancy on physical hardware, prepared and handed over rather than appearing when the payment clears. We are between suppliers on those at the moment, so write to us rather than looking for a price.
One honest warning about the middle step. Moving a loaded site from a shared account to a virtual server makes it slower more often than people expect, because the shared account arrived with LiteSpeed, an opcache and a PHP configuration set up by somebody who does this every day, and the new server arrives with a distribution default. The machine is better and the stack is not, until you build it.
Finding out which half you are in, in ten minutes
- Load the page and record the time to first byte on the first request.
- Load it again from the same browser. If the second load is dramatically faster, you are looking at caching, not at hardware.
- Request a plain static file on the same site. If that is quick and the page is slow, the network and the disk are fine and the application is the subject.
- Open the resource usage display in cPanel and look for the ceiling being touched at the times people complain.
- If the first byte is slow at every hour and for static files too, it is distance or it is the machine. Check where the server is before you check anything else.
If after that it still looks like us, open a ticket from the service itself and say which of the five steps pointed that way. It arrives with the machine attached, which saves the first exchange.