Forums

Hi all, I notice that on my site and also in the YUI doc examples, the MenuNav plugin (http://developer.yahoo.com/yui/3/node-menunav/) renders fairly slow.. There's a very noticeable lag between the time the page renders and the time the menu is actually displayed.

Here's a link to the JS I'm using to load the plugin: http://onpub.com/onpub/frontend/js/site.js

I am loading some custom CSS to override the default menu style, but even without that, the rendering of the menu is still rather slow.

Does anyone have any tricks to speed this up? For example, if I load the YUI JavaScript includes earlier in my code, will the menu render faster?.. I've tried various tweaks like this but have yet to get great performance out of this plugin..

Are they any plans to improve the performance of this widget?

Thanks in advance for any advice.

CT
http://onpub.com/

Hi Ryan, thanks for your suggestions. I made my code use the CDN and now things seem a little snappier.. Also, I am already using the "yui3-loading" CSS class to hide the menu div until it's rendered.

There is still that jarring effect between the time the page renders and between the time the menu renders in the space it belongs, as you pointed out..

Do you have a technique for filling the space before hand so that the menu just appears instead of popping in to place?

I think I've tried something along those lines before but was unsuccessful.. I believe my difficulty was choosing an object to put there with the exact dimensions of the menu before the menu is actually displayed..

How would I go about calculating the size of the menu before it actually renders? Not sure there is a foolproof way to do this since the size of the menu could be different dependent on various client factors such as font size, font family, style customizations etc.. Is there some magic formula I could use to calculate the size of the menu before hand and fill the space with an empty <div> or something like that before the menu is ready to be displayed?

Thanks,

Corey

Your post gave me the idea to modify my CSS as follows:


Basically this makes the menu now "appear" in place instead of "popping" vertically in to empty space.

If you look at my site again you'll notice this, but there is still a noticeable lag between the time the menu appears and the time my custom CSS is applied. You'll notice the stock dark menu border changes to the lighter color defined by my custom CSS. Just gotta figure out now how to make that transition a little smoother.

May I suggest that the YUI docs team add some type of notes about these loading/rendering issues to the menunav plugin docs/examples.

Also, one idea I had to enhance this plugin would be to give the option to define a CSS file as a custom config attribute, for example:


Ideally this new option would cause the plugin to load the custom CSS file and then apply any CSS class modifications before the menu is even displayed. This might enable a smoother rendering of the menu than what I'm getting currently by applying my custom style after the the plug method is called.

Would be nice to be able to load the custom style before the menu rendering process is complete.

Thanks for all your help in figuring this out.

Corey

Thanks again. The fetchCSS config property gives me the control I need to load the menu CSS along with my customizations long before the menunav plugin is loaded. This actually makes the menu render much faster as well. Now there's no lag between the time the menu displays and the time my style customizations are applied. This is the only way I'm able to get my customizations to apply smoothly. The menu now renders as I intend it to, as soon as its displayed.

I actually tried the first suggestion of manually loading my CSS before calling YUI().use. This didn't work since when the loader downloads the menunav CSS it clobbers my customizations. That why I was using YUI.get.css to load my CSS after calling plug on the menu node.

If I can humbly suggest adding these two things to the docs in addition to what I previously suggested:

1. Document fetchCSS at: http://developer.yahoo.com/yui/3/yui/#loader. Currently the page says "The valid configuration options for Loader are as follows." This led me to believe that the list of config properties listed on the page was a complete list, yet there's no mention of fetchCSS. It's only after you mentioned it that I thought to look at the API docs and found more info: http://developer.yahoo.com/yui/3/api/config.html#property_fetchCSS. Maybe just link to the full API doc if you all don't want to list every property on the main doc page.

2. On the http://developer.yahoo.com/yui/3/yui/ page maybe add some some description of the order things are loaded in. It was not obvious to me that the menunav CSS would be loaded by the loader. I assumed that the CSS was being dynamically loaded once the plug method was called. Once you said how it works I used Firebug to confirm and I saw what you described. A blurb about this might save others some time. Sorry if there's already something there about this and I just didn't see.

I should also note that front-loading all the CSS before </head> is actually faster since it seems the browser is better able to cache the files. Not sure there's any browser caching going on when the CSS is loaded dynamically either via the YUI loader or via YUI.get.css. I'd have to look in to this a little further though to see if this is actually true.

Why did the YUI team decide to load CSS along with JavaScript when calling YUI().use? For the menunav plugin, on the surface it would make sense to delay the loading of the CSS until plug is called. Then it would make sense to have a menunav config attribute to supply a custom CSS file that selectively overrides the default SAM skin classes. I would guess this way of customizing the menu CSS is more common then actually re-defining all the SAM skin classes from scratch. There's so many, so I chose to pick and choose the classes to tweak. I placed my customizations in a separate file, making it necessary to load this file after the stock skin is loaded. It's just easier to maintain this way.

In the meantime, using fetchCSS: false is more than workable for my needs.