Why your website is slow: a guide for non-administrators

A slow website isn't a cosmetic detail: visitors leave, and Google knows it. You don't need to be a sysadmin to understand why it happens: you just need the right tools and the right questions to ask whoever manages your server. This guide provides both.

First: how to measure slowness

PageSpeed Insights (pagespeed.web.dev) is Google's free tool: enter your site's address and it returns a score from 0 to 100 plus a series of technical metrics called Core Web Vitals. The three that matter most, with Google's official thresholds:

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	how long the largest element on the page (usually an image or heading) takes to appear	under 2.5 seconds is "good"; between 2.5 and 4 seconds is "needs improvement"; above 4 seconds is "poor"
INP (Interaction to Next Paint)	how long the site takes to respond to a click or tap	under 200 milliseconds to be considered good by Google. Between 200ms and 500ms the site needs improvements; above 500ms user experience is considered poor
CLS (Cumulative Layout Shift)	how much the page "jumps" whilst loading (buttons and text moving around)	"good" threshold: under 0.1

PageSpeed Insights shows two types of data. Lab data is a test performed on the spot under standard conditions: it simulates conditions for a user on a 4G mobile connection with a mid-range device. Field data, on the other hand, comes from real visitors to your site over recent weeks and is what Google actually uses to decide your ranking. If lab scores are high but field data is red, your real visitors see the problem, not the test.

GTmetrix (gtmetrix.com) does similar work and adds a "waterfall" chart showing every single file loaded by the page with timings. It's useful for understanding which element is slowing everything down.

Your browser's Network tab (right-click on the page, "Inspect", then the "Network" tab) is the most granular view: reload the page and see, row by row, how long each image, script or font takes to download. You don't need to understand code: just look for the longest rows.

What is TTFB and why it's the first thing to check

In all three tools you'll see an acronym: TTFB, Time To First Byte. It measures the time between when the browser sends an HTTP request and receives the first byte of response from the server—in other words, how quickly the server starts responding, before the browser can even display anything. Essentially: how long the server takes to "wake up", before images or text even start downloading.

A common reference scale for reading it: 0.1–0.2 seconds: excellent; 0.3–0.5 seconds: good; 0.6–0.9 seconds: average; 1–1.5 seconds: above average; 1.6 seconds or more: very poor. If TTFB is high, the problem isn't in the visitor's browser: it's on the server, in the database, or in the code running before it responds. Server-side processing, caching, database, infrastructure, CDN or backend code are areas to investigate.

The six most common causes, one by one

1. Overcrowded shared hosting

On a shared hosting plan your site runs on the same machine as hundreds of others. If one of them uses too many resources, it slows yours down too.

How to spot it: high TTFB (above 0.6–0.9 seconds) that varies a lot from hour to hour, without any changes you've made to the site.

What to ask your hosting provider: "How many sites do you host on the same machine as my plan, and what CPU and memory (RAM) limits does my account have?" If they can't answer with a number, that's already a red flag.

2. Heavy plugins (or too many plugins)

Each plugin adds code that the server has to run on every visit. It's not about the absolute number, but how much work each one does.

How to spot it: in PageSpeed Insights, the "Diagnostics" section often lists the scripts blocking loading. In GTmetrix, the waterfall chart shows which files (often named after the plugin) weigh the most.

What to ask your developer: "Can you disable the plugins one at a time and rerun the test to see which one makes a difference?" It's a test that takes just a few minutes and isolates the culprit without needing to read code.

3. Unoptimised images

A photo taken with a smartphone can weigh 4–5 megabytes. If the site displays it as-is, the browser has to download all that weight before showing it.

How to spot it: in your browser's Network tab, sort rows by size (the "Size" column): if images are the heaviest rows, that's your problem.

What to ask: "Are images automatically compressed and resized before being published?" There are plugins and services that do this without manual intervention.

4. No caching

Cache is a ready-made copy of the page, saved to avoid recalculating it from scratch on every visit. Without cache, every visitor makes the server start all the work over: database queries, calculations, page generation.

How to spot it: if TTFB is high on the first visit and stays high even when reloading the same page right away, you probably don't have caching active (or it's not working).

What to ask: "Do you have a server-side caching system active? And if I use a caching plugin on my CMS, is it compatible with your setup?"

5. Distance from the server

If the physical server is in Frankfurt and your visitor is in Palermo, the data has to make that journey every time. The greater the distance, the more latency increases—that is, network delay.

A CDN (Content Delivery Network) is a network of servers spread across different geographic locations that keep a copy of your site's files (especially images, fonts, scripts) closer to whoever requests them, reducing that distance.

How to spot it: if the site is slow for visitors far from the server but fast for those nearby, it's a distance issue.

What to ask: "Where is the server physically located? If your audience is in multiple regions or countries, would it make sense to activate a CDN?"

6. Unoptimised database

Many sites (WordPress, e-commerce, CMSs in general) keep content in a database. If the database tables are full of old data, revisions, comment spam, or if they're missing the "indices" that speed up searches, each page takes longer to build.

How to spot it: high TTFB especially on pages that display lots of dynamic content (product lists, searches, pages with many comments).

What to ask your developer: "Is the database cleaned periodically of old and unused data? Have the slowest queries been reviewed?"

In summary: where to start

1. Test your site on PageSpeed Insights and look at field data, not just the score.
2. If LCP, INP or CLS are out of threshold, use GTmetrix to see the waterfall chart and understand which file or request weighs the most.
3. If TTFB is high, the problem is server-side: bring the data (numbers, not hunches) to your hosting provider or developer and ask the questions listed above.
4. Retest after every change: without the before and after numbers, you won't know if you've actually fixed it.