Viewing 28 posts - 1 through 28 (of 28 total)
  • Author
  • #1221104


    I have implemented this srcset modification #1084047 and it worked very well. However, it is not implemented for fullwidth 1500x background pictures in colorsections. How can I achieve this? Is it possible/making sense to try to preload this picture in the heading? I have noticed that the browser is loading it quite late which is a pitty because it is always the first picture after the heading (I am using a background picture in a color section to get a fullwidth picture as a replacement for the layerslider element)


    Hi just a follow up on this one. This is the background image and as you can see from this GTMetrx report it is loading even after the script in the footer……..

    Another question, is there a class that I can refer to for a background image in a color section? I want to disable lazyloading for this class when I switch on that feature in WPRocket (which I have temporarily disabled just for trouble shooting).



    Sorry for the delay. You can’t use the srcset attribute for background images. It will only work on an actual image element or when using the img tag.

    Example from

    <img srcset="elva-fairy-480w.jpg 480w,
                 elva-fairy-800w.jpg 800w"
         sizes="(max-width: 600px) 480px,
         alt="Elva dressed as a fairy">

    So it’s not going to work for the color section because the image is set as background.

    Best regards,


    Thanks Ismael, then I know.


    I still need Enfold’s input as why the background image used in the color section directly under the header is loading so late.

    Check this:

    As you can see the picture×430.jpg is almost loading last on page even after the google analytics script in the footer. Yet this is the first picture on the page.

    I have tried a uncashed version also without any interference from WP Rocket, same results (although it actually for some reason is loading both a version I use for mobile and the desktop version):



    We are not really sure why it loads that image last but the whole page loads under 1.9s according to the testing tool, so I don’t think anyone would notice. We also checked the page directly and the main image was immediately visible even before the page finished loading. We are not able to check it thoroughly because devtools are disabled.

    Best regards,


    Hi Ismael, did you test it from a mobile device? Yes, we have good performance on our site, I am working hard on that, but the user experience is not quite as good as it seems. The fact that our top banner (implemented as a background image in a color section) is loading so late is devastating for the user experience, especially on mobile. Even though we get good grades on GTMetrix, the page feels very slow when almost every picture on the page, that is not even visible in the view port without scrolling, is loading before this top banner.

    In fact, even your footer javascript—5ee3651ebf67a.js is loading before, which make me think that maybe the loading of the background image is triggered from this script? (please bare with me, I am not that savvy in web development😂).

    This is the top banner I am talking about, placed as a background image on a color section directly under the top header×119.jpg (I also noticed that without WP Rocket activated, I have disabled it for trouble shooting here, it seems like it is loading both the desktop and mobile version of it. I have made responsive conditions and added two banners one for mobile and one for the rest, no big deal but good to know).

    This is the GTMETRIX waterfall

    I really need to get to the bottom of this. I do not know what dev tools you are talking about, can I do anything to help?


    I don’t now if this information helps, but it seems to my that all background images are loaded after that footer js. I tried to but a background image in a 1/1 section and it was the exact same behaviour

    GTMETRIX (look for the virtual service provider concept picture)

    Why this is such a big deal for SEO is that Google will increasingly care about loading speed of Largest Content Paint LCP and my top banner is clearly the LCP for all my pages.

    • This reply was modified 3 years, 11 months ago by Terve.


    Thank you for the info.

    Did you install or activate any lazy loading option in your site? It probably causes the images to load after the scripts.

    One solution is to load the images asynchronously instead of waiting for other resources to load, but it will require a bit of modification. For the color section, we have to modify the themes\enfold\config-templatebuilder\avia-shortcodes\section.php file and remove the background image property. We will then replace it with a data-src attribute containing the image URL.

    Please replace the section.php file with this code.


    Then add this snippet in the functions.php file.

    add_action('wp_head', function() {
    		(() => {
    		'use strict';
     		const objects = document.getElementsByClassName('asyncImage');  
    		Array.from(objects).map((item) => {
    			const img = new Image();
    			img.src = item.dataset.src;
    			img.onload = () => {
    				return item.nodeName === 'IMG' ? 
    				item.src = item.dataset.src :        = url(${item.dataset.src})
    }, 999);

    After that, edit the color section element, go to the Advanced tab and use “asyncImage” as a Custom CSS Class name. The script will look for the color section with the “asyncImage” class attribute, load the URL inside the data-src attribute and place it as a background when it’s is fully loaded. This will all happen while the page is loading.

    This is from:

    Best regards,


    Hi Ismael, thank you so much for your support on this!

    I did what you said, but get an error (use Chome inpect and you will see it) for this page

    I should rephrase that, I did not do exactly what you said :

    1. I implemented the code snippet in my child theme’s functions.php. By the way shouldn’t I try to use the new modified section.php in the child theme as well so it is not overwritten in future updates.?

    2. I already had a custom CSS class name in the colorsection to get a responsive image: and temporarily disabled it in order to test your idea (if it is succesful we need to find a way to merge them).

    On your question about lazy-load: Yes, I have two plugins essential-grid and WPRocket using lazyloading. I have before tested to disabled them both, but same results. It seem to me that background images are loading very late no matter what, maybe it works as designed? I mean maybe it is generally logical to load a large background image last, but not in my case as it is (miss-)used as a top banner. If I could find another way (than using the color section background image + special heading) to get a full width top-banner 1500×430 with a H1 heading in front I would try that of course.

    Please also note that I use the advanced responsive tab in the colorsection to load a 415×119 image for mobile and 1500×430 image for the rest (so basically the colorsection is repeated x 2 with different image sizes loading conditionally. Don’t know if this messes things up.



    For some reason, the editor added a code tag in this line: = <code>url(${item.dataset.src})</code>;

    It has to be removed. = url(${item.dataset.src});

    And you can actually add multiple class names in the Custom Class attribute field. Just put a space between them.

    responsive-colorsection asyncImage

    Let us know if it helps.

    Best regards,


    Thanks Ismael, now I get this error (Chrome inspect on page on that modified line:

    “Uncaught SyntaxError: missing ) after argument list”.

    Since I don’t understand the code fully myselft, I need some help to trouble shot.



    My mistake. This line: = url(${item.dataset.src});

    .. should be: = {BACKQUOTE}url(${item.dataset.src}){BACKQUOTE};

    It should work properly now.

    You can also post the login details in the private field so that we can test it properly.

    UPDATE: The editor removes the back quotes which enclose this line:


    Please add it manually by replacing the placeholder {BACKQUOTE}.

    Best regards,


    Thanks Ismael, so what you are saying is that it should look like this? = url(${item.dataset.src})url(${item.dataset.src})url(${item.dataset.src});

    Doesn’t feel right to me………….I must have misunderstood your updated instructions?

    I have added login credentials in private content.



    Thank you for the update.

    We adjusted the script and wrap the line in back quotes. It still doesn’t work because the data-src attribute is missing from the color section container. Did you modify the section.php file as suggested previously? If you can provide the FTP account, we’ll add the modifications for you.

    If you want to test it yourself, just replace the themes\enfold\config-templatebuilder\avia-shortcodes\section.php file with this..


    Best regards,


    Sorry Ismael, I totally missed your reply. I am about to update to the latest Enfold with srcset support now. Does this change anything in your instructions?



    The color section can’t support the srcset option because the image is set as background. You can still replace the section.php file with the code that we provided previously to enable asynchronous loading of the background image.

    Best regards,


    Hi Ismael, thanks will look into this when back from vacation. Are there any plans to support srcset for background images too?



    The current srcset implementation is based on the default scrset feature from WordPress, which is only applicable on image tags, so it’s not going to work on background images. It’s possible, but it may NOT be added in the theme anytime soon.

    Thank you for your patience.

    Best regards,


    Sorry for my stupidity, of course this was what you meant?: = url(${item.dataset.src});

    And know it seems to work very well. Thank you very much.

    • This reply was modified 3 years, 10 months ago by Terve.

    Hi Terve,

    Glad you got it working for you! :)

    If you need further assistance please let us know.

    Best regards,


    Hi Ismael, I am using WPRocket and also essential grid. I will ask the same question to WPRocket but wanted to check with you as well.

    The background image that I am using as the top banner here (name of image Aptilo-IoT-CCS-because-you-do-not….) is implemented in two sizes one for mobile and one for the other screens. I then use the advanced styling for the Enfold background image element to display the right size for the right screen. When I use the lazyload feature for Images in WPRocket, this works great only that it seems like the background image is lazyloaded as it is loading very late even after the essentialgrid is loading. This grid is not even visible on a mobile screen before scrolling so it should clearly load after the background image, check this waterfall:

    But, if I disable the WPRocket lazyloading feature, either for all images or only for background images with their recommended helper plugin, then the image loads before the essentialgrid just as as it should after your great “hack”. But, now BOTH versions of the background image is loading as you can see from this waterfall:

    Just wanted to check with you if you think there is anything in your “hack” that could cause this behaviour?

    Another question that I don’t expect you to answer, since it is out of scope for the support, but you would be my hero if you have any insights:
    In the waterfalls you will notice that there is a huge inactivity (big gap of 2,5 seconds) just before the essential grid is loading. I have tried to use chrome dev tools to figure out what javascript is causing this and how I can improve this, but I am not so savvy in this tool. Do you have any idea?



    But, now BOTH versions of the background image is loading as you can see from this waterfall:

    The theme just hides the sections or elements with css, so the other version of the image is still in the DOM or document and will still be loaded even if it’s not visible in the page. So having two versions of the section or image doesn’t help with the site’s performance in this case.

    Best regards,


    Hi Ismael, are you sure about this?

    Here I have disabled lazy loading for the image class you created (asyncImage) according to GTMetrix both images are loading and the total size of all images is 208.9 Kb

    Here I have enabled lazy loading (or rather not disabled it) for image class asyncImage) and according to GTMetrix the correct version (414×119 smaller size for mobile) is loading and the total size of all images is 149.1 Kb
    The difference 208.9-149.1 = 59.8 Kb is extremely close to the reported size of the 1500×430 larger size for desktop which is 59.9 Kb.

    UPPDATED: The reason why I am so particular about this is that if I prevent the background image from lazyloading my Google Web Core Vitals goes up significantly from 61 points to 83 for mobile and from 84 to 93 for desktop. The reason is that they are very particular about the time for the largest content to load. This will become crucial for SEO going forward.

    • This reply was modified 3 years, 10 months ago by Terve.

    Hi Ismael, to narrow down further what is causing the load of both image versions (mobile and Desktop) I have moved our live site to our development to test the behaviour. This site do NOT have your asyncImage implemented at all. The problem with double loading of the image versions seem to be related to whether the background image is allowed to be lazyloaded or not.

    The Aptilo web WITHOUT your suggested asyncImage “hack”:

    As you can see the background image×430-1.jpg is loaded very late.

    But, if I implement WPRocket’s helper plugin that prevents lazyloading of background images, then the background image will load early as I want but both image versions are loading:

    My conclution from this is that preventing lazyloading of background images will get me to what I want without your asyncImage “hack”. This is a good thing as maintaining custom code is a nightmare in the long run. However, the unwanted side effect is that both image versions are then loaded for some reason. Anything we can do about that?

    I am looking forward to your conclusion.

    • This reply was modified 3 years, 10 months ago by Terve.


    Hi Ismael, are you sure about this?

    Yes, the browser still loads the image because it’s still in the DOM and the browser expects that there’s still a possibility that the image will be manipulated by a script later on. One example is a slider with multiple images — only the first image or slide is visible on page load but the browser will still request all images in the slider.

    And please note that in the section.php file, we moved the image URL in the data-src attribute, so the script will only apply the value of the data attribute either as background image or the value of the src attribute on page load. This might also affect the lazyload option.

    $params['data'] = "data-src='{$src}' data-section-bg-repeat='{$repeat}'";

    Unfortunately, we are not exactly sure how the lazyload option works in that plugin, so we might not be able to help you further in this case.

    Best regards,


    Hi Ismael, Ok I trust your expertise on this. I still don’t get how I can get different results in GTMETRIX waterfall (both images vs one image), but never mind that. Though I do think I get the same result (early loading of background image) by preventing lazyload for the background image as I get with your suggested asyncImage adaptation. Do you see any reason why I should use your adaptation in that case? As much as I appreciate your efforts I want to do as little special hacking as possible.

    The conclusion then is that I will be better of just serving the gigantic 1500×430 image for all screen sizes for the background image? The ultimate solution would of course be to have srcset implemented also for the background image, that would optimize the page with the right size for the right screen automatically and through Imagify I would also get webp served. This would be perfect. Any chance that that would be implemented soon?

    • This reply was modified 3 years, 10 months ago by Terve.


    Yes, in this case the site would be better off using a single optimized image for both mobile and desktop view because the srcset option is only applicable to img tags or elements, and not for background images.

    Best regards,

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