Why is my website so slow? On three sites of mine it was never the server. How to find where your wait is, with only a browser.

When a site is slow, the host is the usual suspect. It is the easy explanation: the host is the one part of a site an owner cannot see. On 15 October 2026 I measured three of my sites the same way. All three are on the same host and behind the same CDN, a network of servers in front of yours that can keep saved copies of pages closer to visitors. The host, the part all three shared, turned out not to be the slow part. The server’s typical first answer from my laptop was 155–167 ms, on all three. Scripts from other companies cost 6 to 10 ms. The two pages that were slow were slow because of their own JavaScript, the animation code on each.

That is one host and three sites; yours may behave differently. The method, though, needs nothing beyond Chrome, and it tells you which of three places your wait is in before you pay anyone.

Find where the wait is, in this order

First, is it slow for anyone but you? Open the page on a phone with Wi-Fi off, or ask someone in another town. Google’s page on lab and field data, the lab being a test run on one machine and the field being real visitors, explains why the answer can differ from person to person: “That is, for some people who visit your site, it may load very quickly, while for others it may load very slowly.” The same page gives one common reason one person’s experience can differ: “The first time a user loads a page it may load slowly, but if the page has proper caching configured, the next time that user returns the page might load right away.” On my laptop, nine of sixty test runs spent about a second just finding the server’s address, probably because of the VPN I was on; the server’s own answer in those runs was 67–136 ms. Try once with any VPN off. If the page is slow only on your machine, your machine is the subject, not the site.

1. The server’s first answer. In Chrome, open the page and open DevTools, Chrome’s built-in panel for people who build pages: Cmd + Option + I on a Mac, Ctrl + Shift + I or F12 on Windows (or right-click → Inspect). Open the Network tab and reload. The first row in the list is the page itself. Click it and open the Timing tab. The row called “Waiting for server response” is the server’s part. Older Chrome and Google’s reference page for the Network panel call the same row “Waiting (TTFB)” and explain it as “1 round trip of latency and the time the server took to prepare the response.” Write the number down, then do it again on an old, rarely visited post, or add a made-up parameter such as ?nocache=1 to the address, because a saved copy of the page can hide a slow server. Google’s page on improving server response time warns:

Google’s page on improving server response time, on caching

Caching is great, but it can mask a slow backend making diagnosing long TTFBs harder since testing a cached page often shows no TTFB issues.

Without DevTools, PageSpeed Insights gives a similar number, measured from Google’s machine. Paste your address, press Analyze, and lower down, under the test results, the line “Document request latency” says whether the server responded quickly or slowly, with the observed time beside it; Google’s page on that line says the server line fails when the server takes more than 600 ms.

On WordPress, Tools → Site Health in the admin reads it for you, by timing the site asking itself. Since version 6.1, as WordPress’s announcement of the check explains, it checks whether the site uses a page cache and whether the response time is acceptable, which by default means under 600 ms, a limit a host or plugin can change; when it is not, Site Health warns that the server response time is slow.

If yours is well under 600 ms, as my three were (155 to 167 ms), the server is probably not where most of your wait is. If it is above 600 ms even on pages nobody visits, the server is part of your wait; what to do about it is in the last section.

2. Your own page. Still in the Network tab, tick “Disable cache” at the top, so the browser fetches every file the way a first visit does, as Google’s reference page for the Network panel recommends; then reload and look at the list. Each row is one file the page asked for. The filter buttons above the list, JS, CSS, Font, Img, show one kind at a time, and the status bar at the bottom shows how much was transferred. Three kinds carry the weight: scripts, fonts and images. Note which kind is biggest on yours. Then look at what the browser had to wait for before it could draw anything: PageSpeed’s lab section has a line about requests that block the first paint, and Google’s page on it says: “Requests are blocking the page’s initial render, which may delay LCP.” LCP is when the biggest thing on the first screen is drawn. Fonts count too; Google’s page on web fonts says “Large font files can take a while to download and negatively affect First Contentful Paint (FCP)”. Scripts cost twice, once to download and once to run. For the running, the closest single number is Total Blocking Time, on the same PageSpeed report; what it is and how it moves between runs is in the article on PageSpeed’s score. For now: if it is in the hundreds of milliseconds on every run, the scripts are where the wait is, and the next check tells you whether they are yours or another company’s.

3. Other companies’ scripts. Google’s guide on third-party JavaScript lists what these usually are: “Social sharing buttons”, “Video player embeds”, “Chat services”, “Advertising iframes”, “Analytics and metrics scripts”, “A/B testing scripts for experiments”. In the Network list they are the rows whose address is not your domain; hover a name to see its full address, or right-click the column header and turn on “Domain”. Google’s page on finding slow third-party scripts gives the test: “measure how your load time changes by blocking the requests to those scripts.” The reading is in the status bar at the bottom of the Network panel, which shows “DOMContentLoaded” and “Load” times. Reload three times with nothing blocked and note the middle Load time. Then, as Google’s page on request blocking says, “In the Network panel, under the Name section, right-click a request and select Block request or Throttle request.” The item to choose is “Block request domain” (in the newest Chrome it sits under “Block requests”); it blocks every file from that company’s address. Reload, and the blocked rows show “(blocked:devtools)” in red. Do that three times and compare the middle Load times; the same page on finding slow scripts notes that “doing three or more runs of measurement and looking at the median values will likely produce more stable results.” The block lasts only while DevTools stays open; the blocking page says “Closing DevTools disables network request blocking and throttling.” PageSpeed cannot see a block made this way, because it loads the page on Google’s machines.

One warning about the shortcut. The current PageSpeed report has a line called “3rd parties”, and it always passes: Google’s page on that line says “This insight always passes, but will still show for informational purposes if any third-party requests are detected.” It cannot tell you a script is slow. Read the time it lists for each company instead.

Three sites of mine, one host, one CDN

The three: cryptowl.io, a product site with an entrance animation; kovalweb.com, a WordPress site with a custom theme; and kovalseo.com, the site this blog is on. Same host, same CDN, measured the same morning on 15 October 2026. A fourth, small personal site measured the same way read like kovalseo.com on every row, so it is left out of the table. The server number is the middle of ten readings taken about five minutes apart, from my laptop, through the CDN’s nearest location; visitors farther from the server wait longer. The file counts are from one load of each page. The rest is on my laptop, with Lighthouse, the test engine inside PageSpeed, five runs per page and device, and my laptop was busy, so compare the columns with each other and not with your PageSpeed report.

The first row is the one an owner expects to differ, and it is the one that did not. That day none of the three pages came from the CDN’s saved copy; kovalweb.com keeps its saved copy with a cache plugin on its own server instead. Every visit reached the server, which spent under ten milliseconds of its own time on each. The row for other companies’ scripts is the same file everywhere, the CDN’s own analytics beacon, and it costs a few milliseconds. Every millisecond of blocking time in the table belongs to the two pages with heavy animation code.

cryptowl.io loads 36 script files of its own on a phone, most of them an animation library and the scenes built on it. Its blocking time on a simulated phone was 1,074 ms in the middle of five runs, and above 200 ms in every one; its hidden headline is the case in the article on real visitors’ numbers. The server’s part of all that was 156 ms.

kovalweb.com is the WordPress case, and the one where I tested both suspects: on my laptop I ran Lighthouse with some addresses blocked. Blocking every request from another company did not lower its blocking time: 147 ms on the phone became 164, inside the run-to-run spread. Blocking the site’s own script files took it from 147 to 0 ms and cut the browser’s work on the page by about two thirds. That is the most those scripts could cost, not a fix: without those files the theme’s animations do not run, and it is a different page. Even then its main content appeared at about 2.85 s on the simulated phone; what remains, as I read it, is the page’s own weight: fifteen stylesheets fetched before it draws, three fonts and a drawing file sharing a slow simulated connection. On a desktop the same page loads seven fonts, 212 KB, more than half its bytes.

And the plugins, the first thing a WordPress owner is told to blame? Three plugins leave traces in its pages, and together they add about 6.4 KB of script and no files. Everything heavy, the twenty-one script files on a desktop, the fifteen stylesheets, the seven fonts, is the theme’s. That matches the first line of the WordPress configuration section on WordPress’s own optimization page: “Your theme will have a huge impact on the performance of your site.” I chose that theme’s animations, and cryptowl.io’s. The slow part of both sites is a decision of mine, sitting on a server that answered in a sixth of a second.

Once you know which of the three it is

The server’s first answer. If it is slow even on a page nobody visits, the first question is whether the site keeps a saved copy of its pages on the server (a cache plugin or the host’s own); the article on AI bots shows a site that did not. If it does and the answer is still slow, that is a question for the host.

Your own page. Scripts you added, an animation, a slider, an effect, are yours to keep or drop, and the blocking test above tells you what they cost. Scripts the theme brought are the theme author’s, or the person who built the site for you. Images are usually yours: a photo wider than the space it fills is wasted bytes, and the fix is to resize it before you upload it. Each font weight and style is a file, and that is a design decision.

Other companies’ scripts. Each is a tag someone added, and whoever added it decides whether it stays. Take them the blocking-test reading. On my three sites it was a few milliseconds and nothing worth removing. On yours, it may be the largest number on the list.

Reading it again after the change

Repeat the reading that found the wait, on the same page and the same tab, three times, and compare the middle readings; the PageSpeed article explains why one run is not enough. If the server’s answer was the problem, that is the Timing tab on the same unvisited page; if a script was, block nothing this time and see whether the Load time stays down. Google’s page on the speed tools says that running Lighthouse from inside Chrome “is useful to validate fixes locally”. Its page on improving server response time gives the whole loop: “measure your TTFB in the field, use lab tools to drill down into the causes, and then apply optimizations where possible.” Your lab is the Network tab; your field is the box of real-visitor numbers at the top of a PageSpeed report, and that box takes weeks to show a change, as the article on it explains.

Then keep the number. The same page on the speed tools reports that “Research by Google has shown that most performance improvements tend to regress within six months.” A plugin update, a new widget, a bigger hero image, and the wait is back without anyone deciding it. The reading you wrote down today is what tells you.

The 7% figure

Among the pages that answer this question, written by hosts, agencies and tool makers, one quotes a figure that circulates widely: a one-second delay costs 7% of conversions; others repeat the idea without the number. It is traced to a report by the Aberdeen Group from November 2008, almost eighteen years old, a survey of more than 160 organisations about web applications used inside companies, not public websites. I could not find a figure that applies to a small-business site in 2026, so this article offers none.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.