Most small business websites are slow in the same few ways. The pages are heavy, the scripts are many and the layout moves while it loads. Google's Core Web Vitals turn those complaints into three numbers that you can check and improve. You do not need to be a developer to understand them, and you do not need a perfect score to benefit from the work.

The three measurements

Largest Contentful Paint (LCP) is how long it takes for the biggest visible element, usually the main image or the headline block, to appear. Aim for 2.5 seconds or less.

Interaction to Next Paint (INP) is how quickly the page responds when someone taps, clicks or types. It looks at the interactions across a whole visit and reports one of the slowest. Aim for 200 milliseconds or less. INP replaced an older measurement called First Input Delay in March 2024.

Cumulative Layout Shift (CLS) is how much the visible content moves while the page loads, for example when a banner pushes the text down just as you are about to tap a link. Aim for 0.1 or less.

Google judges each one at the 75th percentile of real visits, so a page passes when three quarters of visits meet the target, not only the fast ones on good connections.

Real visitors and lab tests are different

There are two kinds of data. Field data comes from real visitors using Chrome, and it is what Google uses. Lab data comes from a test run on one simulated device, such as Lighthouse. Lab data is good for finding causes because you can repeat it. Field data tells you whether visitors actually have a problem.

A new or small site often has no field data yet, because too few people have visited. In that case use lab results as a guide, and look at field data again after a few weeks of traffic.

Check your pages in ten minutes

  1. Open PageSpeed Insights (pagespeed.web.dev) and test your home page, one service page and the page with your main form. Look at the mobile results first, because phones are slower and most visits happen on them.
  2. Read the top section, which shows field data if it exists, and note which of the three measurements fails.
  3. Scroll to the diagnostics and look for the biggest items: the element reported as the LCP element, scripts that take a long time to run, and images without dimensions.
  4. In Google Search Console, open the Core Web Vitals report to see which groups of pages need work.

Field data in PageSpeed Insights and Search Console covers a rolling 28 days, so improvements appear gradually, not the morning after you ship them.

Fixing slow loading (LCP)

Find out what the LCP element is before you change anything. On most small business sites it is the hero image.

  • Make the image smaller. Export it at the size it is shown, in a modern format such as WebP or AVIF, and compress it. A 3,000 pixel photo displayed at 800 pixels wastes most of its bytes.
  • Do not lazy-load it. Lazy loading is right for images below the fold and wrong for the first one, which should start loading immediately.
  • Give it dimensions, so the browser can reserve space and start sooner.
  • Cut what blocks rendering. Large style sheets and scripts loaded in the head of the page delay everything that follows. Remove what you do not use and defer the rest.
  • Check the server. If the page takes a long time to start responding, the cause is hosting, caching or a slow database, and no change to the page itself will fix it.
  • Load fewer fonts. Two or three font files are usually enough. Let the text appear in a fallback font while the real one loads.

Fixing slow responses (INP)

Slow responses almost always come from too much JavaScript running at once.

  • Audit third-party scripts. Chat widgets, tag managers, heat maps, review badges and social feeds are the usual cause. Remove any you do not need and load the rest after the page is usable.
  • Avoid heavy work on every click. If a menu or a filter freezes the page for a moment, the code behind it is doing more than it should.
  • Keep the page simple. A very large number of page elements slows every interaction.
  • Test on a mid-range phone, not on a developer laptop.

Fixing jumping layouts (CLS)

  • Reserve space for images, videos, embeds and adverts by setting their width and height, or an aspect ratio.
  • Do not insert content above what people are reading. Cookie banners and promotions should overlay the page, or sit in space that was reserved for them.
  • Handle fonts carefully. A late font swap can reflow whole paragraphs. Choose a fallback with similar proportions and load fonts early.
  • Animate with transforms. Moving an element with transform and opacity does not shift the layout. Animating width, height or position can.

The usual suspects on small sites

If you only have time to check a few things, check these: an oversized hero image or background video, many font files, a chat widget, an autoplaying slider, a cookie banner that shifts the page, a page builder that adds layers of code, and a long list of tracking tags that nobody remembers adding.

A sensible order of work

  1. Fix the worst measurement on the page with the most visits.
  2. Measure again in the lab straight away, and in the field after a few weeks.
  3. Repeat on the next page, and keep a note of what changed and when.

Do not chase a score of 100. Passing the three thresholds on your most visited pages is worth far more than perfecting a page nobody opens, and a fast page that does not help the visitor is still a failure.