![Check out Enfold](https://kriesi.at/wp-content/themes/kriesi/images/banner-enfold.jpg)
-
AuthorPosts
-
June 10, 2020 at 9:00 am #1221104
Hi,
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)
June 15, 2020 at 10:06 am #1222581Hi just a follow up on this one. This is the background image https://aptilostaging.wpengine.com/wp-content/uploads/2017/07/nr-1-soultion_1500x430-darker-new.jpg and as you can see from this GTMetrx report it is loading even after the script in the footer……..
https://gtmetrix.com/reports/aptilostaging.wpengine.com/kteep34j
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).
June 16, 2020 at 2:41 pm #1223045Hi,
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 https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images:
<img srcset="elva-fairy-480w.jpg 480w, elva-fairy-800w.jpg 800w" sizes="(max-width: 600px) 480px, 800px" src="elva-fairy-800w.jpg" 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,
IsmaelJune 22, 2020 at 6:12 pm #1224652Thanks Ismael, then I know.
June 22, 2020 at 7:21 pm #1224675Ismael,
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: https://gtmetrix.com/reports/aptilostaging.wpengine.com/4YeqqBqy
As you can see the picture https://aptilostaging.wpengine.com/wp-content/uploads/2019/08/Virtual-Service-Provider-1500×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):
https://gtmetrix.com/reports/aptilostaging.wpengine.com/OBbPBKoa
June 24, 2020 at 4:28 pm #1225279Hi,
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,
IsmaelJuly 3, 2020 at 10:35 am #1227731Hi 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 https://aptilostaging.wpengine.com/wp-content/uploads/dynamic_avia/avia-footer-scripts-fe82e08c16b339646073b2fc2bfaacfb—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 https://aptilostaging.wpengine.com/wp-content/uploads/2017/07/nr-1-soultion_1500x430-darker-new-414×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 https://gtmetrix.com/reports/aptilostaging.wpengine.com/ZqvURt9C
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?
July 3, 2020 at 12:00 pm #1227745I 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 https://aptilostaging.wpengine.com/solutions/carrier-wifi/
GTMETRIX https://gtmetrix.com/reports/aptilostaging.wpengine.com/qHxfhT15 (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 4 years, 2 months ago by
Terve.
July 7, 2020 at 1:31 pm #1228585Hi,
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.
// https://pastebin.com/0ZiZb5iE
Then add this snippet in the functions.php file.
add_action('wp_head', function() { ?> <script> (() => { 'use strict'; const objects = document.getElementsByClassName('asyncImage'); Array.from(objects).map((item) => { const img = new Image(); img.src = item.dataset.src; img.onload = () => { item.classList.remove('asyncImage'); return item.nodeName === 'IMG' ? item.src = item.dataset.src : item.style.backgroundImage = url(${item.dataset.src}) }; }); })(); </script> <?php }, 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: https://medium.com/front-end-weekly/how-to-optimize-image-loading-on-your-website-855020fb41ae
Best regards,
IsmaelJuly 7, 2020 at 6:32 pm #1228651Hi 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 https://aptilostaging.wpengine.com/
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: https://kriesi.at/support/topic/how-to-replace-the-advanced-layerslider/#post-1215293 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.
July 10, 2020 at 10:51 am #1229372Hi,
For some reason, the editor added a code tag in this line:
item.style.backgroundImage = <code>url(${item.dataset.src})</code>;
It has to be removed.
item.style.backgroundImage = 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,
IsmaelJuly 10, 2020 at 1:48 pm #1229418Thanks Ismael, now I get this error (Chrome inspect on page https://aptilostaging.wpengine.com/) 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.
July 13, 2020 at 5:58 am #1229836Hi,
My mistake. This line:
item.style.backgroundImage = url(${item.dataset.src});
.. should be:
item.style.backgroundImage = {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:
url(${item.dataset.src})
Please add it manually by replacing the placeholder {BACKQUOTE}.
Best regards,
IsmaelJuly 13, 2020 at 8:55 am #1229871Thanks Ismael, so what you are saying is that it should look like this?
item.style.backgroundImage = 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.
July 15, 2020 at 1:31 pm #1230594Hi,
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..
// https://pastebin.com/0ZiZb5iE
Best regards,
IsmaelJuly 31, 2020 at 1:13 pm #1234370Sorry 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?
August 3, 2020 at 12:59 pm #1234820Hi,
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,
IsmaelAugust 3, 2020 at 8:54 pm #1234966Hi Ismael, thanks will look into this when back from vacation. Are there any plans to support srcset for background images too?
August 6, 2020 at 4:30 am #1235573Hi,
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,
IsmaelAugust 17, 2020 at 11:38 am #1238456Sorry for my stupidity, of course this was what you meant?:
item.style.backgroundImage =
url(${item.dataset.src})
;And know it seems to work very well. Thank you very much.
-
This reply was modified 4 years ago by
Terve.
August 17, 2020 at 5:00 pm #1238552Hi Terve,
Glad you got it working for you! :)
If you need further assistance please let us know.
Best regards,
VictoriaAugust 19, 2020 at 8:20 am #1239045Hi 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 https://aptilostaging.wpengine.com/cloud/cellular-iot-connectivity-management-and-policy-control/ (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:
https://gtmetrix.com/reports/aptilostaging.wpengine.com/g0iqpd25
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:
https://gtmetrix.com/reports/aptilostaging.wpengine.com/aADKJ2eQ
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?August 24, 2020 at 5:09 pm #1240418Hi,
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,
IsmaelAugust 24, 2020 at 7:03 pm #1240472Hi 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 https://gtmetrix.com/reports/aptilostaging.wpengine.com/Rjs2Jcwu
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 https://gtmetrix.com/reports/aptilostaging.wpengine.com/9lIFYbKA
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 4 years ago by
Terve.
August 26, 2020 at 4:57 pm #1240965Hi 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”:
https://gtmetrix.com/reports/aptilodev.wpengine.com/S77xsUeP
As you can see the background image https://aptilodev.wpengine.com/wp-content/uploads/2020/05/Aptilo-IoT-CCS-because-you-do-not-need-another-mobile-core-v4-1500×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:
https://gtmetrix.com/reports/aptilodev.wpengine.com/Q8N3MxWT
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 4 years ago by
Terve.
August 27, 2020 at 6:05 pm #1241284Hi,
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,
IsmaelAugust 27, 2020 at 6:20 pm #1241289Hi 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 4 years ago by
Terve.
August 31, 2020 at 1:41 pm #1242174 -
This reply was modified 4 years, 2 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.