Core Web Vitals and page speed: how to build a fast website

Core Web Vitals are a set of three metrics from Google that describe the experience of loading and using a web page. Each one answers a question a visitor would ask, in a number you can measure.

Largest Contentful Paint asks: how soon do I see the main content? Interaction to Next Paint asks: does the page react when I tap? Cumulative Layout Shift asks: does the page stay still while I read?

Google introduced the set in 2020 and has used it in its ranking systems since 2021. The numbers come from real visits by Chrome users, so they reflect your actual audience on their actual phones and connections.

1. LCPLargest Contentful Paint. Loading speed of the main content.
2. INPInteraction to Next Paint. Speed of response to clicks, taps and key presses.
3. CLSCumulative Layout Shift. How much the layout jumps around unexpectedly.

Page speed is the time a page needs to become visible and usable. Visitors experience it before they read a single word. A slow page loses people who were already interested enough to click.

The research is consistent. A Google study from 2017 found that the probability of a visitor leaving rises by 32 percent as load time goes from one second to three seconds.

A 2020 study by Deloitte, 'Milliseconds Make Millions', measured 37 brand sites. A mobile speed improvement of 0.1 second raised retail conversions by 8.4 percent and average order value by 9.2 percent.

Speed is therefore a revenue topic first and an SEO topic second. Every improvement in this chapter helps visitors from every source: search, advertising, social media and email.

Google defines three ranges per metric: good, needs improvement and poor. The thresholds below come from Google's web.dev documentation and are unchanged as of 2026.

A page passes when it reaches 'good' on all three at the 75th percentile. In plain words: at least three out of four visits must hit the target. Google assesses mobile and desktop separately.

The 75th percentile explains a common surprise. Your own fast laptop shows a quick page, while a quarter of your visitors on older phones have a much slower experience. The metric follows them.

Yes, modestly. Google's page experience documentation states that Core Web Vitals are used by its ranking systems. The same document explains that relevance comes first: a great answer on a slower page can outrank a fast page with a weak answer.

Speed matters most when several pages answer a search equally well. In competitive local markets that is common. Ten plumbers with similar pages compete on details, and experience is one of them.

Treat the 'good' thresholds as the finish line for SEO purposes. Moving from poor to good helps. Shaving a further tenth of a second off an already good score helps your visitors more than your rankings.

Speed tools show two kinds of numbers, and confusing them causes most misunderstandings. Field data is collected from real visitors. Lab data comes from one simulated test on one device.

Field data comes from the Chrome User Experience Report, known as CrUX. It gathers measurements from Chrome users who share usage statistics, over a rolling period of 28 days. Google uses this data for the Core Web Vitals assessment.

Lab data comes from Lighthouse, Google's open-source testing tool. It loads your page once on a simulated mid-range phone with a throttled connection. It is ideal for finding causes and testing fixes right away.

PageSpeed Insights is Google's free speed test at pagespeed.web.dev. It shows field data and lab data for any URL on one screen. It runs in your browser, free of sign-up and installation.

Test more than your home page. Pick one page of each type: home page, a service page, a product or category page and an article. Each template has its own images, scripts and problems.

1. Step 1Open pagespeed.web.dev, paste a URL and press Analyze.
2. Step 2Read the top block first: 'Discover what your real users are experiencing'. This is the field data.
3. Step 3Check the verdict of the Core Web Vitals assessment: passed or failed.
4. Step 4Switch between the Mobile and Desktop tabs. Mobile is usually the harder test.
5. Step 5Scroll to the lab section and the diagnostics. Note which element is the LCP element.
6. Step 6Save the results with the date so you can compare after each fix.

A new or quiet site may show too few visits for field data. PageSpeed Insights then shows data for your whole domain, or lab data only. In that case, work with the lab numbers.

The colored circle in PageSpeed Insights is the Lighthouse performance score. It summarizes five lab metrics in one number: 90 to 100 is green, 50 to 89 is orange and 0 to 49 is red.

This score is separate from the Core Web Vitals assessment. A page can score 65 in the lab and still pass in the field, and the reverse happens too. Google's ranking systems look at the field data.

The score also varies between runs, since network and server conditions change. Run a test three times and use the middle result before drawing conclusions.

PageSpeed Insights tests one URL. Google Search Console shows your whole site. Open the Core Web Vitals report in the menu, with separate views for mobile and desktop.

The report sorts your URLs into good, need improvement and poor, based on field data. It groups pages with a similar structure, so one fix to a template often clears a whole group.

Click an issue, such as 'LCP issue: longer than 2.5s', to see example URLs. After a fix, press 'Validate fix'. Google then monitors the group for 28 days and updates the status.

Largest Contentful Paint measures the moment the largest visible element finishes rendering in the first screen. On most pages that element is the hero image, a large heading or a block of text.

Google's web.dev documentation splits LCP into four parts. Knowing which part is slow tells you where to work. PageSpeed Insights shows this breakdown under the LCP diagnostic.

Google's guidance suggests a Time to First Byte of 0.8 seconds or less. If your server takes two seconds to answer, a 2.5 second LCP is out of reach whatever you do to the images.

First find your LCP element. PageSpeed Insights names it in the diagnostics. Then work through the steps below in order. The first three solve the majority of LCP problems on business sites.

1. 1. Shrink the hero imageServe it at the size it is displayed, in WebP or AVIF format. A hero image above 200 KB deserves a second look.
2. 2. Load it eagerlyRemove lazy loading from the LCP image. Lazy loading is for images further down the page.
3. 3. Give it priorityAdd fetchpriority='high' to the image so the browser downloads it first.
4. 4. Put it in the HTMLAn image set as a CSS background or inserted by a script is discovered late. Use a normal image element.
5. 5. Speed up the serverEnable page caching and use a content delivery network close to your visitors.
6. 6. Clear the pathDefer JavaScript that the first screen can miss, and inline the small amount of CSS it needs.

Images usually make up the largest share of a page's weight. A photo straight from a phone can be 5 MB and 4000 pixels wide, while the page shows it at 800 pixels. The visitor downloads the difference for nothing.

Modern formats do the same job with far fewer bytes. WebP and AVIF are supported by all current browsers and are typically much smaller than JPEG and PNG at the same visual quality.

1. ResizeExport images at the largest size they will be displayed, then let the browser choose smaller versions.
2. Responsive imagesUse the srcset attribute to offer several widths, so a phone downloads a phone-sized file.
3. CompressA quality setting around 75 to 85 percent is visually clean for most photos.
4. Lazy load below the foldAdd loading='lazy' to images that sit below the first screen.
5. Set dimensionsAlways include width and height so the browser reserves the space.
6. Replace heavy mediaUse video in place of animated GIFs, and load videos only when the visitor presses play.

Interaction to Next Paint measures the time between an action by the visitor and the next visual update on screen. Actions are clicks, taps and key presses. Scrolling is excluded.

INP became a Core Web Vital on March 12, 2024, replacing First Input Delay. The old metric measured only the delay of the very first interaction. INP observes all interactions during a visit and reports one of the slowest.

Slow responses almost always come from JavaScript. The browser has one main thread, a single lane for most work. While a long script runs in that lane, a tap has to wait its turn.

An interaction has three phases: input delay while the browser is busy, processing time for the code attached to the action, and presentation delay while the screen is redrawn. Each phase can be shortened.

Field tools tell you whether INP is a problem. To find the cause, open your page, use it like a customer and watch which actions feel sluggish: opening the menu, filtering products, typing in a form.

In the lab, Total Blocking Time is the closest stand-in. Lower that number and INP usually follows.

1. Remove unused scriptsAudit every tag and plugin. Each one you delete frees the main thread.
2. Delay third-party codeLoad chat widgets, heat maps and social embeds after the page is usable, or on first interaction.
3. Break up long tasksDevelopers can split work longer than 50 milliseconds into smaller pieces so the browser can respond in between.
4. Show feedback at onceUpdate the screen first, for example with a pressed state or a spinner, and do the heavy work after.
5. Simplify the pageFewer elements and lighter animations mean less redrawing after each action.
6. Review your tag managerTags added over the years pile up. Remove everything that marketing has stopped using.

Cumulative Layout Shift measures how much visible content moves unexpectedly during a visit. You know the feeling: you reach for a button, an advertisement loads above it, and you tap the wrong thing.

The score is a number, calculated from how much of the screen moved and how far. A score of 0.1 or lower is good. Movement that directly follows an action by the visitor, such as opening a menu, is excluded.

Layout shifts happen when the browser learns the size of something late. An image arrives and pushes the text down. A banner appears at the top. A custom font loads and changes the width of every line.

CLS is often the easiest of the three to solve, since each cause has a direct remedy. PageSpeed Insights lists the elements that moved under 'Avoid large layout shifts'.

Test for shifts on a slow connection. Chrome's developer tools can throttle the network, which makes late-loading elements easy to spot with your own eyes.

Custom fonts and external scripts are small additions that add up. A typical business site loads a font service, analytics, a tag manager, a chat widget, a review badge and an embedded map. Each one costs time.

Third-party scripts run on your page from another company's server. You control whether and when they load, and little else. That makes them a frequent cause of slow LCP and poor INP.

1. Host fonts yourselfServe font files from your own domain in WOFF2 format to save a connection.
2. Limit font filesTwo families and a few weights are plenty. Each weight is a separate download.
3. Show text immediatelyUse font-display: swap so text appears in a fallback font while the custom font loads.
4. Use async or deferMark scripts so they load alongside the page and leave rendering free.
5. Replace embeds with a previewShow an image of the map or video and load the real embed on click.
6. Measure each scriptTest the page twice, once with the script and once after removing it, to see its true cost.

Every visit starts at your server. If the server is slow, everything after it starts late. Check the Time to First Byte in PageSpeed Insights, listed in the diagnostics as server response time.

Caching means storing a finished version of a page or file so it can be served again instantly. Server caching saves the work of building the page. Browser caching saves returning visitors from downloading the same files twice.

A content delivery network, or CDN, is a group of servers around the world that keep copies of your files. A visitor in Sydney receives them from a server nearby, even when your main server is in Europe.

1. Page cachingServe stored HTML for pages that are the same for every visitor.
2. CompressionEnable Brotli or gzip so text files travel in a smaller package.
3. Long cache lifetimesLet browsers keep images, fonts, CSS and scripts for months, with new file names when they change.
4. HTTP/2 or HTTP/3Modern protocols download many files in parallel over one connection.
5. Server locationChoose hosting close to your main audience, and add a CDN for everyone else.

You can spend weeks on speed. Most of the gain comes from a short list. The table ranks common website speed optimization tips by typical impact and effort, so you can start where the return is highest.

Work on one item at a time and retest after each change. That way you learn what helped, and you catch a fix that accidentally broke something.

Your platform sets the starting point. Sites built with many plugins, apps or a general-purpose page builder often load code for features the page leaves unused. Each extra adds scripts and styles.

On platforms such as WordPress, Shopify and Wix, the largest gains usually come from choosing a lightweight theme, removing unused plugins or apps, and using the platform's built-in image optimization.

Hand-written code gives the most control: each page loads only what it needs. That is the approach Delta Six uses on its own platform. Whatever you build on, the measurements in this chapter stay the same.

Speed erodes quietly. A new plugin, a large photo from a colleague, an extra tracking tag: each is small, and together they undo your work. A short recurring check keeps the site healthy.

Remember that field data lags by up to 28 days. Judge a fix first with a lab test, then confirm it a month later in the Core Web Vitals report.

1. MonthlyOpen the Core Web Vitals report in Search Console and look for new issues.
2. After every changeRun PageSpeed Insights on the affected page type, three times, and compare with your saved results.
3. Every quarterReview all scripts, tags and plugins. Remove what is unused.
4. With every uploadResize and compress images before they go on the site.
5. Once a yearTest your site on an older mid-range phone on mobile data. That is your real audience.

Delta Six builds each website on its own platform with hand-written code, so a page carries only the code it uses. Monthly SEO comes standard with every website.

You see your complete website in a 15-minute online showcase before paying anything, and you pay only when you are happy.

• Test one page of each type in PageSpeed Insights, on the Mobile tab, and save the results.
• Check whether the Core Web Vitals assessment passes, based on field data.
• Open the Core Web Vitals report in Search Console and note every issue group.
• Identify the LCP element on your key pages.
• Serve the LCP image in WebP or AVIF at its displayed size.
• Remove lazy loading from the LCP image and add fetchpriority high.
• Add width and height to every image, video and embed.
• Lazy load images below the first screen.
• Remove unused plugins, apps, tags and scripts.
• Delay chat widgets, maps and video embeds until the page is usable or the visitor interacts.
• Self-host fonts in WOFF2, limit weights and use font-display swap.
• Enable page caching, compression and long browser cache lifetimes.
• Check that server response time stays under 0.8 seconds.
• Retest after each fix and press Validate fix in Search Console.
• Plan a monthly check of the Core Web Vitals report.