How Many Visitors Can Shared Hosting Really Handle

Shared hosting can realistically handle somewhere in the low thousands of visitors per day, but that number depends far more on what each visitor does than on how many arrive. If your pages are small, cached, and your database queries are light, you might serve 10,000 daily visitors on a shared plan. If every request triggers a complex query against a large table, 500 visitors can bring the box to its knees. The honest answer to “how many visitors can shared hosting handle” is: enough for a typical small site, until it is not, and you will see it coming before it breaks.

What Actually Limits a Shared Hosting Account

Shared hosting means your account runs on a web server that also serves tens or hundreds of other accounts. The kernel, the web server process, and the PHP-FPM pool are shared. The limits you hit are not CPU cores or RAM in the abstract. They are per-process limits, per-second request limits, and database connection limits set by the hosting provider’s control panel. The first thing to check is not a benchmark, it is your own account’s resource usage page. Most panels show a graph of CPU, memory, and inode usage. If you see steady CPU usage above 80 percent during your peak hour, you are close to the ceiling.

The protocol matters too. Every HTTP request, even a 404, costs a finite amount of work. The web server has to parse the request line, read headers, match the URI against rewrite rules, and then hand off to the application. On a shared box, the provider usually caps the number of concurrent PHP processes you can spawn. That cap is often set via a php_admin_value or a pm.max_children directive in the pool configuration. You can see your own cap by running this from the command line:

grep -E "pm.max_children|pm.start_servers" /etc/php/8.2/fpm/pool.d/www.conf

The output will look like pm.max_children = 10 and pm.start_servers = 4. That means only 10 PHP processes can run at once for your account. If each request takes 200 milliseconds to execute, those 10 processes can handle about 50 requests per second at best. But shared hosting rarely gives you that much. A more typical cap is 4 or 6 children, which translates to roughly 20 to 30 requests per second under ideal conditions. That is about 1.7 to 2.6 million requests per day, but only if the requests are trivial. Real pages with database queries and template rendering are slower.

Measure Your Own Request Time, Not a Generic Number

Instead of trusting a vague capacity figure, measure your own site’s median response time. Use curl with the -w flag to get the total time and the time to first byte. Run it a few times during your peak hour, not at 3 a.m. A command like this gives you a concrete number:

curl -s -o /dev/null -w "connect: %{time_connect}s\nstart: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://yourdomain.com/

If the total time is consistently above 1 second, you are already in trouble for interactive visitors. But the bigger problem is the tail of the distribution. Shared hosting is noisy. A neighbor’s cron job that runs a backup can double your response time for a few minutes. You need to look at the 95th percentile, not the average. Run the command 20 times and sort the results. If the slowest few responses are 3 seconds or more, your capacity is effectively lower than the average suggests.

Also check the response header for caching. A static file served by the web server directly, with a Cache-Control: public, max-age=3600 header, costs almost nothing. A dynamic PHP page that sets Cache-Control: no-store forces the server to regenerate it on every request. The difference is an order of magnitude. If you have not enabled page caching, you are wasting most of your capacity. Look for a caching plugin or a reverse proxy directive in your .htaccess or Nginx config. For example, an Nginx snippet that caches successful responses for 10 minutes can cut your PHP process usage by 90 percent:

location ~ \.php$ {
    fastcgi_cache mycache;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_key $request_uri;
}

That is the single biggest lever you have on shared hosting. Without it, your visitor capacity is whatever your PHP processes can churn out. With it, static and cached responses are served from memory, and your PHP children only run for uncached requests or admin actions.

Database Queries Are the Real Bottleneck

Most shared hosting accounts run MySQL or MariaDB on the same box. The database server has its own connection limit, often 30 or 50 per account. Each PHP process holds one connection for the duration of the request. If you have 6 PHP children and each opens a connection, you have 6 database connections in use. That is fine. But if your code opens a new connection per query instead of reusing one, you can exhaust the limit quickly. Check your code for mysqli_connect or new PDO inside a loop. That is a classic mistake.

You can see your own database usage with SHOW PROCESSLIST; from the MySQL client. If you see many rows with State: Sending data and a long Time value, your queries are slow. A query that takes 500 milliseconds on a table with 100,000 rows will take 5 seconds when the table grows to a million rows. Indexes are not optional. Run EXPLAIN SELECT * FROM posts WHERE author_id = 42 ORDER BY created_at DESC LIMIT 10; and look for type: ALL in the output. That means a full table scan, and it will kill your shared hosting capacity faster than any visitor count.

If you cannot add an index because you do not have ALTER privileges, you can still rewrite the query to use a covered index or a smaller result set. The point is that your capacity is not a fixed number. It is a function of your query plan and your caching strategy. A site with 2,000 daily visitors and a poorly indexed database can be slower than a site with 20,000 visitors and a well-tuned one.

What to Do When You Hit the Ceiling

When your resource usage graph is consistently pegged and your response times are climbing, do not immediately buy a bigger shared plan. First, confirm the bottleneck. Run top and look at the %CPU column for the PHP and MySQL processes. If PHP is at 90 percent, enable page caching. If MySQL is at 90 percent, add indexes and reduce the number of queries per page. If both are fine but your account is still throttled, the provider is capping you at the process level, and no amount of code tuning will help.

Your next step is to look for a static-first approach. Move your images, CSS, and JavaScript to a CDN or an object storage service. That removes the most common static requests from your shared account entirely. Then, for the dynamic parts, use a full-page cache that stores the final HTML. If you still need more, consider a VPS or a dedicated server, but only after you have measured and proven that the shared box is the limit. A cheap VPS with 2 GB of RAM and a single core will often outperform a shared account for a low-traffic site, because you control the PHP process count and the cache. But do not jump there blindly. The question “how many visitors can shared hosting handle” has no universal answer, but your own logs and your own curl timings will tell you exactly when you have outgrown it.