This is part 3 of An introduction to Core Web Vitals, a 3 part series about Core Web Vitals. Core Web Vitals refer to three key metrics that provide a good measure of your website’s user experience. However, in June 2021, Core Web Vitals became one of the ranking signals that Google uses to rank its search engine results. Thus Core Web Vitals began to not only impact conversions but traffic as well. As such, they are one of the most important parts of SiteImp audits.
Last article
Last article, I talked about First Input Delay (FID). FID refers to the gap between when a user interacts with a page and when their browser is ready to respond to the input. Preventing input delay is usually a matter of thinking carefully about what resources you really need on your pages. Once you go through that, discard what you don’t need. And defer the resources that you need later, but not right at page load. Ultimately, the more tasks you can remove from your browser’s UI thread, the lower the input delay.
This article
This article, we’re going to talk about the other performance-centric core web vital. Largest Contentful paint measures how quickly the main content of a page loads and is fully visible to users.
Measuring when content is visible is obviously really important but it’s traditionally been very hard to measure. Older metrics like load or DOMContentLoaded don’t always correspond to what users really see on their screens. Rather, they can incorporate lots of things that happen behind the scenes that may not directly impact user experience.
Then, developers started measuring first contentful paint. First contentful paint is useful so it’s included in all SiteImp audits. But it’s still misleading because it measures the first contentful paint. It captures the beginning of the page load, whereas the middle is usually more interesting.
After that, Google started recommending metrics like First Meaningful Paint and Speed Index. These metrics are useful so they’re in all SiteImp reports, but they’re still often wrong. First Meaningful Paint and Speed Index don’t always accurately capture when the most important content on the page has loaded.
So then, simplicity won and Largest Contentful Paint became the king of metrics. It assumes that site designers will devote the most screen real estate (above the fold) to the most important content on the page. That’s usually a very good design decision, so it’s a safe assumption to make. And while Largest Contentful Paint isn’t perfect, it’s more accurate and easier to explain than other metrics.
So, Largest Contentful Paint became one of the Core Web Vitals. As previously stated, LCP tries to measure quickly the main content loads. To do this, it finds the largest img, video, image (with an svg block) or text block within the viewport and calculates how long it takes to render relative to when the page first started loading.
Preventing long largest contentful paint times
The easiest way to prevent long LCP times is to spend time thinking about all the resources you load on a page. Once again, smaller is better. The fewer resources you download and the smaller the total transfer, the fewer the opportunities for LCP to rear its head and hurt how your users perceive your website.
Ultimately, the shorter your critical rendering path, the shorter your LCP time. The absolute easiest way to shorten your critical rendering path is to decrease the number of resources you need as part of your critical rendering path. You can do this by either removing them from your site entirely or by choosing to defer them.
Web fonts are a major contributor to LCP so again, ask yourself how far you can go with system fonts. Images are a major contributor, so choose the right format, compress them appropriately and serve them on the fastest resources available to you.
Once you’ve carefully considered your resources and pruned everything you don’t really need, you can start looking into other optimizations. Improving server response times is a great second stage optimization. Database driven websites will traditionally show good LCP improvements once they implement proper database caching.
Web developers should learn and apply the PRPL pattern. PRPL is beyond the scope of this article, but I’ll explain the acronym:
- Preload the most important resources.
- Render critical assets as quickly as possible.
- Pre-cache remaining assets.
- Lazy load the rest of the assets.
I’ll explain PRPL more in a future tutorial and we’ll talk about pre-caching and lazy loading both routes and assets. You can seriously speed up your Javascript with this pattern and I highly recommend learning more about it.
End of introduction to Core Web Vitals
Thank you for reading the series! If you have any questions or comments, please use the contact page.