Why Is My Website Slow? 10 Server Side Causes and Fixes

Why is my website slow?

A website is slow when the server takes too long to produce the first response, or when that response takes too long to reach the browser. The usual suspects are weak hosting resources, an old PHP version, slow database queries, missing caching, DNS and TLS delays, bot traffic and plugin bloat. Measure first, then fix.

Page slowness has two separate sources, so it helps to name them first. The first is the server side: the browser sends a request, and the answer arrives late. The second is the browser side: the answer arrives fast, but images, scripts and fonts hold up the screen. This guide covers only the first one.

Therefore we do not repeat image, JavaScript or Core Web Vitals detail here. For those topics, read our guides on how site speed affects SEO, image optimization and JavaScript performance.

If you manage your own VPS or cPanel account, you can follow the commands step by step. If your host manages everything, you will learn which findings to send to your provider and how to word them. We are a digital marketing and web team, not a hosting company. So the explanations rest on official documentation and standards.

Why is my website slow: is the problem the server or the browser?

Separate the two first. Open your browser developer tools and look at the first document request in the network panel. Its timing view shows the wait for the server response as its own item. If that wait is long, the problem most likely sits on the server side.

Suppose the wait is short, but the page still looks slow. Then the problem lives in the browser. For example, heavy images or blocking scripts can cause it. In that case, our image and JavaScript guides are the right place to go.

However, many sites suffer from both at once. The server answers slowly, and the page is also heavy. Work in order here: fix the server side first, because every other loading step waits for the first byte.

Do not decide from a single measurement. So test the same page at different times and from different networks. A site that is fast at night and slow in the afternoon usually points to a resource limit or a traffic problem. A site that is always slow more often has a caching, database or configuration problem.

Also notice how the slowness feels to visitors. They see a blank screen, while you see one number. So your first job is to turn that feeling into a measurable value. Without it, you cannot tell whether any fix worked.

What is TTFB and what counts as slow?

TTFB, or time to first byte, is the time between starting to navigate to a page and the moment the first byte of the response begins to arrive. According to web.dev, it includes redirects, the DNS lookup, connection and TLS negotiation, and the request phase until the first byte.

The same source gives thresholds: good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds. However, these are general targets. A server rendered page and a fully client rendered page do not get judged by the same yardstick.

TTFB is not a Core Web Vitals metric. However, metrics such as LCP wait for the first byte. So a bad TTFB delays every later step. Because of this, we start the diagnosis here.

TTFB is a single number, but it hides several separate delays. The sections below pull these parts apart one by one:

• The redirect chain and the jump from HTTP to HTTPS.
• Then the DNS lookup time.
• Next, the TCP connection and the TLS handshake.
• Finally, the time the server needs to build the page: PHP, database, cache.

Why is my website slow: in what order should you diagnose it?

Changing settings at random is the most expensive path, because you cannot know which change helped. The order below runs from cheap and safe checks to costly and risky changes:

1. Measure the homepage time to first byte several times and write the values down.
2. Split DNS, connection, TLS and server time apart.
3. Then count the redirects in the chain.
4. Next, check cache headers and page caching.
5. Check the PHP version and memory limits.
6. After that, log the slow database queries.
7. Look for bot and attack traffic in the access logs.

One command covers the first two steps. The example below uses the timing variables of the curl tool. Replace example.com with your own address:

curl -o /dev/null -s -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nfirst_byte: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/

The values in the output are cumulative. So if you subtract the TLS value from the first byte value, you get a rough server processing time. Example calculation: if TLS shows 0.25 and first byte shows 1.45, the server spent about 1.2 seconds. These numbers are only an example.

Also, run the command at least five times. The first run often meets a cold cache, and later runs are faster. That gap is a clue in itself.

How do you see where the time goes inside the server?

An outside measurement says the delay sits on the server, but not where. For that, you can add a Server-Timing header to the server response. According to MDN, this header passes performance metrics about the request and response cycle to the browser. Database read time and CPU time are typical examples.

Server-Timing: db;dur=53, app;dur=47.2

In the example header, db shows database time in milliseconds. The app entry is the time of the application code. You can see these values in the Timings section of the network panel. Likewise, web.dev suggests the same header to measure database queries, page build time and cache hits.

Producing the header takes code. Therefore this step belongs to your developer or plugin author. You only need to know what to ask for: a timing that splits page building into at least three parts. Then the debate moves from guesses to numbers.

Be careful when you enable it in production. Metric names can leak system detail. So consider turning on the detail only in a test environment or behind restricted access.

1. How does a hosting resource limit slow your site?

Shared hosting splits the CPU, memory and disk of one machine among many sites. Also, providers set limits per account. A site that exceeds its limit gets throttled, so requests wait in a queue and the time to first byte grows.

The typical symptom is slowness tied to time. The site is fast in the morning, but slows during a campaign or a backup run. Many panels include a resource usage screen. Its name and detail vary by provider, so look for the matching section in your own panel.

web.dev also touches on this. It says that an application with too little memory will struggle to serve pages quickly. In other words, the problem may sit in the ceiling of your plan and not in your code.

However, the fix order is simple. First, cut unneeded processes, then add caching. If you still hit the limit, consider a plan upgrade. We cover what to look for in our guide to choosing web hosting.

Let us be honest: you cannot change the resource limit yourself. That decision belongs to the provider, so you can only collect evidence. Time stamped measurements and screenshots of the usage screen make your support ticket much stronger.

2. Does an old PHP version slow your site down and put it at risk?

Specifically, the PHP project gives every release branch two kinds of support. According to php.net, the first two years bring bug fixes and security fixes. The next two years bring security fixes only. After four years, the branch reaches end of life and no patches follow.

So an old version is not just slow, it is also exposed. We do not promise a specific speed gain, because the gain depends on the application. Still, you can read the performance notes in the release notes of current versions.

To learn your version, one command on the server is enough:

php -v

If you use cPanel, the version choice usually sits in the MultiPHP Manager screen. In the WordPress dashboard, the Site Health page under Tools can also warn you about the PHP version.

So do not change the version directly on a live site. Try it on a staging copy first, because old plugins and themes can break on a new version. Check which release is the current stable version on the php.net page.

3. How do slow database queries delay a page?

For example, while a dynamic page is built, PHP can send dozens of queries to the database. A single query without an index can grow to seconds as the table grows. Such a query holds up the whole page, so the time to first byte suffers directly.

According to the MySQL documentation, the slow query log is disabled by default. The default value of long_query_time is 10 seconds. So do not stop at switching the log on, but also lower the threshold. The settings below are an example:

[mysqld]
slow_query_log = 1
long_query_time = 2
slow_query_log_file = /var/log/mysql/slow.log

The file path varies by distribution. Then, once the log fills up, the mysqldumpslow tool summarizes it. Inspect a suspicious query with EXPLAIN:

EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

If the output shows a full table scan, a suitable index may be missing. However, take a backup before you add an index. Our website backup strategy guide explains how. To refresh your query logic, the SQL query scenarios article also helps.

On shared hosting you usually have no access to these settings. In that case, ask your provider for a slow query summary.

4. Without caching, does the server rebuild every page for every visitor?

Yes. Without a cache, every visit repeats the same work. PHP runs, the database gets queried and the HTML gets assembled. Yet a blog post or a category page can stay the same for days. So repeating that work every time wastes resources.

Separate three layers:

• A page cache serves ready made HTML directly.
• An object cache keeps frequent database results in memory.
• The built in PHP OPcache extension stores compiled code.

Cache-Control headers matter on the browser side too. web.dev recommends suitable Cache-Control headers for static and semi static content, plus a cache invalidation strategy. For the object cache in detail, read our Redis versus Memcached guide.

Pay attention here: cart, checkout and account pages must stay outside the page cache. Otherwise, one customer could see another customer's cart. Therefore, on store sites, always check the exception list of the plugin that applies this setting.

5. Can DNS delay lengthen the time to first byte?

Yes, but for most sites it is a small share. Before the browser connects to your server, it has to turn the domain name into an IP address. If that lookup is slow, the whole request is late. You will feel the difference when your DNS provider is slow or the record chain is long.

First, use the dig command to check. The Query time line at the end of the output shows the lookup time in milliseconds:

dig example.com

If you prefer the browser, our DNS lookup tool lists A, CNAME and NS records. To see where the domain lives, the WHOIS lookup and the IP lookup tools help as well.

Look for needless CNAME chains, old subdomains you no longer use and inconsistent NS records. Also, if you offer IPv6, confirm that both protocols work with the IPv6 test.

Also be careful when you change DNS records. A wrong record can take down email and the site together. If you are unsure, leave the change to your domain or hosting provider.

6. How do TLS and redirect chains delay the first byte?

In practice, every redirect adds another round trip. A visitor types an http address, the server redirects to https, and then it redirects again to the www address. A chain of three steps creates three separate waits before the first byte. web.dev also notes that redirects add up delays.

Run this command to see the chain:

curl -sIL -o /dev/null -w "redirects: %{num_redirects}\nfinal_url: %{url_effective}\n" http://example.com/

If the redirect count is above one, shorten the chain. The goal is that every old address goes straight to the final address. In the browser, our redirect checker does the job.

web.dev also recommends the HSTS header. It helps the browser skip the HTTP to HTTPS redirect round trip on later visits. Check your certificate validity and chain with the SSL checker. You can read what a certificate does in our SSL certificate guide.

However, do not switch on HSTS carelessly. Once it spreads, it is hard to undo, because browsers remember the rule. First make sure all your subdomains are ready for HTTPS.

7. How does bot and DDoS traffic slow a website?

Every request creates work on the server, whether it comes from a person or a bot. When fake bots, overly aggressive crawlers or attack traffic eat the resources, real visitors meet the slowness. Therefore the symptom is usually a sudden and unexplained load spike.

First, start with the access logs. The command below ranks the addresses that sent the most requests. The log file path depends on your setup, and the first field is assumed to be the IP:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

To inspect logs in the browser, our log file analyzer can help. Do not block every busy source, though. Google suggests returning 500, 503 or 429 responses during overload. Still, its crawl rate documentation warns that long lasting error responses can hurt how your site appears in Google.

To tell the real Googlebot from fakes, see our Googlebot verification guide. If you wonder why crawling slowed, our crawl rate drop article applies.

You cannot stop a high volume attack yourself. That job needs network level protection, so contact your hosting provider or an edge protection service right away.

8. How does plugin bloat slow a WordPress site?

Every plugin adds code to page generation, and often extra queries too. The problem is not the number of plugins, but the cost of each one. Ten clean plugins can cost less than one careless plugin. So do not count plugins, measure their cost.

The Query Monitor plugin on WordPress.org shows the queries per page and which plugin or theme sends them. Install it on a staging copy first. Then inspect slow queries and repeated requests by component.

There is also database bloat. Some records in the WordPress options table load automatically on every page view. Leftovers from plugins you removed can grow that area. As a result, every page carries needless data.

Also, scheduled tasks are another resource. The WordPress scheduler fires with visits. If heavy tasks land in busy hours, they can lengthen the time to first byte.

The rule is simple: remove plugins you do not use, and keep only one of two plugins that do the same job. If you must choose a basic structure, read our WordPress versus custom website comparison. On a live site, always take a backup before you delete a plugin.

9. How much do a CDN and server distance affect the first byte?

The physical distance between your server and your visitor adds latency. If your server sits in Europe and your visitor is on another continent, every connection round trip takes longer. Because a TLS handshake needs several round trips, the difference multiplies.

web.dev recommends a CDN as the answer. A CDN serves resources from servers closer to the visitor. Also, CDN providers usually offer fast DNS, HTTP/2, HTTP/3 and modern TLS.

However, a CDN does not solve everything. Dynamic pages that cannot be cached still go to the origin server. Unique query parameters can also block the CDN cache. For example, if every request carries a different tracking parameter, the cache hit rate falls.

To test this on your own site, check where most of your visitors are. For instance, if your audience sits in one country, choosing a server near that country is often as effective as a CDN. For this decision, look at the data center list of your hosting provider.

10. Why does a VPS run out of memory and CPU?

On your own VPS you set the resource limits, but the responsibility also moves to you. When memory runs out, the system swaps to disk and everything slows down. web.dev describes exactly this: with insufficient memory, the application struggles.

Three commands give a quick snapshot:

free -h
uptime
ps aux --sort=-%mem | head -5

The first shows memory and swap use. The second shows the load average, and the third lists the processes that use the most memory. You can also search the kernel logs to see whether the system killed a process for lack of memory.

If you use PHP-FPM, the number of concurrent workers matters. Too low a count makes requests wait in a queue. However, too high a count makes memory run out. The right value depends on server memory and the size of your requests. So do not type a random number. Read the PHP-FPM configuration documentation instead.

Take care at this stage. A wrong worker count can stop the site completely. If you have no safe backup and no rollback plan, leave the change to a specialist.

Which tool measures what?

The table below gathers the tools from this guide at a glance. The last column shows when to pick each one.

Do not rely on a single tool. Combine outside measurement with inside measurement, and the diagnosis gets faster. That way you hold concrete data when you talk to your provider.

How can you summarize the 10 causes in one table?

The table below puts the typical symptom and the first check of every cause side by side. So you can come back to it quickly while diagnosing. The answer to why is my website slow is rarely a single line. Usually two or three causes stack up, so read the whole table.

When should you not do it yourself and leave it to your hosting provider?

Trying to fix everything yourself often backfires. In the cases below, leave the job to your provider or an experienced system administrator:

• You have no access to server settings on shared hosting.
• The attack traffic arrives at network level.
• You would have to change the database structure without a backup.
• You plan to upgrade PHP on a live store without testing.
• The cause is a resource limit and a plan change is required.
• You are not sure what a command does.

This list is not timidity, it is risk management. A wrong command can hit the site, the email and the data together. When you open a support ticket, add your measurement values and the time of the slowdown. That way the provider finds the cause faster.

Approach security with the same honesty. A slow server is sometimes a sign of a break in. If you suspect that, read our OWASP Top 10 guide and get expert help.

How does a slow page hurt SEO and sales?

A slow server hurts in two ways. Visitors leave before the page opens. Search engine bots also crawl less when the server returns errors. According to Google's documentation, frequent 500, 503 or 429 responses lower the crawl rate, and that drop affects the whole hostname.

In e-commerce, the effect turns straight into revenue. Every delay on the way to the cart is a lost chance. You can find the detail in our guide on e-commerce page speed and sales.

On the measurement side, our Lighthouse test guide and our Core Web Vitals guide help you understand browser side delay. When the server improves, these measurements often improve together. Still, we do not promise how much any metric will gain.

How do you confirm the improvement after a fix?

Take the same measurement under the same conditions before and after each change. Use the same page, the same time window and the same command. Make changes one at a time. If you change three settings together, you cannot tell which one worked.

Do not look for one final answer to why is my website slow. Each fix shrinks the remaining share and leaves a new biggest cause behind. So the process is a loop: measure, fix one thing, measure again.

A single measurement is not enough. Run the command at least five times and look at the overall trend. Also note the warm cache and the cold cache results separately.

Real visitor data builds up more slowly. web.dev suggests the Chrome User Experience Report and the web-vitals library for field data. That data may not move within days. So start with lab measurements and watch field data afterward.

Also keep a measurement log. Put the date, the change and the before and after values side by side. When the problem returns in six months, that log saves you time.

Why is my website slow even after hosting upgrades, and how can our team help?

We are not a hosting provider, and we do not offer server operation. As a digital marketing and web team, we help you measure what slowness does to business results. We also help you separate what belongs to the server from what belongs to the site.

If you plan a new site, we build a structure that counts performance from day one. Take a look at our web design service for that. On the search side, our SEO consulting joins technical findings with a content plan. If you run a store, see our e-commerce consulting page.

A small note: none of the commands in this guide is magic. Each one answers only one question. Reading the answer, meaning knowing which value is normal for your site, takes time and comparison. So take your first measurements today, because tomorrow you will have a reference to compare against.

We recommend that you solve findings that need server work together with your provider. We write the finding clearly and help you decide what to ask for. That way your support ticket stops being a vague complaint.