What are the most common reasons a website is slow?

The five most common causes of a slow website are: unoptimised images (the single largest cause — images over 200KB account for 60–80% of page weight on most sites), render-blocking JavaScript (scripts that prevent the page from displaying until they load), no content delivery network (serving assets from a single server location), excessive third-party scripts (chat widgets, analytics, tag managers that each add 50–300ms), and no server-side caching (the server re-generates every page on every request instead of serving a cached version).

What is a good page speed score and how do I check mine?

A good Lighthouse performance score for a business website is 80+ on mobile, 90+ on desktop. Check your score at pagespeed.web.dev — enter your URL and run both mobile and desktop tests. The report shows exactly which factors are costing points and estimates the potential improvement from fixing each one. Core Web Vitals (LCP, CLS, INP) are the most important sub-metrics since Google uses these as ranking signals.

How do I fix slow images on my website without a developer?

To fix slow images without developer involvement: (1) run your images through squoosh.app or tinypng.com before uploading (target under 100KB for most images, under 200KB for full-width hero images), (2) use WebP format instead of JPEG/PNG where your CMS allows it (30–50% smaller for the same visual quality), (3) add `loading="lazy"` attribute to all images that are not visible on initial page load. These three steps alone can reduce page weight by 40–60% on image-heavy sites.

What is the fastest way to improve Core Web Vitals?

The fastest Core Web Vitals improvements come from targeting the metrics with the worst scores first. For LCP (Largest Contentful Paint) — which measures when the main content appears — the highest-impact fix is preloading your hero image with ` ` and ensuring the server responds in under 600ms. For CLS (Cumulative Layout Shift) — which measures visual stability — set explicit width and height attributes on all images and embeds. These two fixes often move LCP from "poor" to "needs improvement" within a week.

When should I rebuild my website vs. optimise it for performance?

Rebuild your website if: it is running on technology that cannot be optimised (old PHP without caching, no asset pipeline, no CDN support), or if a performance audit shows that the architectural issues are fundamental rather than fixable. Optimise first if: your Lighthouse score is below 70 but your site is built on modern technology. Most WordPress and Shopify sites, Next.js sites, and Webflow sites can reach 85+ on mobile with proper image optimisation, caching, and third-party script management — without a rebuild.

Why Your Website Is Slow and How to Fix It Without a Full Rebuild | Codalyst Tech Blog

The advice businesses usually receive when their website is slow is to rebuild it. This is almost always wrong. Most slow websites have two or three fixable problems — not a fundamental architecture problem. Identifying those problems takes 20 minutes with the right tools. Fixing them typically takes days, not months.

Here is how to diagnose the real bottlenecks and fix them without spending $20,000 on a rebuild that will be slow again in two years if the underlying causes are not addressed.

The diagnosis: what your Lighthouse score is actually telling you

Start at pagespeed.web.dev. Enter your URL, run the mobile test, and read the results.

The report shows a performance score from 0–100 and breaks it into four Core Web Vitals:

LCP (Largest Contentful Paint): How long until the main content appears. Under 2.5 seconds is good. Above 4 seconds is poor.
INP (Interaction to Next Paint): How responsive the page is to user interaction. Under 200ms is good.
CLS (Cumulative Layout Shift): How much the page layout shifts while loading. Under 0.1 is good.
FCP (First Contentful Paint): How long until the first element appears. Under 1.8 seconds is good.

These four metrics are not equally important. LCP has the highest weighting and is the most commonly problematic. Fix LCP first.

The five causes of slow websites and how to fix each

1. Unoptimised images (affects 80% of slow websites)

Images are the most common cause of slow page load times. A single hero image served at 2MB where 200KB would suffice adds 3–5 seconds on a mobile connection.

Fix: Convert images to WebP format and compress them before uploading. Use squoosh.app (free, browser-based) or ImageOptim (Mac desktop app). Target:

Full-width hero images: under 200KB
Content images: under 100KB
Thumbnails and icons: under 30KB

For WordPress sites, install the WebP Express plugin to automatically convert and serve WebP versions of all images. For Next.js, the built-in Image component handles this automatically.

Add loading="lazy" to all images that are not visible on initial page load. This defers loading until the user scrolls to them, reducing initial page weight.

Expected improvement: LCP reduction of 1–3 seconds on image-heavy pages.

2. Render-blocking JavaScript and CSS (affects 60% of slow websites)

When a browser encounters a <script> or <link> tag in the HTML head, it stops rendering the page until that resource finishes loading. This is "render blocking."

Symptoms in Lighthouse: "Eliminate render-blocking resources" warning with specific files listed.

Fix: Add defer or async attributes to <script> tags for non-critical JavaScript. Move non-critical CSS to load asynchronously. In WordPress, plugins like Autoptimize handle this automatically. In custom-built sites, this requires developer intervention.

For third-party scripts (chat widgets, analytics, marketing tags), load them after the main page content using a tag manager configured to fire on DOMContentLoaded rather than on page load.

Expected improvement: FCP and LCP reduction of 0.5–2 seconds.

3. No content delivery network (affects all sites serving global traffic)

A CDN (Content Delivery Network) serves your static assets (images, JavaScript, CSS) from servers geographically close to each visitor. Without a CDN, every visitor fetches assets from your single server location, regardless of where they are.

Fix: If your site is on WordPress, install Cloudflare's free plan. It routes your site through their global network and caches static assets automatically. For Next.js, deploying on Vercel automatically includes CDN delivery. For other platforms, Cloudflare's free plan is the simplest option.

Expected improvement: 0.3–1.5 seconds reduction for users far from your server location.

4. Excessive third-party scripts

Each third-party script on your page makes an additional network request, often from a slow server. A typical page with Google Analytics, a chat widget, a marketing pixel, and a cookie consent tool is making 8–15 additional network requests before the page is interactive.

Diagnosis: In Chrome DevTools, go to Network tab, reload the page, and sort by domain. Count the number of third-party domains loading resources. More than five is a problem.

Fix: Remove any third-party scripts that are not actively used and providing measurable business value. Consider replacing multiple analytics and marketing tools with a single tool (many businesses use both Google Analytics and a second analytics platform without needing both). For scripts that must remain, load them asynchronously.

Expected improvement: INP improvement and 0.5–1.5 seconds on overall load time, depending on how many scripts are removed.

5. No server-side caching (affects WordPress and PHP sites most commonly)

Dynamic sites that generate HTML on every request — WordPress, most PHP sites, some Django and Rails sites — are slow under any load if server-side caching is not configured. Without caching, a WordPress page takes 300–800ms to generate for each visitor; with caching, the same page is served in 20–50ms from a static file.

Fix: On WordPress, install WP Rocket or W3 Total Cache. On servers you control, configure nginx or Apache to cache responses for pages that are not user-specific. On managed hosting (Kinsta, WP Engine), server-side caching is often enabled by default — check your hosting panel.

Expected improvement: 200–600ms server response time reduction, which directly improves LCP.

When optimisation is not enough: the genuine rebuild cases

These are the cases where optimisation is not the right path:

The site is running PHP 7.x or lower on shared hosting with no caching capability. Migration to modern hosting is faster and cheaper than optimisation.
The mobile experience is fundamentally broken — not just slow, but non-functional on common viewport sizes. This is a design problem, not a performance problem.
The technology stack is end-of-life (Magento 1, old CodeIgniter, unmaintained custom frameworks) and cannot receive security patches. This is a security issue that happens to also manifest as a performance problem.

In these cases, a rebuild is warranted. In all other cases, optimise first.

The one-day quick win list

If you have developer access and one day to spend:

Run the Lighthouse report and screenshot the results
Compress and convert all images on the three highest-traffic pages to WebP
Add loading="lazy" to all images below the fold on those pages
Install Cloudflare free plan if not already done
Remove any third-party scripts that are unused or that you cannot attribute to a specific business outcome
Install and configure a caching plugin (WordPress) or enable caching at the server level
Re-run the Lighthouse report and compare

Most sites that follow this list go from a score in the 40–60 range to 70–85 in a single day. From 70–85 to 90+ requires developer involvement, but 70–85 is good enough to stop hurting your SEO and conversions.

Back to all articles

Why Your Website Is Slow and How to Fix It Without a Full Rebuild