Elevate^

Field Guide · Web Performance

How to speed up your website

A slow site loses people before they read a word, and search engines notice. This guide shows you how to speed up your website the practical way: understand the three Core Web Vitals, measure what your real visitors feel, then work through the biggest wins in order — images, code, caching, hosting and fonts.

Definition

To speed up your website is to reduce how long a page takes to load and become usable, and to keep it visually stable while it does. Modern performance is judged by Core Web Vitals: loading speed (LCP), responsiveness to input (INP) and visual steadiness (CLS). Improving them makes visitors stay, and gives search engines one more reason to rank you.

Fig 1The Core Web Vitals gauge: loading (LCP), responsiveness (INP) and visual stability (CLS), each with the “good” threshold a page should stay under.

Speed is not a vanity metric. On mobile connections and mid-range phones, a page that feels instant on your laptop can take several long seconds for a real customer — and most of them will not wait. Faster pages keep more visitors, convert more of them, and give both search engines and AI answer tools a cleaner, quicker page to trust. It is one of the few improvements that helps users and rankings at the same time.

01 / Why it mattersPeople, search and AI

Every extra second of load time is a reason to leave. Visitors judge a site in the first moments, and a sluggish page reads as careless before anyone sees your work. Beyond the feeling, speed is measurable and it counts three ways. For people, faster means more of them stay and act. For search, Core Web Vitals are a confirmed Google ranking signal, part of the page experience factors that help decide close contests. For AI answer tools, a light, fast, well-structured page is simply easier to crawl and quote. Speed is where good user experience and good SEO stop competing and start pulling together.

02 / The three vitalsWhat Core Web Vitals measure

Google's Core Web Vitals reduce a complex thing to three human questions. Largest Contentful Paint (LCP) asks: how long until the main content appears? Interaction to Next Paint (INP) asks: when I tap or click, how quickly does the page respond? Cumulative Layout Shift (CLS) asks: does the layout stay put, or do things jump around as it loads? According to Google's web.dev, a page is rated “good” when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of real visits. Those three numbers are the scoreboard for everything that follows.

03 / Measure firstTest before you touch

Never optimize blind. Start with PageSpeed Insights, which pairs a lab test with field data — the Core Web Vitals your actual visitors experienced over the past month, drawn from the Chrome User Experience Report. Lab scores are useful for diagnosis, but field data is the truth: it reflects real phones, real networks and real distances. Test on mobile first, because that is where most people and most problems live. Note your current LCP, INP and CLS, find the single biggest offender, and fix that before moving on. Measuring first stops you polishing things visitors never notice while the real bottleneck sits untouched.

04 / The biggest winsA step-by-step for a faster site

Most sites get the majority of their speed back from a handful of changes. Work through them in this order, re-testing as you go:

Fig 2The optimization stack: a fast foundation of hosting and caching, then trimmed code, then the images and fonts that usually make up most of a page’s weight.

05 / Images and fontsWhere most of the weight lives

On a typical site, images are the heaviest thing you ship, which makes them the fastest place to win. Convert photos to WebP or AVIF, export them no larger than they are ever displayed, and always set width and height so the browser reserves space and nothing jumps — that alone protects your CLS. Fonts are the quiet second offender: a custom typeface that blocks rendering can leave text invisible for a beat. Self-host your fonts, preload the one or two the first screen needs, and use font-display: swap so text shows immediately in a fallback and swaps in without a flash. Small, disciplined asset choices move the needle more than almost anything else.

06 / Code, caching and hostingThe engine underneath

Once assets are lean, the delivery layer matters. Trim unused CSS and JavaScript, inline the critical CSS the first screen needs, and defer the rest so scripts no longer block the paint. Set generous cache lifetimes on static files and put a CDN in front, so returning visitors and people far from your server pull assets from a nearby edge rather than the origin every time. Underneath it all, hosting sets the ceiling: a fast server response (a low time to first byte) means the page can start rendering sooner. Edge and static delivery, where the page is served pre-built from close to the user, is the most reliable foundation for speed there is.

07 / Third partiesThe scripts you did not write

The heaviest part of many sites is code the owner never wrote: chat widgets, analytics, ad tags, A/B testers, embedded videos and social buttons. Each one can pull in more scripts, block the main thread and hurt INP long after your own code is tuned. Treat every third-party tag as a cost to justify. Remove anything unused, load the rest as late as possible, and prefer a lightweight embed or a static image over a full widget where you can. A single abandoned marketing pixel has undone a whole round of optimization more than once.

08 / The Elevate wayFast by construction

At Elevate Labs we would rather build a site that is fast from the first line than bolt speed on afterward. Our in-house builds in Oslo lean on modern formats, minimal JavaScript and edge delivery, so Core Web Vitals tend to pass because of how the site is made, not despite it. Performance is part of the craft, alongside the structure that helps you rank — see our technical SEO guide for the wider picture, and what a website costs when it is built properly. If you want a site that is quick out of the box, look at our web design in Oslo, or browse all our guides.

09 / QuestionsFrequently asked

What is a good Core Web Vitals score?
According to Google's web.dev, a page passes when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of real visits. Hitting all three on both mobile and desktop is the target.
Does website speed affect SEO rankings?
Yes. Core Web Vitals are a confirmed Google ranking signal, part of the page experience factors. Speed rarely outranks strong content on its own, but between two comparable pages the faster one has the edge, and a slow page quietly loses visitors before it can rank at all.
Why is my website slow even on fast hosting?
Fast hosting only sets the floor. Most slowness comes from oversized images, heavy JavaScript, render-blocking code, and third-party scripts like chat widgets, analytics and ad tags. A quick server cannot outrun a page that ships several megabytes of assets to every visitor.
How long does it take to make a website faster?
The biggest wins, image compression, caching and removing unused scripts, can often land in days. Deeper work on code splitting, critical CSS and layout stability takes longer. Speed is not a one-time fix either; it needs checking whenever new features or content are added.

Want a site that is fast by default?

Elevate Labs builds performance-obsessed websites in Oslo — fast, stable and made to pass Core Web Vitals.

See web design in Oslo →