Since its introduction in May 2020, Google’s Core Web Vitals (CWVs) suite has become an important metric for measuring website performance. Given that Google considers these values as part of their page ranking algorithm, maximizing your website’s performance in terms of CWVs not only enhances the experience for your users but improves your search engine ranking. This article will explore tips and techniques to help improve your page scores, increase user satisfaction, and boost your bottom line.
What are Core Web Vitals?
Like so many other things in technology, Google’s Web Vitals are a swarm of three-letter acronyms, each representing some measurable aspect of a website’s performance. To set the stage, let’s define the three key metrics that define the Core Web Vitals:
Largest Contentful Paint
Largest Contentful Paint (LCP): measures perceived load speed by focusing on the amount of time it takes for visible content above the fold to load. To provide an ideal user experience, LCP should be triggered within 2.5 seconds in the page load timeline.
First Input Delay
First Input Delay (FID): measures page responsiveness by measuring the delay between user actions and page response. To provide an ideal user experience, pages should have an FID of 100 milliseconds or less.
Cumulative Layout Shift
Cumulative Layout Shift (CLS): measures visual stability using a composite measurement of layout shifts on the page as it renders. To provide an ideal user experience, pages should maintain a CLS of 0.1 or less; everything between 0.1 and 0.25 is considered moderate and greater than 0.25 is poor.
… and why are they important?
For many businesses, website performance has a direct correlation with business success. Research indicates that websites with passing CWV scores may enjoy up to 37% more visibility in search results compared to pages that don’t (Beus); and that improved CWV scores can increase both revenue per visitor as well as conversion rate (Duong et al.).
While working with Akira, a women’s fashion boutique, Edgio was able to improve the website’s CWVs, bringing the first page load times from 5 seconds to ~1 second, improving CWV measurements and ultimately delivering a +30% increase in organic traffic, a +61% improvement in checkout initiations, and a 37% increase in conversion rate.
Put simply, faster websites make for better SEO rankings and happier users – specifically within the context of e-commerce websites; these combine to decrease bounce rates and increase conversions.
So, how can we improve them?
First Input Delay
Let’s start with the low-hanging fruit: First Input Delay. The good news is that websites have passing FID scores more often than not, which is great to see! If, however, that’s not the case, oftentimes, the culprit is the third-party scripts loaded early in the website’s lifecycle, which can block the main thread execution necessary to receive user input. Tools that capture errors and perform screen recording are prime candidates for additional scrutiny.
Also, while not technically a core element of the CWVs, it’s worth mentioning another related metric: Interaction to Next Paint (INP). INP measures the time between interacting with a page and the subsequent page update reflecting that interaction. While INP and FID both measure overall page responsiveness, INP is concerned with all page interactions rather than the first interaction, aiming to ensure that the page remains responsive throughout the whole session, not just the upfront interactions. INP tracks the worst interaction performance across a user’s experience and reports that to CrUX. It’s very likely that soon INP will replace FID as a measure of page responsiveness, so it’s worth keeping an eye on.
Largest Contentful Paint
Arguably the most important and impactful metric for page performance is LCP. Somewhat predictably, the most common example of Largest Contentful Paint is a “hero” image – a large image or video, usually taking up the full width of the viewport above the “fold.” Though the techniques for optimizing this element are the same as any other page resource, the time it takes for that resource to render is of pinnacle importance because this is the first main element that a user will experience.
Waiting in the Queue
Breaking down the request timing for the LCP element is tremendously useful in optimizing its performance. Any request made by a browser starts with the queue. Every millisecond LCP requests spend in the queue is a millisecond that will contribute to the LCP score, so if you find that these elements are spending a disproportionate amount of time languishing in the browser queue, investigate what’s being requested ahead of it and why, and take steps to prioritize the LCP resources. Maybe resources are below the fold, or other scripts that can be lazy-loaded or otherwise deferred. The order of operations is key.
Waiting on the Server
After initiating the network request, the browser client has to wait for the server to receive, process, and respond to that request. This metric is called the time-to-first-byte (TTFB). If the server is slow to respond to the request, your LCP score will suffer. This is one of the areas where having a CDN can significantly impact improving speed, as CDNs can keep a cached copy of the resource in a location geographically close to your end users and respond with that resource more quickly than a single application server. Other great aspects of using a CDN include built-in security WAFs and the ability to respond to large traffic spikes. If you’re going for speed, you should be using a CDN.
Wide on the Wire
By this point, hopefully, the browser will be requesting the LCP resources early in the page lifecycle, and the server should be responding to them quickly. The next element to consider is the overall size of the requested resource. Every byte that has to travel “over the wire” to the browser will take some time, and the more of those bytes there are, the longer it will take for the request to complete. Therefore care should be taken to ensure that resources are as small as reasonably possible to minimize the time spent transferring them. This might include using 3rd party image optimization and hosting services such as kraken.io or imgix.com, which can both optimize and serve media files in “NextGen” formats such as WebP, further reducing the size.
Help The Browser Out
In addition to size optimizations, consider using <picture> tags, which will enable the browser to choose the right resource to request for the device more intelligently. A desktop browser may have large swathes of screen real estate to display higher-resolution images; however, those same resources will bog down a mobile device with a smaller screen. Using optimized resources and CSS media queries, you can ensure that the browser requests the right resource for its device type and cut down on time spent transferring bytes from the server to the client.
Additionally, you can give the browser a helping hand by asking it to preload LCP resources and specifying a fetch priority. These will give the browser clues to prioritize key resources ahead of less critical ones. The faster things get to the browser, the faster they can be rendered, and the faster the LCP happens, the better.
Cumulative Layout Shift
We see it all the time. After sending your browser off to fetch a website, the page begins to load; while the page builds out, you see the piece you’re interested in and move to click it when suddenly the whole page shifts and the link you thought you were about to click is suddenly somewhere else! This phenomenon is called layout shift. It’s annoying for everyone, usually self-inflicted, and we should strive to minimize it for the good of humanity.
The Usual Suspects
Typical culprits for higher CLS scores are:
- Sticky headers
- Promo or “Hero” banners that are loaded and rendered client-side
- Newsletter, Coupon and GPDR notices
- Other 3rd party integrations that are dynamically injected into the page
Set Some Boundaries
Remember the <picture> element we referenced while discussing LCP? Don’t forget to add dimensions to the various elements contained therein. Omitting these values takes you out of the driver’s seat when directing the browser on how to render these elements. By defining the dimensions, the browser can set aside the correct amount of space into which the image will be painted, reducing the shift.
The same is true for any content that might be dynamically added to the page. Advertisements, <iframe>, or other dynamically added content can contribute to CLS. The page content will shift less by reserving space for these items ahead of time. Also, avoid adding the content above existing page content, as this will cause the entire page to shift below.
Helping the browser to carve out the space ahead of time will reduce the CLS but may come at the expense of the overall user experience as the user waits for these portions of the otherwise blank page to become populated with useful content. As a middle ground, implementing element loading skeletons can be a useful technique to communicate to the user that there’s more to come, giving the impression of a faster experience while the browser does the rest of the heavy lifting to coordinate the additional page contents. What’s more is that these can and should, be implemented using CSS animations rather than animated GIFs, meaning that just a few lines of CSS can be used to implement this technique across your entire website.