Core Web Vital Tooling

Core Web Vitals launched by Google are very practical. When we initially focused on performance, we focused on: Reduce requests! Cache content! Reduce file size! While these are closely related to web page performance, they are abstract. For users, the actual web page performance is reflected in: how long does it take to wait to see the page content? How long does it take to be able to actually interact with a page (e.g., enter content in a form or click a link)? Does the page content jump annoyingly when I try to perform an action? This is the cleverness of core web metrics: they measure these aspects.

The Lighthouse tab of Chrome DevTools now contains these metrics:

It is important to keep an eye on these metrics because remember that in addition to these numbers that will benefit users directly once they visit your website, they can also affect whether users will visit your website. Core web metrics are being incorporated into SEO and new carousel requirements previously reserved for AMP pages only.

Tracking these metrics for one-time audits is useful, but more importantly, observing them over time to prevent performance degradation. Performance tools such as Calibre cover these metrics. New Relic also includes these metrics. SpeedCurve tracks these metrics.

Cumulative layout offset (CLS) is a difficult problem. For example, the website has an ad at the top of the article. Requests for this ad are asynchronous, so the ad is likely to delay occurrence and push down the article content. Not only is this annoying, it can also seriously affect performance metrics and ultimately affect SEO.

Nic Jansma's "Cumulative Layout Offset in Practical Applications" provides an in-depth discussion.

CLS is more than just "Does the page do this?". As shown in the picture above, it has a score. I think 0 is a good goal, because no version of CLS is good for anyone. There are a lot of nuances in this, such as tracking “integratedly” (e.g. in headless browsers, especially in performance tools) and real users on your actual website (called RUM or real user metrics). Both are useful.

If you need to fix your CLS problem, this can be tricky. SpeedCurve Some new tools can help:

For each layout offset, we display films with two frames before and after the offset. We then draw a red box around the moving element, highlighting the exact element that caused the offset. The layout offset score for each offset also helps you understand the impact of that offset and how it is added to the cumulative score.

I hope this will make eradicating and fixing the problem very easy. Especially those tough questions. I didn't know this before, but CLS could be caused by a more nuanced problem, which Mark Zeman points out in the article. For example:

• Only horizontally moving picture carousels trigger CLS. This feels bad because that's exactly what they should do, but obviously you can fix this by just using CSS transform mobile carousels.
• If you have a very large area, there is a greater risk of moving that area. If it moves just a little bit, it will seriously affect the CLS.
• The flashing of style text (FOUT) is the reason for CLS. Even if this is beneficial to performance for other reasons! contradiction! This is a good excuse to fall back with a perfect font.

Tough but important questions. I do need to incorporate performance tests into my CI/CD, which will go a long way to solving this problem. It is becoming increasingly felt that web performance is a complete career subcategory of web development. Front-end web developers do need to understand this and help to some extent, but we already have a lot to do.

The above is the detailed content of Core Web Vital Tooling. For more information, please follow other related articles on the PHP Chinese website!