How to Optimize Core Web Vitals for eCommerce Websites

TheTieBar.com loads LCP in 800ms on Layer0 (Edgio)

In the example above, 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 delivering customization, real-time inventory lookups, and dynamic pricing on its thousands of pages on Edgio.

Typically, LCP is affected by one of the following:

• Slow server response times
• Render-blocking JavaScript and CSS
• Long resource load times
• 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.
3. To reduce resource load times, optimize and compress image and text files, preload essential resources, and deliver different assets based on the network connection and cache assets using a service worker.
4. 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 crucial 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 can respond to that interaction.

Typically, an input delay occurs because JavaScript is executed on the main thread—and all JavaScript is render-blocking by default. 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 the 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 as opposed to LCP and CLS, FID can only be measured in the field (and will not be found in lab data), as it requires 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 fetch 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 makes 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. In the 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 total of all individual scores (impact fraction x distance fraction) for each unexpected layout shift that occurs 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. A font that loads late and is displayed larger or smaller than intended

To improve this metric, consider the following:

1. Include the exact dimensions of 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 Layer0 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 Layer0. In fact, Layer0 is the only platform on the market to guarantee sub-500ms median LCPs.

On Layer0, 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 and 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 Layer0 have a 95%+ cache hit ratio for HTML and JSON data at the edge, while sites on traditional CDNs average 6%. This is a huge difference in delivering the content that typically makes a website slow.

Bottom line

Fast page loads differentiate between delighting shoppers and scaring them off for your competitor’s site. Core Web Vitals consider 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 of months, a poor page experience will hurt your brand’s reputation and impact your SEO ranking. Protect your hard-earned SEO using the optimization tactics offered above, or go instantly with Layer0 (now Edgio).

Layer0 is your all-in-one solution to develop, deploy, preview, experiment, 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 at 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.