This new ranking factor can be a game-changer for a lot of businesses and websites just like the “Hummingbird” algorithm update of 2013. In any case, it is best to take action early on and adjust to the changes that are expected.

In this article, we will tell you all that you need to know about this new Google algorithm update, the Core Web Vitals that will determine your performance, and how to optimize your website’s ‘page experience’ by optimizing web vitals.

Google ‘Page Experience’ update driven by Web Vitals

In Google’s own words, here is what page experience means:

“The page experience signal measures aspects of how users perceive the experience of interacting with a web page.

Optimizing for these factors makes the web more delightful for users across all web browsers and surfaces, and helps sites evolve towards user expectations on mobile.

We believe this will contribute to business success on the web as users grow more engaged and can transact with less friction.”

In other words, they are looking for how usable your website is, how user friendly it is, and whether visitors are will find this website convenient, genuine, informative, and pleasing.

The purpose of this update is to make sure that sites that rank at the top aren’t creating experiences that users don’t like.

The easiest way to think about this update is that user-friendly sites will rank higher than sites that aren’t user friendly.

What Google is trying is to adapt its algorithm to more closely align with the mission of showing the sites first that users love the most.

What are Core Web Vitals?

According to Google:

“Core Web Vitals are a set of real-world, user-centered metrics that quantify key aspects of the user experience. They measure dimensions of web usability such as load time, interactivity, and the stability of content as it loads.”

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

Site owners should not have to be web performance gurus in order to understand the quality of experience they are delivering to their users. The Web Vitals initiative aims to simplify the task and help sites focus on the metrics that matter most, the Core Web Vitals.

Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be presented across all Google tools. Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.

The Three Pillars of Page Experience

The metrics that constitute Core Web Vitals will evolve over time. The current set of metrics for 2020 focuses on three aspects of the user experience, namely, loading, interactivity, and visual stability. This includes the following metrics (and their respective thresholds):

• • Largest Contentful Paint (LCP): LCP measures how long it takes for the largest piece of content to appear on the screen. This could be an image or a block of text. A good grade gives users the feeling that the site loads fast. A slow site causes frustration. To provide good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.

• • First Input Delay (FID): FID measures how long it takes for the site to react to the first interaction by a user. This could be a tap on a button, for instance. A good grade here gives the user a sense that a site is quick to react to input and, therefore, responsive. Slow, again, leads to frustration. Pages should have an FID of less than 100 milliseconds to provide a good user experience.

• Cumulative Layout Shift (CLS): CLS measures the visual stability of your site. In other words, does stuff move around on the screen while it is loading and how often does that happen? Nothing is more frustrating than trying to click a button when a slow-loading ad appears in that spot. To provide good user experience, pages should maintain a CLS of less than 0.1. For each of the above metrics, to ensure you’re hitting the recommended target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

How to measure Core Web Vitals?

You can measure your website’s Core Web Vitals using a variety of tools like Google Search Console, Lighthouse, Chrome Dev Tools, Chrome UX Report and more. But today, we will look at the simplest way of measuring Core Web Vitals of your website. That is by using Google PageSpeed Insights.

Simply navigate to Google PageSpeed Insights and then enter your webpage URL in the box provided and click analyze.

The PageSpeed Insights tools will take a few second to analyze your webpage and then present a report like this:

In this report, you can find the Core Web Vitals measurement marked with a blue flag under the heading ‘Field Data’.

Here, you can find the measurement of all the 4 metrics, that is, FCP, FID, LCP, and CLS.

This is the most convenient and quick way of measuring the performance of your website’s core web vitals.

You can also understand how Lighthouse scores websites in the Google PageSpeed Insights test by checking theLighthouse Scoring Calculator.

Field Data and Lab Data

Web Vitals introduced new ways of determining performance. Some of these metrics can be calculated in a lab setting or simulated in a lab, so to say, while other metrics make sense only if they are tested and collected in the field. In addition, some metrics work well in both settings. Data from metrics collected in a lab setting is called Lab Data whereas data from metrics collected in the field setting is called Field Data.

Google PageSpeed Insights uses both field data and lab data to analyze the performance of your website and suggest improvements.

Optimizing your Website’s Core Web Vitals

Once you’ve measured the Core Web Vitals and identified areas for improvement, the next step is to optimize. In the following sections, we will offer specific recommendations for how to optimize your pages for each of the Core Web Vitals. Let’s get into it!

Largest Contentful Paint – Description and Optimizations

Largest Contentful Paint (LCP) is a Core Web Vitals metric that measures when the largest content element in the viewport becomes visible. It can be used to determine when the main content of the page has finished rendering on the screen.

In simpler words, LCP measures the time from when the page starts loading to when the largest text block or image element is rendered on the screen

In Google’s opinion, to provide good user experience, LCP should occur within 2.5 seconds of when the page first starts loading. Anything greater than 4 seconds is considered to be a poor performance.

To improve LCP, you’ll have to perform the following optimization on your website:

1. Minimize Render Blocking JavaScript and CSS

When JavaScript or CSS is “blocking” it implies that the browser needs to parse and execute the CSS and JavaScript in order to paint the final state of the page in the viewport.

You might see a warning about render-blocking JavaScript and CSS while checking your website’s performance in Google PageSpeed Insights.

Some specific JS and CSS are sometimes conditional, meaning that they are not required to display above-the-fold content. You can prevent them from becoming render-blocking by using async and defer attributes.

To eliminate render-blocking JavaScript and CSS you need to do the following:

Clear JS from Critical Rendering Path: You can move JavaScript out of the critical rendering path by adding either the ‘async’ or the defer’ attribute to the script HTML elements that call JavaScript resources.

The ‘async’ attribute instructs the browser to start downloading the resource right away without slowing down HTML parsing. Once the resource is available, HTML parsing is paused so the resource can be loaded.

The ‘defer’ attribute tells the browser to hold off downloading the resource until HTML parsing is complete. Once the browser has finished with the HTML, then it will download and render all the deferred scripts in the order in which they appear in the document.

Optimize Delivery of CSS Resources: Optimizing the delivery of CSS essentially means you need to figure out how to make it non-render blocking.

You should identify the styles that are required to render above-the-fold content and deliver those styles inline with the HTML. You should use CSS conditionally on devices only when needed. Make sure that you minify CSS and defer non-critical CSS. Also, load the remaining CSS asynchronously.

2. Improve Server Response Time

The longer it takes a browser to receive content from the server, the longer it takes to render anything on the screen. A faster server response time directly improves every single page-load metric, including LCP.

Before anything else, improve how and where your server handles your content. Use Time to First Byte (TTFB) to measure your server response times. You can improve your TTFB in a number of different ways:

Optimize your Server: Analyzing and improving the efficiency of your server-side code will directly improve the time it takes for the browser to receive the data. Take help of your hosting provider to optimize your server for the best performance.

Use a CDN: CDN stands for Content Delivery Network. These are a network of servers located around the globe. Their main purpose is to host and deliver copies of your WordPress web site’s static content such as images, CSS, JS, and video streams quickly and efficiently.

When you use a CDN, every time a user visits your website they are served the static files from whichever server is closest to them. Your web hosting server will also be faster since the CDN is doing a lot of its work.

Enable Caching: Caching saves an HTML copy of the website for a specified time. For a website, we could set the cache to expire once a day. This means that once a day the website will load normally; it will detect a request, get the server to process the code, and show the result as HTML. It will also save the resulting HTML in memory.

The next time when someone loads the website, the cache would load the HTML from memory instead of getting the server to process it.

It reduces the amount of work required to generate a page view. As a result, your web pages load much faster, directly from the cache.

Establish third-party Connection early: Server requests to third-party origins can also impact LCP, especially if they’re needed to display critical content on the page. Use rel=”preconnect” to inform the browser that your page intends to establish a connection as soon as possible.

<link rel=”preconnect” href=”https://example.com”>

You can also use dns-prefetch to resolve DNS lookups faster.

<link rel=”dns-prefetch” href=”https://example.com”>

Although both hints work differently, consider using dns-prefetch as a fallback for browsers that do not support preconnect.

<head>
…
<link rel=”preconnect” href=”https://example.com”>
<link rel=”dns-prefetch” href=”https://example.com”>
<head>

3. Improve Resource Load Times

Although an increase in CSS or JavaScript blocking time will directly result in worse performance, the time it takes to load many other types of resources can also affect paint times. The types of elements that affect LCP are:

• <img> elements
• <image> elements inside an <svg> element
• <video> elements (if specified, the poster image is used to measure LCP)
• An element with a background image loaded via the url() function (as opposed to a CSS gradient)
• Block-level elements containing text nodes or other inline-level text elements
  The time it takes to load these elements if rendered above-the-fold will have a direct effect on LCP. There are a few ways to ensure these files are loaded as fast as possible:

Optimize and compress images: For many sites, images are the largest element in view when the page has finished loading. Hero images, large carousels, or banner images are all common examples of this.

Improving how long it takes to load and render these types of images will directly speed up LCP. To do this:

• Consider not using an image in the first place. If it’s not relevant to the content, remove it.
• Compress images (with an online or offline tool)
• Convert images into newer formats (JPEG 2000, JPEG XR, or WebP)
• Use responsive images
• Consider delivering images using a CDN

Preload important resources: At times, important resources that are declared or used in a certain CSS or JavaScript file may be fetched later than you would like, such as a font placed deep in one of the many CSS files of an application.

If you know that a particular resource should be prioritized, use to fetch it sooner. Many types of resources can be preloaded, but you should first focus on preloading critical assets, such as fonts, above-the-fold images or videos, and critical-path CSS or JavaScript.

<link rel=”preload” as=”script” href=”script.js”>
<link rel=”preload” as=”style” href=”style.css”>
<link rel=”preload” as=”image” href=”img.png”>
<link rel=”preload” as=”video” href=”vid.webm” type=”video/webm”>
<link rel=”preload” href=”font.woff2″ as=”font” type=”font/woff2″ crossorigin>

Compress text files: This is another potentially huge speed gain for your website. Compression reduces the size of various assets including text files before sending them to your browser for interpretation.

The reason this is so helpful is that HTML, JavaScript, and CSS use a lot of repeated content. The more patterns you have in your content the better it can be compressed.
This is something that needs to be set up on your server through the FTP.
You can check out this GTmetrix article for a quick tutorial on how to enable compression on your WordPress website.

Adaptive Serving: If you have large assets that are critical for initial rendering, you can use different variations of the same resource depending on the user’s connection or device. For example, you can display an image instead of a video for any connection speeds lower than 4G:

if (navigator.connection && navigator.connection.effectiveType) {
 if (navigator.connection.effectiveType === '4g') {
   // Load video
 } else {
   // Load image
 }
}

A list of useful properties that you can use:

• navigator.connection.effectiveType: Effective connection type
• navigator.connection.saveData: Data-saver enabled/disabled
• navigator.hardwareConcurrency: CPU core count
• navigator.deviceMemory: Device Memory

First Input Delay – Description and Optimizations

First Input Delay (FID) is a Core Web Vitals metric that captures a user’s first impression of a site’s interactivity and responsiveness. It measures the time from when a user first interacts with a page to the time when the browser is actually able to respond to that interaction. FID is a Field metric and cannot be simulated in a lab environment. A real user interaction is required in order to measure the response delay.

The main cause of a poor FID is heavy JavaScript execution. Optimizing how JavaScript parses, compiles, and executes on your web page will directly reduce FID.

The browser cannot respond to most user input while it’s executing JavaScript on the main thread. In other words, the browser can’t respond to user interactions while the main thread is busy. To improve this, you can perform the following optimizations:

1. Break Up Long Tasks

If you’ve already attempted to reduce the amount of JavaScript that loads on a single page, it can be useful to break down long-running code into smaller, asynchronous tasks.

Long Tasks are JavaScript execution periods where users may find your UI unresponsive. Any piece of code that blocks the main thread for 50 ms or more can be characterized as a Long Task. Long Tasks are a sign of potential JavaScript bloat; loading and executing more than a user may need right now.

Splitting up long tasks can reduce input delay on your site.

FID should improve noticeably as you adopt best practices like code-splitting and breaking up your Long Tasks. While TBT is not a field metric, it’s useful for checking progress towards ultimately improving both Time To Interactive (TTI) and FID.

2. Optimize your Page for Interaction readiness

There are a number of common causes for poor FID and TBT scores in web apps that rely heavily on JavaScript:

First-party script execution can delay interaction readiness:

• • JavaScript size bloat, heavy execution times, and inefficient chunking can slow down how soon a page can respond to user input and impact FID, TBT, and TTI. Progressive loading of code and features can help spread this workout and improve interaction readiness.

• Server-side rendered apps may look like they’re getting pixels painted on the screen quickly, but beware of user interactions being blocked by large script executions (e.g. re-hydration to wire up event listeners). This can take several hundred milliseconds, sometimes even seconds, if route-based code splitting is being used. Consider shifting more logic server-side or generating more content statically during build time.

Optimize Data-fetching:

• • Waiting on a waterfall of cascading fetches (like JavaScript and data fetch for components) can impact interaction latency. Aim to minimize reliance on cascading data fetches.

• Large inline datastores can push out HTML parsing time and impact both paint and interaction metrics. Aim to minimize how much data needs to be post-processed on the client-side.

Improve Third-part Script Execution:

• • Many sites include third-party tags and analytics which can keep the network busy and make the main thread periodically unresponsive, impacting interaction latency. Explore the on-demand loading of third-party code (for example, maybe don’t load those below-the-fold ads until they’re scrolled closer to the viewport).

• In some cases, third-party scripts can pre-empt first-party ones in terms of priority and bandwidth on the main thread, also delaying how soon a page is interaction-ready. Attempt to prioritize loading what you believe offers the greatest value to users first.

Reduce JavaScript Execution Time: Limiting the amount of JavaScript on your page reduces the amount of time that the browser needs to spend executing JavaScript code. This speeds up how fast the browser can begin to respond to any user interactions.
To reduce the amount of JavaScript executed on your page:

• • Defer unused JavaScript

• Minimize unused polyfills

Cumulative Layout Shift – Description and Optimization

Cumulative Layout Shift (CLS) – a Core Web Vitals metric, measures the instability of content by summing shift scores across layout shifts that don’t occur within 500ms of user input. It looks at how much visible content shifted in the viewport as well as the distance the elements impacted were shifted.

You can perform the following optimizations to improve the Cumulative Layout Shift score from your core web vitals:

1. Use font:display values with your custom fonts

All those fancy google fonts might be causing FOIT and FOUT and the chances are you wouldn’t have thought it could lead to any problem.

If you are wondering, what’s FOIT and FOUT, allow me to explain.

When a browser needs a font from a web server, any element that uses that font will be hidden until the font asset has been downloaded fully. This is known as FOIT or flash of invisible text.

Similarly, browsers display a fallback font in the font stack until the custom one loads. This creates a flash of unstyled text or commonly known as FOUT.

Lighthouse can be your friend here in identifying what exactly is the cause of CLS. If the fonts are culprit, there are some easy fixes to deal with them. You can simply use font:display values

You can minimize these effects by using font:display values like auto, swap, block, fallback, and optional.

But if you want to be 100% sure there is no layout shift happening, you should use font:display in conjunction with .

2. Include width and height attributes on image and video elements

Specifying height and width on images used to be a healthy old practice, but with the popularity of responsive web design, it got lost. This is how it should be:

<img src=”datadab-home-page.jpg” width=”1440″ height=”810″ alt=”DataDab Home Hero Image”>

Modern web browsers now set the default aspect ratio of images based on the height width attributes of an image. So it’s a good practice to set them to prevent layout shifts.

img { aspect-ratio: attr(width) / attr(height);}

This predicts an aspect ratio, on the basis of dimension attributes before loading the image. It provides that information at the very beginning of the calculation of the layout. The aspect ratio is used to measure the height as soon as an image is told to be a certain width.

When dealing with responsive images, srcset determines the photos that you let the browser choose between what sizes each image is. To set attributes of img width and height, each image should use the same aspect ratio.

<img width=”1000″ height=”1000″ src=”dd-about-1000.jpg” srcset=”dd-about-1000.jpg 1000w, dd-about-2000.jpg 2000w, dd-about-3000.jpg 3000w” alt=”dd-about”/>

3. Set dimensions on ads and embeds

Ads are among the biggest contributors to layout shifts. Publishers and ad networks often support dynamic ad sizes. Owing to higher click rates and more advertisements competing in the auction, ad sizes improve efficiency and hence revenue. Sadly, due to ads pushing visible content that you are viewing down the page, this can lead to suboptimal user experience.

You can try these steps to reduce the chances of high CLS because of ads:

• Reserve space statically for ad slot. That is to say, style the item before loading the ad tag library.
• When putting ads in the content flow, make sure the slot size is allocated to avoid shifts. If loaded off-screen, those ads will not trigger layout shifts.
• When putting non-sticky ads near the top of the viewport, take extra care.
• Avoid collapsing the allocated space if a placeholder shows no ad when the ad slot is available.
• Eliminate layout shifts by reserving the ad slot with the widest possible duration.
• Use historical data to choose the most likely size for the ad slot.

4. Improve HTTP response and elements synchronization

Slow server HTTP response may also cause issues with the content layout. When you are using a CDN, loading of the indented elements takes quite a few milliseconds. That causes the content to jump. You then need to either build a space in DOM or synchronize the load with other elements.

5. Properly handle dynamically injected content

Never inject content above existing content, except for user interaction. This ensures anticipation of any layout shifts that occur.

You must have noticed layout shifts due to a UI that pops up at the top or bottom of the page when you’re trying to load a site. Just like an ad, this also happens with banners and forms that change much of the page‘s layout.

When you choose to display these kinds of UI elements, reserve enough space in the viewport for it in advance. Try to use a placeholder or skeleton UI so that once it loads, it does not trigger page content to move around unexpectedly.

Summary

Sometime in 2024, Google will update their algorithms to incorporate a new ranking factor: page experience. To measure page experience, Google developed a new set of metrics called the Web Vitals. Within these Web Vitals, you can find three core metrics: Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. These stand for performance, responsiveness, and visual stability — the three pillars of Google’s page experience update.

Now is the time to start working on improving core web vitals of your website because soon, these will become important ranking factors in Google search.

Let us know if you have any questions related to optimizing and improving core web vitals, in the comments below. We’d love to help you out!

Want to know more about improving your website’s core web vitals? Get in touch with us today and we’d be glad to help you out!

The post Core Web Vitals – How to Optimize your Website for the 2024 Google algorithm update appeared first on W3 SpeedUp.

7 Essential Tips for Using Google Reviews to Enhance SEO

1. Encourage honest reviews

You should ensure that your products meet all their requirements to have honest reviews from customers. Loyal customers can give both favorable opinions or leave honest comments. After product use, it is crucial to request reviews as a way of marketing your goods and services. The review process needs to be simplified so your customers do not take much time doing this. Also, if you want to get more Google reviews, you can consider giving out incentives to those who write reviews but you have to be cautious on this since people can gauge fake ones when they see them. If you want your clients to write some positive feedback about you, you can also reward and motivate them with something like getting a discount or winning a prize ticket. All these activities are aimed at ensuring that one has good relations with their buyers who will enjoy their stay in the business and automatically end up writing nice reports boosting SEO.

2. Respond to reviews

If you respond to your customers’ reviews, it will show the customers and search engines that you are active, responsive, and dedicated to satisfying your customers as well as improving their experience with your products/services. Try to take 24-48 hours at most to respond; this shows interest in what clients say about you, whether negative or positive. It is important when giving a response to be polite and professional so that your customers will feel valued and appreciated. Sometimes, all it takes is to just say “thank you” for a positive review but on the other hand for a bad one, offering a solution can help and if possible, invite the customer personally for further discussion on the matter. This indicates that you’re ready to tackle the issues head-on and resolve them right away. Furthermore, using your customer’s name while replying will provide a human touch making more connections with them, and all these steps are important for the SEO of your page.

3. Present the reviews on your website

Google reviews can play a huge part in improving a lot when it comes to your website. They are there to tell people whether your website is worth checking out and whether you can be trusted or not. The more reviews there are, the better for the business and these reviews should be utilized in the right way. These companies should put them on the most important pages of their website, for example, on the homepage. You will have to find good ways to integrate the content of your website with the reviews. What is great about adding reviews to your homepage is that Google will analyze what it is and its engine may like what it sees and then it starts to present it more to people. The best thing about doing things this way is that you will show that you care for your loyal customers and that you value what they have to say.

4. Use the right keywords

The keywords that a business website uses can make or break its success. They are used by search engines to determine when someone writes something in the search bar that they can use those words to deliver the right content someone needs. There are many things that you have to think about when it comes to them but you need to find a way to select the best keywords for your company. One very effective way is to use reviews that your customers left or those of other similar businesses in your quest for your ideal keywords. Since you are catering to potential customers, the best way to find them is by analyzing what they are asking and what they want. Also, you can ask your customers to write extensive reviews, which will boost your keywords and which will result in more customers coming to your website.

5. Use Google My Business features

Utilizing Google My Business (GMB) features is a must to accomplish the geo-localization of your business and make Google Reviews the most efficient. GMB is a highly valuable instrument that helps you to be present wherever you are on the web, on Google Search and Maps, making sure potential customers can join your company. You can also include the Q&A section, which will also be a helpful tool where you and your customers can address common issues and provide more information about your products.

6. Promote reviews on social media

By using social media, you will show the people who follow you and those who check out your profiles how people are satisfied with your products and services. By sharing these reviews, people will get more interested in what you have to offer and it may even boost your standing in the market. Social media platforms have become one of the best tools at the disposal of companies and you can use them in many different ways and by posting your reviews on them you will realize their potential.

7. Analyze competitor reviews

Checking the reviews of your competitors gives you a chance to understand the preferences and dislikes of your customers. Focus on positive and negative reviews alike, as both will help you notice a pattern and the things that you should improve and work on to provide exceptional service and make people more loyal to your brand. Also, you will get a clearer idea of what kind of problems you may be dealing with and you’ll become more creative, offering some amazing solutions that will help you outrank your competitors and provide better service for your customers.

Google reviews are important for any company that wants to stand out and attract more loyal customers. Showing your appreciation for what people have to say about your products and services will send a strong message and an impression of a credible and attentive company, which in turn improves your SEO.

Read More: Essential Tips For Optimizing Your WordPress SEO

Read More: How A Good SEO Strategy Can Help Grow Your Business

The post 7 Strategies for Using Google Reviews to Enhance SEO appeared first on W3 SpeedUp.

User experience has always been integral to building a quality website but now it’ll play a bigger role than ever. You must focus on the kind of experience that your website provides your visitors.

Page Experience, the new ranking signal, combines Core Web Vitals with existing user experience signals to improve the evaluation of the overall experience provided by a page.
Although it is not bound to launch before late 2024, that doesn’t stop you from being proactive and adapting for the change when there is still time at hand.

And, Google being Google, they have provided an early look into the work being done so far.
Don’t know what Core Web Vitals are?

Don’t worry! That’s why we’ve written this early guide to Core Web Vitals and Google’s latest ranking factor.

Google Page Experience Update

The Google page experience signal consists of the Core Web Vitals, as well as the existing page experience metrics. The existing Google page experience metrics include the following:

• HTTPS-security
• Safe-browsing
• Mobile-friendliness
• No Intrusive interstitials

These metrics aim to understand how a user will perceive the experience of a specific web page. It considers factors such as whether the page loads quickly, if it’s mobile-friendly, runs on HTTPS, if there are intrusive ads present, and if content moves around as the page loads.

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

This initiative aims to simplify the landscape and help sites focus on the metrics that matter most, the Core Web Vitals. We’ll discuss more on Core Web Vitals in the following sections.

You can view Google’s detailed documentation for page experience here.

Core Web Vitals

Introduced in May 2020, Core Web Vitals are a set of metrics related to speed, responsiveness, and visual stability of a website.

Core Web Vitals are the subset of Web Vitals that apply to all web pages and should be measured by all site owners.

All Core Web Vitals represents a distinct facet of the user experience. Each is measurable in the field, on real users actually loading and interacting with the page. Each reflects the real-world experience of a critical user-centric outcome.

Google has defined the following as Core Web Vitals:

• Largest Contentful Paint (LCP): LCP measures the loading performance of a website, or how long it takes for a page’s main content to load. LCP should occur within 2.5 seconds of when the page first starts loading, to provide a good user experience.
  
• First Input Delay (FID): FID measure interactivity or the time your website takes to become interactive. Ideally, you should maintain an FID of less than 100 milliseconds.
  
• Cumulative Layout Shift (CLS): CLS measures the visual stability of a page or the amount of unexpected layout shift of visual content on a page. You should aim for a CLS score of less than 0.1
  
  These Core Web Vitals are not set in stone. Chromium blog states that they expect to update Core Web Vitals on an annual basis. Although Google Developers blog states that, “The Core Web Vitals are relevant to all web pages and featured across relevant Google tools. Changes to these metrics will have a wide-reaching impact; as such, developers should expect the definitions and thresholds of the Core Web Vitals to be stable, and updates to have prior notice and a predictable, annual cadence.”
  Let us now take a look at each of the Core Web Vitals metrics in detail.

LCP or Largest Contentful Paint

Largest Contentful Paint (LCP) measures the time at which the largest content element appears on the screen. Please note that it does not measure the time taken by your page to fully load. It simply looks at and measures when the most important part loads.

In the case of a simple web page with only a piece of text and a large image/video, that large image/video will be considered the LCP. Since this is the largest piece of content to load on a browser, it’s bound to make an impression. By getting that largest piece of content to load quicker, your site can appear much faster. So, sometimes, it might just be as simple as optimizing that image/video itself.

Now that you know what LCP is, you can start optimizing it. Your aim is to get LCP loaded in 2.5 seconds or less. Anything below 4 seconds needs less and anything above 4 seconds is considered poor by Google.

The LCP is also dynamic, since the first thing that loads might not immediately be that large image. The LCP shifts to that large image when that appears on the screen.
Let’s take a look at an image from Google that explains how that works:

In the first image on the left, you’ll see the top menu bar with the logo and ‘Visual Stories’ section load up. This is the First Contentful Paint. Then, in the next 3 images, the headline appears as a candidate for LCP. But, in the last image, the image takes place of the headline as the LCP candidate.

How to improve LCP?

According to Google, LCP is primarily affected by four factors:

• Slow server response times
• Render-blocking JavaScript and CSS
• Resource load times
• Client-side rendering

Optimizing these factors will improve your LCP score! You can check out the Google Developers blog to know more about optimizing LCP.

FID or First Input Delay

First Input Delay measures the time taken by the browser to respond to the first interaction by the visitor. The quicker the browser’s reaction, the more responsive the page will appear. You should work on the responsiveness of your pages if you’re looking to offer a positive user experience.

Delay happens when the browser is kept busy with other work in the background. So, it has loaded the page but nothing happens when you tap that button. That’s a bad experience and it leads to frustration.

Remember, even if there’s just a small delay it might make your site feel sluggish and unresponsive.

FID measures all interactions that take place while the page is being loaded. These are input actions like taps, clicks, and keypresses. But it does not include interactions like zooming and scrolling.

Google’s new metrics call for an FID of less than 100ms to appear responsive.
You must remember:

You cannot measure the FID if there is no user interaction. This implies Google can’t simply predict the FID based on the data they have from the lab. Google needs data from real users, also called field data. This also means that this data is less controllable than lab data. This is because it collects data from users will all kinds of devices and who use them in different ways & environments.

How to reduce FID?

According to Google, you can reduce FID by performing the following optimizations:

• Reduce the impact of third-party code
• Reduce JavaScript execution time
• Minimize main thread work
• Keep request counts low and transfer sizes small

You can check out the Google Developers blog to know more about optimizing FID

CLS or Cumulative Layout Shift

CLS or Cumulative Layout Shift tries to determine how stably all the elements load onto your screen. It measures how often elements jump around while loading and by how much.

CLS compares frames to determine the movement of elements. It takes all the points at which unexpected layout shifts happen and calculates the severity of those movements. If a user clicks the menu button and a fold-out menu appears, that doesn’t count as a layout shift since it is expected behavior.

Sometimes a button loads on the screen, inviting users to click it. However, in the background, there’s still a large content area being loaded. So, when the content finally loads completely, the button moves down a bit as you were about to hit it. This affects your CLS score.

Ads are also a common culprit of a poor CLS score since ads cause a lot of layout shifts.
Let us take an example of multiple unstable elements, as shown by Google:

In the first frame above there are four results of an API request for animals, sorted in alphabetical order. In the second frame, more results are added to the sorted list creating an unexpected layout shift.

Many complex sites have so many functionalities and elements that these are heavy to load and content gets loaded whenever it’s ready. This can often also result in content or CTAs jumping around on the screen, making room for slower loading content.

How to improve CLS?

According to Google Developers blog, you can avoid all unexpected layout shift by adhering to the following principles:

• Always include size attributes on your images and video elements, or otherwise reserve the required space with something like CSS aspect ratio boxes. This ensures that the browser can allocate the correct amount of space in the document while the image is loading.
• Never insert content above existing content, except in response to user interaction. This ensures any layout shifts that occur are expected.
• Prefer transform animations to animations of properties that trigger layout changes. Animate transitions in a way that provides context and continuity from state to state.

Official tools to measure Core Web Vitals

There are loads of tools to help you monitor Web Vitals and improve the performance of your site. Here are the most important ones:

• PageSpeed Insights: Google PageSpeed Insights is a full-service measuring tool with both the field as well as lab data. It also gives you advice on what to improve.
• Lighthouse: Google built Lighthouse as a tool to audit PWAs, but now it’s a great tool to monitor performance. It has several audits that PageSpeed Insights doesn’t have and it even has some SEO checks.
  To check Core Web Vitals using Lighthouse, go to a page you want to analyze, right-click, and select “Inspect”. After that, click on the “Lighthouse” button as shown below.
  Now, select the categories that you want to test for and tap the “Generate Report” button.
  
• Search Console Core Web Vitals report: You can now get insights from your site straight from Search Console. This is great to get an understanding of how your site is performing.

Other Web Vitals

While the Core Web Vitals are the critical metrics to understand and deliver great user experience, there are other important metrics as well.

These other Web Vitals often serve as supplemental metrics for the Core Web Vitals. They help capture a larger part of the experience and assist in diagnosing a specific issue.

For example, the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both integral aspects of the loading experience. Both are useful in diagnosing issues with LCP.

TTFB helps determine whether slow server response times are slowing your website. FCP helps determine if there are any render-blocking resources on your page.

Metrics like Total Blocking Time (TBT) and Time to Interactive (TTI) are lab metrics that are important in finding and diagnosing potential interactivity issues that will impact FID.

But, these metrics are not part of the Core Web Vitals because they are not field-measurable, nor do they reflect a user-centric outcome.

Final Words

Soon, Google will incorporate a new ranking factor in its algorithm: page experience. Google developed a new set of metrics which are called the Web Vitals to measure page experience. You can find three core metrics within these Web Vitals: Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. These represent performance, responsiveness, and visual stability, the three pillars of Google’s page experience update.
Did we miss out on something important? Let us know in the comments below.

Want to know more about optimizing Core Web Vitals? Get in touch with us today, and we’ll help you out.

The post Google Page Experience Update 2024 and Core Web Vitals: All You Need to Know! appeared first on W3 SpeedUp.

This Field Data also includes the Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics to analyze real-world website performance better.

In this article, we’ll help you gain a more comprehensive understanding of the FCP and FID core metrics. We’ll also help you understand how to analyze these metrics for your website in PageSpeed Insights.

What is First Contentful Paint (FCP)?

The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of that web page’s content is rendered on the screen. In this metric, “content” refers to text, images, <svg> elements, or non-white <canvas> elements.

First Contentful Paint or FCP measures how long it takes for the browser to render the first piece of DOM content after a user navigates to your page. Images, non-white <canvas> elements, and SVGs on your page are considered DOM content; anything inside an iframe is not included. Google evaluates FCP against the following benchmarks:

How to measure First Contentful Paint (FCP)?

You can check the FCP for any web page by navigating to Google PageSpeed Insights, entering the page URL, and analyzing it. You’ll see the FCP metric on the top in the ‘Field Data’ section of the report.

What is First Input Delay (FID)?

First Input Delay or FID is the time it takes by the browser to respond to the first user interaction on a page. FID measures the delay after distinct actions by the visitor like clicks or taps. Scrolls and zooms don’t trigger the FID metric.

The time from when a user first interacts with your page (clicked a link, tapped a button, and so on) to the time when the browser responds to that interaction. This measurement is taken from whatever interactive element that the user first clicks. It’s important on pages where the user needs to do something or perform some action because this is when the page has become interactive. Google evaluates FID against the following benchmarks:

What is Max Potential First Input Delay?

Maximum Potential First Input Delay (MPFID) is the worst-case scenario that your user might experience. MPFID is the maximum possible delay between a user’s input and the response from the browser. MPFID depends on the length of the longest task running on the main thread.

If we take the longest task on the main thread and imagine a user clicking a button right when the browser starts executing it, we arrive at the worst-case scenario or MPFID. Google evaluates MPFID against the following benchmarks:

How to measure FID and MPFID?

You can measure FID for any web page by navigating to Google PageSpeed Insights, entering the page URL, and analyzing it. You’ll see the FID metric on the top in the ‘Field Data’ section of the report.

To check your MPFID, you’ll have to use Google Lighthouse. Go to a page you want to analyze, right-click, and select “Inspect”. After that, click on the “Lighthouse” button as shown below.

Now, select the categories that you want to test for and tap the “Generate Report” button.

In the Performance report that follows, you can check your MPFID.

Finally, you can also check FID and MPFID from Google Search Console and its Core Web Vitals report.

FCP and FID – taken together

FCP and FID measure different things.

First Contentful Paint or FCP measures the load time of your page. It measures how long the page takes to display the First Contentful Paint.

Whereas, First Input Delay or FID measures the responsiveness of your website. It measures the time delay between first input or action by the visitor and the response from the browser.

Together, both these metrics give you an excellent analysis of the first impression of your website. Moreover, user inputs usually happen after the first piece of content is painted. This is why FCP and FID are inherently connected and give you a good sense of the first impression of your website.

How to improve FCP and FID on your WordPress website?

You can improve FCP and FID by speeding up the download time of resources, optimizing DOM elements for smooth rendering on browsers, and reducing the duration of your longest tasks.

Perform the following tasks and you should see significant improvement in FCP and FID metrics.

• Reduce miscellaneous HTTPS requests: Decreasing the number of HTTP requests that WordPress makes is very important.
  You can reduce the number of external HTTP requests by disabling styles and scripts or by merging them in one file. Also, delete all unnecessary images and files, create CSS image sprite, do lazy loading, ignore irrelevant assets, and combine CSS & JS files. You can find out how to perform these optimizations here.
• Minify and Combine CSS & JavaScript files: Minification of resources means removing unnecessary characters from your HTML, JavaScript, and CSS that are not required to load, such as white space characters, new-line characters, comments, block delimiters, etc. It improves your loading speeds since it reduces the amount of code that has to be requested from the server.
  Concatenation is the process of combining your JavaScript and CSS files into one file with the object of reducing the HTTP requests. In some cases, this can increase the download time of your file, but it is usually better than having additional requests. Find details here.
• Eliminate Render blocking JavaScript and CSS: Some specific JS and CSS are sometimes conditional, meaning that they are not required to display above-the-fold content. You can prevent them from becoming render-blocking by using async and defer attributes.
  To eliminate render-blocking JavaScript and CSS, you need to clear JS from the critical rendering path and optimize the delivery of CSS resources. Find out how to do that here.

FID and Total Blocking Time (TBT)

TBT is the measure of time, during which Long Tasks block the main thread and affect the usability of a page.

Sure, there are similarities between FID and TBT. Both occur between FCP and TTI. And Long Tasks on the main thread can hurt them significantly.

Also, both FID and TBT measure the severity of the unresponsiveness of a page. The difference is that TBT measures it without user input. It merely adds together the blocking time for each Long Task.

FID and Time To Interactive (TTI)

TTI is the time it takes for a page to become fully interactive. A page becomes fully interactive when it responds to user input in less than 50ms, and event handlers are registered for most visible page elements.

Again, FID is a great companion here. A page might become interactive at any moment. But users can click or tap on the screen way before that.

This is where TTI falls short. After all, there’s no point in knowing when a page became fully interactive when the user experience might’ve been ruined way before that.

Users don’t care if a page became interactive in 2 seconds or 8 seconds. But, they do care if a page was interactive when they needed it to be.

So, it’s clear that FID fills the gap left by TTI and presents a more comprehensive metric.

Final Words

FCP measures the lapse of time between the moment a user starts the navigation on your site, and when the browser starts to paint content on the screen. FID measures the time from when a user first interacts with your website to the time when the browser starts to respond to that interaction.

FID won’t become a ranking factor until 2021 as a part of Core Web Vitals. Most people will put it off until then. If you optimize for it now, you’ll get a nice head start on the competition. Moreover, you won’t have to think about it when 2021 rolls around. But optimizing your FID isn’t enough. You’ll also need to think about the other two parts of the Core Web Vitals program.

Did we miss out on something important? Let us know in the comments below.

Want to know more about optimizing Core Web Vitals? Get in touch with us today, and we’ll help you out.

The post What is First Contentful Paint and First Input Delay? How to improve FCP and FID? appeared first on W3 SpeedUp.

What is LCP?

Largest Contentful Paint (LCP) is a Core Web Vitals metric that measures the time when the largest content element in the viewport becomes visible. You can use it to ascertain the exact time when the main content of the page has finished rendering on the screen.

Google Developers blog recommends that sites should strive to have LCP occur within the first 2.5 seconds. Google has set this as one of the benchmarks to qualify for sites aiming to provide a good user experience. You can use Google PageSpeed Insights to test your site’s performance on the Core Web Vitals metrics.

Most Common causes of poor LCP scores and How to Fix them!

Let us understand some of the most common causes of poor LCP scores and go through the steps you can take to fix them.

Slow Server Response Times

The longer the servers take to send content to the browser, the longer it’ll take to render anything on the screen. Speeding up server response time directly improves all the page-load metrics, including LCP.

You should use Time to First Byte (TTFB) to measure your server response times. There are many ways of improving TTFB, let us take a look at them.

1. Server optimization

If you are running expansive queries that take your server a large amount of time to complete, your TTFB will most likely be low. You must break down such queries or serve them more efficiently.
Also, you must keep in check all the other complex operations happening server-side that delay the process of returning page content. By making your server-side code more efficient, you can directly improve the time it takes for the browser to receive the first byte of data from the server.

2. Use CDN

A Content Delivery Network or CDN is a network of servers spread across many different geographical locations. With a single server, your website will load slower for users that are geographically farther away. This is because their browser requests literally have to travel longer distances across the globe. A CDN can help avoid that by serving the site to the browser using a server that’s located closest to the visitor.

3. Cache Assets

If your site’s HTML is static and does not change on every request, then caching can prevent it from being recreated unnecessarily. With server-side caching, a copy of your generated HTML is stored in disk and so it can reduce TTFB and minimize resource usage.

4. Establish 3rd Party connections early

Server requests to third-party origins can also impact LCP and cause LCP issues. This is especially true if they’re necessary in order to display critical content on the page. Use rel=”preconnect” to let the browser know that your page intends to establish a connection at the earliest.

You can also resolve DNS lookups faster by using dns-prefetch.

Although both work differently, you should consider using dns-prefetch as a fallback for browsers that don’t support preconnect.

Render-blocking JS & CSS

Scripts and stylesheets are both render-blocking resources that delay FCP, and ultimately LCP. You can prevent JS & CSS from becoming render-blocking by performing the following optimizations:

1. Minify JS & CSS

For better legibility, JavaScript and CSS files contain characters like spacing, indentation, or comments. These characters are meaningless and unnecessary for the browser. So, by minifying these files you can ensure that such characters get removed. This will ultimately reduce the amount of blocking JS & CSS and improve the time it takes to fully render the main content of the page (LCP).

2. Defer non-critical CSS

You can use the ‘Coverage’ tab in Chrome DevTools to find any unused CSS on your web page.

Remove any unused CSS on your site entirely. Or, you can also move it to another stylesheet if you’ve used it on a separate page of your site.

For any CSS not needed for initial rendering, use loadCSS to load files asynchronously, which leverages rel=”preload” and onload.

3. Inline Critical CSS

You should inline any critical-path CSS used for above-the-fold content. You can do so by including it directly in. If you inline important styles, it eliminates the need to make a round-trip request to fetch critical CSS. Now, when you defer the rest, it’ll significantly minimize CSS blocking time.

Slow Resource Load Time

Sure, an increase in the blocking time of JS or CSS will directly result in worse performance. But, load times can also be affected by the time it takes to load many other types of resources. Such resources include, images, videos, GIFs, text styles, and more.
Let us take a look at a few ways in which you can make these files load as fast as possible.

Image Optimization

For a lot of websites, images are the largest element in view once the page has finished loading. Hero images, banner images, or large carousels are all common examples of this. You should consider compressing images using tools like TinyPNG or TinyJPG and also convert images to the newer formats like WebP or JPEG XR. Make sure to use responsive images. You can also speed things up by serving images through an image CDN.

Preload Key Requests and Important Resources

Sometimes, important resources used in some JS or CSS file might get fetched a little later than you would like. For example, a font stuck deep in one of the many CSS files of an application can prevent the font from loading when you need it.

Use <link rel=”preload”> </code> to fetch a particular resource quickly and prioritize it over others. You can preload many types of resources, but make sure that you focus on preloading critical assets. Critical assets include fonts, above-the-fold images or videos, and critical-path CSS or JavaScript.

Text Compression

Compression algorithms (e.g., Gzip and Brotli) can significantly reduce the size of text files as they are exchanged between the server and browser. Gzip is effectively supported in all browsers. Whereas Brotli can be used in almost all newer browsers and provides even better compression results.

Final Words

The loading time and speed of your site is about to become a lot more important with the upcoming Google algorithm update. If your site does not perform well and score low for the Core Web Vitals metrics, then chances are that you’ll lose some of your hard-earned search rankings. You can either take the risk or play safe and optimize your site to satisfy the Core Web Vitals test! Having a fast website is about to get a lot more important and you should prepare for it. A pleasing UX is important not just to convert more and reduce bounces but also to maintain and improve SERP rankings!

If you’ve got any questions, you can let us know in the comments below and we’ll get back to you with answers!
Get in touch with us if you’d like us to optimize your site and get you a green score on Core Web Vitals.

The post LCP Issues – How To Fix LCP That is Longer Than 4 Seconds? appeared first on W3 SpeedUp.