CLS problem with slideout overlay and page hero

Hm..anyone out there?

Hi there,

your topic slipped past our system - so please accept our apologies for not replying sooner.

Can you disable the Optimized CSS delivery (Critical CSS) option in WP Rocket - the automatic method is one of the main causes of CLS that we see.

Okay..that seems to have done something. However, I still get the LCP issue for div class="page-hero grid-container grid-parent"

Is the background image in the Header Element the Featured Image?

yes it is.

Try adding this PHP Snippet:

add_action( 'wp_head', function() {
    if( is_single() ) {
        if ( wp_is_mobile() ) {
            $featured_img_url = get_the_post_thumbnail_url(get_the_ID(),'medium_large'); 
            echo '<link rel="preload" as="image" href="'.$featured_img_url.'"/>';
        } else {
            $featured_img_url = get_the_post_thumbnail_url(get_the_ID(),'full');
            echo '<link rel="preload" as="image" href="'.$featured_img_url.'"/>';
        }
    }		
});

How to add PHP: https://docs.generatepress.com/article/adding-php/

This will preload the background image, including a smaller attachment size for Mobile.

Hm..tried that but doesn't seam to work :(

well the code is working as the image request is now being made before the HTML is loaded....
But the file its outputting is still 183kb ... how large was the original image in file size ?

The image is 1200 by 801 pixels and the file size is 188kb.

Well Google PSI is definitely having a turn on this one... LCP on background images are awfully hit and miss.
As this cannot be explained:

https://www.screencast.com/t/XxDFIFug

If you check the first frame of the filmstrip highlighted in Red box you can see the LCP ( featured image ) element. If there were the actual delay between FCP and LCP time then that featured image would not be visible in the first frame... going by the FCP/LCP timings i wouldn't expect to see it anywhere near the first frame.

Which makes it really hard ( impossible ) to debug. We're preloading the featured image, as you can see here in the waterfall report:

https://www.webpagetest.org/result/210511_BiDcGE_ae9694fae6582736726d45afd843af48/1/details/#waterfall_view_step1

its the first request to be made after the HTML has loaded. So theres not a request delay.

So this leaves it down to two possiblities ( in my mind anyways ):

1. The size of the image - google may just be 'simulating' that image takes longer to display then it is.
Reducing the size of the image would help.

We could try a quick test, in the code above you will see:

medium_large and large - change them both to medium so we can see if it pulls in the smallest of images.

2. Inteference from other scripts - aside of the unexplainable film strip - i notice every PSI report i ran there were completely different opportunities being flagged. One of the common one was the ezoic ad scripts causing render blocking. You can try deferring those scripts using a plugin like Flying Scripts.

In addition to this - running multiple tests i get various results and various opportunities. They never seem to be the same.

Okay..you seem to be switching up some things here.
- I am not with Ezoic, so I doubt there is Ezoic code running ;-)
- In your PHP code there was no large, just a full. I changed that to medium as well. Tho no change at all.

Aah my bad - false of habit - i meant mediavine ( just saw an Advert script ) appearing in a render blocking opportunity in PSI.

Remove the above snippet and try adding this instead:

add_action( 'wp_head', function() {
    if( is_single() ) {
        $featured_img_url = get_the_post_thumbnail_url(get_the_ID(),'medium'); 
        echo '<link rel="preload" as="image" href="'.$featured_img_url.'"/>';
        echo '<style>
        @media(max-width: 500px) {
            .page-hero { background-image: url('.$featured_img_url .');}
        }
        </style>';
    }		
});

doesn't seem to work either. It does seem to improve the speed score on two out of three requests, tho. God...I hate these core vitals

Well that code is definitely an improvement. On mobile networking test - the image is preloaded ( first in the request queue ) and its a tiny 13kb. Thats a 170kb saving! It loads so fast it actually appears before the logo....
Tested on Lighthouse locally the FCP is 1.3s ( matching Google PSI ) and the LCP is a consistent 2.2s.

But we still see the anomaly on PSI.

So the only thing i can consider is that 'something' else is interfering with the API that measures the LCP element. I still see the Mediavine CSS being preloaded ( the browser complains its preloaded but not used with a short time ) and then theres all the scripts that they load.

A simple to test to determine whether the advert code is interferring would be to temporarily disable it.

As other than this - i am at total loss !