Google truly lives by the saying, ‘Change is the only constant!’ No wonder, the search engine giant rolls out several algorithm updates each year. In 2021 alone, we’ve experienced six confirmed algorithm updates.
The search giant has always been searcher-centric. From penalizing keyword stuffing to making page load time a ranking factor, Google has always pushed SEOs for better UX. Introducing the Core Web Vitals is yet another attempt to uphold an awesome user experience.
Last year, Google announced that page experience signals, namely mobile-friendliness, safe browsing, HTTPS security, and a lack of intrusive interstitials, to be included in the SERP rankings. In the latter half of 2020, it added three new page experience signals (Core Web Vitals) to measure how users perceive the experience of interacting with a web page.
Here’s what Google has to say about introducing Core Web Vitals.
The update was slowly rolled out to all users as the Page Experience Update (June 25, 2021) and continued through August 2021. Recently, Google Search Central tweeted that they’ve finished rolling it out.
The Google web vitals threw SEO experts and website owners for a loop. The page experience update evaluates the speed, responsiveness, and visual stability of pages. Hence, it gives webmasters a sense of how people experience the website. It also offers specific and measurable data points that can help them improve the overall experience.
The Need for Core Web Vitals
Site speed metrics, in general, can be quite confusing. Tools like Google Analytics randomly select sessions when assessing site speed. So, since the data is sampled we don’t have the context to understand how many samples were included in the computation of this metric.
Further, the site speed metrics tend to change each time one uses the Google speed test on it.
Hence, Google identified three Core Web Vitals that are the focal points of measuring page experience. These metrics are a subset of the Web Vitals that will be a component of page experience.
Core Web Vitals qualify as critical ranking factors that merit consideration and attention. The official Google Search Central page shares how important this update is for winning a top spot in the SERPs.
Though most webmasters are aware of the significance of core web vitals, very few can optimize their site for these ranking factors. A recent study conducted by Screaming Frog revealed that only 12% of mobile and 13% of desktop results passed the Core Web Vitals assessment.
Also, Google’s studies have shown that for pages that meet the Core Web Vitals threshold visitors are 24% less likely to abandon the website.
Hence, it’s time to meet the Core Web Vitals!
In this post, we will share everything you would want to know about Core Web Vitals and how you can stay on top of this update.
Difference between Field Data and Lab Data?
PageSpeed Insights (PSI) is a useful tool that measures the performance of a page on both mobile and desktop devices. It offers valuable suggestions on how to make a page faster. PSI offers both lab and field data about a page.
Before we get into the details of the three new page experience signals, it’s critical to understand the difference between field and lab data.
Field Data
Field data is the ‘real’ browsing data of users (CrUX data or real user monitoring) accessing the website. The data is affected by the device and connection used when browsing.
Field data is more reliable in comparison to lab data because it is determined by genuine users interacting with a website under an assortment of conditions.
So, the lab data may look amazing because web developers usually work with modern devices and good internet connections. However, if their website is serving users situated in locations with spotty internet connections or use legacy systems, the field data will show a different and not-so-great picture.
When compared with lab data, field data proves to be a better indicator of how users experience a website.
Lab Data
It is collected in a controlled environment and uses predefined device and network specifications. Hence lab data is useful for reproducing and debugging possible performance issues.
This data will not capture insights related to real-world user experience/bottleneck; yet, it’s viable if one doesn’t have access to real user data.
Google’s Martin Splitt aptly summed up the difference between field and lab data at Google Webmaster Javascript SEO Meet, June 2020. Listen to his response in this video at 29:51.
Evolving Web Vitals
Though Google shared early this September that it has completed the page experience rollout, you can expect Core Web Vitals to evolve with time. Google has clearly stated that it will keep updating these metrics.
Core web vitals may be the best available signals for assessing page experience today. But these signals aren’t perfect and may/may not be completely relevant, considering the evolving nature of search. Hence, you can expect further improvements and updates in Core Web Vitals.
That being said, since CWV has a far-reaching impact on SEO, webmasters can expect the definitions and thresholds of the Core Web Vitals to be stable and updates predictable with prior notice.
At present, for delivering a great page experience, you need to focus on the quality signals, Core Web Vitals (LCP, FID, and CLS), and a few others like TTFB, TBT, and TTI.
We’ll be discussing the former 3 metrics in detail in the coming sections. But before that, let’s see what the latter 3 are about.
Time to First Byte (TTFB)
TTFB measures the responsiveness of a website. It is the time from when the user makes an HTTP request to receiving the first byte of data from the server.
This metric has three components –
- The time for sending the HTTP request
- The time taken by the server to process the request
- The time needed by the server to respond, that is sending the first byte of data to the user
This metric is a critical aspect of a site’s loading experience and is useful in spotting issues with LCP like slow server response times and render-blocking resources.
Time to Interactive (TTI)
TTI is a metric that measures the time from when the page starts loading to when it’s completely interactive, in terms of:
- Displaying useful content (measured using First Contentful Paint or FCP)
- Having most of the visible elements rendered
- Responding to user interactions within 50 milliseconds
User interaction heavily influences a page’s TTI. Therefore, though this metric can be measured in the field, it should only be used from a lab environment.
Total Blocking Time (TBT)
TBT (in milliseconds) measures the total time between First Contentful Paint (FCP) and TTI where the main thread is blocked long enough to block the response to user input.
TBT correlates with First Input Delay, hence a few reports use this metric instead of FID when testing in a lab environment (when real user interaction isn’t possible). Though TBT can be captured in the field, it is easily influenced by user interaction.
Hence, TBT doesn’t make a reliable metric to measure the time taken for a page to become responsive to user input.
Regardless of the update, Google has shared that the changes will be documented in their public Web Vitals Changelogs. Check this space for updates!
The Three Pillars of Page Experience
The Three Pillars of Page ExperienceGoogle has always considered these three factors as the pillars of page experience.
- Loading performance – It shows how fast content appears on the screen.
- Responsiveness – It shows how fast a page responds to user input.
- Visual stability – It relates to whether the content on a page moves around on the screen while loading.
Corresponding to these pillars, Google chose three critical metrics, namely:
- LCP or Largest Contentful Paint
- FID or First Input Delay
- CLS or Cumulative Layout Shift
Let’s look at each of these in detail!
Components of Core Web Vitals: LCP, FID, and CLS
So, what are Google Core Web Vitals?
The Google Core Web Vitals constitute three new page experience signals, namely Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). These were implemented in the SERP ranking system starting mid-June 2021.
Now, let’s look at each component of the Core Web Vitals in detail.
LCP
What is LCP?
It has always been a challenge for webmasters to measure the speed of main page content loading. LCP solves this issue!
LCP meaning Largest Contentful Paint is a user-centric metric that measures the perceived page load speed. The metric measures the time taken for getting the largest page element (a large text block, image, or video) visible within the viewport.
According to Google, for offering a good UX, LCP should occur within 2.5 seconds of when the page first begins loading.
LCP is closely associated with:
- <img> element
- <image> element inside an <svg> element
- The image inside a <video> element
- Heading tags
- Background image loaded with the URL() function or through CSS
- Tables
- Text blocks
- Lists.
How to See LCP?
When you access Google PageSpeed Insights, the LCP element will be specified in the Diagnostics section.
How to Optimize LCP?
To improve your LCP score, you should consider the following tactics.
- Consider preloading important resources. To avoid important resources (fonts, above-the-fold images or videos, and critical-path CSS or JavaScript) from being fetched last, prioritize them by using <link rel=”preload”>.
- Get rid of the unnecessary third-party scripts.
- Install a CDN for quicker transfer of assets (HTML pages, JS files, stylesheets, images, and videos). CDNs ensure that users never have to wait for network requests to faraway servers.
- Upgrade to a better web hosting service.
- Cache resources to improve site loading. If your HTML is static, caching can prevent it from being recreated on every request. Server-side caching stores a copy of the generated HTML on disk, thus minimizing resource consumption and reducing TTFB.
- Set up lazy loading of images.
- Do away with the huge page elements that take time to load, namely large images, carousels, banner images, and GIFs.
- Minify CSS and JS files. Even keeping all CSS and Javascript files in one place (instead of multiple files) will minimize the time taken to fully render the main content of the page.
FID
Whether you like it or not, the ‘don’t judge a book by its cover’ quote is hardly lived by. People make extreme levels of snap judgments. It’s no different with websites.
Several studies have proven that people form an opinion about web pages within 50 milliseconds. That’s the reason first impressions matter.
In the digital world, a great first impression can be the difference between a loyal customer and someone who abandons your site for good.
Speed and responsiveness are critical components of improving a site’s experience. First Input Delay helps webmasters measure the first impression users have of how fast a site loads – its interactivity and responsiveness.
First Input Delay is a web performance metric that tracks the time from which a user first interacts with a page to the time when the browser is able for processing event handlers in response to that interaction (interactivity or page responsiveness).
Simply put, this metric measures how a page responds to user activity or an action like a click on a link, a swipe, or a tap on a button. Let’s say a user clicks on a link that triggers a pop-up, FID measures how long it takes for the site to process and deliver that request.
Possible Interactions Considered in FID
- Clicking on a link or button
- Adding input text into a blank field
- Selecting a drop-down menu
- Clicking a checkbox
A low FID is a sign that the page is usable. An ideal Google FID score is 100 ms or less.
An important point to remember is that you cannot measure FID if there’s no user interaction. That’s because not all users interact with pages so the FID value may not be recorded.
This means:
- Google cannot predict the FID based on the data in the lab. It requires field data (from real users).
- The data is less controllable because it comes from users will all kinds of devices, using it in different ways and environments.
How to See FID?
As mentioned above, FID is a field metric. Here are two tools that can help you measure FID.
i) Chrome User Experience Report or CrUX
Google’s PSI (Google PageSpeed Insights) is a CrUX reporting tool that offers reports for all CWV, including FID.
ii) The Google Search Console Core Web Vitals Report
After accessing GSC, navigate to Enhancements > Core Web Vitals > Mobile and OPEN REPORT. Monitoring the CWV will give you the best insights into your site performance.
Are you wondering how to measure FID in the lab? Well, there’s a metric in lab tools we discussed earlier that can be a great alternative – The Total Blocking Time (TBT). However, it should be used only to reassure you that the FID fixes and optimizations are working.
How to Optimize FID?
Here’s how you can improve your FID score.
-> Break down long tasks like long-running code into smaller and asynchronous tasks. Users often find the UI unresponsive during JavaScript execution periods.
This is a sign of a potential JS bloat.Splitting up these long tasks will reduce the input delay on the site.
-> Minimize JavaScript because it’s challenging for users to interact with the website when JS is running. This will speed up the how browser responds to user interactions.
-> Get rid of the non-essential third-party scripts like heat maps, tags, and analytics that need to load before a user can interact with the website.
At times, the third-party scripts pre-empt first-party ones as per the priority and bandwidth on the main thread. This hugely delays the time taken by a page to be interaction-ready. Hence, it’s wise to remove any unnecessary third-party scripts.
-> Implement browser caching. This stores certain elements in a user’s browser, eliminating the need to reload them every time.
CLS
You must have surely come across a website where you are just about to click on a link and before you realize it, the layout shifts and in comes an ad. So, instead of clicking on the link, you’ve clicked on the ad. That’s called layout shift and it negatively affects the page experience.
The possible causes of poor CLS are:
-> Images without dimensions cause reflow and re-layout. Hence, it’s wise to include ‘width’ and ‘height’ size attributes on images and videos so that the browser knows the correct amount of space that needs to be allocated.
-> Ads, embeds, and iframes without dimensions. Most ad networks and publishers support dynamic ad sizes, causing layout shifts and suboptimal UX.
-> Injecting dynamic content with JavaScript can cause layout shifts. For instance, a ‘Sign up to our newsletter’ or ‘Install our App’ banner can shift the rest of the content on the page. Avoid inserting such content, unless in response to user interaction.
-> Applying fonts or styles late in the load can cause layout shifts via FOUT or FOIT.
- The fallback font gets swapped with a new font (FOUT – flash of unstyled text).
- It displays ‘invisible’ text until a new font is rendered (FOIT – flash of invisible text).
It’s surprising to see that given the significance of UX in the present age, so many websites are yet to stabilize their layout. That’s why Google came up with Cumulative Layout Shift or CLS.
CLS is a page experience metric used to quantify the impact of layout shifts on a website. It measures the visual stability of a page in the lab and field. In plain words, it tells Google the number of elements that have moved/ shifted/ appeared/ disappeared as the page loads.
As a webmaster, it’s critical to calculate CLS based on real user interactions (not just lab data) to get a realistic picture. For instance, ads don’t load on the staging site, so lab data will not reflect real-life experiences.
A low CLS score ensures that the page offers a delightful experience. In fact, Google considers a CLS score of 0.1 or less to be good.
Here are a few ways to improve your CLS score.
-> Use set size attribute dimensions for any media (images, GIFs, etc) so that the user’s browser knows how much space they’ll take up and won’t suddenly change the dimensions.
-> Put all ads in reserved spaces so that they don’t appear suddenly, causing content to shift. Simply put, style the element before the ad tag library starts loading.
Also, if your ad is placed in the content flow, reserve the slot size to prevent shifts.
-> Avoid pop-ups or banners that cause the screen layout to shift when the site is first loading.
-> Add new UI elements below the fold.
Thresholds for GOOD/NEEDS IMPROVEMENT/POOR
Here is a compiled table of the thresholds for web vitals metrics.
Tools to Measure Web Vitals
Monitoring the Core Web Vitals guides the quality signals that ensure a great page experience for users. Here are a few popular tools that support the measurement of Core Web Vitals.
Let’s look at each of these tools in detail.
1. Google Search Console
GSC’s Core Web Vitals report allows SEOs to learn how most of the web pages are performing with respect to CWV. The free tool accesses real field data from CrUX to spot the pages that need more attention than the rest.
In the GSC report, the URL performance is grouped by their status (good, needs improvement, or poor) and metric type (LCP, FID, and CLS). Once you’ve identified the issues, use PageSpeed Insights to explore opportunities and get recommendations for specific optimization.
That brings us to the next tool – PSI!
2. PageSpeed Insights
PSI is one of the most important and indispensable tools when it comes to gauging your site’s CWV health. It is powered by CrUX and Lighthouse (upgraded to use LightHouse 6.0!). As a result, PSI now supports all Web Vitals (LCP, FID, CLS, FCP, TTI, and TBT) in lab and field sections on mobiles and desktops.
The tool works on a per-page basis to offer actionable recommendations to improve page experience for their audience.
3. Google Lighthouse
Lighthouse was originally built by Google as a tool for auditing PWAs. However, it has evolved as a great tool to monitor page performance.
The tool allows SEOs to audit and gauge the website in four areas, namely performance, accessibility, best practices, and SEO. It measures most of the lab UX metrics like LCP, CLS, TTI, and TBT.
It is quite similar to PSI (which is based on Lighthouse) in terms of offering specific recommendations on how to improve the experience. The report checks your Google website score and sets the scores needed to offer the best page experience.
When testing your website using this tool, make sure you check the Lighthouse Scoring Calculator. It shows the weight of different metrics.4. Chrome DevTools
4. Chrome DevToolsDevTools is built directly into the Chrome browser and helps you detect unexpected layout issues. The tool is useful when you need to spot and fix instability issues, thus contributing to CLS.
To open Chrome DevTools, simply right-click and select ‘Inspect.’
The tool’s performance analysis shows all the Core Web Vitals marked clearly with colors like green for good results and red for a page that’s not properly optimized.
5. Chrome UX Report (CrUX)
The CrUX is more of a public dataset that holds real user experience data from millions of websites. It measures the field versions of the Core Web Vitals. It offers excellent grained performance data, offering a quick way to access the CWV.
Chrome UX report is referred to as Real User Monitoring or RUM because it allows SEOs to analyze site performance only based on how customers interact with it.
6. Web Vitals Extension
This handy Chrome extension assesses LCP, FID, and CLS in real-time for Google Chrome on desktop. It spots issues during the development workflow.
The tool is especially useful for developers who may need to analyze and debug the improvements they’ve implemented.
7. SEMrush Site Audit
As you may be aware, SEMrush is an all-in-one tool for the site audit. However, recently it added the measurement of Core Web Vitals to their Site Audit tool.
So, you can use SEMrush Site Audit to check the CWV report in Overview under Thematic Reports. SEMrush uses data from LIghthouse to report metrics like LCP, TBT, and CLS.
8. SpeedVitals
It is a free tool that lets you perform the page experience test on 12 devices and 9 locations. It offers features like Layout Shift Visualizer, platform-specific optimization tips, Waterfall Chart, and Field Data Chart that measure metrics like TTFB, CLP, CLS, TBT, TCP, and FID.
Case Study – Smashing Magazine
Smashing Magazine, an ebook publisher offering editorial content and professional resources, improved their page experience using Core Web Vitals. Performance and UX are central to this firm. However, when they measured their CWV scores, they were surprised to learn that most of their real visitors aren’t getting the experience they aim to deliver.
Their Google Search Console shared a long trail of ‘needs improvement’ notifications.
The firm regularly monitored its Google website score and used the data to fix several performance issues. Thus, they were able to identify specific opportunities and improve everyone’s experience on the website.
Check out the complete case study on Smashing Magazine’s page to understand how they leveraged the Core Web Vitals to improve their page experience.
Case Study – Vodafone
The leading telecommunications company improved its LCP by 31% and had 8% more sales. Vodafone runs A/B testing for Web Vitals on their landing page. Further, they made the following changes to optimize their pages.
- Worked on less render-blocking JavaScript by moving the rendering logic for a widget from client to server-side.
- Optimized images. They resized the hero image and optimized SVG images to avoid loading images that weren’t yet visible in the viewport
The result was:
- An 8% increase in sales
- An improvement of 15% in the lead to visit rate (the number of visitors who got converted into a lead versus the total number of visitors)
- An improvement of 11% in the cart to visit rate (the number of visitors who visited their cart versus the total number of visitors)
You can see the complete case study here.
Case Study – Yelp
Yelp recently added new features to allow advertisers to control their ad campaigns better. However, these features heavily compromised the performance of their website. The speed with page load times for their site increased from 3 seconds to 6 seconds.
Their team measured and monitored the Core Web Vitals and decided to target two specific metrics, namely FCP and TTI metrics. After four months of focused effort, they not just improved their CWV scores but also boosted their conversion metrics.
Here are the key results:
- Reduced the P75 FCPs from 3.25s to 1.80s – a 45% improvement
- Reduced p75 YPCs from 4.31s to 3.21s – a 25% improvement
- Up to 15% lift in conversion rate
Here are a few graphs that show their progress over time.
The website now experiences substantially faster loading times. If you want to get deeper into the Yelp case study of Core Web Vitals, here’s the link.
Facts about Core Web Vitals
Fact 1
The metrics are judged at the 75th percentile of users. So, say 65% of the users are in the ‘good’ category and 10% are in the ‘need improvement’ category, the page will be assessed as ‘need improvement.’
Fact 2
Google uses anonymized data from real users and makes it available in CrUX. This data is used to measure the metrics for search rankings.
Fact 3
The metrics will be gauged for each page on the website. However, Core Web Vitals are not limited to the current components. If there isn’t enough data available, Google confirmed that signals from sections or the overall website will be used.
Fact 4
The metrics may change over time, including the thresholds. Google will include or exclude some other in the future which they may use to evaluate pages over a longer time.
The weight of the Core Web Vitals may also change in importance. For instance, according to Lighthouse version 6 and 7, the weight of the metrics is –
- FID – 25% (via the lab metric proxy Total Blocking Time)
- LCP – 25%
- CLS – 5%
And as per Lighthouse version 8, the weight is –
- FID – 30%
- LCP – 25%
- CLS – 15%
Fact 5
Single-page applications or SPA (Gmail, Google Maps, Airbnb, Netflix, and others) do not measure a couple of metrics through the page transitions. For instance, they don’t measure FID and LCP.
Fact 6
AMP is being taken off as a requirement from the Top Stories feature on mobile after the introduction of Core Web Vitals. New stories don’t have data related to speed metrics. In such a case, metrics from a larger category page or entire domain may be used.
Fact 7
Early this year, Google completely switched to mobile-first indexing. Core Web Vitals are split between mobile and desktop but only mobile signals are referred to for ranking pages.
Fact 8
Core Web Vitals remain one element of page experience or full ranking criteria. Hence, matching search intent will always beat this experience metric. Google has explicitly shared that the pages that match search intent will rank higher than the ones working to improve their CWV metrics.
Fact 9
Lighthouse doesn’t just measure Core Web Vitals. It also measures speed index, time to interaction, first CPU idle, and total blocking time.
Fact 10
The field data used is based on the past 28 days of data available in the CrUX report. Hence, it can take some time for the updates to reflect in the Google website score.
Conclusion
User experience has always been central for Google. Hence, the search mammoth has been stirring the SEO community with newer algorithms and updates. However, these updates have helped SEOs and webmasters build awesome websites.
With the rollout of the Core Web Vitals, Google page experience will now play a bigger role in helping you build even better websites and offer mind-blowing experiences to customers.
Frequently Asked Questions (FAQs)
FAQ #1: Does Google mean that all my web pages should hit the Core Web Vitals thresholds?
Google recommends that SEOs use these thresholds as a guidepost for ensuring optimal page experience. Core Web Vitals thresholds are assessed at the per-page level. So, when assessing the pages, you may find a few pages are above and a few below these thresholds.
Working on optimizing more of your web pages will improve the experience for your site visitors. However, in the long-term, Google believes that working towards a shared set of UX metrics and thresholds will be critical to sustaining a healthy web ecosystem.
FAQ #2: How do I prepare Core Web Vitals for Google?
To prepare for Core Web Vitals, it’s recommended that you analyze each URL as they may show a different score. Each URL has a unique layout, content blocks, and elements. Hence, it’s wise to follow the preliminary steps shared below:
- Make sure the imaged are scaled to the correct placement sizing
- Compress large files
- Lazy load the static content
- Apply a CDN to the hosting platform
- Get rid of unnecessary render-blocking resources
- Serve images only in next-gen formats
- Remove any JavaScript that isn’t in use
- Use the tools shared above to monitor the Google page experience metrics and get recommendations to optimize each of them.
For more recommendations on how to improve your scores visit this page or visit the Search Console Help Center.
FAQ #3: Will the AMP pages help my website survive in Google Core Web Vitals update?
AMP is an effective way to boost page speed; however, privacy is a huge concern, negatively affecting UX. Also, Google’s control issues can be challenging for a few developers and webmasters.
Hence, though AMP pages inherently earn optimal Core Web Vital scores, these drawbacks make implementation counterproductive.
AMP will not disappear completely but certainly may not be required in 2021 for optimized CWV scores. If you choose not to apply AMP, make sure your pages are optimized for LCP, FID, and CLS.
FAQ #4: My website pages are fast. Why does Search Console show warnings on the Search Console Core Web Vitals report?
How a page loads and is experienced by a visitor depends on several factors like devices, network connections, locations, and more. In certain conditions, some users may have a great experience but this doesn’t mean the experience will be the same across locations and devices.
Core Web Vitals considers the full body of user visits when measuring the Google page experience. Its thresholds are assessed at the 75th percentile across the body of users. The Google Search Console CWV report helps report this data.
Further, your definition of ‘fast’ may be confined to speed. But Core Web Vitals looks at more than speed. For instance, the CLS metric monitors the layout shift that may negatively impact UX.
Hence, many factors need to be considered when using the GSC Core Web Vitals report as the basis of your optimization decisions.
FAQ #5: My website is responsive but my CWV score is low. How’s that?
The Page Experience signal measures various aspects of how visitors perceive the experience of interacting with a page. Core Web Vitals is just one aspect of this along with mobile-friendliness. These two do not overlap but are additive while offering a holistic picture of the Google page experience.
Shahid Abbasi is a Senior SEO and Content Marketing Analyst at Growfusely, a SaaS content marketing agency specializing in content and data-driven SEO.
