# Bingo!!



## Michael Morris (Dec 1, 2003)

VBulletin turns header caching off, forcing the browser to reload that script every bloody time!  Loading it once is one thing, but it is a 72K file so of COURSE major slowdown will result if it doesn't cache...

Now to figure out how...

Stay tuned.


----------



## Mark (Dec 1, 2003)

In the meantime why not make Classic the Default, please?  You can run tests on the additional styles without them being the ones that every guest has to use, right?


----------



## Michael Morris (Dec 1, 2003)

Mark said:
			
		

> In the meantime why not make Classic the Default, please?  You can run tests on the additional styles without them being the ones that every guest has to use, right?




Already done, though it was only done a few minutes ago so your session cookie may not reflect this.  Go to user cp and move over to classic, or log out and start a new session to refresh the cookie.


----------



## Mark (Dec 1, 2003)

Thanks Double M!


----------



## Piratecat (Dec 1, 2003)

I'm glad you diagnosed the problem! I hope there's a work-around; the drop-down menues are cool.

Please make classic the default style, unless Morrus has specifically asked otherwise.


----------



## Michael Morris (Dec 1, 2003)

Piratecat said:
			
		

> I'm glad you diagnosed the problem! I hope there's a work-around; the drop-down menues are cool.
> 
> Please make classic the default style, unless Morrus has specifically asked otherwise.




I don't have control over which of the themes is default - Russ does.  All I can do is build theme and turn user access to them on or off.  To my knowledge the default is now classic, but your session cookie may need to be updated to reflect the change.  Simply log off then back on to enforce that change.  Or switch it under USER CP


----------



## Umbran (Dec 1, 2003)

DM Magic said:
			
		

> People don't understand that things get old and need to be updated--it's not just for the sake of change. After all, if that were true, we wouldn't have new technology emerging every year. People would just be complacent with what we have.




Well, as you suggest, that argument works for technology, for things that provide a function, like the menu bar.  However, that argument is pretty darned weak when applied to the cosmetic things like colors and logos.  There is no functional need to change them.  We don't fall "behind the times" if the logo doesn't change.  And black and charcoal are not going to become obsolete and cease to be supported on Windows systems any time soon.


----------



## Morrus (Dec 1, 2003)

I switched the default back to Classic earlier today.  There are dropdowns on the newspage too, though - presumably they are contributing to slowdown also.


----------



## Michael Morris (Dec 1, 2003)

Morrus said:
			
		

> I switched the default back to Classic earlier today.  There are dropdowns on the newspage too, though - presumably they are contributing to slowdown also.




No, that's impossible.


----------



## Mark (Dec 1, 2003)

Cross-posted - The slow down ended for me when I was able to go to the "Classic" style in my User CP while logged in and while logged out once the default was returned to the "Classic" style, so no more problems on my end.  I have every confidence that Double-M will figure out what was up and get it straightened out some time in the near future. 

(Probably should merge a few of these threads...  )


----------



## Michael Morris (Dec 1, 2003)

Umbran said:
			
		

> Well, as you suggest, that argument works for technology, for things that provide a function, like the menu bar.  However, that argument is pretty darned weak when applied to the cosmetic things like colors and logos.  There is no functional need to change them.  We don't fall "behind the times" if the logo doesn't change.  And black and charcoal are not going to become obsolete and cease to be supported on Windows systems any time soon.




Umbran, if we left the colors exactly as they came with the program the body would be purple, the text black and the background white & light purple.  VBulletin doesn't give a rat's tail what the colors are when it renders the page, and the number of color sets have no bearing WHATSOEVER on the speed of the server or the render of the page.

The controlling script for the menus, mm_menu.js, is used successfully on some thousands of websites, corporate and otherwise, with no problem.

I was running mm_menu.js as it's own file, but for nearly TWO MONTHS the mm_menu.js script was piggy backing with vbulletin_global.js - I simply tacked it into that file, while I was running code tests to try to find a way to implement the code.  In that entire time NOONE complained of a slowdown.

This morning I put mm_menu.js back into vbulletin_global.js to see if it would affect the rendering speed of the pages on my system.  I tested it on Opera, NS 7 and IE 6 and it did speed up the rendering by about 2 seconds (Note there is a BIG difference between a loading time and a rendering time).  Yes, even I noticed a slightly slower rendering from the start, but I feel that if the whole page switch is done in under 5 seconds that's acceptable.  Maybe I'm too patient, I dunno.


----------



## LightPhoenix (Dec 1, 2003)

Yayhoo!!!

Good work Michael!  I'm glad that's solved.

As for the change issue, there's no need for change because people have choices, which is the whole point of style sheets.  If you choose to use the original style, great!  If not, well you have several themes that you _can_ use.  This way a majority of people are happy.


----------



## Psionicist (Dec 1, 2003)

This can be solved by putting the whole document header (not technically speaking) such as the ENW-logo, the dropdown menu and all the buttons (user cp, settings etc..) and the banners inside an IFRAME with a width of 100% and a fixed height of about 300 pixels (also, for cosmetics, an invisible black border).

The iframe content is cacheable.

Edit:: "height" not "size".


----------



## the Jester (Dec 1, 2003)

Hey Michael, I just wanted to chime in here and let you know that your hard work _is_ appreciated.  I suspect that everyone will eventually come around, at least once the slowdown is gone for them, with the possible exception of 'Old Skool' diaglo.


----------



## Umbran (Dec 1, 2003)

Michael_Morris said:
			
		

> Umbran, if we left the colors exactly as they came with the program the body would be purple, the text black and the background white & light purple.  VBulletin doesn't give a rat's tail what the colors are when it renders the page, and the number of color sets have no bearing WHATSOEVER on the speed of the server or the render of the page.




I know that.  Sorry, but you're conflating two separate lines of discussion.

You yourself partly mention it here - VBulletin doesn't care what the colors are, or what the logos look like.  There is no _technical_ reason to change them.  Back when you suggested new default colors and logo, you got resistance.  The analogy DM Magic made to technological advancement as a defense of that sort of change doesn't hold, because there's no technological difference between blue and black.

Simply put - the issues of color and logo are matters of taste only.  There is no accounting for taste, meaning that there's no objective argument that one is better than another.  So, you'll meet resistance, and you'll have no objective and substantive defense for the change.  Moreso when the current colors have been in place for so long that they are certainly part of the "look and feel" of the place.

That's all completely separate from the menu-bar/slowdown issues.



> This morning I put mm_menu.js back into vbulletin_global.js to see if it would affect the rendering speed of the pages on my system.  I tested it on Opera, NS 7 and IE 6 and it did speed up the rendering by about 2 seconds (Note there is a BIG difference between a loading time and a rendering time).  Yes, even I noticed a slightly slower rendering from the start, but I feel that if the whole page switch is done in under 5 seconds that's acceptable.  Maybe I'm too patient, I dunno.




Interesting.  You're noting a couple seconds difference in rendering speed, separate from any download speed issues?  Alone, that's not much, however, do you get something more when you add in the extra download time because the script wasn't cached and the extra server load (on a server that seems to have been somehow taxed already) from all the requests for the script?  You imply such above.  If that starts reaching into an extra 5 seconds per page, people will notice.  

And the users are humans.  If they see anything that inconveniences them, even for 5 seconds, then they'll gripe.


----------



## Umbran (Dec 1, 2003)

DM Magic said:
			
		

> OH YEAH?! Well... uh... YOUR MOMMA!




So, you think you're big enough for that, hm?  

Well maybe you should prove it.  

Maybe you should come over here and... lick this freezing cold metal pole.  

I dare you.  I _double dog_ dare you.  

 

(edit: hoping the reference doesn't get this kicked over into the Movies & TV forum)


----------



## Michael Morris (Dec 1, 2003)

Psionicist said:
			
		

> This can be solved by putting the whole document header (not technically speaking) such as the ENW-logo, the dropdown menu and all the buttons (user cp, settings etc..) and the banners inside an IFRAME with a width of 100% and a fixed height of about 300 pixels (also, for cosmetics, an invisible black border).
> 
> The iframe content is cacheable.
> 
> Edit:: "height" not "size".




Won't work.  Tried that awhile ago.


----------

