Why Is Your Website Slow? Common Causes and How to Fix Them

Most slow websites are slow for one of six reasons: the server takes too long to respond, images are far larger than they need to be, too much JavaScript runs before the page becomes usable, third-party scripts compete for the browser’s attention, nothing is cached, or the database behind the page is doing too much work. The trick is to measure which one applies to you before changing anything, because the fix for each is different.

Step one: measure what real visitors experience

Google’s Core Web Vitals are the most useful shared language for speed. They measure three things users feel:

Each is assessed at the 75th percentile of real page loads, so three out of four visits must meet the target. Run your page through PageSpeed Insights and look first at the field data at the top, which comes from real Chrome users. The lab score underneath is a single simulated load; web.dev explains why lab and field data differ. Use the lab report for diagnosis, not as the goal.

If your site has too little traffic for field data, test on a mid-range phone over a throttled connection and record a performance trace in Chrome DevTools. Your own fast laptop on office Wi-Fi is the least representative test you can run.

The common causes, and how to recognise each

1. The server responds slowly

If the browser waits a long time before receiving the first byte of HTML, everything else is delayed with it. Typical reasons are underpowered or overcrowded shared hosting, pages built from scratch on every request, server-side code waiting on slow APIs, and servers far from your visitors. A long Time to First Byte in the DevTools network panel is the giveaway. Fixes include caching rendered pages, serving static pages from a CDN, and moving slow work out of the request.

2. Images are too large

One of the most common causes. A photo 4,000 pixels wide displayed at 800 pixels has 25 times the pixels the page needs, and the visitor downloads all of them. Serve images at the size they are displayed, in modern formats such as WebP or AVIF, with responsive srcset so phones get smaller files. Give the main hero image priority and lazy-load images further down the page. The LCP guide on web.dev covers how to find which element is your largest contentful paint.

3. Too much JavaScript

JavaScript must be downloaded, parsed and executed, and while it runs the page cannot respond to the user. This shows up as poor INP: buttons that lag, menus that open late. Common culprits are large frameworks used for mostly static pages, unused libraries, and code that runs on load but is only needed on interaction. Remove what you do not use, split bundles so each page loads only its own code, and break long tasks into smaller ones. web.dev’s INP guide walks through diagnosing slow interactions.

4. Third-party scripts

Chat widgets, analytics, tag managers, A/B testing tools, embedded videos and review widgets all add JavaScript you do not control. Individually they seem small; together they can dominate the page. List every third-party script, ask whether each still earns its place, and load the survivors after the page is interactive or only when the user needs them, for example loading a video player when someone clicks play.

5. Nothing is cached

Without caching headers, returning visitors download the same CSS, JavaScript and images again on every page. Static assets with fingerprinted file names can be cached for a year; HTML usually needs a shorter or revalidating policy. MDN’s HTTP caching guide explains the directives. A CDN in front of your site adds edge caching close to your visitors.

6. Database queries behind the page

For web apps and dynamic sites, a slow page is often a slow query. Missing indexes, loading entire tables to show ten rows, and the “N+1” pattern (one query for a list, then one more per item) are the usual suspects. Server logs and database query statistics will show which requests and queries take longest. These fixes live in the code and schema, not the frontend.

Bonus: layout shift

If content jumps while loading, CLS suffers and users click the wrong thing. Set width and height on images and embeds, reserve space for ads and banners, and avoid inserting content above what the user is reading. The CLS optimisation guide covers web fonts too.

A practical debugging order

1. Check field data in PageSpeed Insights to see which metric fails and on which devices.
2. Run a lab test on the failing page and identify the LCP element and the longest tasks.
3. In the network panel, check Time to First Byte. If it is long, start with the server and caching.
4. If TTFB is fine, look at what loads before the LCP element: images, fonts, CSS and scripts.
5. For poor INP, record a performance trace while clicking around and look for long JavaScript tasks.
6. Fix one thing at a time and re-measure, so you know what helped.

Platform-specific notes

On WordPress, heavy page builders and plugins that load scripts on every page are frequent causes; caching plugins help, but removing unnecessary plugins helps more. Hosted builders such as Framer handle hosting and CDN for you, so the levers are mostly image weight, embeds and custom code. For a comparison of the two, see Framer vs WordPress for a business website. On web apps built with React or similar, server-side rendering or static generation for public pages often makes the biggest difference.

Will fixing speed improve my rankings?

Possibly, but keep expectations realistic. Google’s Search Central documentation says Core Web Vitals are used by its ranking systems, but that good scores do not guarantee top rankings and page experience does not override relevant content. The more dependable return is commercial: pages that load and respond quickly keep more of the visitors you have already paid to attract. If your landing page is fast but still not converting, our landing page conversion checklist is the next read.

Sources and further reading

• web.dev: Web Vitals
• web.dev: Why lab and field data can be different
• web.dev: Largest Contentful Paint (LCP)
• web.dev: Interaction to Next Paint (INP)
• web.dev: Optimize Cumulative Layout Shift
• Google Search Central: Understanding Core Web Vitals and Google search results
• Google for Developers: About PageSpeed Insights
• MDN: HTTP caching