Search code examples
pagespeedpagespeed-insights

Why is my Largest Contenful Paint so much larger than my page load time?

I'm optimising a WordPress website for page speed. To do so, I use the Google PageSpeed Insights to find my weak points. It is about the website goedkopewebsitezzp.nl.

A few of the measures I've taken:

  • every page is cached
  • I optimised every image with ShortPixel and they're served as WebP
  • all CSS and JS is minified and combined using a plugin. Unfortunately the CSS is still split into three files, but I can't find a way to compile that again into one.
  • I use the Cloudflare CDN
  • jQuery is loaded from Cloudflare CDN.

My current page speed score is about 65-68. The biggest 'red' factor is the Largest Contentful Paint.

enter image description here

I currently am a bit stuck how to proceed with the LCP and I don't understand why this value is so large. If you visit the website, it is quite fast. My experience is about max 2 seconds with empty caches etc.

How come that the LCP has a value of slightly less than 9 seconds, when my page loads way faster? The LCP element is the first bold header (h1 element).

I think that there is something not going alright with the theme. I also have the same problem on an other website, where I also used the same theme. The LCP there is also about 9 seconds.

Perhaps the animation is the cause, but that only takes about 200 ms. I already tried disabling it, but there weren't any numerous improvements.

I'm really stuck how to proceed with this, and as the LCP counts for 25% of the total score, I would really like to get it down to a few seconds.

Thanks a lot in advance. All help is very much appreciated!

Solution

  • Speed Index

    Speed Index is quite complicated to explain here, so I will link to this article and the original speed index that Lighthouse Speed Index is based on

    But in essence it compares a load of images of the site along a timeline as it loads. When it finds it has reached a certain "completeness" compared to the final page design it uses that time for the speed index.

    Now when you apply your full page white cover to hide all the loading going on that creates a paint event that is the whole page and this slightly skews your Speed Index.

    The figures also get skewed by long animations. You say 200ms but the performance trace thinks it is more like 400ms which matches the following item:-

    #ambition_body.fade_in_out {
    transition-duration: 400ms;
}

    So your speed index may be slightly out but if anything it is lower than it is in reality as your white cover stays way past 3.4 seconds when I apply network throttling and CPU throttling to match Lighthouse (the engine behind Page Speed Insights).

    note: This is why you see 9 seconds vs your observed 2 seconds time, Lighthouse is taking into account throttling on the network and CPU as per the linked article information in the previous paragraph.

    Largest Contentful Paint

    This does happen much later, it appears there is a slight shift in the page just as the fadeout occurs. As you can see on this performance trace it happens right before the final image in the trace (the LCP line is the one to look at).

    trace showing when LCP occurs

    This appears to be from something strange happening, perhaps with your menu.

    I turned on "paint flashing" under the "rendering" tab in Developer tools and just as the page is fading into view there is a strange flash towards the top left and then the whole page seems to repaint.

    I don't have time to find the root cause for you but my gut says see what the menu is doing on page load and see if you are hiding it with JS.

    If you are hiding it with JS and you have 0.2 second animations on every element on the site (which is not a good idea) with html * {transition: all 0.2s ease;} then this may cause an unnecessary repaint and put your LCP late.

    Actual problem.

    The problem is we can argue slightly over the numbers but your site is indeed not particularly fast.

    It weights 1.4 megabytes, which is high if you consider a mobile 3G connection may only be about 2 megabits per second (so about 250 kilobytes per second).

    Also you have nearly a megabyte of uncompressed JavaScript to compile and execute on the site (about 250kb zipped).

    That is a lot of heavy lifting on a mobile CPU.

    Try and remove some of the JavaScript bloat, it is difficult when using something like elementor (as your site seems to do) however.

    Also your speed will vastly improve if you fix your critical rendering path and and defer your JavaScript that isn't essential for "above the fold" content to be rendered.