How to Optimize LCP (Largest Contentful Paint)

How to Optimize LCP (Largest Contentful Paint)

1. QuikRead

How long it takes a user to see any content displayed on the screen is one factor that contributes to a bad user experience. The time it takes for the first DOM material to render is measured by First Contentful Paint (FCP), however, it does not include the time it takes for the biggest (typically more meaningful) material on the page to render.
LCP (Largest Contentful Paint) is a Core Web Vitals statistic that determines when the viewport’s largest content element becomes visible. It may be used to tell when the page’s primary content has completed rendering on the screen.
In this article, you’ll learn how to optimize LCP.

2. What factors contribute to a low LCP score?

Slow server response times

A sluggish server will have a negative impact on all of your website’s loading speed metrics. Even if your other resources are optimized, if your server isn’t functioning well, it’ll all be for nothing.

Render-blocking JavaScript and CSS

If you keep adding new plugins to your website or choose a theme with a lot of design elements, you might want to reconsider. The use of JavaScript and CSS, particularly above the fold, has a significant impact on loading speed. When a browser encounters synchronous scripts and external stylesheets, the rendering of a web page is delayed.

Slow resource load times

Above-the-fold images, videos, and text-block components have a direct impact on LCP. To improve loading times, large items like hero banners must be optimized.

Client-side rendering

For many web developers, client-side rendering is popular. It renders web pages in the browser using JavaScript. JavaScript, on the other hand, has a significant influence on LCP since the browser must first load all critical JavaScript before it can finish rendering.

Follow More Articles

Contact Us

3. Slow server response times

The longer it takes for a browser to receive content from the server, the longer it takes for anything to be rendered on the screen. Every single page-load measure, including LCP, is directly improved by a quicker server response time.
Improve how and where your server processes your content before doing anything else. To measure server response times, use the Time to First Byte (TTFB) method. You may increase your TTFB in a variety of ways:
  • Optimize your server
  • Route users to a nearby CDN
  • Cache assets
  • Serve HTML pages cache-first
  • Establish third-party connections early
  • Use signed exchanges

Optimize your server

Are you executing time-consuming queries on your server? Or are there additional sophisticated server-side procedures that cause the process of delivering page content to be delayed? Analyzing and increasing the performance of your server-side code will reduce the time it takes the browser to get data.
Many server-side web frameworks must construct the web page dynamically rather than providing a static page in response to a browser request. To put it another way, rather than transmitting a complete HTML file that is already ready when the browser requests it, frameworks must perform logic to build the page. This might be due to waiting database query results or because a UI framework needs to convert components into HTML (such as React). Many server-side web frameworks include performance suggestions that you may utilize to speed up this process.

Route users to a nearby CDN

A Content Delivery Network (CDN) is a collection of servers located around the world. Because their browser queries must practically go across the world, if the content on your web page is hosted on a single server, your website will load slower for users who are geographically farther away. Consider deploying a content delivery network (CDN) to ensure that your users never have to wait for network requests to reach distant servers.

Cache assets

If your HTML is static and doesn’t need to change with each request, caching can save you time by not having to generate it. Server-side caching reduces TTFB and saves resources by keeping a copy of the produced HTML on disc.
There are a variety of approaches to implement server caching depending on your toolchain:
  • When placed in front of an application server, configure reverse proxies (Varnish, Nginx) to provide cached content or operate as a cache server.
  • Configure and monitor the cache behavior of your cloud provider (Firebase, AWS, Azure).
  • Use a content delivery network (CDN) with edge servers to cache and store your material closer to your users.

Serve HTML pages cache-first

When deployed, a service worker operates in the background of the browser and can intercept server requests. This level of programmatic cache management allows you to cache some or all of the content of an HTML page and only update the cache when the content changes.

Establish third-party connections early (To be written by the developer)

Use signed exchanges (SXGs)

Signed exchanges (SXGs) are content delivery technology that allows for quicker user experiences by delivering material in a manner that is readily cached. SXGs will be cached and occasionally prefetched by Google Search. SXGs may be a significant technique for optimizing LCP for sites that receive a big amount of their traffic from Google Search. See Signed Exchanges for further details.

4. Render blocking JavaScript and CSS

A browser must parse HTML markup into a DOM tree before it can render any content. If any external stylesheets (<link rel=”stylesheet”>) or synchronous JavaScript tags (<script src=”main.js”>) are encountered, the HTML parser will halt.
Both scripts and stylesheets are render-blocking resources, delaying FCP and, as a result, LCP. To speed up the loading of your web page’s core content, defer any non-critical JavaScript and CSS.

Reduce CSS blocking time

Using the following, ensure that just the bare minimum of CSS is obstructing render on your site:
  • Minify CSS
  • Defer non-critical CSS
  • Inline critical CSS

a. Minify CSS

CSS files can include characters like space, indentation, and comments to make them simpler to read. All of these characters are superfluous for the browser, and by minifying these files, they will be deleted. At the end of the day, lowering the amount of blocking CSS will always improve the time it takes to fully render the page’s core content (LCP).
Include an appropriate plugin to minify CSS files on every build if you use a module bundler or build tool:
For Gulp: gulp-clean-css

b. Defer non-critical CSS (To be checked by the developer)

To detect any wasted CSS on your web page, utilize the Coverage tab in Chrome DevTools.
To improve:
Remove any unneeded CSS from your site or relocate it to a different stylesheet if it’s needed on a different page.
Use loadCSS to load files asynchronously for any CSS that isn’t required for initial rendering, leveraging rel=”preload” and onload.
html<link rel=”preload” href=”stylesheet.css” as=”style” onload=”this.rel=’stylesheet'”>

c.Inline critical CSS

Include any critical-path CSS used for above-the-fold material directly in <head>to keep it inline. The necessity for a round-trip request to acquire vital CSS is eliminated when crucial styles are inlined. CSS blocking time is reduced by deferring the rest.
Use a library to automate the procedure if you can’t add inline styles to your site manually. Here are several examples:
The packages Critical, CriticalCSS, and Penthouse all extract and inline above-the-fold CSS.
Critters is a webpack plugin that loads the remainder of the CSS after the important CSS has been inlined.

Reduce JavaScript blocking time

Download and deliver only the bare minimum of JavaScript to users. Reduced blocked JavaScript results in a quick render and, as a result, a better LCP.
This may be done by optimizing your scripts in a variety of ways:

5. Slow resource load times

Although an increase in CSS or JavaScript blocking time will directly affect paint timings, the time it takes to load numerous other types of resources might also have an impact. LCP is influenced by a variety of factors, including:
  • elements using the <img> tag
  • Within an <svg>element, <img> elements
  • <video> elements (LCP is measured using the image on the poster )
  • The url() method is used to load a background image for an element (as opposed to a CSS gradient)
  • Text nodes or other inline-level text components in block-level components
If certain items are presented above the fold, the time it takes to load them has a direct impact on LCP. There are a few things you can do to guarantee that these files load as quickly as possible:
  • Image optimization and compression
  • Important resources should be preloaded.
  • Text files should be compressed.
  • Depending on the network connection, deliver various assets (adaptive serving)
  • Using a service worker, cache assets.

Optimize and compress images

When a website has done loading, photos are often the largest element visible. This can be seen in the form of hero pictures, big carousels, or banner pictures.
LCP will be accelerated by reducing the time it takes to load and draw certain sorts of pictures. To do so, follow these steps:
  • Instead of using a picture, think about not using one at all. Remove everything that isn’t related to the content.
  • Images should be compressed (with Imagemin for example)
  • Convert photos to a more modern format (JPEG 2000, JPEG XR, or WebP)
  • Use photos that are mobile-friendly.
  • Consider employing a content delivery network (CDN) for images.

Preload important resources (To be written by the developer)

Compress text files

Text files (HTML, CSS, JavaScript) may be compressed greatly using compression techniques like Gzip and Brotli as they are sent between the server and browser. Gzip is supported by all browsers, while Brotli, which offers even greater compression, is supported by practically all contemporary browsers.
Compressing your resources reduces the size of their delivery, reducing load times and, as a result, LCP.
  • Check first to see whether your server compresses files automatically. Most hosting platforms, CDNs, and reverse proxy servers either compress assets by default or provide you the option to do so.
  • If you need to change your server to compress files, use Brotli instead of gzip because it has superior compression ratios.
  • Once you’ve decided on a compression strategy, compress assets ahead of time during the development process rather than when the browser requests them. This reduces server costs and latency while making requests, particularly when utilizing high compression ratios.

Adaptive serving (To be written by the developer)

Cache assets using a service worker

As noted previously in this article, service workers may be utilized for a variety of activities, including serving smaller HTML answers. They may also be used to cache any static resource that can be provided to the browser instead of being downloaded from the internet on subsequent requests.
Using a service worker to cache key resources can drastically improve load times, especially for visitors who reload the web page with a slower connection (or even access it offline). Workbox libraries can make the process of updating precached assets easier than developing a bespoke service worker yourself.

6. Client-side rendering

Client-side JavaScript logic is used by many websites to render pages directly in the browser. Single-page apps that handle different aspects of a web page fully on the client rather than on the server have become easier to construct thanks to frameworks and libraries like React, Angular, and Vue.
If you’re creating a site that’s largely rendered on the client, you should be aware of the impact a huge JavaScript package might have on LCP. Users may not be able to see or interact with any content on the page until all of the important JavaScript has completed downloading and running if optimizations aren’t in place to avoid it.
Consider the following optimizations while creating a client-side rendered site:
  • JavaScript should be kept to a minimum.
  • Make use of client-side rendering.
  • Make use of pre-rendering.

Minimize critical JavaScript

If the information on your site only becomes visible or interactable once a particular amount of JavaScript is downloaded, it is even more vital to reduce the size of your bundle as much as possible. This may be accomplished by:
  • JavaScript Minimization
  • Deferring JavaScript that is no longer in use
  • Using as few polyfills as possible
Return to the section on reducing JavaScript blocking time to learn more about these techniques.

Use server-side rendering

For sites that are largely client-rendered, the first priority should always be to reduce the amount of JavaScript used. However, in order to optimize LCP as much as feasible, you should also consider incorporating a server rendering experience.
The server renders the application into HTML, and the client subsequently “hydrates” all of the JavaScript and needed data onto the same DOM content. This can enhance LCP by guaranteeing that the page’s primary content is rendered first on the server rather than solely on the client, but there are a few drawbacks:
  • Keeping the same JavaScript-rendered application on the server and the client might add to the complexity.
  • When opposed to providing static pages from the server, using JavaScript to display an HTML file on the server always increases server response times (TTFB).
  • A server-rendered page may appear to be interactive, but it cannot respond to any user input until all client-side JavaScript has been run. In summary, it might worsen Time to Interactive (TTI).

Use pre-rendering

Pre-rendering is a distinct strategy that is less complex than server-side rendering and also provides a way to increase LCP in your application. During the build process, a headless browser, which is a browser without a user interface, is used to produce static HTML files for each route. These files may then be sent alongside the JavaScript bundles required for the application.
TTI is still badly impacted by pre-rendering, but server response times aren’t as bad as they would be with a server-side rendering solution that dynamically draws each page only when it’s requested.

Developer tools

LCP can be measured and debugged using a variety of tools, including:
Lighthouse 6.0 now adds functionality for measuring LCP in the lab.
When you hover over the Related Node field in Chrome DevTools, the LCP marker appears in the Timings part of the Performance panel, indicating which element is related to LCP.
Chrome DevTools LCP
Chrome User Experience Report delivers aggregated real-world LCP metrics at the origin level.

7. Finishing up

The Largest Contentful Paint statistic is a deceptively basic yet powerful technique to track when significant material appears in the user’s viewport. With all of the other measures at our disposal, we’re coming closer to a uniform, universal method of precisely assessing web performance while keeping the user experience in mind.

Follow More Articles

Contact Us

Jun 11th, 2021|
This website or its third party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy . By tapping on "I accept" you agree to the use of cookies.