Relocate Lighslider-plugin inline javascript to bottom of body?

Started by Muut Archive 10 years ago · 6 replies · 978 views

10 years ago

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 <body>. I noticed that the Lightslider-Plugin produces an inline Javascript within the twig-template which needs jQuery to be loaded beforehand (in the <head> 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...

10 years ago

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

10 years ago

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 <head> vs end of <body>), 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:

TWIG

{% 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.

10 years ago

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!

10 years ago

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 www.toctoc-marseille.com/fr/ - 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 www.toctoc-marseille.fr/fr/, 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.

-> UPDATE:

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

TWIG

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

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

10 years ago

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 </body>.

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.

10 years ago

@ulilu
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 ://github.com/aptly-io/grav-plugin-googlemaps (it's not in the official downloads anymore since the change of beta/release regime).

Topic	Replies	Views	Activity
About the Archive category Archive · by Deleted User, 9 years ago	0	1366	9 years ago
Hey buddies! Archive · by Muut Archive, 9 years ago	2	940	9 years ago
There is a way to do a "if condition" in MD page? Archive · by Muut Archive, 9 years ago	2	4069	9 years ago
Official docker image of grav (+admin +gitsync) Archive · by Muut Archive, 9 years ago	1	2960	9 years ago
Weird Grav + caddy + iOS + https problem Archive · by Muut Archive, 9 years ago	3	1125	9 years ago

Suggested topics