A slow website isn’t just an annoyance: it’s a money leak. Users leave, Google takes it into account and every extra second of delay reduces conversion. If your site takes several seconds to show content on a phone, you’re probably losing a good share of your visitors.

The good news is that slowness is almost never a single problem: it breaks down into identifiable, fixable causes. This guide explains how to diagnose what’s going wrong and what to do in each case, without needing to be a developer.

First, diagnose: where’s the bottleneck?

Before touching anything, you need to know what’s slow. A server that takes a long time to respond isn’t the same as a 5 MB image or a script that blocks the page. Free tools to get started:

  • PageSpeed Insights. Enter your URL and you’ll see two views: real-user data (CrUX) and a lab audit (Lighthouse). The first is the one that matters for rankings; the second tells you what to fix.
  • Chrome developer tools (Performance panel). Open your site, press F12, go to the Performance tab and record a load: you’ll see which resource takes how long and where rendering gets blocked.
  • WebPageTest. More advanced, it lets you see loading from different locations and devices.

The key metric is TTFB (Time to First Byte): how long your server takes to send the first byte of the response. If it’s high, the problem is in the hosting, the database or the server configuration. If TTFB is good but the page is still slow, the problem is in the resources: images, CSS or JavaScript.

Cause 1: the server takes too long (high TTFB)

The server is the first link: if it’s slow to respond, everything else waits. A high TTFB can be due to saturated shared hosting, slow database queries or a lack of server-side caching. What to do:

  • Enable page caching. It’s the optimization with the biggest impact and the least effort: it stores static versions of your pages so the server doesn’t have to generate them on every visit. On WordPress, a caching plugin solves it in a few clicks.
  • Use a CDN. It distributes your content across servers around the world, and each user receives the page from the nearest node, not from your origin server. It greatly reduces TTFB for distant visitors. It also adds security, as we see in How to protect your WordPress site from attacks with a CDN like Cloudflare.
  • Review your hosting. If you’re on a cheap shared plan and your site has traffic, the server may be saturated. An upgrade to a VPS or managed hosting usually solves it.
  • Optimize the database. On WordPress, revisions, temporary data and spam pile up. Cleaning it periodically reduces response time.

Cause 2: images are too heavy

Uncompressed images are the most common cause of perceived slowness. A 3 MB image takes a while to download on a mobile connection and, if it’s in the visible part on load, it blocks LCP. What to do:

  • Compress them. There are online tools and plugins that do it automatically on upload, and you can cut the weight a lot without visible loss of quality.
  • Use modern formats. WebP and AVIF weigh considerably less than JPEG and PNG at comparable quality, and most current browsers support them.
  • Resize them before uploading. Don’t upload an image 4000 px wide if it will be shown at 800 px.
  • Enable lazy loading. Images that are off-screen shouldn’t load until the user gets close to them.
  • Always define width and height. Without explicit dimensions, the browser doesn’t know how much space to reserve and the content jumps when the image loads, which generates CLS (cumulative layout shift).

Cause 3: JavaScript and CSS that block rendering

The browser shows nothing until it processes the CSS and JavaScript in the <head>. If those files are large or there are many of them, the page stays blank waiting. What to do:

  • Minify CSS and JavaScript. Spaces, comments and line breaks are removed; optimization plugins do it automatically.
  • Defer non-critical JavaScript. Analytics scripts, chat, tracking pixels and social widgets don’t need to run before the user sees the page: with defer or async they load after the main content.
  • Remove what isn’t used. Every plugin you install adds CSS and JavaScript. Audit the list and uninstall whatever doesn’t provide clear value.
  • Inline critical CSS. The CSS needed for the visible part of the page can go directly in the HTML to avoid a network request, and the rest loads deferred.

Cause 4: the main thread is blocked (high INP)

INP (Interaction to Next Paint) measures how long your site takes to respond when the user clicks something. If the browser is busy running JavaScript, the click waits. Google considers an INP of 200 milliseconds or less good. What to do:

  • Break up long tasks. If a script runs all at once for half a second, the browser can’t respond to anything else. Splitting the work into smaller chunks gives it room to attend to the user.
  • Audit third-party scripts. Tag managers, tracking pixels, chat widgets and heatmap tools add work to the main thread. Ask yourself whether they’re all essential, and defer the ones you keep.
  • Optimize event handlers. If clicking a button triggers several heavy operations, the delay shoots up. Do only what’s needed to update the interface right away and defer the rest.

Cause 5: content moves while loading (high CLS)

CLS measures visual instability. If the user tries to tap a button and right then the page shifts because an image or an ad loaded, the experience is frustrating. Google considers a CLS of 0.1 or less good. What to do:

  • Reserve space for everything. Images, ads, iframes and embedded content need defined dimensions (width and height, or aspect-ratio in CSS) before the content loads.
  • Load fonts in a controlled way. With custom typefaces, text can first appear in a system font and then swap, moving the whole layout. With font-display or font preloading you minimize that jump.
  • Avoid inserting new content the user didn’t ask for. Cookie banners, pop-ups and notice bars that appear after the initial load should reserve their space or be shown outside the document flow.

Cause 6: unnecessary redirects

Every redirect adds an HTTP request. If your site redirects from HTTP to HTTPS, then from www to non-www and then to the final URL, it piles up latency for no reason. What to do:

  • Review the redirects. With a redirect checker you can see how many hops there are to the final URL. Ideally there’s one, or none if you’re already on HTTPS.
  • Update internal links. If they point to URLs that redirect, change them to go directly to the final destination.
  • Consolidate www and non-www. Choose one canonical version and redirect the other with a single rule, without redirect chains.

Cause 7: inadequate hosting

Sometimes the problem isn’t your site but where it lives. Cheap hosting with limited resources can’t serve a site with real traffic quickly, no matter how much you optimize. Signs that it’s time to switch:

  • A TTFB that stays consistently high.
  • Performance drops at peak hours.
  • Shared resources that run out when your traffic goes up.
  • Technical support that can’t diagnose performance problems.

What to look for in WordPress hosting: NVMe disks (much faster than traditional ones), built-in server caching, a CDN included or easy to integrate, a current PHP version and support that understands web performance. To go deeper, see What is web hosting and how it affects your website’s speed.

Optimizing blindly is wasting time: first you measure where the bottleneck is and only then do you fix it, starting with whatever has the most impact.

If you’d like us to review your site, at Web Support we do the diagnosis and the fixes, and to keep it from degrading again, see The vital importance of web maintenance and WordPress maintenance and What is technical SEO.