What makes a website slow, and how do you measure it?

Module 6: Speed · Reading time: 9 minutes

Learning objective: After this lesson, you can measure where the time is going and recognise the difference between slowness on the server and slowness in the browser.

Key concepts: TTFB, Core Web Vitals (LCP, INP, CLS), lab data, field data, PageSpeed Insights, network tab, compression, external scripts, hosting package limits, 503

Measure first, then fix

"The website is slow" can have ten different causes. If you install a caching plugin, an image optimisation plugin and a bigger package all at once without measuring, you won't know afterwards what actually helped, and you'll have three extra things to maintain. So always start with three questions (the same ones as in your hoster's guide):

1. Is everything slow, or just the admin area? A slow admin area with a fast front end points to plugins that do a lot of work in the admin area, or to bots hammering the login page.
2. Always, or only at certain times? Only during busy periods or when a scheduled task runs: then your package is hitting its limits.
3. For everyone, or only for you? Try it on your phone via 4G or 5G, or ask someone else. If it's only slow for you, the cause lies with your connection or VPN.

Two halves: server and browser

The time a visitor waits consists of two parts (lesson 1.2):

1. The server builds the HTML: web server, PHP, plugins, database. You see this as TTFB (time to first byte), the time until the first byte of the response arrives. web.dev's rule of thumb is that most websites should aim for a TTFB of 0.8 seconds or less.
2. The browser reads that HTML and then fetches everything it contains: stylesheets, scripts, fonts, images, video, tracking codes, chat widgets. Only once enough of this has arrived does the visitor see something.

You fix a high TTFB on the server side: caching (lesson 6.2), fewer or lighter plugins, a newer PHP version, a tidied-up database (lesson 6.3), or more processing power. A low TTFB with a slow page anyway points to the browser side: oversized images, too many scripts, external components.

Core Web Vitals

Google measures the visitor experience with three figures, the Core Web Vitals:

INP replaced the older FID measurement in March 2024. Google uses these figures partly when ranking search results, but the main reason to improve them is simple: visitors leave when a page is slow or keeps shifting.

Lab data and field data

There are two kinds of measurements, and they give different numbers:

• Lab data: a test at one moment, from one location, with a simulated phone and connection. Useful for comparing (before and after a change), but it's not a real visitor.
• Field data: measurements from real visitors using Chrome, over the past 28 days. That's what visitors actually experience. Small websites often don't have enough visitors for field data.

PageSpeed Insights (pagespeed.web.dev) shows both: field data at the top (if available), and a lab test with a score and specific recommendations below it. Don't just look at the score out of 0 to 100. Look at the components: is LCP poor because the server is slow (TTFB), or because the large photo is 3 MB?

Always test a few times (the numbers vary), and also test an ordinary page, not just the homepage.

Taking a look yourself with the browser

Your browser's developer tools (F12) show what's really happening:

• Network tab: refresh the page with the cache disabled (tick "Disable cache"). You'll see every file being loaded, how big it is and how long it took. Sort by size: the largest files are often images. Sort by domain: how much comes from other parties (fonts, tracking codes, videos)?
• The first request (the HTML itself): click on it, Timing tab. "Waiting for server response" is the TTFB.
• Headers of that first request: is there compression (content-encoding: br or gzip), and did the page come from a cache (lesson 6.2)?

The usual culprits

In practice, slowness in WordPress is usually caused by one of these:

1. No page cache: every page is rebuilt from scratch on every visit (lesson 6.2).
2. Too many or heavy plugins, especially plugins that call external services or run heavy queries on every request (lesson 5.3).
3. Large images: a 5 MB photo from a phone on the homepage (lessons 4.4 and 6.3).
4. A heavy theme or a page builder that loads lots of scripts and stylesheets on every page (lesson 5.1).
5. External components: fonts, videos, chat widgets, tracking codes, social media buttons from other parties. Each is a connection to another server, which can be slow.
6. An old PHP version (lesson 8.4).
7. A cluttered database: thousands of revisions, spam, plugin log tables (lesson 6.3).
8. Bots: crawlers, AI crawlers and login attempts keep your package busy (lesson 7.3).
9. The package is hitting its limits: not enough processing power (CPU), processes or memory for the traffic.

The limits of your package

With shared hosting, each package gets a fixed share of the server: processing power, memory, disk speed and a number of simultaneous processes. If your website uses more, it gets throttled, or visitors get a 503 error (Service Unavailable, called "Resource Limit Is Reached" by some hosters). In DirectAdmin with CloudLinux you see this under Resource Usage (with "faults" if your website was throttled), and X-Ray shows you, per page, which plugin or query is costing time. Other hosters have similar overviews, sometimes only on request.

A bigger package helps if your website genuinely needs more (a busy webshop). It doesn't fix a badly set up website: the problem will come back later. Find the cause first.

Summary

• Measure first: everything or just the admin area, always or sometimes, everyone or only you.
• TTFB is the server side (aim for 0.8 seconds or less); the rest is what the browser loads.
• Core Web Vitals: LCP (2.5 s), INP (200 ms) and CLS (0.1); INP replaced FID in 2024.
• PageSpeed Insights shows field data and lab data; the network tab shows what's really loading.
• Most slowness comes from no cache, heavy plugins, large images and external components; a bigger package is only the last step.

Quiz

Exercise

Exercise A6.1: Measure your TTFB and compression. Enter your website's address and, if you like, one ordinary page (for example your contact page). The tool requests each page three times without cookies and gives the median TTFB, the size of the HTML, and whether the server sends the HTML compressed (content-encoding gzip or br). Compare the result with a test in PageSpeed Insights and note down what you notice.

Further reading

These articles describe the steps in WebOké's panels; they work similarly in other panels.

• DirectAdmin guide 18.3: My website is slow
• DirectAdmin guide 17.3: Resource Usage: CPU, memory and processes
• DirectAdmin guide 17.4: X-Ray: tracking down slow pages
• DirectAdmin guide 17.5: 503 or 'Resource Limit Is Reached': what now?
• My website is slow or uses too much CPU: here's how to make it faster
• Core Web Vitals (web.dev, English): https://web.dev/articles/vitals
• PageSpeed Insights: https://pagespeed.web.dev/