Why Your Website Loads in 4 Seconds (And What That's Actually Costing You)

Most business owners don't think about their website until something breaks. A form stops submitting. A link goes dead. The homepage looks wrong on mobile. But there's a problem that never triggers an alert, never shows up as a bug report, and quietly costs you customers every single day: your site is slow.

Not broken. Just slow. And that distinction is why most teams never fix it.

The Number No One Tells You About

Google's own research has been consistent for years: as page load time goes from one second to three seconds, the probability of a bounce increases by 32%. Push it to five seconds and that number climbs to 90%.

Your visitor didn't leave because your product was wrong for them. They left because they never got the chance to see it.

This isn't a conversion optimization problem. It's a first-impression problem. And in 2026, a slow website doesn't just lose you visitors — it signals something to everyone who does stick around: this company doesn't sweat the details.

What's Actually Slowing You Down

We audit a lot of sites before we rebuild them. The same culprits show up, almost every time:

Unoptimized images. A hero image exported at full resolution from Figma, dropped into a WordPress media library, served as a 4MB PNG on mobile. It's more common than it should be in 2026. Modern formats like WebP and AVIF, combined with proper srcset attributes and lazy loading, can cut image payload by 60–80% without any visible quality loss.

Render-blocking JavaScript. Every script tag that loads before your content renders is a toll booth between your server and your visitor's screen. Most template-built sites accumulate these over time — a cookie banner plugin here, a chat widget there — until the browser is processing 40 third-party scripts before showing a single word of your homepage.

No caching strategy. If every visitor triggers a full server round-trip for static content that hasn't changed in weeks, you're burning time and money simultaneously. CDN configuration, cache-control headers, and edge delivery aren't advanced topics — they're table stakes.

Oversized JavaScript bundles. This one is particularly common in React-heavy sites that weren't built with performance in mind from the start. Shipping 800KB of JavaScript to render a marketing page is a choice — a bad one. Server Components in Next.js exist precisely to solve this. If your dev team isn't using them, ask why.

Why 100 Lighthouse Score Matters (and Doesn't)

We aim for 100 across all Lighthouse categories on every site we ship. It's a useful proxy — it forces you to care about the right things. But it's not a trophy. It's a floor.

A perfect Lighthouse score on a staging URL doesn't mean your production site performs. Real-world Core Web Vitals are measured by actual Chrome users, in actual conditions, on actual networks. The field data in Google Search Console is what Google uses for ranking decisions. The lab score is just where you verify your work.

What matters in practice:

• LCP under 1.2s. Largest Contentful Paint is typically your hero image or headline. If a visitor waits more than 2.5s to see the main content, Google classifies your page as "poor." We target 1.2s as our internal ceiling.
• CLS as close to zero as possible. Cumulative Layout Shift is the jank — elements jumping around as the page loads. It's annoying for users and penalized by search engines.
• INP under 200ms. Interaction to Next Paint replaced FID in 2024. It measures how quickly your page responds to user input. A sluggish interactive element — a menu that stutters, a form that hesitates — contributes to a poor INP score.

These aren't abstract engineering metrics. They're the technical expression of whether your site feels fast to the people using it.

The Business Case, Made Simply

Here's a way to think about what site speed is worth to you.

If your site gets 5,000 monthly visitors and converts at 2%, that's 100 leads per month. If a 3-second load time is causing a 32% bounce increase versus a 1-second load time, you're losing meaningful traffic before it ever engages. Close that gap and you're not running more ads, hiring more salespeople, or changing your offer — you're just letting the work you've already done actually land.

Speed is leverage. It compounds. A faster site ranks better organically (Google has been explicit about Core Web Vitals as a ranking signal since 2021). Better rankings mean more traffic. More traffic means more opportunities to convert. All of that from fixing problems that were invisible to you.

The Template Problem

Here's the uncomfortable truth: most slow websites aren't slow because of neglect. They're slow because of the architecture they were built on.

A Webflow template, a WordPress theme, a Wix site — these tools make it easy to launch. They also make it very hard to not carry dead weight. You inherit someone else's JavaScript, someone else's CSS, someone else's assumptions about what a website needs to do.

When we build in Next.js from a blank canvas, we ship exactly what the site needs and nothing else. No unused CSS from a theme that supports 400 layout combinations you'll never use. No JavaScript for features you didn't ask for. No plugin bloat that accumulates every time someone needs to add a feature.

The performance isn't something we bolt on at the end. It's the consequence of building deliberately from the start.

What To Do Right Now

You don't need to rebuild your site today. But you should know where you stand.

Run your site through PageSpeed Insights (pagespeed.web.dev). Look at the Field Data section, not just the lab score. If your LCP is above 2.5s or your CLS is above 0.1, you have a measurable problem.

Check your Search Console. Under Experience → Core Web Vitals, Google tells you exactly which URLs are failing and why. This is the data that affects your rankings.

Audit your third-party scripts. Open DevTools → Network, filter by JS, and look at what's loading. If you can't explain why a script is there, it probably shouldn't be.

If what you find is worse than you expected, that's actually useful information. Most sites we inherit have never been audited this way.

A Closing Thought

A website that loads instantly, looks intentional, and works on every device isn't a luxury tier deliverable. It's the minimum bar for a company that takes itself seriously.

The gap between "we have a website" and "we have a website that works for us" is almost always technical. It's images, it's JavaScript, it's architecture decisions made (or not made) before the first line of code was written.

If you're not sure which side of that gap you're on, now's a good time to find out.

D&A designs and builds websites in Figma and Next.js for companies that refuse to settle for a template. Based in Lugano, working across Europe and North America. Start a project →