What's the best practice for inserting paths to JS and CSS files in the head—but only for resources they are needed on?

I'm building a big full screen slider using MIGx, pThumb and picturefill.js. I think I only need to rely on picturefill to resize my bigger images, so it's not going to be applied to every single image throughout the site, and thus not needed on every page in the site.

I have a TV selector set up to allow the user to put the big slider on the page, and a MIGx TV allowing them to select images, apply links to other resources etc.

In an effort to keep the site simple and avoid having tons of templates, and a different header chunk for each template, I'm wondering if there is a way to use a placeholder in conjunction with my other TVs that will populate a placeholder in the head with the path to my picturefill.js file whenever the user has selected to put a big slider on the page.

I guess I could always just put the path to the picturefill.js file in the head and allow it to download regardless of whether it's needed on the page or not.

Any hints or suggestions, greatly appreciated.

I use a include a standard chunk at the bottom of templates for universal javascript includes then add extra lines in the templates for specialist pages. You could use a notempty modifier on TVs to include only when used eg. [[*mytv:notempty=`<script etc etc`]] but there would be a performance hit if doing this alot.

Best practice is to include javascript at the end rather than in the head, use cdn repositories whenever possible (eg. https://developers.google.com/speed/libraries/devguide and http://www.bootstrapcdn.com/ ), and use versioning on your own hosted scripts/css to allow proper browser caching (eg. yourscript.js?v=1.0 ).

Thanks for the Quick Response Dan:

Will need to wrap my brain around the notempty concept and how to implement. I could simply create and alternate header chunk for use on the page (i.e. [[$header_alternate]], etc.). Can't help but think though that there are times when developers want certain CSS and JS available on any given page, but don't want to create a bunch of different header chunks or multiple templates.

Usually I follow developers instructions or example for placement of the js file — be it in the head or at the end. Perhaps not best practice, but if something works wherever it's placed... I roll with it. I'm using Foudation 5, and some js goes in the head, whereas others go in the footer.

If I understand your suggestion, the actual js would be inserted between the backtick marks, as opposed to inserting a path to a js file via a placeholder in the head?

Thanks for the Quick Response Dan:

Will need to wrap my brain around the notempty concept and how to implement. I could simply create and alternate header chunk for use on the page (i.e. [[$header_alternate]], etc.). Can't help but think though that there are times when developers want certain CSS and JS available on any given page, but don't want to create a bunch of different header chunks or multiple templates.

Usually I follow developers instructions or example for placement of the js file — be it in the head or at the end. Perhaps not best practice, but if something works wherever it's placed... I roll with it. I'm using Foundation 5, and some js goes in the head, whereas others go in the footer.

If I understand your suggestion, the actual js would be inserted between the backtick marks, as opposed to inserting a path to a js file via a placeholder in the head?

You would create a TV with checkboxes, or a select, or some way for the user to indicate what JS/CSS should be added to that page.

I prefer to have a snippet in the template, with the various regClientCSS and regClientScript functions to load these as necessary.

The reason for putting javascript at the bottom of the page is that whenever the browser sees a link to a .js file it stops loading, requests and downloads the javascript file, then continues processing. So loading a lot of javascript at the beginning of the page can make it appear to be very slow to load, while putting the javascript at the bottom makes it appear faster, since the page is loaded before the browser starts downloading the javascript files.

The only time javascript should be in the head is if there is something that is critical to the page layout, and you don't want the page loading badly until it gets its javascript.

Hi Susan:

Thanks for the feedback. Very helpful. The TV seems like a way to go, but then the site manager would need to know to check that box. Using informative captions and descriptions will certainly help.

Just looking for a way to maybe have less boxes to check. I guess when the TVs get plentiful, I should be putting them into categories to make the whole process a bit less overwhelming.

Best

I always make a css and js tv for all my templates where I can manually include the script tags for any particular page but if I understand correctly you want it to include the script file based on a specific TV value, as others have mentioned you can use output modifiers or you could also create a snippet that checks for the TV value and renders the script tag.

An output modifier like this will work:



*Output modifiers can affect performance but I will leave that up to your judgement

You can also use something like the If extra to accomplish this as well.

http://rtfm.modx.com/extras/revo/if

Hope that helps,good luck.

Hi Ben:
I really appreciate your feedback. I'm actually building on what I initially learned from your MIGx tutorial. I've added in pthumb and picturefill to deal with the responsive image aspect. So I only need picturefill.js on the resource that has one of these big sliders.

When you say "can affect performance". What exactly does that mean? Guess I can read up more on that.

I'll give everything suggested here a try over the next day or so, and see what seems to work best.

"Can affect performance" means that if you use too many output modifiers it can make your site load a bit slower since MODX has to check the modifiers in order to decide what to do render/not render the output.

That makes sense. Thanks for clarifying.