Please, let me disagree on that. I mean, why is your question dumb? I believe itâs definitely not.
The rationale behind not having lazy loading by default is avoiding a breaking change. There are a several scenarios in which a widget is expected to appear as soon as it can. For instance, itâs a vital property of our Age Verification and Cookie Consent widgets. I understand that making a customer to perform manual changes in a code is a barely user-friendly way. Weâre considering other options to achieve the same functionality without putting that burden on anyone but us.
Thanks @ivanenko - I feel the best option would be to have a âCopy code without Lazy Loadâ and a âCopy code with Lazy Loadâ or something similar. Copying the Lazy Load code in each time isnât optimal but kudos for implementing it!
Obviously this method will work on apps that are loading below the fold, such as the facebook feed and instagram feed and testimonials slider. But will it harm the functionality of the form builder? We use forms that slide out with the button in the bottom right. Will putting lazy load on these prevent them from working correctly or with the proper timing?
A second question. Someone above stated that the pagespeed was improved only very marginally (IE not very much at all) when using the lazy load method. Have you (Elfsight Devs) tested this and shown that in fact it is a pretty substantial improvement?
I ask because as it stands, without a doubt the elfsight javascripts take the most time of all the items on our pages:
Thank you for your questions.
Lazy loading feature will work as expected if an installation code (a widget container div, to be precise) is not in an initial view. Therefore, in you case it will do the job if you add the code, for example, to a page footer. Widget will start loading once a user commits a first activity (move a mouse, scroll, tap a screen, whateverâŚ) or a widget container div appears in a view (it could be disabled if needed).
I prepared an example for you to evaluate the lazy-loading feature and decide whether itâs worth trying or not. All the pages below are identical, except a widget installed on.
There is no widget on the first one, and as we can see PageSpeed reports 81 points for performance on mobile.
The widget container div is on the second line. It has nothing to do with the widget itself. itâs just a âtargetâ that helps us detecting a proper position in a page to embed the widget. The âContact Usâ button is a part of the widget, so it will appear after widget is loaded. As for widgets that stick to a window rather than appear somewhere in a document an actual widget container div position doesnât make much difference. But when it takes to lazy-loading itâs better to put it to the bottom.
I would like to vote again that this become the default for all types of widgets that logically would not need to load immediately (the exceptions being things like age verification). I just realized that I have not been adding this to the install code and have had to ask my dev to go back to several sites and add it.
Yes, it should work. This is the installation code of the widget from a new dashboard, thatâs why it differs a bit from the code we used in our post.
NOTE: In my example instead of âbla-blaâ address of js array, I just donât like scrollbars, you know
Essence of method is in position of string with script before closing body tag. This will delay start of script and speed up loading. Moreover, if there are several widgets on site, one request to js array is enough.
The site I admin has three different elfsight widgets and one string of script at the bottom. It works great and loads fast.