Largest Contentful Paint is a metric that measures how quickly a page’s main content loads and paints its visual elements to the screen. In this article, you will learn what a good Largest Contentful Paint Score is, how Largest Contentful Paint is measured, how to optimize servers, networks, and more!
What is Largest Contentful Paint (LCP)?
First, the “paint” in largest contentful paint is for when pixels on your screen are rendered or painted in. Second, paint events, known as performance entries, are tracked and analyzed every time the browser paints through the performance observer browser API.
Many events occur every time a pixel is updated, so there is a separate and more useful largest contentful paint event. A contentful paint event is a paint event that draws the pixels of a handful of DOM elements, called image elements.
The largest contentful paint is painted when the element uses the most pixels on our user screen.
How is LCP Measured?
LCP is the number of seconds between the very first bite that the page is loaded and the final largest contentful paint event as soon as users touch tap or interact with the page. When that window of time closes, LCP stops being measured. Whatever element had the highest number of seconds between the first byte and when it was painted is reported for the LCP for that URL. Like every other part of page experience, every page on your website has an LCP score.
What is a good LCP score?
Your home page may have a less than stellar LCP, but your product or article pages could have fantastic results. Neither page impacts how the other performs on this metric. All of these results are generated by, and collected from, people using your site.
So, what is a good or bad LCP score? The most important thing to remember is that LCP is just one part of page experience, one of the many inputs that search has. Therefore, there isn’t a pass or fail score. However, it is just a number used to compare similar sites to determine which site users have a better experience.
A good goal to aim for is that your largest contentful paint happens in less than 2.5 seconds for at least 75 of the sessions on your page.
How to Find Your LCP Score
Site owners can quickly get all web vitals and page experience results on the Google Search Console page experience report. The search console gives valuable insights into how web pages and how the entire website is performing. For example, to find your LCP score, you can go to the web vital section of the page experience report, and any URLs below a 2.5-second goal will be highlighted. If anything on this page is highlighted, it helps users locate the specific URL that needs improvement.
The only LCP score that matters is the one in the page experience report, as this score comes from actual users of your website. Occasionally, site owners will have trouble determining the reason for the score. This could be because users are using an older device or a device relatively different than the one you are using. However, you can find this information inside your site’s analytics, which helps to understand better what kind of experience people are having on that particular page.
Once you get your LCP reporting close to the actual report, you can use the performance observer API to get more information about an LCP event. From here, you can check out the element attribute for each entry. This will give you the actual live DOM node that triggered this LCP event.
Elements that Affect LCP
After identifying the LCP score and the elements causing it, you can find solutions to reduce all LCP problems, such as slow servers, slow networks, or codes that slow performance.
Servers
Whenever troubleshooting, it is beneficial to start with the server LCP measures from the browser’s first byte until users interact with the page. If the server is running slow or not fully optimized, it inflates the LCP before the browser code can start running.
Site owners will want to reduce their server logic and operations to essential tasks while ensuring that the CMS and backend are caching pages rather than rebuilding them on every request. For caching, make sure that your static files, like images, style sheets, and scripts, are served with long-lived caching headers that will reduce the number of files your server has to send out.
Networks
Even if the server is turbocharged and the front end is performing well, if the network is slow, it will undermine all of the work of the server. Therefore, it is essential to be using a CDN (content delivery network). These are services you can get to serve copies of the content on your server on their servers. For example, if your server is in Los Angeles but in San Francisco, a CDN will copy those files and store them closer to the end-user. Less distance means less time spent on the wire, so files load faster, bringing down the LCP.
The most popular CDNs will have data centers located near the vast majority of people in the world. First, however, review the analytics for your website and choose the best CDN for your users.
Significant gains in speed can also be accomplished using a service worker, which is a script that your browser runs in the background, separate from a web page, opening the door to features that don’t need a web page or user interaction.
Front End Code
LCP measures what is on the user’s screen and stops being reported once the page is interacted with. The element that triggers the LCP will likely be in the initial area shown at the top of the page when the URL is first loaded, called the initial viewport. Therefore, it is important to make sure whatever is rendered in the initial viewport can do so as fast as possible.
The first thing that can be done is to remove any scripts and style sheets in the document’s head that aren’t being used on the page. These block and slow the browser down.
Some attributes can be added to any script tag that can help to speed up its rendering, such as defer and async. Browsers can only do one thing at a time, and by default, it will go from the top to the bottom of the code, downloading and parsing everything one line at a time. If adding the async attribute to the script tag, telling the browser that we are not relying on any other resource on the page, it will execute as soon as it is finished downloading. If the script is essential and needs to run as quickly as possible, the async attribute is an excellent second choice after directly inputting the script into the head.
If the script needs to be on the page but is in no rush, defer is a great option. While scripts that use async may interrupt the browser from rendering other parts of the DOM, they execute immediately after downloading. Defer is more polite and tells the browser that it can download and process other things on the page but won’t interrupt the browser to be executed. Defer will run after the page has been fully parsed. Defer is a great idea for anything that isn’t critical for the initial viewport.
If any assets are hosted on other domains, such as a CDN, you can jumpstart the work the browser needs to do by adding the DNS prefetch or preload metadata to the page. DNS prefetch is a signal to warn that content will need to be or is going to be downloaded from this domain in the future.
Usually, as the browser processes the source code of the page, it will discover URLs of assets that need to be downloaded. Next, the browser will use DNS to access the asset’s IP address. By using DNS prefetch, the browser goes through the process of fetching the DNS to discover the IP address in the background while processing the page, so by the time the URL is needed the DNS has already resolved, making the website load faster.
Of course, there is more work to be done. However, if you follow best practices and only load content over HTTPS, the browser needs to initiate a handshake to the server before bytes can be downloaded. Handshake is when a few messages get passed back and forth from the browser to the server and back to secure communication between them. Adding a preconnect statement to the page allows the process to happen faster by letting the server know it is okay to work in the background.
Another similar concept to DNS prefetch and preconnect is preload. Preload is another piece of metadata that will tell the browser that we can download and parse the content. However, if you preload too many things, the browser can get bogged down and perform even worse than it does without it. Preload is best when used on content that is extremely important. Preload can be used on scripts, style sheets, images, videos, web fonts, and most things that trigger an LCP event.
There are some key things that you should ensure on your page to make sure that your site is running efficiently. The first one is using efficient images, making sure the images are not larger than they need to be, and compressing images down as much as possible. Every byte saved on our initial viewport means the LCP happens more quickly. Adding lazy load for images that are not in the initial viewport tells the browser that we can delay loading these images since they’re less likely to be seen right away. This allows it to free up other resources making room for more critical content. It is important to make sure you are not adding this to content in your initial viewport, potentially deprioritizing it and negatively impacting the LCP.
Edge Cases
LCP does not look at the largest element on the user’s screen. Instead, it looks at the element with the most visible pixels. So if you have a large element that is clipped or has its opacity set to zero, then those non-visible pixels aren’t counted towards its size.
LCP only looks at an element’s initial position and size to ensure that you don’t hurt browser performance. So if it’s rendered on the screen and is moved off, it can still likewise count. However, if it renders off the screen and is animated onto the screen, it will not be measured by LCP.
Since LCP is what users are seeing, you may get some bad LCP scores. For example, if a page gets loaded into the background window or tab, those pages will be loaded slower and lower priority than tabs with the foreground. So, dive into your analytics to look for patterns that might explain weird results when in doubt.
Due to the security model on the web, you can’t get LCP information from an iframe on your page, at least by default. However, as far as the browser is concerned, that content still impacts your URL’s LCP. So, if you’re monitoring your LCP via performance observer, you may miss the LCP events reported by the browser. You can avoid this by adding cores to the iframes and having them report their values to the parent iframe. If possible, iframes are something users want to try to avoid.
Performance observer does not emit events when you get to the page using the back or forward browser buttons because those pages are cached in the browser. So the same events in the pipeline are not being executed. However, the browser still reports the LCP information for those situations.
While this is not so much an edge case, it is an important tip. Users can get a sneak preview of LCP scores. While the canonical information only comes out every 28 days, you can keep track of your actions by using your analytics and the performance observer code.