4

I don't know why my LCP would be a p tag, and I have no idea what I would do to reduce the size of it. Sometimes it gets up to 2.6s and gives a yellow rating(instead of green).

enter image description here

This is the p tag. All of those classes are bootstrap classes.

<p className="text-center mb-md-5 mt-0 mb-5">{aboutText}</p>

This is the variable aboutText

const aboutText = `Suddenly  Magazine highlights the uniqueness of Saskatchewan,  and its sudden rise in popularity and growth mentioned in publications such as USA Today and the New York Times.

Advertorials and Articles focus on its rare & particular tourism, its passionate sports, its character, and the prosperous opportunity for businesses and artists influenced by a Saskatchewan setting.

It is centred in Saskatoon, but contributors range from Lac La Ronge in the North, to provincial boundaries east and west, to the Outlaw Caves near the US border.`

The domain is https://suddenlysask.com

Sam
  • 1,765
  • 11
  • 82
  • 176
  • I'm just realizing that i think it depends on the time of my first contentful paint. The LCP seems to always be .6 higher than the FCP – Sam Aug 10 '20 at 01:53
  • For those stumbling on this question wondering how to improve their lighthouse score in general, I posted an [answer on this topic on another question](https://stackoverflow.com/a/65440846/6331353) with lots of general tips. – Sam Jan 17 '21 at 05:12

3 Answers3

3

So why is your LCP a p tag?

Its only on mobile a p tag, and here take a look at the mobile size.

enter image description here

Its clearly to see that the p tag takes the most place here.

You could try to make the image bigger on mobile devices, so lighthouse will count the image as the LCP.

Another solution is to split up your p tag into 2 smaller p tags

Another solution could be (witch is not recommended) to cut your p tag slightly out of the viewport because...

The size of the element reported for Largest Contentful Paint is typically the size that's visible to the user within the viewport. If the element extends outside of the viewport, or if any of the element is clipped or has non-visible overflow, those portions do not count toward the element's size.

I guess your bad result comes from this line here:

<link data-react-helmet="true" rel="preload" href="https://fonts.googleapis.com/css?family=Montserrat|Helvetica+Neue|Helvetica|Arial&amp;display=swap">

Why does it take up to 2.6 sec?

Here is what i guess:

Loading the google font can take its time and its not guaranteed that it loads always exactly the same time, so when the font is loaded it will swap your fonts and that means the p tag swaps. That means that the p tag with the new font is treated as new LCP.

For testing purposes you could try to remove the link and see if it affects your speed score at your LCP

At the end, i would split the paragraph up into 2 smaller paragraphs so that the image is the LCP. i think its the easiest solution.

bill.gates
  • 14,145
  • 3
  • 19
  • 47
  • So I ran lighthouse audits on a local version of my website, using `gatsby build && gatsby serve` and discovered that my LCP doesn't really get above 1.7 locally. It's only on the server that LCP times can get higher. Also is there a way just to download the fonts and load them from a local file? – Sam Aug 13 '20 at 20:02
  • @Sam well even if you download the fonts and put them on your server your clients still need to download it as far as i know. it could be the server. LCP means largest contentful paint and if the server responsens slow why whatevery, high latency or something it increases that time too – bill.gates Aug 14 '20 at 05:04
2

People seems to completely misunderstand the purpose of the Largest Contentful Paint metric. It is designed to show you when the majority of the above the fold content is ready.

What item is the Largest Contentful Paint is not as important as when it occurs. What item is only useful in determining what could be slowing your page down.

It is the main metric in determining when 'above the fold' content is painted sufficiently that an end user would see the page as "complete" (this is perceived completeness, there can still be stuff loading lower down the page / in the background).

The suggestions of splitting the paragraph, wrapping it in a div, making it taller etc. etc. serve no purpose, they just shift the LCP onto something else (possibly) making your score look better but not actually fixing the problem.

What you want to do is optimise the initial content on the page.

For this you want to serve just the 'above the fold' HTML along with the CSS and JS required for above the fold content.

Then you serve everything else.

This article is a good introduction to critical JS and CSS https://www.smashingmagazine.com/2015/08/understanding-critical-css/

However in a nutshell inlining critical CSS and JS means that the CSS and JS required to render the initial content on the page should be inline within the HTML. Now I am guessing with something like Gatsby you would inline the critical JS that renders the above the fold content, above the fold CSS etc. but the principle is the same.

The key is that the above the fold content should all be served (except for non vector images) within the HTML so that there is no round-trip time waiting for CSS files, JS files etc.

So for clarity instead of:-

  • HTML requested, (200ms round trip to server)
  • HTML loaded and parsed, links to CSS and JS found required to render the initial page content
  • CSS and JS requested. (200ms round trip to server)
  • CSS and JS loaded
  • Enough to render the page.

Instead you have

  • HTML requested, (200ms round trip to server)
  • HTML loaded, all required CSS and JS inlined in HTML
  • Enough to render the page

This may not seem like a lot but that 200ms can make a huge difference to perceived speed.

Also this is a simplified example, often a page requires 20 requests or more to render the above the fold content. Due to the limitations of 8 requests at a time (normally) this means there could be up to 3 round-trips of 200ms waiting for server responses.

Looking at your site you will be getting a false reading for "critical request chains" as there is no HTML served in the initial page as it is all rendered via JS. This could be why you do not think there is a problem.

If you do the above your will get low FCP and LCP times assuming your images are optimised.

GrahamTheDev
  • 22,724
  • 2
  • 32
  • 64
  • I don't really understand what your trying to tell me to do. Do I have to make this not a single page application? I don't think I'm quite at the level of understanding with this stuff as you are so you might have to simplify this. All I do is is import my css files using something like `import ./styles.css` or scss – Sam Aug 11 '20 at 02:23
  • Did you read the article I linked as that is the simplest explanation of what critical CSS is? If you don't understand something in the linked article then I am happy to explain but if you don't understand **any of it** you might want to read up on how browsers render pages and what inline styles and inline script elements are (` – GrahamTheDev Aug 11 '20 at 05:02
  • You also need to realise that "I have no idea what I would do to reduce the size of it." means you don't understand it in the first place so perhaps have a quick read of https://web.dev/lighthouse-largest-contentful-paint/ and then https://web.dev/lcp/#how-to-improve-largest-contentful-paint-on-your-site and see how much of that makes sense to you, yet again ask questions if some of it doesn't make sense. FInal thing to consider - getting from 80 to 90 on PSI is about 3 times easier than 90 to 95, those last few points for 99/100 require some serious work and understanding. – GrahamTheDev Aug 11 '20 at 05:09
  • I've been told gatsby does all this automatically. Why are you saying that I have ` HTML requested, (200ms round trip to server) HTML loaded, all required CSS and JS inlined in HTML Enough to render the page ` – Sam Aug 13 '20 at 03:40
  • So I ran lighthouse audits on a local version of my website, using `gatsby build && gatsby serve` and discovered that my LCP doesn't really get above 1.7 locally. It's only on the server that LCP times can get higher. `Reduce initial server response time` is a notification i frequently get that I'm working on. I currently have a [bountied question open for it](https://stackoverflow.com/questions/62894636/reduce-initial-server-response-time-with-netlify-and-gatsby). – Sam Aug 13 '20 at 20:02
  • ok will have a look but I don't use React so my knowledge is limited there I am afraid. – GrahamTheDev Aug 14 '20 at 06:14
0

There are some Gatsby users complaining recently about a huge fall and decreasing of Lighthouse score and everyone agrees on the same: the score of the Lighthouse has decreased a lot due to a high LCP (Largest Contentful Paint) response time.

This is the result of the changes in the new Lighthouse version (v6) which in fact, introduces the LCP as a new concept and metric. As you can see, the changelog was written in may but depends on the user, and on the site, the changes arrive on different dates (I guess that depends on Google's servers and the time that this change replicates through them).

According to the documentation:

Largest Contentful Paint (LCP) is a measurement of perceived loading experience. It marks the point during page load when the primary–or "largest"–content has loaded and is visible to the user. LCP is an important complement to First Contentful Paint (FCP) which only captures the very beginning of the loading experience. LCP provides a signal to developers about how quickly a user is actually able to see the content of a page. An LCP score below 2.5 seconds is considered 'Good.'

As you said, this metric is closely related to FCP and it's a complement of it: improving FCP will definitely improve the LCP score. According to the changelog:

FCP's weight has been reduced from 23% to 15%. Measuring only when the first pixel is painted (FCP) didn't give us a complete picture. Combining it with measuring when users are able to see what they most likely care about (LCP) better reflects the loading experience.

You can follow this Gatsby GitHub thread to check how the users bypass this issue in other cases.

In your case, I would suggest:

  • Delete your <p> and check the score again to see the changes (just to be sure).
  • Wrapping your <p> inside a <div>.
  • Splitting your <p> in 2 or 3 small pieces to make them available for the LCP as well as FCP.

If none of the above work, I would try playing on <p>'s height to see if it improves the score.

I guess that Gatsby (and also Google) are working on adjusting this new feature and fix this bad score issues.

Ferran Buireu
  • 28,630
  • 6
  • 39
  • 67
  • So I ran lighthouse audits on a local version of my website, using `gatsby build && gatsby serve` and discovered that my LCP doesn't really get above 1.7 locally. It's only on the server that LCP times can get higher. I haven't been doing it locally though because the `total blocking time` and `time to interactive` always fail locally – Sam Aug 13 '20 at 20:04