Website Speed and Core Web Vitals: A Complete Guide

What Core Web Vitals Mean in Plain Language

Let us start with the essentials. Core Web Vitals are three metrics Google uses to measure how a page actually loads through the eyes of a real human, not a robot. They answer three simple questions: did the main content appear quickly, did the site react quickly to your action, and did the layout stay put under your finger.

LCP — how fast the main content shows

LCP (Largest Contentful Paint) is the moment the biggest visible element finishes rendering: usually a hero image, a headline, or a large banner. A visitor considers the page loaded when that block appears, not when the last footer script arrives. A solid target in 2026 is roughly 2.5 seconds on a typical mobile connection.

INP — how fast the site responds

INP (Interaction to Next Paint) replaced the old FID and measures responsiveness: you tap a button, open a menu, start typing — and how many milliseconds pass before the interface visibly reacts. If nothing happens for half a second after a click, the brain is convinced the site froze. A comfortable range is under 200 milliseconds.

CLS — how stable the layout is

CLS (Cumulative Layout Shift) catches the most annoying bug: you aim at a button, an image or banner loads above it, everything jumps down, and you click the wrong thing. It is a cumulative shift of the layout, and the closer to zero, the tidier the site feels. A healthy value is below 0.1.

Remember a simple formula: LCP is about seeing, INP is about tapping, CLS is about not jumping. Google collects all three from real Chrome users and treats them as part of a page quality signal for ranking.

Why Speed Affects SEO and Conversion

Let us be blunt: a slow site loses money at the door, before the visitor has read a single word. Every extra second of waiting increases the share of people who close the tab and leave for a competitor that opened instantly.

Speed and search rankings

Core Web Vitals are an official ranking factor. This does not mean a fast but empty page beats a slow but expert one: content still comes first. But when two pieces are close in quality, speed becomes the tiebreaker that lifts you higher. A fast site is also crawled more thoroughly — on the same crawl budget, the bot reaches more of your pages.

Speed and money

On commercial projects the link between website speed and revenue is plain to see. Speeding up the first screen noticeably lifts checkout and form conversion, lowers your cost of acquisition (you stop losing half your paid traffic on the loading screen), and increases how deep people browse. We have seen this repeatedly across our development and optimization work: technical performance pays back faster than yet another ad campaign.

There is a reputation layer too. A laggy site is subconsciously read as unreliable: if everything stutters here, can I trust it with my payment? Speed is your brand's first handshake, and it should feel confident.

How to Measure Speed: Lab vs Field

Before you fix anything, measure honestly. And here it is vital to separate two fundamentally different kinds of data, because people constantly confuse them.

Lab data

Lab measurements are taken by a tool in controlled conditions: a fixed connection, a defined device, a clean environment. This is Lighthouse (built into Chrome DevTools) and the lab section of PageSpeed Insights. The upside is repeatability: you change code and immediately see if things improved. The downside is that it is a simulation, not living people.

Field data

Field data are metrics collected from real Chrome users (the CrUX dataset). These are exactly what Google uses for ranking. They show how the site behaves on real devices, real networks, and real geography. Field numbers are measured at the 75th percentile: the goal is for the site to be fast not on average but for three quarters of the audience.

A practical measurement order

1. Run your key templates (home, category, product, form) through PageSpeed Insights — separately for mobile and desktop.
2. Look at field Core Web Vitals first if they exist; use the lab score as a debugging tool.
3. Open the Performance tab in DevTools and find which element drives LCP and which scripts block the main thread.

The golden rule: optimize by the field, debug by the lab. Chasing a pretty hundred in Lighthouse without regard for real users is work done for a screenshot, not for the business.

LCP: What It Covers and How to Improve It

LCP is usually what people mean when they say the site takes ages to load. Improving it means showing the main first-screen element sooner. Let us break it into parts.

What LCP is made of

LCP has four ingredients: server response time (TTFB), a delay before the resource starts loading, the load time of the resource itself, and the render time. Any of them can be the bottleneck, so treatment starts with diagnosis, not guessing.

What actually speeds up LCP

• A fast server response. Keep TTFB low: server-side caching, adequate hosting, and few heavy database queries in generating the first screen.
• Priority for the main resource. The LCP image or heading font should load with high priority (preload), not in the general queue.
• No lazy loading for the first screen. A classic mistake is putting lazy-load on the top banner. Save lazy loading for what sits below the fold.
• A light, properly compressed LCP element. A giant 2 MB PNG hero will wreck the metric even on a fast server.

A word on render-blocking. If the browser must download and run heavy CSS and JavaScript before showing the first screen, LCP is delayed by exactly that time. That is why critical CSS is inlined while secondary scripts are pushed down and deferred.

INP and CLS: Responsiveness and Stability

If LCP is about seeing, INP and CLS are about the sense of quality after loading. They are often underrated, and that is a mistake: they are exactly what makes a site feel carefully built.

How to improve INP

Bad INP almost always means the browser's main thread is busy with heavy JavaScript. The user taps — but at that moment the thread is crunching analytics, driving a slider, or rendering a widget, and the reaction is delayed. What helps:

• Break long tasks into short ones, giving the browser pauses to handle clicks.
• Remove or defer third-party scripts that grind in the background.
• Avoid heavy handlers on every move and keystroke.
• Move optional computation out of the moment of interaction.

How to remove layout shifts (CLS)

CLS is cured with markup discipline. The main rules:

1. Always set width and height (or aspect-ratio) on images and video so space is reserved in advance.
2. Reserve space for banners, widgets, and ad slots instead of letting them push content when they appear.
3. Load fonts so that swapping the system font for a custom one does not move the text (correct font-display and fallback metrics).
4. Never insert content above what the user already sees — only below it.

Payments and forms are a special pain point. On our Payora payment service project we watched first-screen stability especially closely: when money is involved, a jumping layout and a slow button response directly reduce trust and the number of completed transactions.

The Biggest Causes of a Slow Site

Good news: slow sites have few causes, and they are surprisingly typical. In nine cases out of ten, someone on this list is to blame.

Heavy images

The absolute heavyweight of page size. Full-resolution photos, multi-megabyte PNG screenshots, images the browser shrinks to a small size but downloads in full. Often the image is the LCP element too, so it is a double hit.

Fonts

Several weights in heavy formats, loaded from an external domain, with no preload — and the text either flickers or appears late, shoving the layout as it goes.

Blocking CSS and JavaScript

Giant bundles that must be downloaded and executed before the first paint. Heavy frameworks are especially wasteful where a couple of lines of code would do.

Third-party scripts

Chats, pixels, a dozen analytics tags, social widgets, A/B tests. Each is light on its own, but together they eat the main thread and wreck INP. This is the most underrated category.

Slow hosting and high TTFB

If the server thinks for a second before answering, no front-end magic fully hides that. Cheap overloaded hosting, no server cache, heavy database queries — all of it sits at the base of LCP.

The practical takeaway: do not rush to fix everything at once. Measure first, find your main source of loss — and hit that.

Image Optimization: Formats and Lazy Loading

Since images are the heavyweight, speed optimization almost always starts there. This is the fastest, most visible win at the lowest risk.

Modern formats

Move to WebP, and where possible to AVIF. At comparable quality they weigh noticeably less than classic JPEG and PNG. For icons and simple graphics use SVG: it is vector, weightless, and perfectly crisp on any screen.

Correct sizing and responsiveness

Never serve an image wider than it actually displays. Prepare several sizes and wire them through srcset so a phone gets a compact version and a desktop gets a large one. A 4000-pixel hero in an 800-pixel container is thrown-away megabytes and seconds.

Lazy loading — but wisely

• Add loading="lazy" to images below the first screen so they do not interfere with the initial paint.
• But load the first-screen LCP image immediately and with priority — lazy loading only hurts here.
• Always set dimensions so lazy loading does not cause layout shifts (that same CLS).

And do not forget compression. Running assets through a decent optimizer often trims 40–70% of the weight with no visible quality loss. For content sites those are literally free seconds.

Fonts, Critical CSS and Excess JavaScript

After images, the second most important zone is the code the browser must process before showing the page. Most render-blocking problems hide here.

Fonts

• Keep the minimum number of weights — two is often enough.
• Use woff2 and serve fonts from your own domain.
• Preload the key first-screen font.
• Set font-display: swap so text is readable at once instead of waiting for the font.

Critical CSS

The idea is simple: the styles needed for the first screen are inlined right into the HTML, and the rest of the CSS loads later. That way the browser paints the top of the page without waiting for the whole stylesheet. Also strip out dead rules — over the years a site accumulates a great many of them.

Less JavaScript

The most honest optimization is not loading what you can do without. Check whether you are pulling a heavy framework for a couple of effects. Defer secondary scripts with defer and async, split the bundle, and load code on demand. Separately audit third-party widgets: every chat, pixel, and tag must justify its place in the performance budget. We covered how this fits with multilingual sites without bloating the page in our piece on the multilingual site and SEO.

Caching, CDN, HTTP/2 and Hosting

Front-end optimization hits a ceiling if the foundation — the server and delivery — is slow. These items pay off across every page at once.

Caching

It works on two levels. Server cache avoids regenerating a heavy page repeatedly and directly lowers TTFB. Browser cache (correct Cache-Control headers for static assets) means that on return visits images, fonts, and scripts are not downloaded again.

CDN

A content delivery network serves static assets from the server closest to the user geographically. The farther your audience is from the origin, the stronger the effect: latency drops and the first byte arrives faster.

HTTP/2, HTTP/3 and compression

• Enable a modern protocol (HTTP/2 or HTTP/3) — it loads dozens of small files in parallel more efficiently.
• Enable compression of text resources (Brotli or gzip) on the server.
• Minify HTML, CSS, and JS, stripping whitespace and comments.

Hosting and TTFB

An adequate server is not a luxury but a baseline. On the busy 24freelance marketplace project we hit exactly the server layer: without caching and query optimization the first byte crawled, and no amount of image work reached the target numbers until we put the backend in order.

Speed on Mobile Devices

An important truth of 2026: Google evaluates your site primarily by its mobile version, and most traffic comes from phones. And a phone means a weaker processor, a less stable network, and less patience from the user.

Why mobile is harsher

What runs instantly on a powerful laptop takes several times longer on an average smartphone. Heavy JavaScript hits INP especially hard on mobile precisely because the processor is weaker and chews through each task longer.

What to do

• Test with a throttled device and a slow network emulation, not only on your flagship.
• Make controls large enough and reserve space in advance to avoid accidental taps and shifts.
• Cut third-party scripts especially hard — their cost on mobile is several times higher.
• Serve images at mobile size, not desktop ones shrunk by the browser.

The good news: if a site flies on an average phone over a mediocre network, it will almost certainly be fast on desktop. So optimize for the worst realistic scenario, not for your work monitor.

Monitoring and Ongoing Control

Speed is not a one-off project but a form of hygiene. A site lives: content is added, new widgets and banners arrive, code is updated — and performance quietly degrades. Without monitoring you learn about a problem from falling sales, not from a report.

How to keep a finger on the pulse

• Regularly check field Core Web Vitals in Google Search Console — it shows the real trend for your audience.
• Set up automated checks of key templates to catch regressions right after a release, not a month later.
• Set a performance budget — a page-weight and script-count ceiling the team is not allowed to exceed.
• Treat every new third-party script as a separate decision: what it gives the business and what it costs in speed.

Who watches over it

In practice it helps to make one person responsible for speed — otherwise the metric becomes nobody's and sags first. If you have no such person on the team, the role can be outsourced: we, for instance, take on periodic audits and performance support, which is easiest to arrange through our contact form.

The core idea: measure before and after every major change. The claim that things got faster should be proven, not merely felt.

A Practical Site Speed Checklist

Let us gather everything into one applied list. Work through it top to bottom — the items are roughly sorted by effect-to-effort ratio. You do not have to do everything at once, but each point is worth reviewing.

Measure and prioritize

1. Measure your key templates in PageSpeed Insights (mobile and desktop) and record the current Core Web Vitals.
2. Find the LCP element of each important template and its main bottleneck.

Images

1. Convert images to WebP or AVIF, and icons to SVG.
2. Serve responsive sizes via srcset, never larger than the container.
3. Enable lazy loading below the first screen; load the LCP image with priority.
4. Set image dimensions so there are no layout shifts.

Code and fonts

1. Inline the critical CSS and load the rest later.
2. Reduce font weights, add preload and font-display: swap.
3. Defer scripts with defer/async and remove unused CSS and JS.
4. Audit third-party widgets and delete anything superfluous.

Server and delivery

1. Enable server caching and lower TTFB.
2. Set up browser caching of static assets and Brotli/gzip compression.
3. Add a CDN and a modern protocol, HTTP/2 or HTTP/3.
4. Minify HTML, CSS, and JS.

Control

1. Verify the result on a throttled mobile-device emulation.
2. Set up field-metric monitoring and a performance budget.
3. Re-measure before and after — record the win in numbers.

Work through this checklist honestly and you get not just a pretty score but a faster, more stable, and more profitable site. And that, in the end, is the point.

FAQ