⚡
Blog
SEO

Your website takes 4 seconds to load. Here is why (and how to fix it)

18 June 2026·7 min

We audit Spanish SME websites every week. Speed problems always come from the same places. We tell you straight, with the metrics Google actually uses in 2026.

Last week we audited a dental clinic's website in Madrid. PageSpeed Insights gave it a 34 on mobile. The owner was convinced it was the hosting's fault and had been paying more for a "premium" plan for months.

The hosting was not the problem. It was a 4.2MB uncompressed JPEG cover image. A 10-minute fix brought the score up to 78.

This is the kind of thing we find constantly. Speed problems almost always come from the same places.

Speed metrics in an analytics panel

The metrics Google uses in 2026

Before talking about solutions, it is worth understanding what Google measures. Many websites are still optimising for FID (First Input Delay), which Google replaced in 2024 with INP.

LCP (Largest Contentful Paint): how long it takes for the largest element on screen to appear. Target: under 2.5 seconds. Usual culprit: a huge unoptimised hero image.

INP (Interaction to Next Paint): how long the website takes to respond when the user clicks, types or taps something. Target: under 200ms. Usual culprit: too much JavaScript running on the main thread.

CLS (Cumulative Layout Shift): how much elements shift while the page loads. That frustrating moment when you are about to tap a button and it moves just before. Target: under 0.1.

The number one problem: images

70% of the websites we audit have poorly optimised images as the main cause of their high LCP. The fix is straightforward:

  • Convert to WebP or AVIF format (30-50% less weight than JPEG for the same visual quality)
  • Always define `width` and `height` attributes on images (prevents CLS)
  • Use `loading="lazy"` on everything not in the first scroll
  • The hero image should have `loading="eager"` and `fetchpriority="high"`

    • The second problem: JavaScript

    Modern websites load a lot of JavaScript. The problem is that all that JS blocks the main thread and makes the site feel frozen even if it looks fine visually.

  • Split code into smaller chunks (code splitting)
  • Defer third-party scripts (analytics, chat, etc.) with `defer` or `async`
  • If using React, leverage Server Components to avoid sending to the client code that does not need to run there

    • The third problem: the server

    TTFB (Time to First Byte) measures how long the server takes to start responding. If it exceeds 600ms, something is wrong. Most common causes: saturated shared hosting, database queries without indexes, or no caching.

    With Next.js on Vercel, typical TTFB is under 80ms. With WordPress on cheap shared hosting it can exceed 2 seconds before the browser has received a single byte.

    Lighthouse panel with performance scores

    How to measure before fixing

    Do not optimise blind. Measure first with these tools:

  • PageSpeed Insights — real user data from Chrome, free
  • Google Search Console → Page Experience — aggregates data from all your traffic
  • WebPageTest — more detailed analysis, useful when CrUX data is not available

    • At Codelvia we include a Core Web Vitals audit before every launch, with a contractual target of Lighthouse 90+ on mobile. If you want us to review yours, get in touch.

    Have a project in mind?

    Tell us what you want to achieve.

    Let's talk