Why Is My Website Slow? Hosting or Something Else?

When someone asks, “why is my website slow?”, hosting is usually the first suspect. The reaction is understandable: the site feels slow, the server has a provider name on the invoice, and changing providers feels like a clean fix.

It is also a common way to waste a week.

A page load crosses several layers before a visitor can use the page: DNS, connection setup, TLS, server processing, content transfer, caching, and browser rendering. Slowness can live in any one of them. If the page is slow because of a 4 MB image, a blocking JavaScript bundle, or an uncached database query, moving the same site may change nothing.

The useful question is not “is my hosting slow?” The useful question is which layer is slow. Diagnose a slow website by isolating that layer first.

Mental model: the request lifecycle

A browser does not load a page in one step. It walks through a chain of work:

DNS resolution: the browser asks where the hostname points. Slow authoritative DNS, broken records, or bad TTL choices can delay the start.
TCP and TLS handshake: the browser opens a connection and negotiates encryption. Distance, routing, packet loss, old protocol support, and certificate setup can all show up here.
Server processing: the web server, application runtime, database, and upstream APIs produce the response. This is where slow TTFB often becomes visible.
Content download: HTML, images, CSS, JavaScript, fonts, and API responses move over the network. Large payloads and missing compression hurt here.
Browser rendering: the browser parses, styles, lays out, paints, and runs JavaScript. A fast server cannot save a front end that blocks the main thread.

Diagram placeholder: request lifecycle from browser to DNS resolver, TCP/TLS, web server, application/database, content download, and browser rendering.

Why is my website slow? Measure before guessing

Start with a waterfall, not a score. Chrome DevTools documents the Network panel and its request timing view in its Network reference. Use it to separate waiting time, download time, and blocked rendering resources.

PageSpeed Insights and WebPageTest are useful, but read the waterfall before debating the score. The number at the top is a summary. The waterfall is the evidence.

Screenshot placeholder: DevTools Network waterfall showing DNS, initial connection, TLS, waiting for server response, content download, and render-blocking CSS or JavaScript.

Use the command line as a second view. curl exposes timing variables such as time_namelookup, time_connect, time_appconnect, time_starttransfer, and time_total in its write-out documentation.

curl -o /dev/null -sS -w 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download} http=%{http_code} proto=%{http_version}\n' https://example.com/

Those times are cumulative from the start of the transfer. To estimate stage cost, subtract the previous stage. For example, TLS cost is roughly time_appconnect - time_connect, and server wait plus request time is roughly time_starttransfer - time_appconnect for HTTPS.

Then run the same test against a tiny static file and a dynamic page:

curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download}\n' https://example.com/favicon.ico
curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download}\n' 'https://example.com/?probe=1'

That comparison is the fastest split in the whole investigation. If the static file has low TTFB but the dynamic page has high TTFB, your host may be fine and the app is probably slow. If both are slow from several networks, look harder at the host, origin network, CDN, or routing.

Add basic path checks:

ping -c 20 example.com
traceroute example.com
mtr -rwzc 100 example.com

Use MTR from the visitor region when possible. A test from your laptop only proves the path from your laptop.

Layer-by-layer diagnosis

DNS resolution

Symptom: The page pauses before any connection starts. DevTools shows a long DNS phase, or curl reports high time_namelookup.

How to test: Check authoritative records and resolver behavior:

dig example.com A +stats
dig example.com AAAA +stats
dig NS example.com +short
dig SOA example.com +short
dig +trace example.com

If one resolver is slow but another is normal, the problem may sit with a resolver path rather than your authoritative DNS. If authoritative nameservers are slow, misconfigured, or inconsistent, fix the DNS provider or registrar setup first.

Verdict: Usually not the host. It is often the registrar, DNS provider, nameserver configuration, or resolver path. The host is involved only when it also runs your authoritative DNS.

Connection and TLS

Symptom: DNS finishes quickly, but the connection or TLS phase is long. Visitors far from the server complain more than visitors near the server.

How to test: Compare TCP, TLS, and protocol support:

curl -o /dev/null -sS -w 'tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s proto=%{http_version}\n' https://example.com/
curl -I --http2 https://example.com/
curl -I --http3-only https://example.com/

The last command requires a curl build with HTTP/3 support. If it fails locally, use browser DevTools or an external test. MDN’s HTTP evolution guide summarizes how HTTP/2 multiplexing and HTTP/3 over QUIC change connection behavior.

TLS overhead is rarely the whole problem on a warm connection, but repeated cold connections from distant regions add up. Certificate errors, missing session reuse, no HTTP/2, no HTTP/3, and no edge cache can make this layer worse than it should. If you are changing certificate configuration, verify the certificate chain, renewal path, redirects, and protocol support before blaming the host.

Verdict: Mixed. Geographic distance is a node location problem. Routing quality and packet loss can be host-related. Certificate configuration and protocol support may be your web server or CDN configuration.

Server response and TTFB

Symptom: DNS, TCP, and TLS look reasonable, but time_starttransfer is high. DevTools shows a long “waiting for server response” phase. Users see a blank page before the first byte arrives.

How to test: Compare static TTFB with dynamic TTFB from the same client:

curl -o /dev/null -sS -H 'Cache-Control: no-cache' -w 'static_ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/favicon.ico
curl -o /dev/null -sS -H 'Cache-Control: no-cache' -w 'dynamic_ttfb=%{time_starttransfer}s total=%{time_total}s\n' 'https://example.com/?uncached=1'

If both are slow, check the server itself:

uptime
free -m
vmstat 1 10
top -bn1 | sed -n '1,5p'

On a VPS, sustained CPU steal while the instance is lightly loaded is a red flag. It means the hypervisor is not giving your virtual CPU the time it asked for. RAM pressure, swap churn, and disk wait can create the same user-visible symptom.

If the static file is fast and the dynamic page is slow, move up the stack. Check application logs, PHP-FPM status, slow database queries, cache misses, upstream API latency, and queue workers. In a WordPress, PHP, or custom app, one uncached page or slow SQL query can make the host look guilty.

Verdict: Could be host or app. High TTFB on a tiny static file points toward host, origin network, CDN miss behavior, or web server configuration. High TTFB only on dynamic pages usually points to application code, database work, PHP/runtime limits, or cache misses.

Payload size

Symptom: TTFB is fine, but total load time is high. The waterfall shows large images, fonts, JavaScript bundles, CSS, or API responses taking most of the time.

How to test: Look at transferred bytes in DevTools and compare compressed responses:

curl -sS -o /dev/null -D - -H 'Accept-Encoding: br,gzip' https://example.com/
curl -o /dev/null -sS -w 'bytes=%{size_download} total=%{time_total}s\n' https://example.com/

Check for content-encoding: br or content-encoding: gzip on compressible text responses. MDN’s HTTP compression guide explains Accept-Encoding and response compression. For images, inspect dimensions and formats. A 3000 px image squeezed into a 360 px mobile slot is a content problem, not a VPS problem.

Verdict: Not the host. Hosting can affect throughput, but unoptimized images, excessive JavaScript, unused CSS, and missing compression belong to the site build and delivery configuration.

Caching and CDN

Symptom: The first request is slow, repeat requests are faster, or every page hit regenerates dynamic content. Global visitors see inconsistent results.

How to test: Inspect cache headers and repeat requests:

curl -I https://example.com/
curl -I https://example.com/assets/app.css
curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/
curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/

Look for cache-control, etag, last-modified, age, vary, and CDN-specific headers such as x-cache. A page cache can turn dynamic generation into a quick static response. A CDN can move static assets closer to users, but cache-busting query strings, no-store headers, and logged-in cookies can bypass it.

Verdict: Host-adjacent and configuration-driven. The host may provide a cache or CDN integration, but the policy is usually yours: what can be cached, for how long, and whether dynamic pages are safe to cache.

Front-end rendering

Symptom: HTML arrives quickly, but the page still feels slow. DevTools shows long main-thread tasks, render-blocking CSS, large JavaScript execution time, layout shifts, or late-loading fonts.

How to test: In DevTools, combine the Network panel with the Performance panel. Look for blocking scripts in the waterfall and long tasks during parse, style, layout, and paint. PageSpeed Insights can flag render-blocking resources and main-thread work, but confirm the finding in the trace rather than treating the score as the diagnosis.

Common fixes include deferring noncritical JavaScript, splitting bundles, removing unused CSS, preloading the right font files, setting image dimensions, and moving expensive work out of the critical path.

Verdict: Not the host. A stronger CPU on the origin server will not reduce the JavaScript execution cost on a visitor’s phone.

Network path, routing, and peering

Symptom: The site is fast for you and slow for a specific country, ISP, office, or mobile carrier. TTFB may be acceptable near the data center and poor near the audience. Packet loss or route detours appear in MTR.

How to test: Run path tests from the visitor geography, not only from your workstation:

mtr -rwzc 100 example.com
traceroute example.com
ping -c 50 example.com

Ask users in the affected region to run the same tests, or use a Looking Glass near them. Compare routes by ASN and city, not just hop count. A physically close server can still take a poor carrier path. A farther server with better peering can sometimes behave better for the audience you care about. For planning, match the node location to the visitor geography you actually need to serve.

Verdict: Host-related. Node location, carrier mix, transit quality, peering, and return path all belong to the hosting network decision. Your application code cannot fix a bad route to your main audience.

So is it actually the host?

Hosting is the proven bottleneck when the evidence points below the application layer.

Strong host signals include high TTFB on a tiny static file from multiple test networks, sustained CPU steal or disk wait on a lightly loaded VPS, RAM pressure that you did not create, packet loss on the path to the origin, or poor routing to your main visitor geography. Another common signal is the regional split: “fine for me, slow for visitors elsewhere.” That often means the node is in the wrong region or the network path is poor for that audience.

Weak host signals include a low PageSpeed score with huge images, slow dynamic pages while static files are fast, long JavaScript tasks after HTML arrives, or missing cache headers. Those problems can follow you to any provider.

Signal	Likely host issue?	Why
Tiny static file has high TTFB from several regions	Yes	Origin server, node network, CDN miss path, or overloaded VPS may be slow
Static file is fast but dynamic page TTFB is high	Usually no	Application, database, PHP/runtime, or upstream API work is slow
DNS lookup is slow or inconsistent	Usually no	Registrar, authoritative DNS provider, resolver path, or bad records are more likely
Large images or JavaScript dominate the waterfall	No	Payload and front-end build problems follow the site to any host
Repeat view is much faster than first view	Mixed	Caching policy, CDN, and application cache need review
Visitors in one region are slow while nearby users are fine	Often yes	Node location, peering, routing, and return path matter
CPU steal, disk wait, or swap churn appear under light load	Yes	Oversold VPS, noisy neighbor, or under-provisioned instance is plausible

Decision flowchart

Slow before connection starts
  -> likely layer: DNS
  -> fix: authoritative DNS, registrar records, resolver path, TTL policy

High TCP or TLS time
  -> likely layer: distance, routing, protocol support, TLS config
  -> fix: closer node, better route, HTTP/2 or HTTP/3, clean certificate setup

High TTFB on static and dynamic URLs
  -> likely layer: host, origin web server, CDN miss path, routing
  -> fix: inspect VPS load, CPU steal, disk wait, packet loss, node location

High TTFB only on dynamic URLs
  -> likely layer: application or database
  -> fix: page cache, query profiling, PHP/runtime tuning, upstream timeout review

Low TTFB but high total load time
  -> likely layer: payload
  -> fix: compress text, resize images, reduce JS and CSS, cache assets

HTML arrives quickly but the page is still unusable
  -> likely layer: front-end rendering
  -> fix: remove render blockers, reduce main-thread work, defer noncritical scripts

Slow only for one geography or carrier
  -> likely layer: routing and peering
  -> fix: choose a better node, test Looking Glass paths, use CDN or provider with better regional routing

When changing or upgrading hosting genuinely helps

Changing providers helps when the host is the measured bottleneck: an oversold VPS with CPU steal, an instance without enough RAM or disk performance, a node far from your users, weak peering to the target region, no IPv6 where your audience benefits from it, no HTTP/3 or modern edge support in your delivery path, or an IP setup that does not fit the service.

If your measurements point to location or routing as the bottleneck, compare Riven Cloud’s Tokyo and Singapore locations and network paths. When those match your audience, you can view VPS plans or order from the Riven Cloud portal.

Conclusion

The next time the question is “why is my website slow?”, do not start with a provider migration. Start with the waterfall, split static from dynamic, check the path, and name the slow layer.

Switching hosts helps when hosting is the proven bottleneck. If DNS is broken, fix DNS. If the app is generating pages slowly, fix the app or cache it. If the payload is too large, shrink it. If the route to your users is bad, then hosting location and network quality become the right problem to solve.