Why is your website slow? In nine cases out of ten, it is one of the same seven issues. We audit roughly 4 sites a month, and the diagnosis is shockingly consistent. Heavy images. Render-blocking scripts. Bloated JavaScript bundles. Cheap hosting. Bad font loading. Missing cache headers. Lazy loading that was never lazy. Each one is a known fix with a predictable hour count, and most sites only need 8 to 24 hours of focused work to move from a Lighthouse mobile score in the 40s to one in the 90s.
This article walks through the seven, in the order we tackle them on every audit, with the symptom, the cause, and the fix.
How fast should a website actually be?
Two numbers. Largest Contentful Paint (LCP) under 2.5 seconds on mobile, on a 4G connection. First Input Delay or Interaction to Next Paint under 200 milliseconds. These are the thresholds Google's Core Web Vitals documentation uses, and they are the bar we set for every doubleSix Studio build. For hand-coded marketing sites, we typically hit LCP under 1 second on mobile and Lighthouse mobile scores between 92 and 95.
Anything slower than that has measurable consequences. According to Google's research, every additional second of load time drops mobile conversions by 20%. A page that loads in 4 seconds converts roughly 50% worse than the same page at 1 second.
Why does slow loading hurt your business?
Three lines on the spreadsheet that move.
Conversion rate. The 100ms tax on every step of the funnel compounds. A 4-step checkout that adds 400ms per step is 1.6 seconds slower end to end, which Amazon and Google have both publicly tied to revenue drops in the 7 to 10% range.
Search ranking. Google has ranked Core Web Vitals as a direct ranking signal since 2021. Two pages with identical content rank differently if one has a green LCP and the other a red one. The gap shows up on competitive head terms, not long-tail.
Bounce rate. The 53% bounce threshold (mobile users leaving when a page exceeds 3 seconds) has not changed in five years. Slow sites lose visitors before the analytics pixel fires, which means the data understates the loss.
What are the seven reasons sites are slow?
In order of how often they show up in our audits.
1. Heavy, unoptimised images
Symptom. Lighthouse flags "Properly size images" or "Serve images in next-gen formats." Total page weight over 1.5 MB.
Cause. The team uploaded a 4000-pixel JPEG straight from a DSLR or stock library, and the CMS served it at 4000 pixels even on a 320-pixel mobile screen. WordPress is the worst offender here, because the default image library does not generate WebP or AVIF.
Fix. Convert hero images to WebP at quality 80 (typically 60 to 80% smaller than JPEG). Use the picture element with srcset to serve the right size per breakpoint. Target under 200 KB per hero image. Use a tool like sharp, ImageMagick, or a service like Cloudinary or Cloudflare Images for the conversion. Time to fix: 2 to 4 hours for a typical site.
2. Render-blocking CSS and JavaScript
Symptom. Lighthouse flags "Eliminate render-blocking resources." First Contentful Paint over 2 seconds.
Cause. The browser pauses rendering until every CSS file in the head is downloaded and parsed. Same for any synchronous script tag without defer or async. Most pagebuilder sites load 4 to 8 separate stylesheets, plus jQuery, plus a theme JS file, plus the page builder's runtime, plus Google Analytics.
Fix. Inline the critical CSS for above-the-fold content (typically under 14 KB), defer the rest. Add defer or async to every script tag that does not need to run before paint. Tools like Critical or Penthouse extract critical CSS automatically. Time to fix: 4 to 6 hours.
3. Bad font loading
Symptom. Flash of invisible text (FOIT) or flash of unstyled text (FOUT) on first load. Cumulative Layout Shift (CLS) over 0.1.
Cause. Loading fonts from Google Fonts CDN adds a third-party DNS lookup and a CSS roundtrip before any text can render. Loading more font files than the page needs (4 weights x 2 styles = 8 files = 320 KB+) blocks the critical path. No font-display set, so the browser holds rendering until the font arrives.
Fix. Self-host fonts as WOFF2. Preload the above-the-fold weights with <link rel="preload" as="font" type="font/woff2" crossorigin>. Set font-display: swap on every @font-face rule. Subset the font to Latin if you do not need the full character set, which usually drops file size by 70%. The MDN guide on font-display covers the trade-offs. Time to fix: 2 to 3 hours.
4. Bloated JavaScript bundles
Symptom. Lighthouse flags "Reduce unused JavaScript" or "Avoid serving legacy JavaScript to modern browsers." Total transfer size of JS over 300 KB.
Cause. The site loads jQuery + 6 plugins + a 200 KB carousel library to show 3 testimonials + analytics + chat widget + 4 tracking pixels, all on every page. Pagebuilders are the worst offenders.
Fix. Audit the bundle with source-map-explorer, Vite's rollup-plugin-visualizer, or webpack-bundle-analyzer. Code-split by route, so the homepage does not ship the dashboard's React tree. Lazy-import heavy components with dynamic imports. Replace jQuery with vanilla JS where possible. Replace the 200 KB carousel with native CSS scroll-snap (free, smaller, faster). Time to fix: 6 to 12 hours.
5. Slow hosting
Symptom. Time to First Byte (TTFB) consistently over 600 milliseconds. Spikes during peak traffic hours.
Cause. Shared hosting oversells CPU and disk. The host's server is responding slowly because 200 other sites are running on the same physical machine.
Fix. Migrate to Cloudflare Pages (free for static), Vercel ($20/month for hobby, $250 for pro teams), Netlify (similar pricing), or managed WordPress on a real host like Kinsta or WP Engine. TTFB typically drops from 800ms to under 200ms after the migration. Set up Cloudflare in front for global edge caching even if you stay on your existing host. Time to fix: 4 to 8 hours, including DNS and SSL.
6. Missing or wrong cache headers
Symptom. Repeat visits are as slow as first visits. PageSpeed Insights flags "Serve static assets with an efficient cache policy."
Cause. The host serves images and CSS with no Cache-Control header, or with a max-age of zero. Every visit, the browser re-downloads everything.
Fix. Set Cache-Control: public, max-age=31536000, immutable on hashed assets (filenames with content hashes, like main.a3f9c.css). Set Cache-Control: no-cache on HTML so visitors always get fresh content. For sites that ship without hashed filenames, set max-age to 86400 (one day) on assets and rely on cache busting. Time to fix: 1 to 2 hours.
7. Below-the-fold images that load eagerly
Symptom. The page appears to load fast but Lighthouse flags "Defer offscreen images." Total network requests over 80 on a marketing site.
Cause. Every image on the page starts downloading the moment the HTML parses, including images 4 viewports below the fold. Images at the top of the page compete for bandwidth with images that may never be seen.
Fix. Add loading="lazy" to every <img> below the first viewport. Same for <iframe> embeds (YouTube, Google Maps). Native browser lazy loading is supported everywhere now, so you do not need a JavaScript library. For above-the-fold hero images, leave loading="eager" and add fetchpriority="high". Time to fix: 1 hour.
How do you measure your site speed today?
Five tools, free, in the order we use them.
- PageSpeed Insights. Google's hosted Lighthouse runner. Gives you a Core Web Vitals score from real Chrome users (CrUX data) and a synthetic Lighthouse score. Start here.
- Lighthouse in Chrome DevTools. Open DevTools, go to the Lighthouse tab, run a mobile audit. Gives the same score with a more detailed breakdown.
- WebPageTest. The pro tool. Filmstrip view, throttled connections, 9-test runs to average noise out, request waterfall. Use for deep audits.
- Chrome DevTools Performance panel. For paint, layout, and main-thread bottlenecks. Use when Lighthouse says something is slow but does not say why.
- Real-user metrics. Cloudflare Analytics, Vercel Speed Insights, or a self-hosted boomerang.js setup. Synthetic tests miss real-world conditions, real users do not.
How much does it cost to fix?
If your site is old, slow and built on a heavy page builder, fixing it piece by piece can cost more than starting fresh. A new fast website from us starts at £299, and we design your new homepage free first so you can compare.
For a hand-coded site that already passes Core Web Vitals but needs the last 10 points, expect 8 to 12 hours of targeted work. For a deeply broken pagebuilder site, the honest answer is often that a rebuild ships faster than a salvage. We discuss that calculation in our pagebuilders article.
Lighthouse scores we hit on every doubleSix Studio build: 99 to 100 on desktop, 92 to 95 on mobile. Sub-second LCP on 4G. CLS under 0.05. These numbers are written into every proposal and verified before sign-off.
What about Core Web Vitals specifically?
The three Core Web Vitals that Google measures for ranking are LCP (Largest Contentful Paint), INP (Interaction to Next Paint, replacing FID in March 2024), and CLS (Cumulative Layout Shift). Each has a green, amber, and red threshold.
- LCP green: under 2.5 seconds on mobile, over the 75th percentile of real users
- INP green: under 200 milliseconds
- CLS green: under 0.1
Each one corresponds roughly to a fix above. LCP is mostly images and hosting (fixes 1 and 5). INP is mostly JavaScript (fix 4). CLS is mostly fonts and images without dimensions (fixes 1 and 3). Hit all three green and Google rewards you with better organic ranking, real users get a better experience, and the conversion math takes care of itself.
The honest closing note
Why is your website slow? Almost always one or more of the seven above. Almost never a mystery that takes weeks to solve. If you have a Lighthouse mobile score under 70 and want it over 90, send us the URL via our contact page and we will tell you which of the seven are biting, what it costs to fix, and how long it will take. Read what we ship at each tier on our services page if you want to see how we bundle this work into the build.