SEO Fundamentals: Core Web Vitals

SEO Fundamentals: Core Web Vitals

Maybe you’ve seen core web vitals around – whether in Google Search Console or elsewhere, but what does it mean? Core Web Vitals play a crucial role in determining the overall user experience of your website, which in turn affects your search engine rankings. That’s great, but what are the metrics, what do the metrics mean, and how do you measure them?

This post is going to get fairly technical. We’re going to look to use built in browser tools to gauge the various different elements of core web vitals. Are there better ways to do this? Yep – you can head right into Google Search Console (GSC) and look there, but its fun to geek out and really understand what these measurements are under the hood. Let’s get to it!

What Are Core Web Vitals?

Let’s start by breaking down what exactly Core Web Vitals are. These metrics, which include loading, interactivity, and visual stability, measure the user experience on your website. Understanding the importance of Core Web Vitals is crucial because they directly impact search engine rankings and user satisfaction.

Core Web Vitals Breakdown

Understanding the concept of Core Web Vitals is crucial for optimizing your website’s performance and user experience. To break it down further, here are six key aspects you need to know:

• Largest Contentful Paint (LCP): This measures how long it takes for the largest element on your webpage to load. Aim for an LCP of under 2.5 seconds for a good user experience.
• First Input Delay (FID): FID measures the time it takes for a webpage to respond to a user’s first interaction, such as clicking a button. A low FID score indicates a responsive website.
• Cumulative Layout Shift (CLS): CLS measures the visual stability of a webpage, focusing on the unexpected shifting of elements during loading. A lower CLS score means a more stable and user-friendly experience.
• Interaction to Next Paint (INP): Replacing FID in March 2024, INP measures the time it takes for the browser to visually respond to any user interaction, such as clicking, typing, or scrolling. A low INP score indicates a consistently responsive website throughout a user’s engagement.

Ok, let’s get into each of these a little more. We have the core 3 that have been in place for a while, and now we have INP coming on the scene and taking a leading role starting in March of this year.

Importance of Core Web Vitals

First though, let’s talk about why these metrics are important. Have you ever visited a site, read a bit of the site, went to click…and the button moved? 

If your site is slow or obnoxious (like a button that dodges clicks), it’s invariably going to drive down user engagement. Frustration = I’m not staying on your page.

Improving your website’s performance and user experience is crucial, and that’s where Core Web Vitals come in. Core Web Vitals is a reflection of performance and a good indication of the user experience. If the users are frustrated with your site, engagement will be lacking, dwell time will be low, and bounce rate will be high. These are all clear indications that your content is not meeting a user’s needs and satisfying search intent. As such, it’s critical to get your site performing as well as possible.

It’s kind of a double whammy – if your Core Web Vitals are off, Google will penalize you. Core Web Vitals are a direct ranking factor. What’s worse, here, however, is that if your site performance is poor, users are going to bounce. User engagement is another signal to Google. Bad perf plus users not sticking around means your page/site is going to fall even faster in SERP.

Now, let’s get into the specifics.

How to Start a Performance Recording in Chrome Dev Tools

This is where it gets a little geeky the post digs in on how to use Chrome Dev Tools to try and measure core web vitals. This is not the easiest way – but it is fun. This is a great way to dig further into the nuts and bolts and try to really understand what is having the biggest impact on your site’s performance.

This exact same process is followed regardless of which Core Web Vital is being measured. Follow these simple steps to get the dev tools open and a recording started.

1. Open the webpage you want to analyze.

In my case, I am opening https://sc.scomurr.com/seo-fundamentals-featured-snippets/

2. Open the Developer Tools:

• Windows/Linux: Press Ctrl+Shift+I.
• Mac: Press Cmd+Option+I.
• Or, hit the 3 dots in the upper right corner and browse to Dev Tools
• Or, hit F12 (at least on Windows)

I’m also going to configure my dev tools to present my browser as a mobile device. It’s always best to optimize for mobile first.

3. Navigate to the “Performance” tab.

4. Click the “Record” button (circled icon) to start recording a performance trace.

5. Reload the webpage (or click the “Reload” button in the toolbar).

With the dev tools open, if you right mouse click on the reload button you get a few options.

• Normal Reload: This is the standard page reload, similar to clicking the reload button or pressing F5. It will re-fetch resources, but might use cached versions if they are considered fresh.
• Hard Reload: This option forces the browser to re-fetch all resources from the server, ignoring any cached content. It’s more thorough than a normal reload and is useful for seeing changes that might be affected by caching.
• Empty Cache and Hard Reload: This option clears the browser’s cache for the page and then performs a hard reload. It ensures that all resources are fetched anew from the server, which can be helpful for developers when testing changes or debugging caching issues.

For this, I always go with Empty Cache and Hard Reload. This represents worst case scenario – optimize for for the worst and it’ll be a benefit across the board. Keep in mind that the cache in question here is the local cache – this does not necessarily overpower non client side caching.

6. Wait for the page to load fully.

<insert Jeopardy song here>

7. Click the “Stop” button (red square icon) to stop recording.

Now that you have a recording, we can dig in for LCP, FID, CLS, INP or any other TLA (three letter acronym) we want to throw at it.

Largest Contentful Paint (LCP)

Now let’s talk about Largest Contentful Paint (LCP). LCP refers to the time it takes for the largest content element on your webpage to load and become visible to the user. This metric is crucial because it directly impacts user experience and can affect your website’s ranking on search engine results pages. To measure and optimize LCP, you need to focus on improving server response times, optimizing images and videos, and minimizing render-blocking resources.

What Is LCP?

In general, the Largest Contentful Paint (LCP) refers to the largest element (image or text block) visible within the user’s viewport that finishes loading. It is considered a key metric for measuring webpage performance because it approximates the point when the main content of the page has likely loaded and becomes available to the user.

• LCP measures the time it takes for the largest image, video, or block-level text element to load on the page.
• It indicates when the most important content becomes available to users, allowing them to start engaging with your website.
• A good LCP score is crucial for providing a positive user experience, as a slow-loading largest element can frustrate users and lead to higher bounce rates.

Here’s how the LCP element is determined:

1. Candidate Identification: The browser identifies all potential LCP candidates, which are typically the largest images, video thumbnails, background images, and text elements like headings and paragraphs.
2. Size Comparison: The browser compares the size of each candidate within the viewport. The element with the largest area within the viewport becomes the LCP candidate.
3. Paint Completion: The browser monitors the loading progress of the LCP candidate. Once the element finishes loading and is fully painted within the viewport, the current time is recorded as the LCP value.

Therefore, the LCP element can be different for different users depending on their screen size and the specific content displayed within their viewport.

How to Measure LCP with Chrome Dev Tools

Google considers an LCP measurement of under 2.5 seconds as good, so we always aim to achieve this benchmark.

I want to get to the nitty gritty and really determine what might be impacting my page performance, so that’s why we’re hopping into the Chrome Dev Tools. It turns out that my post on Featured Snippets actually has a lower LCP score than I would like. As such, let’s break it down with the built in browser tools and see if there is anything I can do to solve the performance issue.

1. Follow the instructions above to create a recording

2. Locate the LCP measurement:

• In the Performance panel, look for the “Timings” track.
• Within the Timings track, you should see an entry labelled “Largest Contentful Paint” (LCP).
• The LCP entry will have a timestamp indicating when the LCP occurred.

Here, we can see that LCP was 1.8 seconds. We’re aiming for < 2.5s, so we’re in the ballpark. It’s always good to run the test multiple times, and reconfigure for different mobile as well as test desktop.

3. What’s causing the slowness:

• To identify the specific element that triggered the LCP, hover over the LCP entry in the Timings track.
• A preview of the element will appear in the Performance panel, and the element itself will be highlighted on the webpage.

This screenshot is a little hard to decipher, so let’s walk it. First with a click on LCP within the timing swim lane it brings up the summary in the middle of the screen. From there, we see the timing (2.8s in this case – really bad) and it tells you the related node. In this case, it’s a <p>. By hovering over the related node, it highlights the content in the browser on the left. You can see that it’s the first text content of the post because it is highlighted.

Additional Tips:

• You can zoom in on the Timings track to get a closer look at the LCP event and other performance metrics.
• You can also export the performance recording as a JSON file for further analysis.

Here we can see that it’s the first paragraph of the post that’s getting flagged for being slow. What’s interesting is that I am testing both with the ads being displayed as well as without using a local ad blocker. I get a much lower LCP score each time I allow the ads to load. This is where I need to consider whether or not I want to allow the banner ad at the top of the page if it is going to impact overall performance.

To Do: Dig into making sure Google AdSense’s auto ads are loading async and there are no other blocking elements. Since my LCP is staying the same (it’s always paragraph 1), it is a little odd that the banner ad is impacting the LCP measurement. More to do here!

How to Optimize LCP

Here are some general tips and tricks to optimize for LCP. Unfortunately, every site is different, every page is different, and each situation is unique.

Content and Code:

• Prioritize above-the-fold content: Make sure the most important elements users see first are lightweight and load quickly.
• Minimize large images and videos: Optimize their size and consider lazy loading for content below the fold. I pretty much only use .webp images at this point.
• Reduce render-blocking scripts: Defer non-critical JavaScript to avoid stalling content rendering.
• Minify HTML, CSS, and JavaScript: Compress code for efficient transfer and loading.

Resource Load:

• Preload key resources: Fonts, scripts, and critical images can be preloaded for a head start.
• Optimize font delivery: Use web fonts strategically and consider font display options.
• Leverage browser caching: Cache static resources like images and scripts for faster repeat visits.
• Minimize HTTP requests: Combine resources and optimize image formats to reduce roundtrips to the server.

Technical Tweaks:

• Implement asynchronous ad loading: Don’t let ads delay your main content. This is probably what is getting me – I intend on doing a blog post specifically around optimizing for Google AdSense in the future.
• Consider server-side rendering: Offload some rendering to the server for faster initial page load.
• Utilize a Content Delivery Network (CDN): Deliver content from geographically closer servers for quicker reach. I use Cloudflare for this – my site traffic is low enough that I still fall within the free tier.
• Monitor and analyze performance: Tools like Google PageSpeed Insights and Lighthouse offer valuable insights and optimization suggestions.

Bonus Tip:

• Test and iterate: Every website is unique, so experiment with different configurations and find the sweet spot for your specific content and audience.

Iterate, and then iterate some more. Find a way to get that LCP to be consistently < 2.5s, and you will make Google happy.

First Input Delay (FID)

Now let’s talk about First Input Delay (FID). FID measures the time it takes for a user to interact with your website after it has loaded. It is important because a long FID can lead to a frustrating user experience, causing visitors to leave your site. To measure FID, you can use tools like Google’s PageSpeed Insights or Chrome User Experience Report. To optimize FID, you should focus on improving server response times, minimizing JavaScript execution, and optimizing third-party scripts.

What Is FID?

First Input Delay (FID) measures the time it takes for a webpage to respond to a user’s first interaction, like clicking a button, tapping a link, or typing in a form. Essentially, it captures how quickly the page reacts to the user’s initial engagement.

First Input Delay (FID) is focused on the responsiveness of a page when a user first interacts with it.

Interactions:

• Click
• Tap
• Key Press

It’s not about how quickly the page loads, but rather how quickly the page can respond to a user’s interaction once it’s interactive. This responsiveness is often impacted by the amount and complexity of JavaScript running on the page. If the browser’s main thread is busy processing JavaScript, it can delay the page’s response to user input, leading to a higher FID.

Why is FID important?

FID is a crucial metric for website performance because it directly impacts user experience. A fast FID provides a sense of responsiveness and keeps users engaged. Conversely, a slow FID can lead to frustration, disengagement, and ultimately, higher bounce rates. I know if I have to wait…I’m probably not. If I click and we don’t go anywhere…well…I go somewhere else.

How is FID calculated?

The browser records the time between a user’s first interaction and the browser’s “time to first meaningful paint,” which occurs when the browser judges that the content has changed to the point where it is visually impactful for the user. This includes rendering dynamic elements like responses to clicks or changes in page layout.

Good vs. Bad FID scores:

• Good: Less than 100 milliseconds provides a smooth and responsive experience.
• Moderate: 100-300 milliseconds can still be acceptable, but some users might notice a slight delay.
• Poor: Above 300 milliseconds leads to frustration and significantly impacts user experience.

Now, let’s look at how to use the Chrome Dev tools just like we did with LCP to determine FID.

How to Measure FID with Chrome Dev Tools

You can measure First Input Delay (FID) using Chrome Dev Tools, although it’s a bit indirect. FID measures the time from when a user first interacts with your site (i.e., when they click a link, tap on a button, etc.) to the time when the browser is actually able to begin processing event handlers in response to that interaction. Chrome Dev Tools do not give you the FID measurement like they do for LCP – we’ll have to do a little math.

Since FID is an event-based metric that requires real user interaction, it cannot be simulated or measured in a lab environment like with Lighthouse or other automated tools (not really). However, you can get an idea of FID by looking at similar metrics in Chrome Dev Tools. Let’s do it!

1. Follow the instructions above to create a recording.

• The only difference here is that you do need to click on something or press a key during the recording. I chose to click one of the links in the table of contents within the Featured Snippets post.

2. Find FID

• Hit Ctrl-F and search for ‘FID’

But, is this the true measurement we want to look at? Dev tools takes micro screenshots, and we can use those to tell a little more about the interaction.

This is the spot!

3. Calculating the Measurement

• Grab the time stamps from the performance window and just do a little subtraction!
• Compare your FID score to the following benchmarks:
  • Good: Less than 100 milliseconds (smooth and responsive experience)
  • Moderate: 100-300 milliseconds (acceptable, but slight delay)
  • Poor: Above 300 milliseconds (frustrating and impacts user experience)

In this case, the FID for the Featured Snippets posts seems to be around 35ms which is great!

Additional Tips:

• You can repeat the recording process with different interactions to analyze FID for various user actions.
• Iterate and measure for desktop vs. mobile.
• Measure with and without ads.

How to Optimize FID

Several factors can affect FID, including server response times, resource loading, JavaScript execution, and rendering. To optimize FID, you can focus on:

• Minimizing server response times.
• Preloading critical resources.
• Optimizing JavaScript code to avoid blocking the main thread.
• Reducing layout shifts.

By focusing on these aspects, you can ensure your website responds quickly to user interactions, providing a more positive and engaging experience. There’s more that can be done, but this is a great place to start!

Cumulative Layout Shift (CLS)

Let’s now talk about Cumulative Layout Shift (CLS). CLS refers to the unexpected shifting of webpage elements as it loads, causing a poor user experience. It is crucial to address CLS because it affects your site’s performance and user engagement. This one is a pet peeve of mine (as demo’ed by the GIF up top with the button moving). When I run into this, I run away.

What Is CLS?

Cumulative Layout Shift (CLS) measures how much a webpage unexpectedly shifts its layout while a user is viewing it. Imagine you’re reading an article online, and suddenly the content jumps down because an ad loads, or you tap a button but end up clicking something else because the layout shifted beneath your finger. These frustrating experiences are what CLS aims to quantify.

It’s effectively:

• Give me 5
• Up high
• On the side
• On the other side
• Down low…

If it’s too slow, you get a swing and a miss. If the site is performant with no CLS issues then there’s just a really nice down low “high five”, and you, as the reader, are happy.

Here’s a breakdown:

Focus: Visual stability of the page during interaction.

What it measures: The total amount of unexpected layout shifts that occur throughout the entire time a user is on the page.

Types of shifts: Any visible change in the position of an element, including:

• Images loading
• Ads appearing
• Content dynamically updating
• Fonts changing

Why is CLS important?

• A stable layout fosters a positive user experience, making users feel in control and preventing frustration.
• Google considers CLS as one of the Core Web Vitals, meaning it can impact your website’s search ranking.
• A high CLS can lead to increased bounce rates and decreased engagement.

How is CLS calculated?

CLS takes into account both the magnitude and frequency of layout shifts:

• Distance fraction: How much an element moves relative to the viewport size.
• Impact fraction: How likely a user is to be visually impacted by the shift.

These factors are combined to create a score ranging from 0 (no shift) to 1 (maximum shift).

Good vs. Bad CLS scores:

• Good: Less than 0.1 – Minimal shifting, excellent user experience.
• Moderate: 0.1 – 0.25 – Some noticeable shifts, but still acceptable for most users.
• Poor: Above 0.25 – Frequent and/or large shifts, significantly impacting user experience.

Let’s explore how to use Chrome Dev Tools to measure a website’s CLS and aim for a more stable and user-friendly web experience.

How to Measure CLS with Chrome Dev Tools

Measuring CLS in Chrome Dev Tools is super straight forward – the score is essentially given to you in the browsers. It’s just a matter of finding it!

1. Follow the instructions above to open Chrome Dev Tools and create a recording.

2. Locate Layout Shifts in the Performance Window

3. Find the CLS Score

• Within the Summary section of the page, the CLS score will be displayed. Simply select the CLS event from the swim lane furthest to the right and you have the cumulative score!

Pretty simple! Here, you can see there were only 2 layout shifts and they happened very fast. This content on the page is essentially static (this was recorded with no ads).

I re-recorded with ads enabled and then scrolled up and down the page. Here was the result from that test:

Despite this score floating into the mid range of acceptability, this was a pretty aggressive test where I forced all of the shifts as fast as I could by scrolling up and down very quickly a few times. I’m happy with this!

How to Optimize CLS

Here are a few tips for optimizing Core Web Vitals related to CLS (Cumulative Layout Shift). The goal here is just to prevent the screen from jumping around if and whenever possible.

• Minimize layout shifts, especially late in the page load process. Avoid inserting or changing elements in a way that causes existing content to shift. Use CSS and JavaScript to set up page layout before rendering content.
• Size images properly and set height/width attributes so space is reserved for them as the page loads. Avoid images loading later and causing layout jumps.
• Avoid large changes in font size or element dimensions after initial render. This can cause content to suddenly shift.
• Use flexbox, grid, and other modern layout methods to create more predictable and stable layouts. Avoid floats and other older techniques.
• Load fonts asynchronously to avoid FOIT (flash of invisible text) and layout shifts when fonts load.
• Set min-height on containers/components so more space is reserved upfront if more content loads in later.
• Use server rendering frameworks to serve fuller HTML so less has to change and shift around on the client side.
• Use skeleton screens and placeholders to reserve space for loading components, avoid components suddenly appearing and forcing layout issues.

The key focus areas are reserving space properly for page elements so content doesn’t jump around, avoiding inserting additional elements that force shifts, and minimizing font and component dimension changes. This will lead to the lowest CLS score and optimization for core web vitals. And, most importantly, it will lead to a happier reader.

Interaction to Next Paint (INP)

So, what’s the difference between FID and INP? FID is really just focused on the very first interaction on a website, and it really only measures the time between the interaction and when the browser processes the interaction. It’s limited in that it doesn’t really consider event handler code or DOM re-re-rendering. INP seeks to address that by creating a measurement that more accurately assesses the impact of the interaction on the user experience.

What is INP

INP, or Interaction to Next Paint, is a web performance metric that measures the responsiveness of a webpage. It specifically captures the delay between a user’s interaction with a page (like clicking a link or button, typing in a text box, etc.) and the next visual update or “paint” of the page in response to that interaction.

Here’s a closer look at INP:

1. Focus: INP measures the responsiveness of a web page during user interactions. It’s all about how quickly a page can visually respond to an input action.
2. What it measures: INP captures the time it takes for the browser to start processing the result of the user’s interaction and to reflect that on the screen. This includes time for the browser to process event handlers, execute any JavaScript triggered by the interaction, and render any changes to the webpage.
   • It’s the full interaction – not just the click -> handler. It’s the click -> handler -> processing -> rendering (paint…as in the next paint…as in the name)
3. Types of Interactions Measured: This metric is concerned with various user interactions such as clicks, taps, and key presses. It measures the latency for these interactions.
4. Why is INP important?:
   • A low INP (quick response) enhances the user experience, making the site feel more responsive and interactive.
   • Slow INP can lead to a perception of a sluggish or unresponsive page, impacting user satisfaction.
   • INP is a critical factor in overall web performance, and improving it can lead to better user engagement and retention.
5. How is INP calculated?:
   • INP is measured in milliseconds (ms).
   • INP is not just about the first interaction – it’s the worst case scenario for all interactions on the page during the page’s lifecycle.
   • It typically measures the longest interaction delay that a user experiences within the 98th percentile of all interaction latencies.
6. Good vs. Bad INP scores:
   • Good: Typically, an INP of 100ms or less is considered good, indicating that the site responds quickly to user inputs.
   • Poor: An INP longer than 300ms is often considered poor, as it indicates a noticeable delay in response to user interactions.

How to Measure INP with Chrome Dev Tools

1. Create a recording just as above.

• Again, we’re measuring interactions, so, an interaction or two will be required during the recording.

2. Identify the event you want to assess

For the interaction, I once again just clicked on a link within the table of contents.

The click is actually represented as two separate interactions within Chrome Dev tools. There’s a mouse down and then there’s a mouse up event. Should we measure INP starting from mouse down or should we start measuring it from mouse up? It somewhat depends, and Google is actually going to sample this over a bunch of interactions with your site as they calculate core web vitals and start to factor performance into ranking.

Next question, should total time end at the end of the animation? In this case, when the link in the table of contents is clicked, the site scrolls to the spot in the page where the link content exists. For my site, because the scroll is graceful, it takes about 200 MS from the time of mouse down to the animation being completed. That’s actually pretty good considering that I want this scroll to be graceful. In this case, we wouldn’t really want to measure all the way from mouse down all the way to the end of the animation as this is not going to accurately reflect what my INP score is.

How to Optimize for INP

Optimizing a site for INP (Interaction to Next Paint) involves several steps, starting with identifying any issues and then tackling it from both code and rendering perspectives. Here’s a breakdown:

1. Identify the Problem:

• Field Data: Use tools like Chrome’s Performance panel or Google Search Console reports to gather real-user INP data and understand which interactions are contributing the most to the delay.
• Lab Data: Analyze the data to pinpoint specific code blocks or rendering processes causing the delay.

2. Optimize Interactions:

• Reduce Input Delay: This involves minimizing background CPU activity on the main thread. Look for long tasks and consider offloading them to Web Workers or delaying them until after the critical rendering path.
• Optimize Event Callbacks: Ensure event handlers execute efficiently by avoiding complex calculations or DOM manipulation within them. Consider using asynchronous tasks to avoid blocking the main thread.
• Minimize Presentation Delay: Reduce the time it takes for the browser to paint the updated UI after receiving the user’s interaction. Techniques like optimizing CSS calculations, minimizing DOM mutations, and using efficient layout techniques can help.

3. Focus on Rendering:

• Avoid Large, Complex Layouts: Break down complex layouts into smaller, reusable components to reduce paint time.
• Minimize Layout Thrashing: Avoid dynamic changes that trigger repeated layout calculations. Use CSS media queries and sticky positioning effectively to reduce layout adjustments.
• Optimize DOM Size: Keep the DOM tree structure lean and efficient by avoiding unnecessary nesting and minimizing the number of elements.

By following these steps and utilizing the available tools, you can effectively optimize your site for INP and improve its responsiveness and user experience. Remember, iterative testing and analysis are crucial in identifying the most effective improvements for your specific site. Iterate and play!

Why Core Web Vitals Matter for SEO

You may be wondering why Core Web Vitals matter for SEO. Well, they have a direct impact on your search rankings, user experience, and bounce rates. If your website doesn’t meet the Core Web Vitals metrics, it could result in lower visibility in search results, frustrated users, and higher bounce rates.

Impact on Search Rankings

Improving Core Web Vitals is crucial for SEO because it directly impacts search rankings. The better your website performs in terms of loading speed, interactivity, and visual stability, the higher it will rank in search engine results. Here are five reasons why Core Web Vitals matter for SEO:

• Better user experience: Websites that provide a seamless and enjoyable user experience tend to have lower bounce rates and higher engagement rates, which search engines take into account when determining search rankings.
• Mobile optimization: With the increasing use of mobile devices, search engines prioritize websites that are optimized for mobile, including fast loading times and responsive design.
• Competitor advantage: By prioritizing Core Web Vitals, you can gain an edge over competitors who neglect this aspect of SEO.
• Increased visibility: As your website ranks higher in search results, it becomes more visible to potential visitors, leading to increased organic traffic.
• Improved conversion rates: A fast and user-friendly website leads to higher conversion rates, as visitors are more likely to stay, explore, and make a purchase.

User Experience and Bounce Rates

Optimizing Core Web Vitals is essential for SEO because it directly impacts:

• User experience
  • Website visitors expect fast-loading pages and a smooth browsing experience
  • Core Web Vitals like Largest Contentful Paint (LCP), First Input Delay (FID), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) play a crucial role in meeting these expectations
    • LCP measures how quickly the main content of a page loads
    • FID & INP gauge interactivity
    • CLS assesses visual stability
• Bounce rates
  • If Core Web Vitals are not optimized, users may become frustrated and abandon the site, resulting in high bounce rates
  • Search engines prioritize sites that provide a positive user experience
  • Improving Core Web Vitals can lead to better rankings and increased organic traffic

Therefore, it is vital to closely monitor and enhance Core Web Vitals to enhance user experience and reduce bounce rates.

Other Web Performance Tools

Here are some other tools I may go into in future posts. These are going to be more run of the mill, and most likely be the tools one would use to tune a web site for the purposes of core web vitals:

• Google Search Console
  • This report offers a comprehensive overview of your website’s Core Web Vitals performance based on real-world user data (CrUX).
  • It allows you to identify pages with poor Core Web Vitals scores and prioritize optimization efforts.
  • Search Console also provides valuable insights into the distribution of your Core Web Vitals scores across different user segments (e.g., mobile vs. desktop).
• Lighthouse
  • This Chrome extension audits your web page and provides a detailed report on its performance, including Core Web Vitals metrics.
  • You can run Lighthouse directly on any webpage to gain real-time insights into its performance.
  • Lighthouse also integrates with various development tools and workflows, making it a convenient option for developers.

There are other tools out there (some paid, some free) but they all essentially engage with your site/pages, assess the performance, and then give pointers on how to fix. At the end of the day, GSC is really where you want to start. This is Google themselves telling you what to look at and what to fix in order to help drive your rankings!

Conclusion

This was kind of a geek out post. I hope by going into the Chrome Dev Tools it helped some folks get a better understanding of what is being measured as part of Core Web Vitals. A deeper understanding helps identify the things that really need to be fixed on a page or site and can really have a positive impact on SEO and rankings.

Happy blogging!

Additional Reading

• Core Web Vitals: A Guide to Improving Page Speed (semrush.com)
• Core Web Vitals report – Search Console Help (google.com)
• Core Web Vitals: What They Are & How to Improve Them (backlinko.com)
  

FAQ