Web performance
When a user clicks your link in Google, you have around 2-3 seconds before most of them start hitting back. That's not an opinion — it's how browsers, mobile devices and patience work in 2026. A slow website costs you two things at the same time: the users who never see it, and the search ranking that would have brought them there.
This is a short, useful guide to why page speed actually affects Google ranking, what typically makes pages slow, and how you can measure it yourself before you spend a single dollar fixing it.
TL;DR
The most important takeaways
- Google uses Core Web Vitals (LCP, INP, CLS) as direct ranking signals — not as a bonus, but as part of the page experience evaluation.
- Speed affects bounce rate, conversion and crawl budget. It's the same investment moving three important levers at once.
- Mobile is the yardstick. Google evaluates Core Web Vitals from real visits on mobile devices over regular 4G — not from your MacBook on fibre.
- The usual culprits are predictable: heavy images, unused JavaScript, blocking third-party scripts, and pages rebuilt on every visit.
- You can test it yourself in under a minute with PageSpeed Insights. Measure before you optimise — otherwise you'll end up guessing at the wrong thing.
Why speed actually ranks you on Google
Google has said it openly since 2021: Core Web Vitals are part of their page experience ranking signals. They're three concrete numbers, all measured from real users' visits to your site (what they call field data from the Chrome User Experience Report). Largest Contentful Paint (LCP) measures how fast the largest visible element renders — in practice: how fast the user feels the page is there. Interaction to Next Paint (INP) measures how responsive the page is when they touch it. Cumulative Layout Shift (CLS) measures whether content jumps around during load — that irritating phenomenon where a button moves right before you click it.
Google doesn't rank on speed alone — relevance, links and content are still the heavy factors. But when two pages answer the same query equally well, Google picks the one that gives the user the better experience. And speed is the most measurable part of that experience. It's also the part Google can most easily measure objectively across billions of visits.
Equally important: speed affects how much of your site Google even crawls. The crawl budget — how many pages Googlebot visits in a given period — gets smaller when the server is slow. A small marketing site barely notices, but an e-commerce site with thousands of products or a knowledge base with many articles can genuinely end up with fewer pages indexed if the site is sluggish.
Speed is also conversion — not just ranking
Even if Google didn't rank on speed at all, it would still be the fastest path to better numbers in your analytics. Every extra second of load time costs users — that's consistent across all major studies, and it hits mobile hardest, because most mobile visits happen without time and without patience.
It's not just about bounce rate. On a website where users have to fill out a form, download a whitepaper, or click further into a purchase flow, slow transitions reduce the number of people who get through at all. A slow page is a leak running through the entire funnel — and it's completely visible to the users who experience it.
This is the unrecognised advantage of investing in speed: you optimise SEO and conversion with the same work. It's rare for a technical investment to hit two KPIs at once that cleanly.
A fast vs. a slow website — in practice
Fast website
LCP under 2.5s, INP under 200ms, CLS under 0.1 on mobile.
- Page becomes usable before the user notices it loaded
- Page experience signal nudges ranking in a positive direction
- Crawl budget gets spent on content, not on waiting
- Conversion is higher because flow isn't broken by waiting
- Mobile visits convert in line with desktop
- Less infrastructure carrying the same number of visits
Slow website
LCP over 4s, noticeable lag on interaction, layout shifts.
- User stares at a blank screen or half-loaded content too long
- Google deprioritises page experience in competitive searches
- Fewer pages indexed when the site is large
- Conversion drops with every second of load time
- Mobile traffic bounces noticeably harder than desktop
- Ad spend funnels traffic into a leaky funnel
What typically makes a website slow
In 9 out of 10 cases, it's the same culprits. Many of them can be solved without changing platform.
- 01
Images that weigh too much
By far the most common cause. A 2 MB hero image at full resolution, served as JPG or PNG instead of AVIF/WebP, without width/height attributes and without lazy-loading images below the fold. Just serving images in modern formats and the right size often halves LCP.
- 02
JavaScript you don't need
WordPress themes, page builders and analytics snippets that load jQuery, animation libs and seven third-party scripts before the content can render. Every KB of JavaScript is a small tax on the CPU — and the mobile CPU is the slowest link in the whole chain.
- 03
Third-party scripts that block rendering
Chat widgets, A/B testing tools, cookie banners and marketing pixels fetched synchronously. Even a fast website becomes slow if it waits on a sluggish third-party server in Boston before it's allowed to show text in Aarhus.
- 04
Pages built from scratch on every visit
Classic WordPress or a Node app without caching has to build HTML on the server for every single request. That means waiting on database, plugins and rendering. Static HTML on a CDN serves in under 50ms — from Denmark and from Australia.
- 05
Hosting that sits far from the users
A server in Germany isn't far from Denmark — but it's far enough. A CDN (Content Delivery Network) like Cloudflare places the content close to the user and removes seconds of waiting on the first request. For a global site it's not a luxury, it's table stakes.
Quick wins that typically move Core Web Vitals
Not an exhaustive list — but the moves we reach for first, because they typically have the best effort-to-impact ratio.
- Convert all hero and above-the-fold images to AVIF or WebP, and specify width and height in HTML.
- Lazy-load all images below the fold with loading="lazy".
- Defer or remove third-party scripts that aren't critical to first render — chat, analytics, A/B testing.
- Switch to static or pre-rendered HTML where pages don't change per user (next build, ISR, or a static site generator).
- Put a CDN in front of the site — Cloudflare, Fastly or Vercel's edge — and caching headers on everything that isn't personal.
- Render a stable layout from the first paint: use skeleton loaders or fixed dimensions so CLS doesn't spike when images appear.
- Audit your font loading: use font-display: swap, preload only the weight you use above the fold, and consider variable fonts.
Questions we get over and over
How big is the ranking effect of Core Web Vitals really?
Not enormous in isolation, but real. Google has described it as a "tiebreaker" — when other signals are comparable, the faster page wins. In competitive searches where your relevance and links are level with competitors', it can be the difference between position 3 and position 7. And because it also affects conversion, the ROI on a speed fix is typically solid even if Google didn't rank on it.
Our site is built on WordPress. Can we do anything without changing platform?
Yes, quite a bit. Caching plugins (WP Rocket, FlyingPress), a CDN in front (Cloudflare), image optimisation (Imagify, ShortPixel) and removing heavy plugins often solves 60-70% of the problem. But if you're running a page builder with heavy templates and many plugins, and you plan to scale content or traffic, it's worth considering a more modern stack. We have a separate post coming on when WordPress becomes the wrong choice.
We have an SPA (React/Vue) — is that automatically fast?
No. A classic client-side SPA is often slower on first load because the browser has to fetch, parse and execute large JavaScript bundles before it can show anything. That gives bad LCP and bad SEO. The fix is server-side rendering or static generation — Next.js, Remix, Nuxt — so the first HTML is there immediately and JavaScript hydrates afterwards.
How often should we monitor Core Web Vitals?
Set it up once and let it run. Google Search Console has a free Core Web Vitals report that shows your actual field data over time and tells you when something regresses. That's the most important tool — more important than running PageSpeed Insights manually — because it shows what your real users experience, not what a lab tool measures under ideal conditions.
How fast is flaretech.dk?
You can test it yourself on pagespeed.web.dev — that's the whole point of having an open benchmark. The site is built on Next.js on the edge with static HTML, AVIF images, and minimal JavaScript above the fold. We aim for green on all three Core Web Vitals (LCP, INP, CLS) on both mobile and desktop. If you run the test and find something we can do better, please tell us.
If you're stuck with a slow site
Happy to do a quick audit — no sales pitch.
Send us your URL and we'll get back with a concrete list of the biggest wins. You'll get a no-strings assessment, not a quote — and you can act on the list yourself if you want to fix it in-house.