How to pass Google's
Core Web Vitals ranking

Guidance for pagespeed & UX friendly websites. In May 2021, Web Vitals will be a SEO ranking factor, based on CrUX data.

Core Web Vitals FAQ ROI calculator

  • What does Web Vitals provide?

    Essential metrics for a healthy site

    Google introduced Core Web Vitals to help you gain real life insight in how your users experience your website or webshop by:

    • Loading time: how long do your users have to wait until they see something on your website;
    • Interactivity: how long until your users can do something on your website;
    • Visual stability: will the website they see be stable, or shift while loading.
  • Better loading time

    Improving Largest Contentful Paint

    LCP reports the render time of the largest image or text block visible within the viewport of your webshop or site. This could be your main product image.

    • A LCP lower then 2.5 seconds, means your website has a good loading score.
    • A fast LCP helps reassure the user that the page is useful, thus lowering the bounce-rate.
    • I help you and your team with a strategy that will lower your LCP.
  • Faster Interactivity

    First Input Delay

    The FID metric measures your users first impression of the interactivity and responsiveness within your website or webshop.

    • An optimal FID User Experience is lower then 100ms;
    • When the FID-metric is high, the browser is too busy with parsing something else, usually JavaScript;
    • I help you implement better parsing-methods on your website, by giving you best practice methods amongst all other JavaScript.
  • More visual stability

    Cumulative Layout Shift

    Every unexpected layout shift that occurs while your user is interacting on your webshop page, is measured by the CLS metric.

    • You should aim for your CLS to be lower then 10%;
    • This will ensure that your users will not start reading - or worse clicking- something that will shift later;
    • I will help you to prevent users getting frustrated and bounce due to layout-shifts and lead your e-commerce to increased conversion.

We found that when a site meets the above thresholds, users are 24% less likely to abandon page loads

Google / Chromium
  • Erwin Hofman is happy to help

    Start making your website faster

    Are you interested in improving or passing Google's Core Web Vitals assessment as part of your pagespeed or CRO strategy? I know I am as on top of impacting conversion, Core Web Vitals will become a ranking factor in 2021.

Frequently asked questions



  • The easiest way to determine of your site or shop is passing the Core Web Vitals is by using Google's PageSpeed Insights or using the pagespeed tool on my site. In case of sufficient data, you will see one of the following statements about your specific page URL or origin on passing the Core Web Vitals metrics:

    • field data shows that this page passes the Core Web Vitals assessment;
    • field data shows that this page does not pass the Core Web Vitals assessment;
  • We can answer this question since November 2020. Core Web Vitals will become a ranking factor in May 2021. Together with this ranking update, a visual indicator will be added to the SERP's as well.

    Do note that they will be testing a visual indicator prior to Core Web Vitals becoming a ranking factor. See my November article on Core Web Vitals highlighting per May 2021.

  • It will be a ranking factor in 2021. Obviously, it will already impact conversion as various researches are pointing out.

    At the same time, pages that are passing the Core Web Vitals assessment will also see their chances increase of become part of the Google Top Stories. Having AMP pages isn't the only requirement anymore. Passing Core Web Vitals will do the job as well.

    Chromium is always busy improving and catering to optimal user experience. They are experimenting with different types of fast page labelling. Passing the Core Web Vitals assessment might yield more benefits in the future as well. For example, reduced pay-per-click (PPC) costs.

  • Google announced a visual indicator for Core Web Vitals and the first tests with such indicator are already spotted in the SERP's. To also get a (positive) visual indicator, you need:

    • enough visitors;
    • all Core Web Vitals (FID, LCP, CLS) metrics should be green for the last 28 days.
  • As far as first tests by Google have shown us, it might look like the Google AMP indicator. In the case of passing Core Web Vitals, it could mean that it will be a grey circle with a white star. See also the blogpost Core Web Vitals visual indicator and Google news top stories


  • It is about "Field data". This means that:

    • Core Web Vitals is about real users, out in the field;
    • Chrome UX Report (CrUX) is forged from data collected via Chrome, directly from its users browsing the web;
    • It is about performance data from your very own traffic, amongst Chrome users only.
  • Chromium users have their experiences tracked during a page visit. Once a visitor leaves the page, for example clicking to another page, Google will send the performance and UX metrics to their own servers. This is better known as the Chrome User Experience (CrUX) report.

  • All Chromium users (nowadays even Microsoft Edge users) have their data send to Google / CrUX. This means most real user experiences of Apple / iOS users might not be send to Google servers, as they often use Safari and Linux users might use FireFox.

    Do note that users can opt-out from this setting and stop their browser from sending their experiences and thus UX and pagespeed metrics to Google servers.

  • Nobody knows. Tests I conducted in the past pointed out that your site needs around 400 pageviews a month per device (mobile, tablet, desktop), using Chromium to get a Core Web Vitals origin summary when using PageSpeed Insights. Do note that this might be the absolute minimum.

    When a site doesn't have enough visitors, chances are you need to find other ways to rank higher. Do note: improved pagespeed will still impact conversion positively, no matter the amount of visitors or passing the Core Web Vitals assessment.

  • When doing a PageSpeed Insights test, you will always see "Lab data". "Field data", sitting on top of "Lab data", will be displayed as well. When you don't see any coloured bar charts, your webpage didn't have sufficient visitors (yet) to yield any data.

    However, if your origin (domain) did have enough visitors to yield a summary, PageSpeed Insights might at least still show you an origin summary. When no "Field data" at all is being displayed, your website or webshop doesn't have enough visitors and you won't benefit from Core Web Vitals ranking factor. Do note though that improving your pagespeed, performance and UX will still impact conversion and might make you future proof in case the amount of visitors increase over time.

  • Hopefully, you’ll have enough traffic to get some data to see Field data within PageSpeed Insights, Google Search Console and CrUX.If not, you can still track the Core Web Vitals of your visitors and store it where ever you want. For example to Google Analytics or via Google Tag Manager. GoogleChrome published a library, including code examples on github.


  • For each metric, visitors should have an experience below the following boundaries:

    • Largest Contentful Paint should be below 2.5 seconds;
    • First Input Delay should be below 100 milliseconds;
    • Cumulative Layout Shift should be below 10% (0.1).
  • Luckily: no. There might always be visitors under really poor circumstances, when it comes to device capabilities and internet connectivity. For example when having an international website or webshop, users may come from different regions, working with different budgets and thus different smartphone devices.

    As a result, at least 75% of visitors should have an experience within the three metric boundaries to be able to pass the Core Web Vitals. To put it mathematically: the 75th percentile of the data of each metrics, should be within the green thresholds.

  • To create the three buckets, being green for good experience, orange for needing improvement and red for poor experience, Google looked at their very own CrUX data as well as user experience researches to come up with a threshold or bucket distribution. They also analyzed what the percentage of different amount of (in case of the LCP) seconds was. See also Defining the Core Web Vitals on website.

  • Although PageSpeed Insights was using the 50th percentile (being the median) when using Lighthouse v4, Google changed this to the the 75th percentile over time to make sure that pages work well for the majority of users. By focusing on 75th percentile values for our metrics, it is ensured that pages provide a good user experience under the most difficult device and network conditions and developers can understand the most frustrating user experiences on their site

    Google did use a higher percentile (90th percentile) for a short amount of time for some metrics. However, as faster websites and webshops are likely to increasingly attract more users under more difficult conditions, this could skew the data too fast. As a result, the 75th percentile is being used so data will not be overly impacted by outliers.

Passing Web Vitals

  • The short answer is: no you don't. Well, at least not necessarily to pass the Core Web Vitals. This is because the Core Web Vitals will get their data from real user experiences. As a result, the circumstances of your visitors play an important role as well, while the overall PageSpeed score might give you a general impression of your performance and UX hygiene.

  • Although PageSpeed Insights might show you four metrics, these three are part of the Core Web Vitals:

    • Largest Contentful Paint;
    • First Input Delay;
    • Cumulative Layout Shift.

    To pass the Core Web Vitals assessment, users should have an optimal experience for each given metric.

    The above means First Contentful Paint isn't part of the Core Web Vitals. Do note that an optimal First Contentful Paint will trigger early user engagement, so don't forget to optimize this metric as well.

  • Considering you do see data and charts in the Field data section when using PageSpeed Insights, it is just showing you a summary of the last 28 days. This means, optimizing today isn't enough to skew or impact the data of the other 27 days which might still take the bad experiences into account.

    To get an optimal sense of the impact of your changes on the real user experience amongst your visitors, check again in 28 days since optimizing speed / UX.

  • The Field data and thus Core Web Vitals data of real user experience as shown within PageSpeed Insights, is covering data of the last 28 days. As technical optimizations might only become noticeable after 28 new days, chances are it will take at around 28 days.

    When Core Web Vitals metrics are already close to the thresholds as set by Google, you might see your webpages or website passing the Core Web Vitals even earlier. Although at time of writing it isn't clear yet how long it takes for Google to impact the SERP's, chances are it will be quite instant, as soon as your webpages or website is passing the Core Web Vitals assessment.

  • It totally depends on your target audience and ambitions. Fast webpages with optimal UX on top of it will allow more users to find and digest your content, causing an increasement in visitors. As this could also allow more visitors under difficult device and network conditions, this could change your averages as well as percentiles.

    Besides change in type of users, chances are your website or webshop will grow as well, serving more resources with new risks of impacting the Core Web Vitals metrics. In other words, keep monitoring.

  • Ranking also depends on the quality of your content, how your competitors are doing, et cetera. At the end, Core Web Vitals is just one of the many ranking factors of which Google won't tell us how it is used in their algorithms. Maybe your competitors are also doing a great job when it comes to pagespeed and UX, or they have better content quality.


  • CLS stands for Cumulative Layout Shift, meaning that shifts are happening during a pagevisit. Ads that are lazily loaded, might push other content down. This will impact user experience, as users have to reorient while reading. As Google knows this will impact UX and thus bounce, CLS has become a ranking factor.

  • To give an idea of CLS, the following could impact layout shifts:

    • Images without dimensions or without a fixed parent;
    • Ads, iframes that are being inserted or loaded;
    • Dynamically inserting new elements and content on the fly (client side rendering);
    • Web fonts, changing characteristics of the text in regards of line-height, letter-spacing and letter-width.
  • To detect CLS, you can:

    • log it to your JS console to test your own experienced CLS, via
      new PerformanceObserver((list) => list.getEntries().map(console.log)).observe({type: 'layout-shift', buffered: true})
    • use the performance tab within Chrome DevTools to detect CLS (personal CLS);
    • use brower plugins (personal CLS);
    • use Lighthouse or PageSpeed Insights (lab data);
    • use other online toolings (lab data);
    • use JS libraries to send data to your analytics (real user monitoring);
    • consult CrUX via PageSpeed Insights or Google data studio (real user monitoring).
  • Google already tracked Largest Contentful Paint (LCP) data way before it became part of PageSpeed Insights or Core Web Vitals. The latter happened on May 27th, while LCP data of real users is already being tracked since at least september 2019.

    In contrary to its predecessor, the First Meaningful Paint (FMP) metric, the LCP is telling a better story about the (possibly) most important element within the viewport. Possibly, as other content could still be more meaningful, but compaired to the FMP, it is clearer which element we are talking about when it comes to user engagement and tracking meaningful paints in general.

  • To give an idea of LCP, the following could impact the largest contentful paint:

    • Bad hosting or a heavy CMS, for example with quite a few plugins, are more likely to result in a higher server response time and thus TTFB metric. As a results, the browser will receive the HTML later in time, and thus the LCP will be shifted back as well;
    • Render as well as parse blocking resources will prevent the browser to parse and render the HTML containing the largest element late in time;
    • Slow resources, such as resources responsible for the largest elements but served with quite some network latency, will start later in the process;
    • Not serving responsive and thus smaller images, for example on product detail pages or hero images on article pages;
    • Client side rendering when this is delaying the layout and composition of the largest element within the viewport.
  • The timedelay between the (first) moment of user interaction and the moment the browser was able to respond to the user interaction, is encapsulated in the First Input Delay (or FID) metric. Responses within 100ms are perceived as fast by the human eye. Slower response times on user interactions might be experiences as an unnatural delay, leading to distrust or user frustration.

  • To give an idea of FID, the following could impact the largest contentful paint:

    • Render blocking JavaScript;
    • Fully page load with deferred JavaScript;
    • Long JavaScript tasks, such as ordering of search results or checkout calculations;
    • Long JavaScript execution time;
    • Large JavaScript bundles.
  • Lab tools such as Lighthouse (or PageSpeed Insights, as PageSpeed Insights uses Lighthouse engine) can’t measure FID since there are no end-users to calculate interactions. Lab tools could simulate an input, but every user has a different experience depending on their constraints and thus also have another perception of performance. This matters as different users might start interacting at different intervals, resulting in different outcomes.

    Instead of trying to simulate FID, these tools use a metric called Total Blocking Time (TBT) to predict potential FID bottlenecks.

  • You could say the bar for LCP already is quite high. You should enable users to see the largest element as soon as possible. A fast FCP is still important towards early user engagement and thus reducing the bounce rate. For example, it is better to have an FCP of 1 second and a LCP of 2.5, than an LCP of 2.3 and an LCP of 2.4.

    But Google might have chosen to not make FCP part of Core Web Vitals as the 'is it happening' aspect of use experience is already covered by the LCP metric.

  • Although not being part of Core Web Vitals, you still see FCP being displayed in the CrUX or field data, when:

    • your site or shop has enough visitors;
    • you are checking PageSpeed Insights or Google Search Console data.

    Reasons might be:

    • esthetics, 4 graphs is easier to divide over two columns than 3 graphs;
    • FCP still is the first noticeable metric after TTFB. TTFB is important, but FCP can still be pushed back depending on your theme or frontend code. As a results, FCP still gives you a good understanding of first user engagement. A white screen for a long period could increase bounce, so you might want to keep FCP (and still engaging with meaningful elements) as low as possible.


  • Probably not in such way. Obviously you could create very lean pages for Google's PageSpeed Insights testing, resulting in optimal "Lab data". However, it is the "Field data" that counts towards Google ranking and you can't hack the devices and network conditions of your visitors. You could implement best practices though, helping your overall score as well as real users.

    For example, you could choose to also serve lean pages to real visitors. This is more of a best practice than hacking though, as lean pages are good for real user experience, which eventually is the purpose of Core Web Vitals.

  • Some platforms require very specific knowledge and architecture, such as Magento. However, most hosting companies (especially within The Netherlands) are often doing a good job already. Due to CPU boundaries of smartphone devices, the frontend code as produced by platforms and developers play a bigger role. Moreover, Core Web Vitals really is about user experience instead of pagespeed, so it often is a matter of frontend coding.

    Hosting might not be the number one bottleneck when not passing Core Web Vitals yet, but as the TTFB is the starting point of all, hosting shouldn't be overlooked.

  • When Chromium could collect sufficient visitor data for your website or webshop, you can consult the free CrUX reporting to view historical TTFB data and detect changes and patterns. For example, when LCP patterns are the same as TTFB patterns, chances are that TTFB is the main bottleneck, impacting the LCP as well.

  • It is quite likely that the platform your company is using as a webshop or website solution is making a difference. For example, some content management solution might request all hosted resources, even unused resources on specific pages. Other platforms might always insert resources in the head without any performance strategy in mind, creating render blocking resources.

    As a result, some platforms will give your developers a harder time to pass the Core Web Vitals, but it is achievable, no matter the platform.

  • Although SaaS solutions are closed source and only allow for frontend changes using templates and other resources, it is still possible to optimize for Core Web Vitals. I once optimized a site where no server side changes could be made. In my case, this meant no HTTP/2 and no next-gen WebP images. Nevertheles, we scored a 95% on mobile and the website was passing the Core Web Vitals.

    However, most agencies creating templates, often create them in the same way. As a result, same mistakes can be seen within the average SaaS webshop, such as Lightspeed, Shopify, BigCommerce. This is where the role of in-depth developers or consultants such as myself are playing an important role.

  • Some of your performance and UX issues could be fixed using plugins. This might introduce new anti-patterns though. For example:

    • most plugins for inlining critical CSS often only include partial CSS, resulting in increased layout shifts;
    • most plugins for deferring JavaScript will result in deferred or delayed JavaScript execution. However, when JavaScript is responsible for the largest elements within the viewport, this may result in a poor LCP;
    • Even today, (JavaScript) resources are still bundled by plugins or even platform. This may result in decreased FID.

    Moreover, with every new plugin chances are that you are unwillingly and unwittingly increasing the server response time and thus TTFB, pushing back the LCP metric even further. So, when you do choose to fix issues with plugins, keep a close eye on the impact on real user experience and metrics.

  • As frontend architecture and thus HTML, CSS and JS are responsible for the work a browser has to do, this very same frontend code will have its influence on the metrics. As a result, your developers are the ones that will have to do the coding, where CRO or SEO specialist are often the ones pushing for optimization work.

    Obviously, one platform will allow more room for improvements than other platforms, but your developers should still be capable of optimizing for improved Core Web Vitals and conversion.

  • As always: it depends. Yes, Google engineers did come up with service workers, also part of PWA. At the same time, they always vouched for using only necessery JavaScript. Even Alex Russell, one of the founding fathers of PWA.

    In the Technical section, I re-used Google's description of factors that could impact the three Core Web Vitals metrics. In each metric, JavaScript will often play a role as well. Rendering and layout work as done by the browser can only be done after JavaScript has been downloaded, compiled, parsed and executed. Keep a close eye on the impact on real user experience and metrics when moving to Client Side Rendering (CSR) such as the average PWA.

    Rather have the full insights? Read about PWA and its technical implications.

Your webshop's instant report?

crux ttfb small
crux lcp small
crux fid small
crux device distribution small