Hi,

eo_web.ashx is used to render a few things, most importantly JavaScript files and built-in images. You can take the JavaScript files off eo_web.ashx by enabling physical script files:

http://www.essentialobjects.com/ViewDoc.aspx?t=InstallationAndDeployment%2fdeploy.html

You may still see that in the status bar after this because eo_web.ashx is also used to render other things. But those are asynchronous and should not block the page from being loaded. Even for the JavaScript files, it may still take a while if you load it for the first time. The files should be cached by your browser and it should be much quicker afterwards. If you continue to experience slow load time then it might be that your browser caching has somehow stopped working. So you will want to check that. In that case there isn't really the server side code can do.

Thanks

Hi Kevin,

From our experience, it generally does not make too much sense to digging into why a browser loads curtains things certain way for one menu but not for the other. The reason is because how the browser loads whatever it needs is completely dependant on the browser itself. The browser can decide however way to load it as it sees fits, and neither JavaScript nor server side code can do anything about it -- except for caching instructions, which sometimes the browser still choose to ignore. Sometimes different browsers behave differently, different versions of the same browser behave differently or even the same version of the same browser behaves differently on different machines, even between different sessions. In another word, there is no "standard implementation" as for how browser loads things.

Having that said, if the loading messages/delay are so significant and indeed bothers you or your customers, the best way for you is to compare your working menu and your non-working menu. It should not be difficult to find out the triggering point. Once you have that, it may be easy to find out a workaround. What you do want to keep in mind is, as explained above, since there is no standard on this matter, any solution may be temporary or have other implications.

Thanks

Hi Kevin,

I believe we have already explained the issue to you quite thoroughly. I will summary our points again here:

1. There is no way to precisely control how browser loads things. Thus there is no official solution for this problem (this is also why we can not provide a solution to you);
2. If you wish to avoid a certain observed behavior, try using trial and error to find out the triggering point and work around it;
3. Since the issue does not affect any functionality, it may not be worthy trying to find out a "solution" that nobody knows why it works. You could end up trying hours and days finding a solution that works for one day but stops working the second day;

Hope this clears up.

Thanks

Hi,

The code you pasted is what initializes the menu. As for eo_web.ashx?id=b07569df-aab1-4833-b62f-f5d642a057b3, that can be the menu requesting an empty document. I believe this is needed when:

1. You use cross frame feature. In this case the sub menu is created in a target frame, - or -;
2. Your page is rendered over HTTPS. This is needed to to avoid "the page contains both secure and non-secure ....";

However since we do not know the version you are running, we can not be sure. If you can let us know your exact version number, we should be able to find out what exactly that request is for.

Thanks

Hi,

We have confirmed that it is the empty document Url. As explained above, the menu requesting this Url on each sub menu when either cross frame or HTTPS is used. This causes extra delays but unfortunately we do not believe there is a workaround for this. The delay can be more apparent over HTTPS because browser doesn't cache pages transferred over HTTPS. So it will fetch it again and again.

Thanks