Are you a GenerateCustomer?

Do you have an active GP Premium or GenerateBlocks Pro license key?

Create a GenerateSupport account for GeneratePress and GenerateBlocks support in one dedicated place.

Create an account
Already have a GenerateSupport account? Login

Just browsing?

Feel free to browse the forums. Support for our free versions is provided on WordPress.org (GeneratePress, GenerateBlocks).

Want to become a premium user? Learn more below.

Largest Contentful Paint

  • Hi Guys,
    Just moved to GP from Divi to eliminate poor performance. Have just created the homepage and before moving to the other pages, I want to ensure I have the optimal performance poss so I can carry this through to all the other pages with best practice etc. Am with cloudlfare apo, kinsta etc. and using permatters, and having followed all the tutorials etc. I still hit a performance wall.

    Speed scores are infinitely better (thanks) but I still get some areas for improvement on a fairly lean homepage. LCP keeps mentioning the main homepage image. I’ve tried pre-loading / lazy loading, css selector lazy load etc, but still can’t get more performance. Any ideas? Any pointers for the rest of the page? Want the site to be as fast as poss as this was the purpose of the investment in the rebuild.

    Thanks so much!

  • Hi there,

    In the PageSpeed Reports beneath the Treemap, there is Show audits relevant to option – and select the LCP.

    There are 3 main opportunities:

    Reduce initial server response time
    This will impact the LCP times for TTFB and potentially the Load Delay and Load Time. This time is related to how long it takes the server to process the request.
    NOTE: It maybe the Host is throttling the staging sites performance, its quite common to see, so a big improvement may be seen when the site is pushed to production. You may want to confirm this with the host.

    Largest Contentful Paint element
    The LCP element is the image, and in the image’s HTML we can see the lazyload class. That is an indicator that the image is being lazyloaded.
    Whatever plugin you’re using to lazy load the image, use its settings to ignore that image. As you don’t want it to lazyload images that above the fold.

    Eliminate render-blocking resources
    Use Perfmatters to resolve the issue. It has options to defer the loading of resources, which in this case the JS file.

  • Thanks very much Alvind.

    Staging is lower spec machined so think there will be some performance gains to be had.

    Just surprised the main image is flagging so highly. I’m now NOT lazy loading. But can’t understand why a small image is taking so long to load. Any ideas?

    Getting 90 on mobile page speed, and 95 ish on desktop. Am I missing something?

    Thanks

    Thanks!

  • Hi there,

    Background Images are loaded via CSS.
    So they prone to performance issues, as first the stylesheet must be loaded and parsed by the browser before the image request can be made.

    One method is to:

    1. add a Featured Image to the page, which will be used as the hero background.

    2. use the Disable Element metabox to disable the featured image, so the Theme doesn’t output it at the top of the page.

    3. select the Container with the Background Image.
    3.1 activate its Dynamic Data and set it to display the Featured Image as the background. This is our fallback.
    3.2 in Advanced > Additional CSS Class(es) add: page-hero

    4. Add this PHP snippet to the site:

    
    add_action( 'wp_head', function() {
        if( is_front_page() ) {
            $featured_img_url = get_the_post_thumbnail_url(get_the_ID(),'medium_large');
            $featured_img_url_full = get_the_post_thumbnail_url(get_the_ID(),'full');
            echo '<link rel="preload" media="(max-width: 768px)" as="image" href="'.$featured_img_url.'"/>';
            echo '<link rel="preload" media="(min-width: 769px)" as="image" href="'.$featured_img_url_full.'"/>';
            echo '<style>
            @media(max-width: 768px) {
                .page-hero:before { background-image: url('.$featured_img_url .') !important;}
            }
            @media(min-width: 769px) {
                .page-hero:before { background-image: url('.$featured_img_url_full .') !important;}
            }
            </style>';
        }		
    },1000);
    

    On the home page that snippet will preload a featured image based on the screen size ( Full for desktop, Medium Large for mobile ) and then overwrite the background image of the page-hero container

  • Hi David,
    Brilliant. I’ll give this a try. Superstar.

  • Presumably the code can also be for the homepage, desktop view? The abide appears to read for tablet and mobile only?

    Final Q. If a log of my pages follow the same layout, I can extend the php to account for them?

    Thanks David!

  • It applies to Desktop too. The code outputs:
    the medium_large image for screen sizes of 768px and below.
    the full image for screen sizes of 768px and below.

    To apply it the same process to pages too.
    Change this line:

    if( is_front_page() ) {

    to

    if( is_front_page() || is_page() ) {

  • Thanks David,
    I’ve implemented the changes you kindly suggested, but made little improvement.
    After some reading, I also added fetchpriority=”high” – again, not much improved. Weird.

    echo ‘<link rel=”preload” media=”(max-width: 768px)” as=”image” href=”‘.$featured_img_url.'”/ fetchpriority=”high”>’;
    echo ‘<link rel=”preload” media=”(min-width: 769px)” as=”image” href=”‘.$featured_img_url_full.'”/ fetchpriority=”high”>’;

  • The fetchpriority attribute you’ve included in the link tag is not a standard attribute and is not recognized by browsers. Therefore, it won’t have any effect on the browser’s behaviour.

  • Ok, thanks. Do you think I’ve taken this as far as I can then?

  • Your overall performance score now is 92/96 on mobile/desktop. The only thing you need to address now is the TTFB, which may improve when you move out from the staging environment.

  • Thanks so much everyone!

  • You’re welcome!

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.