Caleb is a Frontend developer and Technical writer. He enjoys creating JAMStack applications with Next.js.
Published on
The performance of a software is a very important metric that is used to measure its usability when actual humans use them. These metrics are further categorized based on the time of feedback that users get or give when they’re making use of your software.
A great tool, which is a common one also, is the Chrome Developer Tool. It provides a suite of options that you can use to measure the performance of a web application and how you can improve it for future purposes so that you build software that is inclusive and user-centric for people to use on the web.
These performance metrics are categorized below. You should take a look at them.
Now that you have seen the user-centric web performance metrics that can be measured, let us dive into the main scope of this article — which is to measure, or identify the Largest Contentful Paint element on a webpage with the Chrome Developer Tool.
The Largest Contentful Paint metric is an important performance metric that is measured to determine the specific load speed of a webpage. It represents more of a timeline from when the content on a webpage isn’t visible, to a point where it is available for the visitor to use the information on that webpage.
This metric is dependent on the usability of such a website or webpage. Hence, questions like — “can the user interact with this page or not” — are necessary.
This performance metric — the LCP — gives us the approximate time it takes for the largest image or text block to be rendered in the browser. In a general perspective, it is the time taken for all the content of a webpage to be visible within the viewport of the webpage.
Results from various performance metric tests have shown that a good LCP score is between 0 to 2.5s, when the score begins to go beyond the 3.0s threshold, then a lot of work needs to be done concerning the performance. According to the Largest Contentful Paint API in the W3 Consortium standards, the types of elements that have the Largest Contentful Paint are;
The elements above should be given the utmost attention when you’re trying to build high performant apps that work on the web. Image elements are known to cause a huge amount of slow page load time in websites over the years.
That is why attributes like the loading and preload values are added to image resources or external ones.
These options are added to elements that we suspect might be having a Large Contentful Paint, which would bring about a poor user experience for people visiting our websites/app.
Google’s Chrome Developer Tool provides a lot of functionalities for us, and one of them is the performance metrics tab that allows us to measure the user-centric metrics of a website which we can use to improve the user experience that can be delivered to people in the future.
If you are on Windows, you can open Chrome Dev Tools with these key combinations Ctrl + Shift + i , on a Mac, these key combinations does the trick CMD + Shift + C.
Now that you have opened the Dev Tools in Chrome, locate the “Performance” tab, and click on it, once that is done, you will have something that is similar to the image below.
In the image above, we’re taking a look at a website that supposedly doesn’t have elements that may generate a Largest Contentful Paint, because the website contains texts. But, before we go deep into that, let’s continue from where we stopped.
Now that you have clicked on the “Performance” tab, you can click on the “refresh” icon — the one with a red arrow pointing to it. Do not forget to select the type of device that you’d love to check this performance metric on.
The image below shows the results of the performance metrics of this website. When I hover on the “LCP” block in the “Timings” row, it detects the element with the Largest Contentful Paint, by highlighting that element.
As I mentioned before that this website contains mostly texts, you would think that the LCP performance metric will be nice right? But, guess what? It isn’t.
If you can recall, The Largest Contentful Paint API standards indicate that the block-level element also has high LCP, which means that it’ll take some time before the content is completely visible in the browser’s viewport.
You can take a look at the “Frontend developer & Technical writer” text as it is wrapped in a block-level element — a <div> — in Chrome’s Dev Tool below;
Let’s take a look at another website, say, for example, Unsplash’s website. As you know, this website is a library of high-quality images, and your first guess is that the website will have a lot of elements with Large Contentful Paint times.
Well… you may be right, and you might also be wrong. But, let’s repeat the same process that we made on the previous website, up to the LCP result level.
Taking a look at the image below, you’d notice that, upon hovering on the “LCP” item in the “Timings” row, the image element with a className of ”qq9Ze” is the Largest Contentful Paint element
You may be wondering why this particular image — and not all the images on this website — is the Largest Contentful Paint element. Well… this is because this element is a background image and its source is referenced in a different way.
Take a look at the image below, when the element is hovered upon, in the “elements” tab.
In the previous sections, we took a look at the concept of the performances of websites or applications that are built to work on the web, the overview of the Largest Contentful Paint metric and how it affects the UX — user experiences — of people visiting these websites, and how to find the LCP element with Google’s Chrome Developer Tool.
In this section, we’ll go over the basic things that we can do to optimize our applications to suit this — Largest Contentful Paint — metric. Let’s take a look at some of them below.
The Largest Contentful Paint performance metric is mostly affected by the following factors:
One of the common ways to improve your LCP, when it comes to the assets — images, fonts etcetera — that you’re using on your website is to optimize those images. There are lots of service providers out there that can get that done for you. An example is Imagekit
Imagekit helps you to optimize your images by providing an image CDN for you to use, hence, leaving you with one less thing to worry about when building your applications. You can also check out Cloudinary.
A way to optimize your LCP performance metric for client-side rendering is to enforce the best practices of this process. As we know that any application or website that is rendered on the client-side depends on JavaScript for the content to be rendered in the browser.
Until the JavaScript that powers such websites has been fully executed, you will not be able to see the content, which will therefore result in a poor LCP performance metric.
There are some common patterns that you can practice when you’re trying to optimize this metric in a client-side rendered application, they are:
Fortunately, a lot of popular frontend Frameworks have been adopting these patterns. Next.js, the React framework for building user interfaces came up with this model — one that included pre-rendering and SSR — when they announced their product.
Earlier on, in the previous week, Nuxt.js shipped support for these features in their latest version. The easiest way to start optimizing for your LCP performance metric is to use an image CDN service provider like Cloudinary or Imagekit.
As important as the optimization of images are to the Largest Contentful Paint of a website. There are some resources that block some elements from be rendered when the page is loaded for the first time, and they are commonly found in the <head /> section of a webpage.
Some of these resources are external JavaScript files and css stylesheets.
The styles of your website will deter the rendering of all HTML elements on your webpage, since the stylesheets have to be fetched so we don’t end up rendering an unstyled website.
In situations where you need to make use of external script files in your webpage, it is always advisable that you add the defer or the async attribute so that the rendering of all the elements on that website isn't dependent on it.
Another way to fix the render-blocking JavaScript is to write the script with an inline syntax. So instead of the normal approach of referencing your scripts, you'd have something like the one below
But, the tradeoff of the approach above is that, you can't use it for large scripts, it is recommended that you employ this method when your script is smaller in size.
One way to fix the stylesheets from blocking elements is to check for unused CSS rules or declarations and remove them from the stylesheets.
You may be wondering how you can know which style rule(s) are not currently in use. Well… there's a feature of the chrome developer tool that shows the overview of all the styles in your website.
You can use the tool to discover unused style declarations, media queries and you can even get a an overview of the fonts you're using on your website. There's an article here that explains how you can use the tool.
Another approach would be to split your stylesheets based on how important they are to the website.
Say, for example, you have some animation on your website that have been declared with some keyframes, you can decide to improve the UX of the people that visit your website.
Animations on a webpage deals with the motion of elements, and some people have vestibular disorders which is a type of disorder that is related to motion sickness.
You can conditionally render animations for people who do not have these disorder, by using the prefers-reduced-motion media query to show animations to people who need them.
The syntax can be seen below.
The syntax above will render the animation stylesheets for people who have not set a preference for the type of motion they'd be getting on their devices.
This approach doesn't only improve the UX of your website, it also adds an improvement to the overall performance of your website.
We hope that you have been able to gain something from this article!
Get visual proof, steps to reproduce and technical logs with one click
Continue reading
Try Bird on your next bug - you’ll love it
“Game changer”
Julie, Head of QA
Try Bird later, from your desktop