Google Shows How To Fix LCP Core Web Vitals

Google Shows How To Fix LCP Core Web Vitals

Barry Pollard, the Google Chrome Web Performance Developer Advocate, explained how to find the real causes of a poor Lowest Contentful Paint score and how to fix them.

Largest Contentful Paint (LCP)

LCP is a core web vitals metric that measures how long it takes for the largest content element to display in a site visitors viewport (the part that a user sees in a browser). A content element can be an image or text.

For LCP, the largest content elements are block-level HTML elements that take up the largest space horizontally, like paragraph <p>, headings (H1 – H6), and images <img> (basically most HTML elements that take up a large amount of horizontal space).

1. Know What Data You’re Looking At

Barry Pollard wrote that a common mistake that publishers and SEOs make after seeing that PageSpeed Insights (PSI) flags a page for a poor LCP score is to debug the issue in the Lighthouse tool or through Chrome Dev Tools.

Pollard recommends sticking around on PSI because it offers multiple hints for understanding the problems causing a poor LCP performance.

It’s important to understand what data PSI is giving you, particularly the data derived from the Chrome User Experience Report (CrUX), which are from anonymized Chrome visitor scores. There are two kinds:

URL-Level Data
Origin-Level Data

The URL-Level scores are those for the specific page that is being debugged. Origin-Level Data is aggregated scores from the entire website.

PSI will show URL-level data if there’s been enough measured traffic to a URL. Otherwise it’ll show Origin-Level Data (the aggregated sitewide score).

2. Review The TTFB Score

Barry recommends taking a look at the TTFB (Time to First Byte) score because, in his words, “TTFB is the 1st thing that happens to your page.”

A byte is the smallest unit of digital data for representing text, numbers or multimedia. TTFB tells you how much time it took for a server to respond with the first byte, revealing if the server response time is a reason for the poor LCP performance.

He says that focusing efforts optimizing a web page will never fix a problem that’s rooted in a poor TTFB sore.

Barry Pollard writes:

“A slow TTFB basically means 1 of 2 things:

1) It takes too long to send a request to your server
2) You server takes too long to respond

But which it is (and why!) can be tricky to figure out and there’s a few possible reasons for each of those categories.”

Barry continued his LCP debugging overview with specific tests which are outlined below.

3. Compare TTFB With Lighthouse Lab Test

Pollard recommends testing with the Lighthouse Lab Tests, specifically the “Initial server response time” audit. The goal is to check if the TTFB issue is repeatable in order to eliminate the possibility that the PSI values are a fluke.

Lab Results are synthetic, not based on actual user visits. Synthetic means that they’re simulated by an algorithm based on a visit triggered by a Lighthouse test.

Synthetic tests are useful because they’re repeatable and allow a user to isolate a specific cause of an issue.

If the Lighthouse Lab Test doesn’t replicate the issue that means the problem isn’t the server.

He advised:

“A key thing here is to check if the slow TTFB is repeatable. So scroll down and see if the Lighthouse lab test matched up to this slow real-user TTFB when it tested the page. Look for the “Initial server response time” audit.

In this case that was much faster – that’s interesting!”

4. Expert Tip: How To Check If CDN Is Hiding An Issue

Barry dropped an excellent tip about Content Delivery Networks (CDNs), like Cloudflare. A CDN will keep a copy of a web page at data centers which will speed up delivery of the web pages but will also mask any underlying issues at the server level.

The CDN doesn’t keep a copy at every data center around the world. When a user requests a web page the CDN will fetch that web page from the server and then will make a copy of it in that server that’s closer to those users. So that first fetch is always slower but if the server is slow to begin with then that first fetch will be even slower than delivering the web page straight from the server.

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *