Since their introduction in May of 2020, Google’s suite of Core Web Vitals (CWVs) have become important metrics 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. In this article, we’ll explore some tips and techniques to help improve your page scores, increase user satisfaction, and boost your bottom line.
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 (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 (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 (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.
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.).
We have a case study that, 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 - and specifically within the context of e-commerce websites, these combine to decrease bounce rates and increase conversions.
Let’s start with the low-hanging fruit: First Input Delay. The good news is more often than not, websites have passing FID scores, 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 which is 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 it takes 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, thereby 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 in the near future INP will replace FID as a measure for page responsiveness, so it’s worth keeping an eye on.
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,” and 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.
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 there are resources below the fold or other scripts that can be lazy-loaded or otherwise deferred. The order of operations is key.
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 with the request your LCP score will suffer. This is one of the areas where having a CDN can have a significant impact on 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. There are other great aspects of using a CDN, like 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.
By this point, hopefully the browser is requesting the LCP resources early in the page lifecycle, and the server should be responding with them quickly. The next element to consider is the overall size of the resource being requested. Every byte that has to travel “over the wire” to the browser is going to take some amount of 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 the use of 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.
In addition to size optimizations, consider the use of <picture> tags, which will enable the browser to more intelligently choose the right resource to request for the device. 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. Through the use of 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, as well as 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.
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, it’s usually self-inflicted, and we should be striving to minimize it for the good of humanity.
Typical culprits for higher CLS scores are:
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
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 it comes to 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. By taking care to reserve space for these items ahead of time, the page content will shift less. Also work to 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.
Get the information you need. When you’re ready, chat with us, get an assessment or start your free trial.