I noticed that if we use AssetList->register the assets are sorted in a different way than they are registered. I also noticed that there are only two constants to define the position (ASSET_POSITION_HEADER and ASSET_POSITION_FOOTER).
How can I register a JS asset that's outputted in the end?
I also tried $('script').load als an alternative, but that doesn't work. $(window').load is too slow, as it waits until all assets including images are loaded. Modifying a footer file is not an option for me, because it's a package.
Ideas are very much appreciated :)
The ordering of assets is controlled by their order in registerGroup().
// view.js code // blank line // special_functions.js code // blank line // monkeypants.js code // blank line // sillyputty.js code
nice name ;) thanks for your answer.
Thanks for your time and help.
My reason for this is to be able to move jQuery and any other render blocking asset out of the head. The goal is to get everything I need for a basic page render in the first 14k request. It is all about the "perceived performance" of the site.
This article has more background information on the topic.
The article author writes more extensively about it in his book (I got the book in the fall and it was excellent).
I look forward to HTTP/2. It will make these workarounds unnecessary.
I have definitely heard that Auto-Nav blocks for sites with many pages can be slow. Which makes me think that for large sites a custom nav block could be used to improve performance.
For 5.7, there is the Manual Nav block, which builds non-dynamic navigation menus by choosing individual pages with the page selector.
The Manual Nav block creates one level of navigation. Some sites require multiple levels of navigation, like a drop down. Which gave me the idea to make a block that allows for selecting individual pages with the page selector and building a drop down with them. Basically you create a drop down that looks identical to the Auto-Nav drop down, but it isn't dynamic.
I haven't heard anything about page lists being slow, but I imagine there could be speed issues on a large site.
- Be very specific with the page type (if possible, do select one);
- Search beneath a page;
- Don't check "include all child pages" if you're only looking for direct pages beneath a particular page;
I can imagine when you are searching for a wide selection (everywhere) and don't select a page type, searching can be extensive when having 100/1000s of pages!
As for manual navigation, there's List Designer as well with some more options/configurations (open link in new window, add anchor like #mydiv-selector, add class names etc.) and selection of types (Page, URL, File, Text & Bootstrap Modal). See https://www.concrete5.org/marketplace/addons/list-designer/... for the Add-On.