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.
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:
- Measure first. Test the page in PageSpeed Insights and look at real-user field data before changing anything, so you fix what actually slows visitors down instead of guessing.
- Optimize images. Serve modern formats like WebP or AVIF, size each image to how it is displayed, compress it, and set explicit width and height so nothing shifts as it loads.
- Lazy-load offscreen media. Load images and embeds below the fold only as the visitor scrolls toward them, while loading the main hero image eagerly so the largest element paints fast.
- Trim and defer code. Remove unused CSS and JavaScript, inline the critical CSS the first screen needs, and defer or async the rest so scripts stop blocking the render.
- Cache and use a CDN. Set long cache lifetimes on static assets and serve them from a content delivery network so returning visitors and distant users get files from a nearby edge.
- Choose solid hosting. Run on hosting with a fast server response, ideally edge or static delivery, so the first byte arrives quickly instead of waiting on a slow database or shared box.
- Tame fonts and third-party scripts. Self-host and preload key fonts with font-display swap, then audit every third-party tag and remove or defer the ones that are not earning their 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?
Does website speed affect SEO rankings?
Why is my website slow even on fast hosting?
How long does it take to make a website faster?
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 →