On this site home page (https://ourtexastown.com/), we have two LayerSliders. One at the top, and one near the bottom.
When the page loads, the browser inspection panel tells me it's about 10 Mb. Even when I disable Javascript, I see this heft. I had thought that LayersSlider would load the first slide image (about 644Kb) and then, using js, lazy load the subsequent slides as they transition.
Thank you for getting in touch with us. My name is Attila and I'm happy to assist you today. I appreciate your patience while we've been working towards your ticket.
For this purpose and to improve your site's performance you could use the 'Conditional script loading' and 'Include scripts in the footer' options, located in the 'Advanced' settings on the main page of the admin area.
- both "Include scripts in the footer" and "Conditional script loading" are enabled. I believe this is the default.
- I'm not sure you understand my issue. What I'm saying is - all the slides for both slideshows are being loaded via http request IMMEDIATELY on page load. Lazy load is not working.
Thank you for the feedback. I will consult with the dev team regarding your case, so they can look into this to see if they can find anything, and I'll get back to you shortly.
The Lazy Load only loads the images for the active and the upcoming slide. It loads the upcoming slide's images for a seamless transition between them. It does not load the rest of the slider.
Please note that the inspector can be deceiving. The browser starts to initialize your slider and load all the images after the DOMReady event, so it's possible that for a split second the browser starts to load these images, but it's immediately stopped after that, without actually loading them. Because of this, the inspector network tab might be showing that they are loaded, when in reality, they are not.
This is certainly the way it is designed, but it is not the way it is working.
The Network tab of the inspector will show you when a Request is cancelled. I see no such cancellation.
Further - the slides for both slideshows I sent you have a 4 second transition time. So if the behavior your are describing was happening, I should see those images being loaded every 4 seconds in the inspector. But I don't. I see them all loaded immediately.
For me, your site works as expected: new images are being loaded as I navigate in your sliders. There are several reasons why you might experience a different outcome. Caching would be the main suspect, the browser might have a copy of the resource in memory/on disk, so uses it right away. The previously mentioned split second might also be enough for some images to load before they are cancelled. Also, please note that the previously mentioned 10MB size includes everything on your site, not just the ones used in LayerSlider.
I've also found another issue: a theme/plugin changes every resource URL in the source code, appending ?35a67f at the end of the URL. This is considered a really bad practise, as the original URL params are used for cache control and other means. It also interferes with srcset attributes. Due to the URL mismatch, some resources are loaded twice on your site.
I appreciate your response, and I’ve disabled the W3 Total Cache feature that was adding the query-like string. I’m not clear it was a problem, as it wasn't a real query string. But in the adventure of troubleshooting, I’ll take any logical avenue.
That said - I’m using Cloudflare, as many do. And Cloudflare is very quickly serving up the images asked for. Faster than your html replace can try to cancel the load.
The Layerslider code starts off with html (html #1) that loads all the slide images (src is set to a real and unique image):
<see html-1.png>
And then, when the slider initializes, the contents of#layerslider_232 is replaced with html (html #2) that only contains a fully formed<imgtag for the first slide, and commences lazy loading of subsequent slides.
<see html-2.png>
Seems ok in theory. But in practice, modern browsers and cdn’s like Cloudflare make it less likely that this 'cancel' (which is really just removing the<imgtag from the page) succeed in it’s goal. The image may have already loaded, or loaded enough so that no cancel occurs. Further - this method requires javascript to cancel these loads. So Googlebot is always going to load all these images and therefore consider the page to be very heavy.
From what I’ve read, there is no true way to cancel an image load in modern browsers. There is no event to 'cancel' a single request. Replacing the src='' attr is undefined and actually behaves differently depending on the browser. Replacing the full html section containing all the images is (I am guessing here) essentially the same as setting src=''.
So my questions is - Why not just load the html #2 and completely skip loading html #1. No race condition with cancelling the image load. No js overhead. Simple and efficient.
The first screenshot shows the original HTML markup that's used for initialization. Since LayerSlider is also available as a standalone jQuery plugin, we need a simple markup that everyone can write by hand and is easy to understand. Saving server resources by using a simpler markup and a way shorter output is a major consideration as well. Every JavaScript based plugin works like this since the actual markup in DOM can be very different and complex, plus it always changes during runtime. Due to performance considerations, LayerSlider actually performs these tasks in chunks similarly how the lazy load feature works (current & next slide), so it's definitely not a bottleneck.
As you said, the real solution would be to not include the actual URL for images. Unfortunately, it also has several downsides. The most obvious would be search engines and SEO. Also, the src attribute is mandatory and would result erratic browser behavior if omitted, so we would need to fill the source code with redundant URLs pointing to a 1px x 1px empty GIF file. This solution has all sorts of problems, like the fact that other image preloaders and similar solutions integrated into WP themes/plugins wouldn't be compatible with it and would cause a lot of trouble in many cases.
We chose a compromise to maximize compatibility, but in practise the two solution works similarly. We've tested many scenarios with many tools. The inspector is a very useful tool, but it can report false positives if you also check the results with other network monitoring solutions.
Since the browser starts to look for images at the same time when LayerSlider initializes, and one of its first task is to change the src attributes, the time difference should be extremely small. It's possible that the browser starts the download some images, but it's not that common and would only affect very few images. Also, modern browsers stop the data stream if you remove the image or change the src attribute.
Even if you have a very fast internet connection and the best CloudFlare server, you won't be downloading 10 MB of data in just a fraction of a second. We're talking about milliseconds here. Resolving DNS and performing other handshake protocols before the download usually takes more time. I still believe that those images is likely loaded from cache if they immediately appear in the inspector.
To satisfy all needs, I think we're going to implement the second option as well and add a switch to change between the two modes. I've added it to our to-do list. LayerSlider at its core is already prepared to handle this and uses attributes like data-src if it's present. This means that even the current version can be used like that if you have an image preloader that hooks into WP's image functions and generates an alternate markup.
Sure thing. We also have a beta release channel you can select in the product activation box.
We strive for excellence in customer service and to offer the highest quality products we can produce. If you are satisfied with our work, please consider rating LayerSlider with 5 stars on this page. It would really mean a lot to us!
On this site home page (https://ourtexastown.com/), we have two LayerSliders. One at the top, and one near the bottom.
When the page loads, the browser inspection panel tells me it's about 10 Mb. Even when I disable Javascript, I see this heft. I had thought that LayersSlider would load the first slide image (about 644Kb) and then, using js, lazy load the subsequent slides as they transition.
Have I configured something incorrectly?
Thank you
Hello Steve Mullen,
Thank you for getting in touch with us. My name is Attila and I'm happy to assist you today. I appreciate your patience while we've been working towards your ticket.
For this purpose and to improve your site's performance you could use the 'Conditional script loading' and 'Include scripts in the footer' options, located in the 'Advanced' settings on the main page of the admin area.
A few thoughts:
- both "Include scripts in the footer" and "Conditional script loading" are enabled. I believe this is the default.
- I'm not sure you understand my issue. What I'm saying is - all the slides for both slideshows are being loaded via http request IMMEDIATELY on page load. Lazy load is not working.
Thank you for the feedback. I will consult with the dev team regarding your case, so they can look into this to see if they can find anything, and I'll get back to you shortly.
Hello again,
The Lazy Load only loads the images for the active and the upcoming slide. It loads the upcoming slide's images for a seamless transition between them. It does not load the rest of the slider.
Please note that the inspector can be deceiving. The browser starts to initialize your slider and load all the images after the DOMReady event, so it's possible that for a split second the browser starts to load these images, but it's immediately stopped after that, without actually loading them. Because of this, the inspector network tab might be showing that they are loaded, when in reality, they are not.
This is certainly the way it is designed, but it is not the way it is working.
The Network tab of the inspector will show you when a Request is cancelled. I see no such cancellation.
Further - the slides for both slideshows I sent you have a 4 second transition time. So if the behavior your are describing was happening, I should see those images being loaded every 4 seconds in the inspector. But I don't. I see them all loaded immediately.
You can verify this by looking at the homepage of https://ourtexastown.com/
Thank you for the feedback. My colleagues and I will look into this further, to see if we can find anything, and get back to you with the results.
Hi Steve,
I'm John from the Kreatura Dev Team.
For me, your site works as expected: new images are being loaded as I navigate in your sliders. There are several reasons why you might experience a different outcome. Caching would be the main suspect, the browser might have a copy of the resource in memory/on disk, so uses it right away. The previously mentioned split second might also be enough for some images to load before they are cancelled. Also, please note that the previously mentioned 10MB size includes everything on your site, not just the ones used in LayerSlider.
I've also found another issue: a theme/plugin changes every resource URL in the source code, appending ?35a67f at the end of the URL. This is considered a really bad practise, as the original URL params are used for cache control and other means. It also interferes with srcset attributes. Due to the URL mismatch, some resources are loaded twice on your site.
Best Regards,
John | Kreatura Dev Team
I appreciate your response, and I’ve disabled the W3 Total Cache feature that was adding the query-like string. I’m not clear it was a problem, as it wasn't a real query string. But in the adventure of troubleshooting, I’ll take any logical avenue.
That said - I’m using Cloudflare, as many do. And Cloudflare is very quickly serving up the images asked for. Faster than your html replace can try to cancel the load.
The Layerslider code starts off with html (html #1) that loads all the slide images (src is set to a real and unique image):
<see html-1.png>
And then, when the slider initializes, the contents of #layerslider_232 is replaced with html (html #2) that only contains a fully formed <img tag for the first slide, and commences lazy loading of subsequent slides.
<see html-2.png>
Seems ok in theory. But in practice, modern browsers and cdn’s like Cloudflare make it less likely that this 'cancel' (which is really just removing the <img tag from the page) succeed in it’s goal. The image may have already loaded, or loaded enough so that no cancel occurs. Further - this method requires javascript to cancel these loads. So Googlebot is always going to load all these images and therefore consider the page to be very heavy.
From what I’ve read, there is no true way to cancel an image load in modern browsers. There is no event to 'cancel' a single request. Replacing the src='' attr is undefined and actually behaves differently depending on the browser. Replacing the full html section containing all the images is (I am guessing here) essentially the same as setting src=''.
So my questions is - Why not just load the html #2 and completely skip loading html #1. No race condition with cancelling the image load. No js overhead. Simple and efficient.
Thank you
Steve Mullen
The first screenshot shows the original HTML markup that's used for initialization. Since LayerSlider is also available as a standalone jQuery plugin, we need a simple markup that everyone can write by hand and is easy to understand. Saving server resources by using a simpler markup and a way shorter output is a major consideration as well. Every JavaScript based plugin works like this since the actual markup in DOM can be very different and complex, plus it always changes during runtime. Due to performance considerations, LayerSlider actually performs these tasks in chunks similarly how the lazy load feature works (current & next slide), so it's definitely not a bottleneck.
As you said, the real solution would be to not include the actual URL for images. Unfortunately, it also has several downsides. The most obvious would be search engines and SEO. Also, the src attribute is mandatory and would result erratic browser behavior if omitted, so we would need to fill the source code with redundant URLs pointing to a 1px x 1px empty GIF file. This solution has all sorts of problems, like the fact that other image preloaders and similar solutions integrated into WP themes/plugins wouldn't be compatible with it and would cause a lot of trouble in many cases.
We chose a compromise to maximize compatibility, but in practise the two solution works similarly. We've tested many scenarios with many tools. The inspector is a very useful tool, but it can report false positives if you also check the results with other network monitoring solutions.
Since the browser starts to look for images at the same time when LayerSlider initializes, and one of its first task is to change the src attributes, the time difference should be extremely small. It's possible that the browser starts the download some images, but it's not that common and would only affect very few images. Also, modern browsers stop the data stream if you remove the image or change the src attribute.
Even if you have a very fast internet connection and the best CloudFlare server, you won't be downloading 10 MB of data in just a fraction of a second. We're talking about milliseconds here. Resolving DNS and performing other handshake protocols before the download usually takes more time. I still believe that those images is likely loaded from cache if they immediately appear in the inspector.
Best Regards,
John | Kreatura Dev Team
To satisfy all needs, I think we're going to implement the second option as well and add a switch to change between the two modes. I've added it to our to-do list. LayerSlider at its core is already prepared to handle this and uses attributes like data-src if it's present. This means that even the current version can be used like that if you have an image preloader that hooks into WP's image functions and generates an alternate markup.
Best Regards,
John | Kreatura Dev Team
That is tremendous news. If you need a beta tester, don't hesitate to ask.
Thank you
Sure thing. We also have a beta release channel you can select in the product activation box.
We strive for excellence in customer service and to offer the highest quality products we can produce. If you are satisfied with our work, please consider rating LayerSlider with 5 stars on this page. It would really mean a lot to us!
Thank you!
Best Regards,
John | Kreatura Dev Team