CODEWITHSUNDEEP
wordpressperformancepagespeedcore-web-vitals
user9437856
user9437856

Reputation: 2388

How to improve the Core Web Vital after getting 95 above in performance

I am using WordPress and Wp-rocket is installed on my website.

Now my issue is, I am getting 98 in the performance but my Core Web Vitals Assessment still shows Failed.

Any idea how to solve core web vitals? LCP is showing 2.9s. Do I need to work on this?

enter image description here

Upvotes: 0

Views: 580

Answers (1)

Barry Pollard
Barry Pollard

Reputation: 46040

Core Web Vitals are measured over field data, not the fixed, repeatable definitions that lab-based tools like Lighthouse uses to analyse your website. See this article for good discussion on them both.

Often times Lighthouse is set too strictly, and people complain it shows worse performance than is seen by the site's real users, but it is just as easy to have the opposite as you see here. PageSpeed Insights (PSI) tries to use settings that are broadly applicable to all sites to give you "insights" into how to improve your performance but the results should be calibrated towards the real-user data that you see at the top of the audit.

In your case, I can see from your screenshots that you are seeing a high Time to First Byte (TTFB) in your real user data of 1.9 seconds. This makes passing the LCP limit of 2.5 seconds quite tough as it only leaves 0.6 seconds for that.

The question is why are you seeing that long TTFB in the field, when you don't see the same in your lab-based results - where you see a 1.1 second LCP time - including TTFB? There could be a number of reasons, and several potential options to resolve:

  • Your users are further away from your data centre, whereas PSI is close by. Are you using a CDN?
  • Your users are predominately using poorer network conditions than Lighthouse uses. Do you just need to serve less to them in these cases? For example, hold back images for those on slower network conditions using the Effective Connection Type API and only load them on demand so LCP is text by default? Or don't use web fonts for these users. Or other forms of progressive enhancements.
  • Your page visits are often jumping through several redirect steps - all of which add to TTFB, but for PSI you put the end of URL in directly so miss this in the analysis. This can often be out of your control if the referrer uses a link shortener (e.g. Twitter does).
  • Your page visits are often from uncached pages, that take time to generate. But when using PSI you run the test a few times, and so are benefiting from that page being cached and so is served quickly. Can you optimise your back-end server code, or improve your caching?
  • Your pages are not eligible for the super-fast in-memory bfcache for repeat visits when going back and forth throughout the site, which can be seen as a free web-performance win!.
  • Your pages often suffer from contention when lots of people visit at once, and that wasn't apparent in the PSI tests.

Those are some of the more common reasons for a slow TTFB but you may understand your sites, your infrastructure, and your users better to understand the main reason. Once you solve that, you should see your LCP times reduce and hopefully pass CWV.

Upvotes: 1

Related Questions