Website speed and Core Web Vitals: why it matters and how to speed up your site

Website speed determines whether a visitor waits for the page to load, whether they send an enquiry and how the site ranks in search. Google measures it through Core Web Vitals — three metrics of real user experience: LCP (how fast the main content appears; up to 2.5 seconds is good), INP (responsiveness to interactions; up to 200 ms) and CLS (visual stability; up to 0.1). Sites are most often sped up by optimising images, fonts, scripts and the server side.

Below is what each metric means, how to measure speed properly and which actions give the biggest effect.

Why speed matters for business

A slow website is not a technical detail but lost customers. A visitor who stares at a blank screen for several seconds often simply returns to the search results and opens a competitor.

• Conversion. The sooner a page becomes useful, the more people reach the form, catalogue or call button.
• SEO. Core Web Vitals are among the signals Google uses to assess page experience. It is not the main factor — content matters more — but with everything else equal, the faster site wins.
• Mobile internet. Many visitors come from phones and not always over a fast connection. A site that works well on an office computer can be painfully slow on a smartphone.
• Advertising. If you pay per click, a slow landing page means part of the budget goes to people who never saw the offer.
• Brand perception. A sluggish site is subconsciously associated with an unreliable company.

Indirect signs help you tell that speed is the real problem: noticeably worse engagement on mobile than on desktop, customers complaining that the site "takes ages to open", and a gap between the number of ad clicks and the number of visits recorded by analytics.

What Core Web Vitals are

These are three metrics describing how a user experiences a page loading and working. They are assessed on real visitor data: a page is considered good if the thresholds are met for most visits (at the 75th percentile).

• LCP (Largest Contentful Paint) — the time it takes for the largest visible element to load: the main image, a banner or a large heading. Poor LCP is usually caused by heavy images, a slow server or render-blocking scripts and styles.
• INP (Interaction to Next Paint) — how quickly the page responds to clicks, taps and typing. Since March 2024 this metric has replaced FID. Poor INP signals overloaded JavaScript: heavy widgets, libraries and analytics scripts.
• CLS (Cumulative Layout Shift) — how much content "jumps" during loading. A classic example: you are about to tap a button when a banner suddenly appears above it and you hit the wrong thing. The causes are images without set dimensions, late-loading fonts and ad blocks.

How to measure website speed

It is important to distinguish two types of data:

• Field data — what real visitors experience. It is shown in PageSpeed Insights (the real-user data block) and the Core Web Vitals report in Google Search Console. This is what the search engine takes into account.
• Lab data — the result of a test under controlled conditions: Lighthouse, the Performance tab in the browser's developer tools. It is useful for finding causes and verifying fixes.

Practical measuring tips:

1. Check the mobile version first — it is usually worse and more important.
2. Test not only the home page but key templates: a service page, a product page, a blog post, the contacts page.
3. Run several measurements: a single test result can fluctuate.
4. Record baseline values before optimisation so you can see the effect.
5. Remember that field data updates with a delay — improvements will not show immediately.

Optimise not for a test score but for the experience of a real visitor on a phone. A green number in a lab report does not help if live users see a slow page.

How to speed up a website: the main techniques

Images

• Use modern formats — WebP or AVIF — and compress files without visible loss of quality.
• Serve images at the right size for each screen rather than one huge picture for all devices.
• Enable lazy loading for images below the first screen, but not for the main banner — that one should load with priority.
• Always set width and height so the browser reserves space and the layout does not jump.

Fonts

• Load only the weights and character sets you need.
• Use font-display: swap so text is visible immediately.
• Self-host fonts if it speeds up loading, and preload the main one.

JavaScript and third-party scripts

• Remove unused libraries and plugins.
• Defer non-critical scripts.
• Audit third-party services: live chats, widgets, multiple analytics systems, ad pixels. Each one adds weight and slows the page's response.
• Heavy sliders and animations on the first screen often bring little benefit and a lot of delay.

Server and delivery

• Check server response time: if it is high, no front-end optimisation will save you.
• Set up caching of pages and static files, compression (gzip or brotli), HTTP/2 or HTTP/3.
• Use a CDN if your audience is geographically spread, as is often the case for exporters.
• Choose hosting with spare capacity rather than the cheapest plan.

Speed is decided at the design stage

Many speed problems are born not in the code but in the mock-up. If the design calls for full-screen video on the first screen, several different fonts, a slider of a dozen photos and an animation on every block, the developer can only soften the consequences. That is why performance should be discussed with the designer from the very start.

• First screen. One strong image or a clean typographic headline usually works both faster and more clearly than a carousel.
• Fonts. One or two typefaces with a limited set of weights are enough for an expressive brand identity.
• Video. Background video is rarely justified; if you need it, use a short lightweight clip and a static poster image on mobile.
• Animations. Light CSS transitions instead of heavy libraries — and only where they help users understand the interface.
• Icons and illustrations. Vector formats instead of raster wherever possible.

A good practice is to set a "performance budget": cap the total weight of the first screen and the number of third-party scripts, and check every new mock-up against those limits.

A step-by-step optimisation plan

1. Measure field and lab metrics for the key page templates.
2. Identify which metric is the problem and on which pages.
3. Find specific causes in Lighthouse reports and developer tools.
4. Start with the changes that have the greatest effect: images, third-party scripts, caching.
5. Check that the fixes have not broken anything: forms, analytics, appearance.
6. After a few weeks, compare field data with the baseline.
7. Make the rules stick: set requirements on image size and adding new scripts for everyone who updates the site.

Common mistakes

• Uploading photos straight from the camera without compressing them.
• Adding every new widget "as a trial" and forgetting to remove it.
• Optimising only the home page while ignoring the pages that receive ad and search traffic.
• Chasing the maximum test score instead of improving real experience.
• Installing "speed-up" plugins that conflict with each other.
• Embedding heavy PDF catalogues directly in the page instead of offering a download link.
• Believing the problem is solved forever: without monitoring, a site gradually gets heavier again.

If a site is so outdated that targeted optimisation does not help, it may be time to think about a redesign. Speed is only one part of search promotion; for more, see our article on SEO for business in Uzbekistan. If you need help with an audit and speed-up, the Dasta Creative team will check your key pages and propose a work plan — see our web development page.