Sorting assets
Permalink
I want to load all JavaScript files first and in the end a file that initializes stuff. What's the best approach here?
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 :)
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 :)
Hi MrKDilkington,
nice name ;) thanks for your answer.
I meant ordering of assets in general, not within a asset group. I think it's not quite possible in C5 to specify an exact ordering of assets. Luckily I managed to change my JavaScript so it will execute in a proper way using (function($){ });
Thanks for your time and help.
nice name ;) thanks for your answer.
I meant ordering of assets in general, not within a asset group. I think it's not quite possible in C5 to specify an exact ordering of assets. Luckily I managed to change my JavaScript so it will execute in a proper way using (function($){ });
Thanks for your time and help.
I am also very interested in a way to specify the exact ordering of assets.
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.
https://www.filamentgroup.com/lab/weight-wait.html...
The article author writes more extensively about it in his book (I got the book in the fall and it was excellent).
http://abookapart.com/products/responsible-responsive-design...
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.
https://www.filamentgroup.com/lab/weight-wait.html...
The article author writes more extensively about it in his book (I got the book in the fall and it was excellent).
http://abookapart.com/products/responsible-responsive-design...
But then you won't be able to use $ in none of your views. Wouldn't you see that as a huge drawback? Also, wouldn't you say the CDN resource is likely to be cached by the visitor already, if he's not browsing in cognito or with a clear cache?
It definitely creates more work, but it is supposed to make a substantial difference in render speed and the time it takes to get a usable page.
I look forward to HTTP/2. It will make these workarounds unnecessary.
I look forward to HTTP/2. It will make these workarounds unnecessary.
I don't know. Loading the jquery takes only miliseconds if I look in Developer Tools. And once it's loaded it's even faster. For me the biggest performance bottleneck is loading dynamic pages (e.g. with autonavs / pagelists). Sometimes they take up more than 2 seconds to generate... Have you had trouble with that?
Apparently the larger the website and the slower the data connection, the more render blocking becomes a problem. Before the page is rendered, every additional trip to the server for assets delays the page from being usable (usable meaning page text is available to read). On slower connections with significant latency, the problem is made that much worse - each trip to the server is even slower. The idea is to get the bare minimum assets to the page in the first server round trip to render the page, so the user can use the page while the rest of the assets load. The total load time doesn't change, the time to get a readable page does, which means less time looking at a blank screen during load (this creates the feeling that the page loads faster).
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.
https://github.com/concrete5japan/Manual-Nav...
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.
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.
https://github.com/concrete5japan/Manual-Nav...
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.
I've read about page lists being slow by others as well in the forum, but haven't experienced it either. May be with couple hundreds/thousands of pages, but haven't had these kinda sites to be honest. Perhaps it would be best to:
- 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.
- 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.
The ordering of assets is controlled by their order in registerGroup().
Example:
- three JavaScript files
- output
When "CSS and JavaScript Cache" is enabled, the combined/minified JavaScript file created also maintains the order within it.
Example:
- inside this cached file, each separate JavaScript file's code is separated by an empty line