Why is my website slow? The 6 causes and what fixes each

A website loads slowly when one of six things takes too long: the server's first answer, the main image, the main image being found late, the JavaScript that has to run, the scripts other companies add, or the fonts and a layout that keeps moving. Each one has its own fix, and a fix aimed at the wrong cause changes nothing. Google's line for fast enough is the Largest Contentful Paint (LCP), the moment the main content appears: 2.5 seconds or less for at least 75% of visits, as web.dev defines it.

This piece is for whoever owns the site and is asking why it feels slow: a founder, a marketing lead, an owner who heard it from a customer. It names the six causes, shows how to tell which one is yours in about ten minutes, and what fixes each.

How common is a slow website?

Very common, and mostly on phones. The 2025 Web Almanac by HTTP Archive found that 48% of mobile websites pass all three Core Web Vitals, up from 36% in 2023. The metric that fails most is the load itself: on phones, 62% of sites have a good LCP, 25% need improvement and 13% are poor.

Pages keep getting heavier, too. The median desktop home page reached 2.9 MB in 2025, 7.3% more than a year earlier, according to the Web Almanac page weight chapter. The median mobile home page carries 911 KB of images and 632 KB of JavaScript.

And speed shows up in revenue. In the Milliseconds Make Millions study, run by Deloitte and 55 for Google across 37 European and American brands and more than 30 million sessions, a 0.1-second gain in mobile speed came with a 9.1% rise in retail shoppers moving from a product page to the basket. Retail shoppers also spent 9.2% more.

Why a faster server rarely fixes it alone

The first move most owners make is a bigger hosting plan. It helps one cause out of six. Web.dev splits LCP into four parts: time to first byte, the delay before the main image starts loading, the time it takes to download, and the delay before it is drawn. On a well-tuned page, web.dev suggests about 40% of the time goes to the server's answer and 40% to downloading the main resource, with under 10% each for the two delays. A new server shrinks the first part. If the time goes into a 1.4 MB hero photo or a script that blocks rendering, the new plan costs more and the page stays slow.

So the order is: measure, find the cause, fix that cause.

How do I find out why my site is slow?

Open PageSpeed Insights, paste the address of the page that matters most (the home page, and the landing page your ads point to), and read the report in this order:

1. The top block, the field data. This is what real Chrome visitors experienced over the last 28 days, at the 75th percentile. If it says there is no data, the page has too little traffic and you rely on the lab test underneath.
2. Mobile first. The mobile tab is the one that usually fails.
3. Which metric is red. A red LCP means the load is slow. A red INP (Interaction to Next Paint) means the page is slow to react to taps and clicks. A red CLS (Cumulative Layout Shift) means things jump around while it loads.
4. The LCP breakdown in the diagnostics. It shows how many milliseconds go to each of the four parts above. The biggest part points at your cause.

Ten minutes is enough to know where to look. The six causes below follow the order we check them in.

Cause 1: the server takes too long to answer

Time to first byte (TTFB) is the wait before the browser receives anything at all. Web.dev rates 0.8 seconds or less as good and over 1.8 seconds as poor. The usual reasons: the page is rebuilt from the database on every visit, a shared hosting plan is busy serving other sites, the server sits on another continent from your visitors, or a chain of redirects (http to https, then to www) adds round trips before the page even starts.

What fixes it: serve pages from a cache, or build them ahead of time when the content allows it. Put a CDN in front so the answer comes from a city near the visitor. Remove the redirect hops. Only then look at a bigger server.

Cause 2: the main image is too heavy

On most marketing pages the largest visible element is a hero photo. Uploaded straight from a camera or a design tool, it can weigh several megabytes for a banner shown 1,200 pixels wide. In the breakdown, this is the resource load duration.

What fixes it: export the image at the size it is shown, with a set of sizes for different screens through srcset. Use AVIF or WebP and compress it. Then set a weight budget for the hero and check it every time someone replaces the photo, because that is when it comes back.

Cause 3: the main image starts loading too late

A light image can still arrive late if the browser finds it late. The usual culprit is lazy loading applied to every image, the hero included: the browser waits for the layout before asking for it. The 2025 Web Almanac found that 16% to 17% of pages lazy-load their LCP image. Heroes set as CSS backgrounds or inserted by JavaScript have the same problem, since the browser cannot see them in the HTML.

What fixes it: keep loading="lazy" for images below the fold only. Put the hero in the HTML as a plain img and mark it fetchpriority="high" so the browser fetches it first.

Cause 4: too much JavaScript

An image is downloaded and drawn. JavaScript is downloaded, parsed and run, and while it runs the page cannot respond. The Web Almanac puts it in one line: "100 KB of an image is just pixels, but 100 KB of JavaScript is work." The median mobile page carries 251 KB of uncompressed JavaScript it never uses. Heavy JavaScript shows up as a poor INP, as a long render delay, or both. Page builders, sliders, animation libraries and themes that load every feature on every page are the frequent sources.

What fixes it: remove what the page does not use. Load the rest only on the pages that need it, and defer whatever the first view can do without. Render the content on the server, so the text does not wait for a script to appear. Our list of frontend mistakes that tank Lighthouse scores covers the code side in detail.

Cause 5: scripts from other companies

Analytics, tag managers, chat widgets, heatmaps, A/B testing tools, ad pixels, embedded maps and videos. Each one is code from someone else's server, and you do not control how heavy it is or when it changes. According to the Web Almanac third-parties chapter, at least 90% of pages use one or more third parties. They pile up quietly: every campaign adds a pixel, and nobody removes the one from the campaign before.

What fixes it: list every tag and who asked for it. Remove the ones whose data nobody reads. Load the rest after the page is usable, and swap heavy embeds (a chat widget, a video player) for a light placeholder that loads the real thing on click. A/B testing tools that hide the page until they pick a variant hold back everything, so check whether a test is running at all.

Cause 6: fonts and a layout that keeps moving

The median mobile home page loads 122 KB of fonts, per the Web Almanac. Several weights of a custom typeface, fetched from another domain, can hold the text back or swap it in late. Images without set dimensions, banners inserted at the top and late ads push the content down while people read. That movement is what CLS measures, and a score above 0.25 is poor.

What fixes it: load only the weights the design uses and host them on your own domain. Use font-display: swap with a fallback font sized to match. Give every image, embed and ad slot its dimensions in advance, so the space is reserved before the content arrives.

What this looks like in practice

An illustrative breakdown, not a client's. A home page has an LCP of 4.2 seconds on mobile. PageSpeed Insights splits it into 0.6 seconds of time to first byte, 2.1 seconds of resource load delay, 1.2 seconds of load duration and 0.3 seconds of render delay. The server is fine. The hero is lazy-loaded and weighs 1.4 MB. Loading it eagerly with high priority removes most of the 2.1 seconds; exporting it at the right size in AVIF removes most of the 1.2. Two changes to one image, no new hosting plan, and the page can land under 2.5 seconds.

The same page with a TTFB of 2 seconds calls for the opposite work: caching and a CDN first, the image after. That is why the breakdown comes before any fix.

How to keep a site fast after the fix

Speed is lost a little at a time: a new tag, a new section, a heavier photo. Three habits hold it. Set a weight budget for the key pages and check it before each release. Review the tag manager every quarter with whoever runs marketing. Watch the Core Web Vitals report in Search Console, which reads the same field data as PageSpeed Insights; since that data covers 28 days, a fix shows up there about a month later.

If speed dropped together with your rankings after a redesign, our guide on why a site disappears from Google after a redesign covers the indexing side. For the budget of keeping a site in shape, see what website maintenance costs in 2026. For Next.js sites, Core Web Vitals on Next.js goes through the framework's own tools.

Sources

• web.dev: How the Core Web Vitals metrics thresholds were defined
• web.dev: Optimize Largest Contentful Paint
• web.dev: Time to First Byte (TTFB)
• HTTP Archive Web Almanac 2025: Performance
• HTTP Archive Web Almanac 2025: Page Weight
• HTTP Archive Web Almanac 2025: Third Parties
• web.dev: Milliseconds make millions
• Google Search Central: Understanding page experience