Relocate Lighslider-plugin inline javascript to bottom of body?

Hi there!

I’m trying to optimize my Grav-Page in regards to Google Pagespeed, which means relocating all JS & CSS-files to the bottom of . I noticed that the Lightslider-Plugin produces an inline Javascript within the twig-template which needs jQuery to be loaded beforehand (in the of the page), thus making it a render-blocking resource.

I already tried altering the inline-js (waiting for jquery to be loaded before calling the inline-script) but without success. And since its within a modular page, i can’t use {{ parent() }} to append to {{ block javascripts }} as suggested by this solution to a slightly different problem.

I’m out of ideas what else to try…

Trying to figure this out right now for the same reason. And also with Lightslider.
Did you find a way?

The LightSlider-plugin has two invocations of JS as far as I can tell: In it’s template, and in it’s plugin system.

The latter uses the Asset Manager, and basically says: “Load jQuery, then LightSlider, through the Asset System”. But because the Asset Manager never knows where the assets are invoked in template (there is no forced system of vs end of ), it cannot predict how the theme operates.

That said, it seems a solution would be to wrap the concrete inline parts of the template and push it to the Asset Manager, like so:

{% set script %}
JavaScript code (no <script> elements), including 
$(document).ready(function() {
{% endset %}
{% do assets.addInlineJs(script) %}

This would work from a modular page also, and pushing to Asset Manager is better than pushing to a Twig block of scripts.

Cool solution, I’m still quite new to Twig and I’ve tried wrap the inline code with assets.addInlineJs (which for some reason didn’t work) but I didn’t know about this neat trick - setting the block of code as a variable. Thanks!

Wow, thank you @gingah - that is a very interesting idea! I have just implemented it but stumbled upon a strange bug that affects the embedding of the Lightslider inline JS at the bottom of the <body>.

Have a look at - the Lightslider is used within the salmon-colored area called “Temoignages” / Testimonials.

Now, when I have just freshly cleared Gravs cache in the backend (via “All” or just “Cache”) and then visit the site, the Lightslider inline JS is correctly placed at the bottom of the <body>. However, once I do a forced reload in the browser, it disappears, and the page remains like this until I clear the cache once more and it appears again…

At first i thought it might have to do with Cloudflares caching - however, the same problem also surfaces on the french domain, which is NOT namehosted via Cloudflare.

Apparently, ONLY the inline JS of Lightslider is affected by this. The inline blocks for Google Analytics and Featherl ight that also get embedded at the end of <body> do not have this problem…

It seems really bizarre and it’s pretty much impossible to debug for any external person (due to the fact that you have to have backend access to clear the cache every once in a while), but I’d be grateful for any suggestions or hints.


At first I thought it might have to do with some page level cache that comes in the way of Lightsliders random id generation…:

{% set unique_id = 'ls-' ~ random_string(10) %}

but that’s not it :frowning: So, i’m sorta lost on this. Do you happen to have any ideas what might cause this?

Are you sure the page rules in CloudFlare are set up correctly? Both .fr and .fr/fr show up with resources loading through a CDN, as indeed I would expect them to. In both cases, the LightSlider-script is loaded just before .

From your case test, it seems to have more to do with your brower’s cache than the site, Grav’s cache, or the CloudFlare cache.

Might it be this issue? When a page gets rendered, also its assets are generated. These are then all served. Your rendered page is cached but not the ‘rendered’ assets.
Later, on subsequent requests, the page is retrieved from the cache; the actual rendering step is skipped. also the asset generation is skipped! In addition, modular pages, suffer additional peculiarities.

I’ve been struggling like hell with my googlemaps plug-in to get these caching issues ironed out (especially in the modular pages it’s very difficult). You can read more on it in these defects:

After reading that your page works again after clearing the cache, that made me ring a bell. Hope this background helps you finding a solution for your case.
(I read in last changelog that the rendering pipeline in grav changed so maybe those Issues I struggled with are gone now?)
PS the plugin I talk about is this one https :// (it’s not in the official downloads anymore since the change of beta/release regime).