Slow website: 7 common causes and how to spot them without IT skills

A website that takes 6–7 seconds to load loses visitors before the page is even visible. Non-technical site owners often don't know where to start when troubleshooting slowness. This guide covers the 7 most common causes, how to spot them with two free tools, and who to ask for help with each one.

First: what to measure and with what

The reference tool is PageSpeed Insights from Google (pagespeed.web.dev), which is free: just paste in your site's address. PSI uses the Chrome User Experience Report (CrUX) for real-world data, measuring metrics such as First Contentful Paint (FCP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP). PSI rates user experience as Good, Needs improvement and Poor based on established thresholds for key metrics.

Two thresholds that matter for non-technical users:

Metric	Good	Needs improvement	Poor
LCP (time to load main content)	0–2500ms	2500–4000ms	over 4000ms
TTFB (server response time)	0–800ms	800–1800ms	over 1800ms

The second useful tool is GTmetrix (gtmetrix.com): it combines Google PageSpeed and Yahoo YSlow data in an intuitive interface with advanced features, including an interactive waterfall chart to analyse each resource. Basic use is free, but it's worth signing up because a free account lets you run tests from select locations—choosing a city closest to your site's server avoids skewing results with network distance.

The 7 most common causes

1. Overloaded shared hosting

On shared hosting, resources (CPU, RAM, disk I/O) are divided among hundreds of sites on the same server. If TTFB in PageSpeed Insights consistently exceeds 800 ms, even on simple pages without heavy plugins, your main suspect is the server, not your site. Contact your hosting support with the TTFB figure; if the problem persists after several weeks, you'll need a plan with dedicated resources (VPS) or a different host.

2. Heavy or too many plugins (CMS)

On WordPress, Joomla or PrestaShop, each plugin adds database queries and scripts to load. You can spot this by disabling plugins one at a time and re-running the GTmetrix test after each one, comparing total load time. Contact the developer or agency managing your site, since they need to understand which plugins are essential.

3. Unoptimised images

Images uploaded at their original camera resolution (often 4–6 MB) instead of compressed for web are a common and easy-to-spot cause: PageSpeed Insights' diagnostics section lists images to optimise, showing the potential savings for each file. Contact whoever uploads content with a compression tool before uploading, or the developer for server-side automatic optimisation.

4. No caching

Without caching, every visit regenerates the page from scratch by querying the database. Check this by comparing TTFB on a first visit and a subsequent one shortly after: if they're identical, caching isn't working or isn't enabled. Ask your hosting (many control panels have built-in cache to enable) or the developer for a CMS-level caching plugin.

5. Server geographically far away

If your audience is in Italy but your server is in the United States, each request travels more kilometres and more network nodes. Test this with GTmetrix by selecting an Italian city as your test location: if initial connection time (not server TTFB, but network latency) is high, distance matters. Ask your hosting which data centre hosts your site, or consider a CDN for static content.

6. Database needing optimisation

Database tables that have grown over time, full of article revisions, comment spam or never-cleaned logs, slow down every query. You spot this indirectly: if TTFB worsens progressively over time with no site changes, that's a hint. Ask the developer or your hosting for database table cleanup and optimisation.

7. Slow DNS or SSL certificate

Before the browser even contacts the server, it must resolve the domain name (DNS) and, for HTTPS, negotiate the certificate. In GTmetrix's waterfall chart these phases appear as separate items at the start of loading, before the first HTTP request. If they take hundreds of milliseconds, the problem is with your DNS provider or certificate configuration. Ask whoever manages your domain or hosting to verify which DNS servers are being used.

In summary

None of these checks require sysadmin skills: a browser, PageSpeed Insights and GTmetrix are enough to pinpoint the main suspect. The next step—actually fixing it—almost always goes to whoever manages your site or hosting, but arriving with precise data (LCP, TTFB, which waterfall phase is slow) dramatically cuts their response time.