Skip to content
More coming soon.
At Kanopi, we closely monitor (a subset of Web Vitals) during development which was introduced in June 2021 into Google’s ranking algorithm. Ensuring healthy Web Vitals throughout the build and/or maintenance is of paramount importance and requires a shift not only in how we go about building components, but in maintaining a high level of quality across overall user experience.
Cross Discipline Approach
At Kanopi we acknowledge that achieving healthy Web Vitals across the board is not siloed to one discipline. Ensuring healthy Web Vitals requires a cross discipline approach spanning Front-end Engineering, Web Engineering, Systems, Audience and Revenue and Visual Design.
As defined by Google, the 3 Core Web Vitals are currently:
Largest Contentful Paint
Largest Contentful Paint is an important metric for measuring perceived user performance, specifically loading performance.
This metric reports the render time of the largest element on the page that is visible to the user.
An LCP score of 2.5 seconds or less is considered to be a conducive measurement for good user experience.
LCP is measured in seconds (s) and can be tracked against the following DOM elements:
How to diagnose Largest Contentful Paint
The quickest way to diagnose the Largest Contentful Paint element on the page is by following these steps:
How to fix Largest Contentful Paint
Once you have diagnosed which element on the page has the Largest Contentful Paint, the next step is to figure out why.
There are 3 main factors that contribute to LCP:
It’s important that your server is optimized in a way that doesn’t have a domino effect on other vitals.
To measure the “speed” of your server you can track the vital.
Here are some high-level guidelines for ensuring Largest Contentful Paint occurs as fast as possible:
The time it takes the browser to fetch resources like images or videos can also have an effect on LCP:
Cumulative Layout Shift
Cumulative Layout Shift measures the visual stability of a web page.
CLS can be an elusive metric to get right as elements targeted as having a layout shift are often not the root cause. By ensuring
limited layout shifts on the page, visitors will be presented with a smooth and delightful user experience.
A CLS score of 0.1 or less is considered to be a conducive measurement for good user experience.
It’s important to understand that the CLS metric does not just measure one offending element. The CLS score reported is the sum total of all layout shifts on the page. A layout shift occurs any time a visible element (i.e above the fold), changes its position from one rendered frame to the next.
To be clear, a layout shift is only considered a problem if it’s unexpected - so a shift in an elements position that was triggered on purpose by a user is acceptable.
It’s useful to know that a layout shift can be caused by the following events:
Considering the above, it would be plausible that nearby DOM elements could then change their position and dimensions based on another elements movement.
How to diagnose Cumulative Layout Shift
The quickest way to diagnose an element that has undergone a layout shift is by following these steps:
As an alternative, you can also diagnose Layout Shifts on the page by:
How to fix Cumulative Layout Shift
Elements that cause CLS can be easily fixed in some instances. As a general rule of thumb ensure that:
Handling Ad Sizes
When it comes to ads, it’s important that slot sizes are consistent in order to prevent CLS. Ads are generally difficult to predict considering that Ad Servers can serve ads at different heights and widths depending on impression data. There are a number of ways to mitigate this:
googletag.pubads().addEventListener('slotRenderEnded', function(event) {
var size = event.size;
if(size === null) return;
var slot = event.slot;
var slotDiv = document.getElementById(slot.getSlotElementId());
if (size[0] > slotDiv.clientWidth) {
slotDiv.style.width = size[0] + 'px';
}
if (size[1] > slotDiv.clientHeight) {
slotDiv.style.height = size[1] + 'px';
}
});
Handling Web Fonts
Handling FOUT (Flash of Unstyled Text) and FOIT (Flash of Invisible Text) have become a much discussed topic recently. It’s important to be aware that your page could subscribe to either of the unwanted side-effects of embedding custom fonts. Here’s what you can do to mitigate those effects:
First Input Delay
First Input Delay measures the interactivity of the web page. It quantifies the user’s experience with regards to how fast the page load feels.
By maintaining a low FID score, users will feel like the page is loading faster.
First Input Delay is specifically purposed for measuring how quickly the page becomes interactive to the user on their first impression, where as a vital such as First Contentful Paint measures how quickly the page becomes visible. These are 2 important concepts to grasp when it comes to debugging and diagnosing Core Web Vitals.
An FID score of 100 milliseconds (ms) or less is considering to be a conducive measurement for good user experience.
FID is a unique Core Web Vital and is not actually tracked in Lighthouse or other service metrics. FID is a field metric, meaning that its score is generated by collating data from millions of websites accessed by Google Chrome users. When it comes to generating a score for FID “in the lab” or otherwise through Lighthouse, you will be looking to improve the metric. You can think of TBT as a proxy to FID. This is because FID requires a real user and real users cannot be “spoofed” by Lighthouse.
Most importantly, this vital measures the delay from when an event has been received to when the main thread of the browser is idle, this is also known as “input latency”. The “event” can include user events like clicks or taps, but there are far more events in JavaScript that do not require actual user input. FID does not measure the time it takes to actually process the event in JavaScript or the time that it takes to update the UI based on event handlers.
How to diagnose First Input Delay
Unfortunately, diagnosing Total Blocking Time in Chrome is not as easy as diagnosing Largest Contentful Paint or Cumulative Layout Shift.
One of the biggest clues for diagnosing TBT is identifying heavy JavaScript execution on the main thread. This requires an understanding of how the browser parses HTML and JavaScript as well as what is known as a . A Long Task is any JavaScript-based task on the main thread that takes longer than 50 milliseconds (ms) to execute. While the browser is executing a JS task on the main thread, it cannot respond to any user input, as JavaScript is not a multi-threaded language.
You can identify any Long Tasks on your webpage by following these steps:
Using Google Chrome’s “Coverage” tab can provide critical insight into how much of the JavaScript on the page is actually being used.
Identifying this code can help you off-load non-critical JavaScript until after page load.
How to fix First Input Delay
FID can be fixed in a number of ways that relate to analyzing JavaScript performance:
We’ve already discussed at a high-level what Long Tasks are, but more importantly, we want to make sure that these long tasks can be broken up into smaller, asynchronous tasks. This can be achieved by code-splitting your JavaScript bundles using syntax as well as keeping an eye on polyfill’s clogging up your main bundle. Fallback polyfills can add a tremendous amount of bloat to bundle sizes.
Other factors to look at are the size of your JavaScript bundles as well as how many JavaScript files your page is loading during initial load. If the main thread has to parse unnecessary JavaScript that may not be needed by the user the chance of Long Tasks preventing user interaction during load rises exponentially. Where possible you should also defer the fetching of data from API services as network latency can also effect TBT.
One area of conversation (especially with clients) should be around the number and purpose of 3rd-party scripts. Multiple 3rd-party scripts can quickly become unmaintainable and lead to delayed JavaScript execution. Ensuring 3rd party scripts use the async and defer attributes can also help improve latency.
Measuring
A plethora of tools have become available to manage and maintain healthy Core Web Vitals. In fact, most performance/reporting based tools now offer some kind of Web Vitals-based data. At Kanopi, we use the following tools to report accurate Web Vital metrics:
This library can be used during development to diagnose Web Vital metrics. It comes with a fairly easy to understand API that directly tracks
Web Vital data on page load. The data can be a bit hard to read but if you’re looking for a programmatic approach to understanding the health
of your web page, this library won’t let you down.
import {getLCP, getFID, getCLS} from 'web-vitals';
getCLS(console.log);
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.