You might have noticed that your LCP will often be worse than your FCP. This is quite common, as the header, hamburger menu or (inlined) SVG logo will be rendered sooner than the rest of the page. But what does it mean if your LCP and FCP are almost the same?
See the situation below:
The image above is a screenshot of a mobile PageSpeed Insights results of a Magento 1 homepage. Yes, there still are some M1 shops out there, but I've seen the same within other shops and platforms as well.
And we can see that the 75th percentile FCP (4 seconds) and LCP (4.1 seconds) are quite close. This means users are apparently seeing the largest element hero image pop in right after the page got rendered for the first time.
As a matter of fact, when directly querying the CrUX database using Google's API, mobile FCP and LCP are as following:
- FCP: 4.05 seconds while max 1.8 seconds is recommended;
- LCP: 4.11 seconds while max 2.5 seconds is recommended.
FCP and LCP bottleneck
We basically don't only have an LCP bottleneck, we also have a huge FCP bottleneck. As a matter of fact, when seeing a PageSpeed Insights report with almost equal FCP and LCP, there is a common bottleneck impacting both metrics at the same time.
Chances are: A/B testing. A/B testing is often used to determine better alternative webpage versions or copy to increase conversion. But when implemented without consideration (or properly reading the guides), it's likely to break your visitor's real user experience too.
When running into such situation, be sure to look for A/B testing best practices for your A/B testing provider. Using a self-built A/B testing solution? Reach out to get your implementation evaluated.
