A hands-on field report from our engineering team: the eleven reasons business websites are actually slow in 2026, ranked by how often we see them, with the specific fix we apply for each one.

A slow website is never just "a slow website." It is a stack of small, boring decisions that compounded over two or three years until the homepage takes nine seconds to load on a mid-range phone and nobody on the team wants to be the person who has to fix it.

This post is the field report. Over the past few years we have been called in to audit and rescue websites — marketing sites, ecommerce stores, booking platforms, internal admin panels — and the same eleven causes keep showing up. We have ranked them roughly by how often they are the real culprit and how much performance each fix typically returns.

If you are sitting on a slow site in 2026, start at the top of this list. You will almost certainly find your problem before you get to the bottom.

1. Unoptimised hero and product images

What we see: a 4 MB PNG rendered at 400 pixels wide. A hero banner shipped straight out of Figma at 3840 pixels on a page that is never wider than 1280. Product galleries serving 12 full-resolution photos per page with no lazy loading.

Why it is slow: images are usually 60–80% of a page's weight. On mobile connections they are the single biggest reason "time to visually ready" feels painful.

The fix:

• Serve images in WebP or AVIF, with a PNG/JPEG fallback only if you still support very old browsers.
• Use srcset and sizes attributes so the browser downloads the correct size for the viewport.
• Resize at build time or via an image CDN — not in CSS.
• Add loading="lazy" to every image that is not above the fold, and fetchpriority="high" to the LCP image.
• Put a hard rule in your CMS: nothing over 300 KB gets published. Enforce it.

Done properly, this one fix alone regularly cuts page weight by 70% and shaves 2–4 seconds off mobile load times.

2. Render-blocking JavaScript from third-party tags

What we see: the homepage loads five analytics scripts, two A/B testing tools, a chat widget, a consent manager, a heatmap tracker, and a legacy tag nobody remembers adding. Each one blocks rendering until it replies.

Why it is slow: every synchronous script tag in the document head is a tollbooth on the road to first paint. Third-party tags are especially painful because you do not control their servers or their response times.

The fix:

• Audit your tags. Open the site, run a real waterfall in DevTools, and list every third-party domain it calls. Delete anything not actively in use.
• Load whatever is left with async or defer, or better, through a server-side tag manager so the browser only loads them when they are actually needed.
• Move the consent manager and chat widget to load after the main content, not before.
• If a vendor's script blocks rendering and they refuse to fix it, that vendor is costing you money. Replace them.

3. Unused CSS and JavaScript from the theme

What we see: a 600 KB CSS file from a theme or page builder, of which the homepage uses about 40 KB. A bundled JS file containing the code for every component on every page of the site.

Why it is slow: the browser has to download, parse, and execute the whole thing before it can paint. On a low-end Android device this can add several seconds of main-thread blocking.

The fix:

• Use a bundler (Vite, Webpack, esbuild) that supports tree-shaking and code splitting.
• Inline the critical CSS for the top of the page, and defer the rest.
• Ship per-route bundles so the blog does not load the checkout code, and vice versa.
• If you are on a template or page builder, check if it has a "purge unused CSS" mode. Most do. Turn it on.

4. No caching at all, or caching configured wrong

What we see: every visitor hits PHP. Every PHP request hits the database. Static assets serve with Cache-Control: no-cache because someone was debugging once and never put the header back.

Why it is slow: the server re-does the same work for every visitor. The CDN cannot help because the origin is telling it not to cache.

The fix:

• Set sensible Cache-Control headers on static assets: public, max-age=31536000, immutable for hashed filenames, and shorter windows for images that change.
• Cache rendered HTML for logged-out visitors. Most marketing pages do not need to be regenerated per request.
• Put a real CDN in front of the site (Cloudflare, Bunny, Fastly) and configure it to cache at the edge.
• For dynamic content, consider an object cache (Redis, Memcached) for expensive queries.

5. Database N+1 queries on the homepage

What we see: the homepage shows 8 featured products. Behind the scenes it is running 1 query for the product list, then 1 query per product for the price, 1 per product for the stock, 1 per product for the primary image — 33 queries where 2 or 3 would do.

Why it is slow: each query is a round trip. On a remote database, 30 round trips can easily be 300 ms of pure network latency before any logic runs.

The fix:

• Turn on query logging in development and count the queries on each page. If the number scales with the number of rows you display, you have an N+1.
• Use eager loading (with() in Laravel, select_related or prefetch_related in Django, include in Prisma).
• Add the right indexes. A missing index on a foreign key is a very common cause of a "slow" page that is actually fine code on a broken schema.
• Cache the rendered block, not only the query.

6. Bloated fonts and icon libraries

What we see: the site loads six font weights from Google Fonts when it uses two. It pulls in a full Font Awesome icon library (60,000+ icons) to display a phone, an envelope, and an arrow.

Why it is slow: fonts are render-blocking by default. Every extra weight is an additional download, and the entire icon library has to arrive before the first icon paints.

The fix:

• Self-host fonts, serve them in WOFF2, and preload the ones used above the fold.
• Subset fonts to the characters you actually use — for Latin-only sites this typically cuts 70% of the file size.
• Replace icon libraries with inline SVG for the 10 to 20 icons you actually need.
• Add font-display: swap so text renders immediately with a fallback while the web font loads.

7. Hosting that is too small, too far away, or both

What we see: a site with UK customers hosted on a shared server in a US data centre. A PHP app on a four-dollar-a-month plan handling 20,000 monthly visitors. A VPS with 1 GB of RAM running MySQL, PHP-FPM, and a headless CMS at the same time.

Why it is slow: network latency is physics. A round trip across the Atlantic is around 80 ms before anything else happens. And if the server is swapping to disk because it is out of memory, every request is catastrophically slow.

The fix:

• Host in the same region as the majority of your users. If you serve multiple regions, use a CDN with edge compute for at least the cached HTML.
• Size the server for peak traffic, not average. Watch memory pressure, not just CPU.
• For WordPress, PHP, Laravel, or Rails sites, make sure OPcache or opcode caching is actually enabled in production. It is not always the default.

8. Too many redirects, especially chained

What we see: http → https → www → trailing-slash — three redirects before the real page loads.

Why it is slow: each redirect is a full round trip. On a slow mobile connection that can be 1 to 2 seconds of waiting, with nothing on screen.

The fix:

• Pick a canonical host (www or non-www, with HTTPS) and redirect everything to it in a single hop at the edge.
• Keep a redirect map for legacy URLs, but flatten chains. Every old URL should 301 directly to its final destination.
• Run a crawl (Screaming Frog, Sitebulb, or your CDN's analytics) at least once a year to catch chains that have crept in.

9. Overweight single-page apps for mostly-static content

What we see: a marketing site built as a full client-rendered React app, shipping 700 KB of JavaScript, taking four seconds to render on mobile, for pages that have two buttons and a contact form.

Why it is slow: the browser downloads the app shell, parses and executes the JS, then fetches data, then renders. Search engines see a spinner. Users on flaky mobile networks see a blank screen for seconds.

The fix:

• For mostly-static content (marketing, blog, docs), use static-site generation or server rendering. Next.js, Astro, Nuxt, Remix, Laravel with Blade — all fine choices.
• Send HTML first. Hydrate only the parts that need interactivity — so-called "islands" architecture.
• Keep SPAs for the parts of the product that genuinely are an app: dashboards, editors, multi-step flows.

10. A broken or missing Core Web Vitals budget

What we see: nobody on the team knows what the Largest Contentful Paint of the homepage is, or what the Cumulative Layout Shift budget should be. New features get shipped without measuring. Performance slowly drifts downward until it becomes a noticeable problem.

Why it is slow: without a budget, every new widget, tracker, or hero animation adds a little more weight. A year of "just a little" adds up to a complete rewrite.

The fix:

• Set explicit budgets: LCP under 2.5 seconds on mobile, INP under 200 ms, CLS under 0.1, total page weight under 1.5 MB.
• Run Lighthouse or WebPageTest in CI on every pull request. Fail the build if the budget is busted.
• Wire Real User Monitoring so you see actual user experience, not only synthetic lab numbers. The two often disagree, and the users are always right.

11. Legacy code that nobody dares touch

What we see: a piece of the site that "has always been slow." A report page that takes 12 seconds. An admin search that loads the entire table into memory. Everyone has learned to work around it because the last person who tried to fix it broke something else.

Why it is slow: often it is a naive algorithm (quadratic where linear would do), a query with no index, a script that reads an entire file when it could stream it, or a report that recalculates from raw events every time instead of caching totals.

The fix:

• Treat the slow piece as a first-class feature, not a chore. Give it an owner, write tests around the current behaviour, then refactor under the tests.
• 80% of the time the fix is a single index, a single cache, or a single query rewrite. It is rarely a full rewrite.
• Do not start with the rewrite. Start with the measurement.

The honest summary

Websites do not become slow because of one dramatic mistake. They become slow because nobody has been measuring, nobody owns the budget, and every week a new image, script, or plugin gets added without a question being asked.

If you want to get your website genuinely fast in 2026, the order of operations is simple:

• Measure with real tools (Lighthouse, WebPageTest, RUM). Find out where you actually stand.
• Fix the heavy hitters first — images, third-party scripts, database queries. These typically deliver 80% of the win.
• Set a budget and defend it. Anything that adds weight has to justify its existence.
• Automate the check so the next regression is caught in CI, not in production.

Most of the sites we rescue do not need a rewrite. They need a careful pass through this list, a little engineering discipline, and someone who genuinely cares about how the site feels on a mid-range Android phone on a slow connection in a car park.

If you are staring at a site and do not know where to start, start with the images. You will be surprised how far that alone will get you.

Want a hand auditing your site's performance against this list? That is exactly the kind of work our engineering team does day to day — get in touch through the contact page and we will give you an honest assessment.

Original Source: Why your business website is slow in 2026: the 11 real causes we see (and how to fix each one)