SEO

How to Optimize Core Web Vitals for eCommerce Websites

Core Web Vitals will be added into Google's ranking algorithm. Websites that are slow to load, become interactive and visually will rank lower than they currently do, come early 2021.

Google’s upcoming Page Experience update introduces signals derived from Core Web Vitals (CWV) into the official ranking algorithm. Core Web Vitals are a set of metrics that measure the speed in which pages load, become interactive and visually stabilize for real users who interact with them. Websites that fail the Core Web Vitals test will rank lower than they currently do come early 2021.

CWV consists of 3 speed metrics found to have a major impact on a user’s perceived experience. These include Largest Contentful Paint (LCP) to measure load times, First Input Delay (FID) to measure interactivity and responsiveness, and Cumulative Layout Shift (CLS) to measure visual stability. While website speed has been at the forefront for many eCommerce companies, it’s about to become one of the most important factors in the online landscape. Here are the metrics you must focus on and how to improve speed for each.

What are the Core Web Vitals

Making a good first impression online is critical. Shoppers want to see products immediately, browse quickly and checkout easily—with no interruptions. If their expectations aren’t met, they’ll bounce and never return. Core Web Vitals helps address this problem by gauging the experience pages provide to mobile shoppers as they browse through a site in real-time. 

While most Google tools rely on synthetic tests which take place on simulated environments (known as lab data), Core Web Vitals are measured using field data collected from Google Chrome User Experience (CrUX)—a database of real-world Chrome user data. Field data captures the dramatic effects of real-user variables, such as device, network conditions and/or settings. Depending on a user’s conditions, the performance of a site can vary dramatically and impact your Core Web Vital scores.  

Each CWV metric has different thresholds to be considered good, moderate or poor. However, they all have one thing in common and that is that Google uses the 75th percentile when classifying pages into these groups—a page that hits the threshold to be considered fast for 75% of the page loads or more is a good experience.

You can’t optimize what you do not know, so let’s get to know each of the three metrics that make up the Core Web Vitals.

Source: https://web.dev/vitals/

Largest Contentful Paint (LCP)

Users typically feel that the page has loaded when the largest content element is fully visible on the screen, i.e. by the speed of the Largest Contentful Paint, or LCP. Content elements can include: block-level elements, images (including images inside SVG files) and videos. For eCommerce, LCPs usually measure the speed in which the product image / hero image loads. If this is slow, users assume the entire experience will be similar, which leads them to leave for a competitor’s site.

LCPs of 2.5 seconds or less are considered fast, pages with LCPs between 2.6 and 4.0 seconds need improvement and LCPs that are longer than 4.0 seconds are slow. 

TheTieBar.com loads LCP in 800ms on Moovweb XDN

In the example above, you can see Tie Bar’s LCP is marked at 900ms, when the main image is fully painted. Tie Bar consistently delivers sub-second page loads to mobile shoppers while still delivering customization, real-time inventory lookups and dynamic pricing on its thousands of pages on Moovweb XDN.

Typically, LCP is affected by one of the following:

  1. Slow server response times
  2. Render-blocking JavaScript and CSS
  3. Long resource load times
  4. Client-side rendering issues

To optimize your LCP, consider the following:

  1. Optimize server response times by routing traffic to the closest CDN PoP available, caching assets, using a service worker and establishing third-party connections early with "rel="preconnect"."
  2. Reduce JavaScript blocking time by minifying code (e.g. removing whitespace), compressing data with tools like Broti or Gzip, splitting bundles and sending only what's necessary at the beginning, and serving code with newer syntax with tools such as Babel

    Reduce CSS by removing any unused CSS or unnecessary characters such as spacing, indentation, or comments, and by inlining critical CSS by including it directly in the head of the page. 
  1. To reduce resource load times, optimize and compress image and text files, preload important resources, deliver different assets based on network connection and cache assets using a service worker.
  2. Optimize client-side rendering by reducing JavaScript blocking time (see #2 to optimize for this), using server-side rendering (SSR) and pre-rendering.

First Input Delay (FID) 

While a user’s first impression is impacted by the speed at which the largest image is rendered, it’s just as important for your site to be responsive once your user tries to interact with it. First Input Delay, or FID, measures the time from when a user first interacts with a page (clicks, taps, or presses a key) to the time when the browser is actually able to respond to that interaction.

Typically, an input delay occurs because JavaScript is being executed on the main thread—and by default, all JavaScript is render-blocking. This means that when the browser comes across a JavaScript file, it must pause what it's doing to download, parse, compile, and execute that JavaScript. The longer this takes, the more delay a user experiences and the less Google will view the page as usable. 

Google considers an FID of 100 milliseconds or less as fast, between 1.1 and 3.0 seconds as needing improvement and over 3.0 seconds as slow. While it’s important to strive for the 75th percentile for all Core Web Vitals, Google recommends looking at the 95th–99th percentiles for FID on mobile and desktop, as this will represent the worst user experiences and verify the areas that need the most improvement (as it will focus on the FID for 95%+ of the page loads). 

It’s also important to note that opposed to LCP and CLS, FID can only be measured in the field (and will not be found in lab data), as it requires a real user interaction. 

Common reasons for slow FIDs include: 

  1. Long tasks that block the main thread for 50 milliseconds or more
  2. First-party script execution delaying interaction readiness
  3. Heavy JavaScript execution time

How to optime for FID:  

  1. Break down long-running code into smaller, asynchronous tasks and utilize code-splitting. 
  2. Move heavy script loading (and execution) for non-essential components off the critical path and minimize cascading data fetches and how much data needs to be post-processed on the client-side. 
  3. Use a web worker, such as Comlink, Workway or Workerize, which make it possible to run JavaScript on a background thread, code-split your JavaScript bundle into multiple chunks (also known as lazy-loading), and load all third-party scripts with defer or async.

Cumulative Layout Shift (CLS) 

A page’s visual stability is another contributing factor that impacts the user experience and can halt shoppers from continuing down the path-to-purchase. The third and final metric in Core Web Vitals is Cumulative Layout Shift, or CLS, which measures how often users experience unexpected layout shifts. 

You’ve experienced these instances: You’re about to tap a link or product image, but right before you touch the screen the page moves, and bam, you click something else unintentionally. Best case scenario, these situations are a slight annoyance, but worst case you send shoppers searching for a smoother, less janky experience on the web.

Google calculates these page movements by multiplying the impact fraction, or how much visible content shifted in the viewport, by the distance fraction, or the distance an unstable element has moved in the frame divided by the screen's largest dimension (height or width). The sum total of all individual scores (impact fraction x distance fraction) for each unexpected layout shift that takes place while a shopper browses, results in a page’s CLS. 

Google considers a CLS lower than 0.1 as good, between 0.1 and 0.25 as moderate and greater than 0.25 as poor. 

If you find a poor CLS, it’s likely due to one of the following:

  1. An image or video resizing itself
  2. Ads resizing
  3. Font that loads late and is displayed larger or smaller than intended

To improve this metric, consider the following:

  1. Include exact dimensions on your images and video elements.
  2. Avoid popup ads or banners. Instead, statically reserve a large space for the ad slot.
  3. Avoid flashes of unstyled or invisible text (FOIT/FOUT) with tools such as font display and the Font Loading API.

How Moovweb XDN helps optimize speed for each Core Web Vitals metric 

Large, complex eCommerce websites with millions of pages, 1000s of SKUs, A/B tests and personalization, dynamic pricing and real-time inventory lookups can achieve sub-seconds speeds with Moovweb XDN. In fact, the XDN is the only platform on the market to guarantee sub-500ms median LCPs. 

On the XDN, content instantly renders, or paints, on a page and becomes immediately tappable due to our application-aware, JavaScript configurable CDN called CDN-as-JavaScript. It utilizes advanced predictive prefetching along with edge computing to stream dynamic content (JSON/SSR/HTML) from the edge into the user’s browser—before it's even requested. This keeps sites 5 seconds ahead of shoppers' taps at all times. 

Websites on the XDN have a 95%+ cache hit ratio for HTML and JSON data at the edge, while sites on traditional CDNs average at 6%. This is a huge difference in delivering the content that typically makes a website slow. 

Schedule 1-on-1 Demo

Schedule a consultative conversation now to learn how the Moovweb XDN can help you achieve sub-second page loads.

Click here!

Bottom line

Fast page loads are the difference between delighting shoppers and scaring them off for your competitor’s site. Core Web Vitals take into account a user’s first impression of speed, interactivity and visual stability by measuring Largest Contentful Paint, First Input Delay and Cumulative Layout Shift. If speeds are longer than 2.5s for LCP, 100ms for FID or .1 for CLS, you can assume both users and Google perceive your site as slow. Google will lower your rank and consumers will bounce and never return.

In just a couple months, a poor page experience will not only hurt your brand’s reputation, but will impact your SEO ranking. Protect your hard-earned SEO by using the optimization tactics offered above, or go instant with Moovweb XDN

XDN is your all-in-one solution to develop, deploy, preview, experiment on, monitor, and run your frontend. Shoe Carnival, REVOLVE, and 1-800-Flowers, are just a few examples of eCommerce websites that deliver sub-second speeds and are reaping the benefits of it. If you have any questions about the Page Experience update, or how to speed up your site, we’d be happy to put you in touch with a site speed expert today

Google’s upcoming Page Experience update introduces signals derived from Core Web Vitals (CWV) into the official ranking algorithm. Core Web Vitals are a set of metrics that measure the speed in which pages load, become interactive and visually stabilize for real users who interact with them. Websites that fail the Core Web Vitals test will rank lower than they currently do come early 2021. 

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Newsletter
Get great insight from our expert team.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
By signing up you agree to our Terms & Conditions

Don't wait another second. Go instant.

Get started in seconds