Why Is My Website Slow? How to Find the Cause in 15 Minutes

A slow website is almost always slow for one or two specific reasons, and you can name them in about fifteen minutes with free tools, before spending a cent on new hosting or a redesign. That matters because visitors never file a complaint about a sluggish page. They tap back, pick the next result, and your analytics log one more bounce that nobody can explain. When Deloitte Digital tracked 37 retail, travel and luxury brands for Google, a 0.1 second improvement in mobile speed lifted retail conversions by 8.4% and travel conversions by 10.1%, which makes a tenth of a second worth more than most landing page headlines.

Google measures slowness with three Core Web Vitals, collected from the Chrome browsers of real visitors on their own phones and connections. Your site passes when its main content appears within 2.5 seconds, when it responds to a tap in under 200 milliseconds, and when its layout holds still with a shift score under 0.1.

Most of the web misses at least one of these on mobile. The 2024 Web Almanac found that 59% of mobile sites had a good LCP, 74% a good INP and 79% a good CLS, yet only 43% cleared all three at once, because each metric fails for a different reason and most sites carry at least one of those reasons. Only 42% of mobile sites had a good TTFB, which tells you how many slow pages are already behind before the browser has seen a single line of HTML.

Your website is slow because the server is late with its first byte, because the page is heavy enough that the browser spends seconds fetching and parsing it, or because scripts keep the phone's processor too busy to respond to a tap. Each of those has a short list of usual causes, and the table maps each one to the symptom you would notice and the check that confirms it.

The order of that table is not an accident. The first two rows live on the server, the next six live in the page, and the last one lives in the plumbing between the visitor and your domain, so the next two sections take the server and the page in turn.

"80-90% of the end-user response time is spent on the frontend. Start there."

Steve Souders, author of High Performance Web Sites, in The Performance Golden Rule

Check time to first byte before anything else, because it tells you which half of the problem you own. TTFB covers redirects, the DNS lookup, the connection and TLS handshake, and the time your server spends building the page, all before the browser receives a single byte to work with.

Souders wrote that rule for the average site, and his 2012 rerun across 50,000 sites in the HTTP Archive still put 87% of load time on the frontend. Slow sites break the average. In the Web Almanac's breakdown of mobile sites with a poor LCP, TTFB alone consumed 2.27 seconds, the wait before the main image even started downloading took 1.29 seconds, downloading that image took 350 milliseconds and rendering it took 360. The image compression every checklist recommends goes after the smallest slice of that pie.

When TTFB is the problem, the cause is usually that the server rebuilds every page from scratch on every visit. A WordPress or Laravel page without a page cache runs PHP and a stack of database queries for each request, and on shared hosting it does that while competing with every other site on the same machine, which is why the delay grows at lunchtime and shrinks at 3 a.m. A cached page skips almost all of that work, and a CDN in front of the origin can hand it over from a data centre a few hundred miles from the visitor.

On most pages the largest thing in the first screen is a photo, and the browser often learns about it too late to start downloading it early. That discovery gap is the 1.29 seconds of load delay in the breakdown above, and it is the cheapest second you will ever win back.

Two habits cause most of it. The first is lazy loading the hero: loading="lazy" tells the browser to wait until the image is about to scroll into view, which is sensible for photos halfway down the page and self-defeating for the one at the top, yet the Web Almanac found 16% of mobile sites doing it to their LCP image. The second is hiding the hero from the HTML entirely, as a CSS background or a slide injected by a carousel script, so the browser has to download and run that code before it even finds out the image exists. In 2024, 35% of mobile sites had an LCP element that was not discoverable in the initial HTML.

The fix is unglamorous. Put the hero in a plain <img> tag in the HTML, leave it eagerly loaded, add fetchpriority="high" so it jumps the queue, serve it as WebP or AVIF at the width it actually displays, and give it width and height attributes so nothing below it jumps when it arrives. Homepage sliders deserve extra suspicion here, because the slide a visitor sees first is often the last one the script gets around to loading.

Our own homepage runs a full-bleed slider, so we found this one out on our own code. The first slide ships as a plain <img> with fetchpriority="high" and a preload hint in the <head>, and every later slide waits in a data-src attribute until the script fetches it one slide before its turn. Native loading="lazy" would have deferred none of them, because a fading carousel stacks every slide in the viewport at once and the browser treats all of them as visible.

Third-party code is the most common reason a page looks finished yet ignores taps. Chat widgets, analytics, ad tags, heatmaps, review badges and social pixels each run JavaScript on the visitor's processor, and while one of them is busy the page cannot react to anything the visitor does.

Phones feel this far more than laptops. The same Web Almanac data shows 97% of desktop sites with a good INP against 74% on mobile, a gap that comes from slower phone processors chewing through the same scripts a desktop barely notices. A tag that costs nothing in your office can cost a customer on a three-year-old Android a half-second stall every time they open the menu.

WordPress sites add a second layer. Many plugins load their CSS and JavaScript on every page, including the pages that never use them, so a contact-form plugin can weigh down your blog posts and a page builder can ship its whole toolkit to a page with three paragraphs. Every abandoned plugin is also code an attacker can probe, which is why trimming the plugin list shows up in our WordPress security checklist as well as in every speed audit. On our own site, Google Tag Manager was costing about 275 KiB of transfer and roughly 300 milliseconds of main-thread work on mobile, and a PageSpeed Insights run we made on April 25, 2026 showed its scripts executing right in the window where the main image paints. We now hold the tag back until a visitor first scrolls, taps or clicks, or until 3.5 seconds pass with no interaction at all, so the page paints before any tracking code runs. The trade is that a visitor who leaves within 3.5 seconds without touching anything never records a pageview, which a lead-generation site can accept and a store counting every ad click might not.

When we ran the cached-versus-uncached test from the tip above against this article, Cloudflare's edge returned the first byte in a median 0.10 seconds and our origin server took a median 0.31 seconds, roughly three times as long, even though the origin keeps its own page cache.

How we measured: 10 curl requests per variant to this page from a machine in the Dallas area, all routed through Cloudflare's Dallas-Fort Worth data centre, on the evening of October 1, 2026. The plain URL returned a cache HIT on all 10 requests, and the version with a unique query string returned a MISS on all 10, ranging from 0.24 to 0.38 seconds.

Both numbers sit well under the 800 millisecond line, so the server is not what slows this page, and a hosting upgrade would only make a fast answer slightly faster.

A number from your own desk only describes your own route to the site, so we borrowed more desks. Using the Globalping measurement network, we fetched this page from twelve probes in eleven cities on six continents, twice, 25 minutes after a deploy had purged every copy from Cloudflare's edge. We expected the first pass to catch cold locations fetching from our origin in Texas. Instead all twelve answered from cache: first byte between 49 and 273 milliseconds on the first pass, and between 21 and 123 milliseconds on the second, with a median of 43.

How we measured: two Globalping HTTP measurements of this URL at 11:04 pm and 11:05 pm Central on October 1, 2026, three probes each in North America, Europe and Asia and one each in South America, Oceania and Africa, reading cf-cache-status and time to first byte from each response. The two passes drew overlapping but not identical probe sets.

The reason is a shared middle layer. With Cloudflare's Tiered Cache, an edge location that misses asks an upper-tier location before it asks the origin, and that fits what we saw: the Age header on every warm response pointed at the same moment about ten minutes earlier, when we had fetched the page once from Dallas to check the deploy. One visit had warmed the page for everyone. A CDN without that layer refills one city at a time, and a fast test from your office then says nothing about the first visitor in Sydney, so find out which kind you have before you trust a single number.

Two smaller things fell out of the data. In Singapore the slowest first byte, 273 milliseconds, was 259 milliseconds of DNS lookup, so the plumbing row in the table above can be most of the wait on its own. And the probe in Lagos was served from London on both passes, because the nearest cache location is not always on your continent. Neither shows up in a test from your desk, which is the point of running one from somewhere else.

The business owner's version of our finding: ask whoever runs your site whether its CDN shares a cache between locations, because if it does not, a fast number from their office is only true in their city.

In April 2026 we tried the textbook render-blocking fix on our own stylesheet. The homepage's largest paint was waiting on about 243 KB of CSS while the hero image it needed to show had loaded in 158 milliseconds, so we kept a 4 KB critical stylesheet in the way and loaded the other 226 KB of Tailwind in the background. On paper that should have pulled our 3.12 second lab LCP into the good band. We reverted it six minutes after it shipped, because every page painted without its styles for a moment before the full stylesheet arrived, and the site felt slower to us than the version it replaced.

From our commit history: the change shipped at 9:50 am and was reverted at 9:56 am Central on April 24, 2026. The byte counts and the 3.12 second LCP come from the change's own notes, measured in Chrome DevTools before it shipped.

The score was timing the moment the hero painted. Visitors were watching everything around it. If we try again, it will be with a critical stylesheet extracted from the real pages by a tool built for that, because a hand-picked one covers the hero and leaves the navigation to arrive late, and a navigation that arrives late reads as a broken page no matter what the metric says.

For the business owner, our six minutes bought one rule: when a developer promises a better speed score, look at the page on a phone before you pay for the number, because we raised ours and made the site look broken doing it.

To diagnose a slow website, start with real-visitor data, use it to pick the failing metric, and then use browser tools to find the specific file or server delay behind it. Change one thing at a time and measure again, or you will never know which change earned the improvement.

1. Run your homepage and your busiest inner page through the PCDrama PageSpeed Scanner on mobile, and read the field data before the lab score if your site has enough traffic to report it.
2. Note which metric fails, because it picks your branch: a slow TTFB or LCP points to the server and the hero image, a slow INP points to scripts, and a poor CLS points to unsized media and late fonts.
3. Open Chrome DevTools, tick Disable cache in the Network panel, set throttling to a mobile profile, reload, and read the first row's waiting time, which is your TTFB.
4. Sort the Network panel by size and by time to find the heaviest and slowest files, and note which ones come from domains you do not own.
5. Record a Performance trace, find the LCP marker, and look for long tasks (the red-flagged blocks) and which script owns them.
6. Repeat one test from a phone on mobile data, away from your office network, to check how the site behaves for someone who has never visited it before.

Pick the one page that earns you the most money or leads, run it through the PageSpeed Scanner on mobile, and write down the failing metric before you change anything. Then compare your score with the sites in our Hall of Fast Websites, all verified at 90 or higher on mobile, to see how far you have to go. If the diagnosis points at an aging theme or a host that cannot keep up, the Secure or Replace check looks at your current site live and sends back a scoped plan with a real price attached.

Sources: web.dev, Milliseconds Make Millions (Deloitte Digital for Google); HTTP Archive, Web Almanac 2024: Performance; Google Search Central, Understanding Core Web Vitals and Google search results; Steve Souders, The Performance Golden Rule.