Core Web Vitals are three specific measurements Google uses to assess the real-world experience of visiting a web page. They cover how quickly the main content loads, how quickly the page responds to interaction, and how much the page layout shifts unexpectedly while loading. Google uses these measurements as part of its ranking algorithm, and they also appear directly in your Google Search Console account.

Accounting firms do not need to become web performance engineers, but understanding what these metrics measure and knowing which scores to aim for puts you in a position to have informed conversations with your developer and to prioritise the right fixes. Poor Core Web Vitals scores are often the hidden reason a well-written page does not rank as well as it should.

Why Google introduced Core Web Vitals

Before Core Web Vitals, Google's speed signals were based largely on lab measurements: how quickly a page loaded in a controlled test environment. These measurements did not always reflect what real users experienced, particularly on mobile devices or slower connections.

Google introduced Core Web Vitals in 2020 and made them a ranking factor in 2021 as part of the Page Experience update. The goal was to use real-world user data, collected anonymously from Chrome browsers, to evaluate pages based on how they actually perform rather than how they perform under ideal conditions.

The three metrics reflect three distinct aspects of page experience that users consistently cite as frustrating: waiting for the main content to appear, waiting for the page to respond after clicking, and watching the page jump around as elements load.

LCP: how quickly your main content appears

LCP stands for Largest Contentful Paint. It measures how long it takes for the largest visible element on the screen to fully load. On most accounting websites, this is typically a hero image at the top of the page, a large banner, or in some cases a large block of text.

The target is under 2.5 seconds. Pages with LCP between 2.5 and 4 seconds "need improvement," and anything above 4 seconds is classified as "poor."

Why this matters for accounting firm websites: most firms display a prominent hero image on their homepage, often a photograph of the office, staff, or a stock image representing professionalism. If that image is not compressed and optimised, it becomes the element causing the worst LCP score. A hero image weighing several megabytes can push LCP to six or seven seconds on a mobile connection.

Other common causes of poor LCP include web fonts that delay text rendering, large above-the-fold HTML blocks, and slow server response times. Fixing LCP often involves a combination of image compression, a content delivery network, and better hosting.

INP: how quickly your page responds to interaction

INP stands for Interaction to Next Paint. It replaced FID (First Input Delay) in March 2024. Where FID measured only the first interaction on a page, INP measures the responsiveness of all interactions throughout the page lifetime: clicks, taps, and keyboard input.

The target is under 200 milliseconds. Between 200 and 500 milliseconds "needs improvement," and anything above 500 milliseconds is classified as "poor."

For most simple accounting websites, INP is usually not the primary problem. It becomes an issue on pages with complex JavaScript, such as interactive calculators, multi-step contact forms, or pages that load third-party scripts (live chat widgets, marketing automation tools) that compete for processing time on the visitor's device.

If your Search Console INP data shows "poor" scores, the most common cause is JavaScript from third-party tools blocking the main thread. Your developer can diagnose this using Chrome DevTools Performance panel.

CLS: how stable your page layout is

CLS stands for Cumulative Layout Shift. It measures how much the visible content of a page moves while loading. A score of 0 means nothing moved. The target is under 0.1. Between 0.1 and 0.25 "needs improvement," and anything above 0.25 is "poor."

You have experienced poor CLS when you go to click a button and, just as you click, an image loads above it and pushes everything down, causing you to click something you did not intend to. This is a particularly poor experience on mobile where targets are smaller.

On accounting websites, common causes of CLS include images loaded without width and height attributes in the HTML (the browser does not reserve space for them, so the layout shifts when they load), web fonts that cause text to reflow when they replace the fallback font, and banner or cookie consent notices that push content down after the page has loaded.

Fixing CLS is often achievable without complex developer work. Adding explicit width and height attributes to all images is a straightforward fix. Ensuring your cookie banner uses a fixed position (so it overlays rather than pushes content) is another common improvement.

What typically causes poor CWV scores on accounting websites

Most accounting websites share similar technical profiles, which means they tend to fail on similar Core Web Vitals issues.

Hero images causing poor LCP: A large, uncompressed image as the first visual element is the most common source of poor LCP. Compressing the hero image to under 150kb and serving it in WebP format is usually the single most impactful fix.

Google Fonts causing CLS: Loading web fonts from Google Fonts can cause a "flash of unstyled text" followed by a layout shift when the web font loads. This is improved by adding font-display: swap to your font declarations and preloading the font files.

Late-loading JavaScript causing CLS: Cookie banners, chat widgets, and marketing scripts that inject content into the page after it has rendered cause layout shifts. These should either be loaded with defer so they do not block rendering, or designed to overlay content rather than push it.

Third-party scripts causing poor INP: Live chat tools, marketing automation, and heatmap tools run JavaScript that competes with your page's own scripts. Each additional third-party tool introduces potential INP issues.

How to check your Core Web Vitals

Google Search Console provides the most useful view. Navigate to Search Console, select "Core Web Vitals" from the left menu, and you will see two reports: one for mobile and one for desktop. Each report groups your URLs into "Good," "Needs improvement," and "Poor" categories and identifies which metric is failing. This data is based on real user visits over the past 28 days.

Google PageSpeed Insights gives you a page-by-page view. Enter any URL and scroll down to the "Diagnose performance issues" section. You will see Core Web Vitals scores for both lab (simulated) and field (real user) data where available. The "Opportunities" and "Diagnostics" sections explain what is causing each issue.

Chrome DevTools is a browser tool available by pressing F12 in Chrome. The "Lighthouse" tab runs a full performance audit and scores all three Core Web Vitals. This is what developers use to diagnose specific issues.

Do you need a developer to fix Core Web Vitals?

This depends on which metrics are failing.

LCP improvements often include image compression, which you can partially do yourself by replacing large images with compressed WebP versions. Server response time and render-blocking resources require developer involvement.

CLS improvements for missing image dimensions are straightforward for a developer and low risk to implement. Font-related CLS typically requires changes to your theme or layout files.

INP improvements almost always require a developer. They involve identifying specific JavaScript execution bottlenecks, which requires profiling tools and technical knowledge.

When briefing your developer on Core Web Vitals, share the specific report from PageSpeed Insights or Search Console, identify which metric is failing and which URLs are affected, and ask for a plan to move those URLs from "Poor" or "Needs improvement" to "Good."

How much do Core Web Vitals affect your rankings?

Core Web Vitals are a confirmed ranking factor, but Google has been explicit that they are not the dominant signal in most cases. If two pages are very similar in content quality and relevance, the one with better Core Web Vitals will tend to rank higher. But a page with excellent content and poor Core Web Vitals will usually still outrank a page with mediocre content and perfect Core Web Vitals.

The practical implication for accounting firms is: fix critical failures (pages rated "Poor") as a priority, because poor scores likely indicate user experience problems that are affecting your enquiry rate regardless of their ranking impact. Chasing the last few points from "Good" to perfect is less valuable than producing better content or improving your local SEO presence.

Key takeaways

  • Core Web Vitals are three real-world performance metrics: LCP (loading speed, target under 2.5 seconds), INP (responsiveness, target under 200ms), and CLS (layout stability, target under 0.1).
  • Check your Core Web Vitals in Google Search Console's Core Web Vitals report, which shows data based on real user visits across all your pages.
  • Unoptimised hero images are the most common cause of poor LCP scores on accounting websites; compressing and converting to WebP typically makes the biggest single improvement.
  • CLS issues are often caused by images without explicit dimensions and late-loading cookie or chat banners; these are relatively straightforward developer fixes.
  • INP issues usually require developer involvement to diagnose and fix.
  • Core Web Vitals are a tiebreaker ranking signal; fixing "Poor" pages is worthwhile, but content quality remains the more important long-term investment.

Frequently asked questions

What is the difference between FID and INP?

FID (First Input Delay) measured the delay before the browser responded to the very first interaction on a page. INP (Interaction to Next Paint) replaced FID in March 2024 and is more comprehensive: it measures the responsiveness of all interactions throughout the page lifetime, not just the first one. INP gives a more complete picture of how interactive your page feels in practice.

My Search Console shows "Not enough data" for Core Web Vitals. What does that mean?

Search Console's Core Web Vitals report is based on real user data from Chrome browsers. If your website receives fewer than a certain threshold of visits, Google does not have enough data to produce a reliable report. You can still test individual pages using PageSpeed Insights, which provides both simulated lab data and any available field data.

Can a poor CLS score affect my enquiry rate?

Yes. If your contact form or call-to-action button shifts position while the page loads, users either miss it or click the wrong element. CLS issues are most pronounced on mobile, where many accounting firm enquiries originate. Fixing CLS often produces an immediate improvement in form submission rates.

How often does Google update the Core Web Vitals metrics?

Google reviews and sometimes updates the Core Web Vitals metrics annually. The most recent significant change was replacing FID with INP in March 2024. Google announces upcoming changes well in advance, usually with at least six months notice. Following the SEO for accountants guide on AccountingStack will keep you informed of any updates.

Should I focus on my homepage or all pages for Core Web Vitals?

Fix your highest-traffic pages first: your homepage, your main service pages, and any pages that already rank well and drive enquiries. These are the pages where improvements will have the most immediate impact. The Search Console Core Web Vitals report shows which specific URLs are rated "Poor" so you can prioritise them directly.