Skip to content
Codivine
Websites

Why Website Performance Matters (Beyond the Score)

What page speed actually costs you in conversion, crawl efficiency and trust — and the handful of fixes that produce most of the improvement.

Oskar Szymczak3 min read

Performance work gets sold on a number: get your Lighthouse score above 90. That’s a poor goal, because the score is a proxy and you can game it. The real reasons to care are more concrete.

What slowness actually costs

Conversion. This is the big one and it’s well documented across e-commerce and lead generation alike: as pages get slower, fewer people complete what they came to do. The effect is steepest in the first few seconds. Going from four seconds to two matters far more than going from two to 1.5.

Mobile visitors specifically. Your site is probably tested on a fast laptop on office wi-fi. A meaningful share of your visitors are on a three-year-old Android phone on a patchy connection. That’s where the drop-off lives, and it’s invisible from your desk.

Crawl efficiency. For large sites, slow responses mean fewer pages crawled per visit. If you have thousands of URLs and a slow server, deep pages get visited rarely, and updates take longer to be reflected.

Trust. People form judgements about competence from the first interaction. A site that stutters, shifts and blocks feels like a business that will be slow to reply.

The three metrics that matter

LCP — Largest Contentful Paint. How long until the main thing appears. Usually a hero image, a heading, or a product photo. Target under 2.5 seconds.

INP — Interaction to Next Paint. How long the page takes to respond when someone taps or clicks. This is the one JavaScript-heavy sites fail. Target under 200 milliseconds.

CLS — Cumulative Layout Shift. How much the page jumps around while loading. Usually caused by images without dimensions, fonts swapping, or injected banners. Target under 0.1.

Measure them with field data — real visitors — not just lab tools. Lab tests run on a simulated device from one location; field data tells you what your actual audience experiences.

Where the improvement usually comes from

In our experience, four things account for most of the win on a typical business site:

1. Images. Almost always the largest payload. Serve modern formats, size them for the container rather than shipping a 3000px original into a 600px slot, lazy-load anything below the fold, and set explicit dimensions to prevent shift.

2. JavaScript you don’t need. Analytics, chat widgets, tag managers, A/B testing tools, three fonts, a cookie consent platform, and a carousel library. Each one seemed reasonable. Together they’re often more code than the site itself. Audit what’s loading and ask what each one is worth.

3. Fonts. Self-host, subset to the characters you use, preload the one that renders your headline, and use font-display: swap so text is readable while it loads.

4. Rendering strategy. Static generation or server rendering with sensible caching beats a client-side app that fetches everything after load — for content sites, which is most business sites.

What isn’t worth your time

  • Squeezing the last few points out of a Lighthouse score by deferring things users need immediately.
  • Micro-optimising code paths on a site whose real problem is a 4MB hero image.
  • Removing a genuinely useful feature to save 20 milliseconds.

Performance is a means to an end. If a change makes the site faster and worse, it’s not an improvement.

A pragmatic order of work

  1. Measure with field data and identify the slowest template, not the slowest page.
  2. Fix images on that template.
  3. Remove or defer third-party scripts nobody can justify.
  4. Sort out fonts.
  5. Re-measure. Most sites are now in acceptable territory.
  6. Only then go looking for the harder wins.

If your site is slow and you’d rather someone else worked out why, that’s a normal part of an SEO audit — and unlike an analysis-only engagement, we can implement the fixes as well.

Oskar Szymczak

Founder & Software Engineer

Leads the technical side of every project — architecture, development and the decisions that are expensive to change later.

More about the team

Want help with this?

This is the kind of work we do. These pages explain how.

Got a version of this problem?

Describe it in your own words. We'll tell you what we'd do about it — and whether it's worth doing at all.

No specification needed. A description of the problem is enough to start.