Select a language
List of Core Web Vitals Recommendations (Part 2)
List of Core Web Vitals Recommendations (Part 2)
In the last part of the article on optimizing web applications, we talked about the main recommendations of the guys from Google, Largest Contentful Paint (LCP), the priority of LCP, as well as the use of CDN to optimize documents and TTFB elements. In this part, I suggest you familiarize yourself with no less important things in Core Web Vitals. And we'll start with Cumulative Layout Shift (CLS).
Cumulative Layout Shift (CLS)
The following set of recommendations relates to Cumulative Layout Shift (CLS), which is a measure of visual stability on web pages. Although CLS has improved significantly on the Internet since 2020, about a quarter of websites still do not meet the recommended threshold, so there are many opportunities left for them to improve their user experience. The first and most important of them is to set explicit dimensions for any content downloaded from the page.
Layout shifts (layout shift) usually occurs when existing content is moved after other content has finished loading. So the main way to improve this is to reserve any necessary space in advance as much as possible.
The easiest way to fix layout offsets caused by non—dimensional images is to explicitly set width and height attributes (or equivalent CSS properties). However, according to HTTP Archive, 72% pages have at least one image without size. Without an explicit size, browsers initially set the default height to 0 pixels and can cause a noticeable layout offset when the image finally loads and the dimensions are detected.
It is also important to remember that images are not the only factors affecting CLS. The layout shift may be caused by other content that is usually loaded after the initial page display, including third-party ads or embedded videos. The aspect ratio property can help in dealing with this. This is a relatively new CSS feature that allows developers to explicitly specify the aspect ratio for images as well as for non-image elements. This will allow you to set a dynamic width (for example, depending on the size of the screen), and the browser will automatically calculate the appropriate height in much the same way as it does for images with dimensions.
Sometimes it is impossible to know the exact size of dynamic content because it is dynamic by nature. However, even if you don't know the exact size, you can still take steps to minimize layout changes as much as possible. Setting a reasonable minimum height is almost always better than letting the browser use the default height of 0px for an empty element. If the height of the element turns out to be less than the specified min-height, then such a container will simply stretch a little.
Make sure the pages are suitable for bfcache
Browsers use a navigation mechanism called back/forward cache or bfcache for short. It is used to instantly load a page from an earlier or later browser history (memory snapshot).
Bfcache is a significant performance optimization at the browser level, and it completely eliminates layout shifts during page loading, which for many sites is a vulnerability where most of their CLS errors occur. The introduction of bfcache was the biggest improvement of the CLS.
Despite this, a significant number of websites are not eligible for bfcache and therefore miss this free boost in web performance.
Site owners should make sure that their pages can use bfcache, and eliminate all the reasons why this is not the case. Chrome already has a bfcache tester in DevTools, and this year it is planned to improve this tool with the help of Lighthouse.
Despite the fact that bfcache is included in the CLS section, it will also improve other key indicators.
Avoid animations/transitions in CSS
Another common layout offset problem is the animation of elements. For example, cookie banners or other notification banners that are pushed from the top or bottom often contribute to poor CLS performance. This is especially problematic when these banners displace other content, but even if this is not the case, their animation can still affect the CLS.
Pages that use CSS animation tend to have a lower CLS score. This is not surprising, because every action when performing a transition or when playing an animation leads to a shift in the layout.
What may surprise some developers is that this happens even in cases where the element is taken out of the normal flow of documents. For example, absolutely positioned elements that animate at the top or left will cause the layout to shift, even if they don't move other content. However, if instead of animating from the top or left, you animate transform:translateX() or transform:translateY(), this will not force the browser to update the page layout and, therefore, will not produce any layout shifts.
Preferring CSS animations that can be updated in the browser's linker thread has long been a best practice in terms of performance, as they move this work to the GPU rather than to the main thread. And besides being a common practice, it can also help improve CLS performance.
To summarize, never use transition and animations in CSS that require the browser to update the page layout, except when you do this in response to a user touch or keystroke (but not when hovering the cursor).
First Input Delay (FID)
Our latest set of recommendations relates to First Input Delay (FID), which is a measure of the page's response to user interaction.
New Interaction to Next Paint (INP) metric is a possible successor to FID, and all the recommendations below apply equally to both FID and INP. Considering that sites work worse with INP than with FID (especially on mobile devices), we recommend that developers consider these performance recommendations, despite the "good" FID.
Avoid or interrupt long-running tasks
Tasks are any part of the discrete work that the browser does. Tasks include rendering, linking, parsing, and compiling and executing scripts. When tasks become lengthy, i.e. 50 milliseconds or longer, they block the ability of the main thread to respond quickly to user input.
Judging by the web almanac, there is a lot of evidence that that developers could do more to avoid or break up long-running tasks. Splitting long tasks may not be as easy a case as the other recommendations in this article.
Despite the fact that you should always strive to do as little work in JavaScript as possible, you can help the main thread a little by breaking long tasks into smaller ones. This can be achieved by often giving way to the main stream so that rendering updates and other user interactions can happen faster.
Another option is to consider using APIs such as isInputPending and the Scheduler API. isInputPending is a function that returns a boolean value indicating whether user input is expected. If it returns true, you can concede to the main thread so that it can process the expected user input.
The Scheduler API is a more advanced approach that allows you to schedule work based on a priority system that takes into account whether the work being done is visible to the user or background.
By breaking large tasks into smaller ones, you give the browser more opportunities to perform critical work visible to the user, such as processing interactions and any related rendering updates.
Avoid unnecessary JavaScript
There's no doubt about it: websites are using more JavaScript than ever before, and it doesn't look like this trend is going to change anytime soon. When you send too much JavaScript, you create an environment where tasks compete for the attention of the main thread. This can definitely affect the response rate of your website, especially during the critical launch period.
However, this is a solvable problem. You have several options:
Use the coverage tool(https://developer.chrome.com/docs/devtools/coverage /) in Chrome DevTools to find unused code in your website's resources. By reducing the amount of resources needed at startup, you can ensure that your website spends less time parsing and compiling code, resulting in a smoother initial user experience.
Sometimes the unused code that you find with the coverage tool is marked as "unused" because it was not executed during startup, but is still needed for some functions in the future. This is code that you can move to a separate package using code separation.
If you use tag manager, be sure to check your tags periodically to make sure they are optimized or used at all. Old tags with unused code can be removed to make your tag manager's JavaScript smaller and more efficient.
Avoid large updates when rendering
JavaScript is not the only thing that can affect the response speed of your site. Rendering itself can be expensive work, and when large rendering updates occur, they can interfere with your website's ability to respond to user actions.
Optimizing rendering is not an easy process, and it often depends on what you are trying to achieve. However, there are some things you can do to make sure your rendering is reasonable and doesn't stretch into long tasks.:
Avoid using requestAnimationFrame() to perform any non-visual work. requestAnimationFrame() calls are processed at the rendering stage of the event loop, and when too much work is done at this stage, rendering updates may be delayed. It is very important that any work you do with requestAnimationFrame() is reserved strictly for tasks related to rendering updates.
Keep the DOM size small. The size of the DOM and the intensity of the layout work closely interact. When a renderer needs to update the layout for a very large DOM, the work required to recalculate its layout can increase significantly.
Use CSS content. CSS content depends on the CSS contain property, which gives the browser instructions on how to work with the layout for a container for which the contain property is set, including even isolating the layout and rendering area to a specific root in the DOM. This is not always an easy process, but by isolating areas containing complex layouts, you can avoid unnecessary layout and rendering work.
Conclusion
Improving the performance of a page can seem like a daunting task, especially considering that there are many guides on the internet that need to be taken into account. However, by focusing on these recommendations, you will be able to approach the problem in a focused and purposeful manner and, hopefully, improve the results of the main indicators of your website.
Although the recommendations given here are by no means the entire pool of recommendations, it is believed that these are the most effective ones with which sites can improve the performance of key indicators in 2023.
If you want to go beyond the recommendations listed here, check out these optimization guides for more information.:
Let your sites be fast for your users in all the most important aspects.
