They said it was a vBulletin issue huh? Funny. Some people just like to blame others so that they don't have to deal with your problems. I would advise you to contact support and complain about whoever said that but with BH it won't do any good.

Yeah, I was nowhere close to 6 seconds on your site and I definitely am nowhere near 6 seconds on mine. That site must have some issues they need to fix.

So I changed lots of things last night. Disabled some settings. Got rid of quick navigation, member list, customized profiles, VBexperience add-on, as well as other minor things. My members say they have noticed some improvement.

I stayed up all night and never got a vbulletin database error (usually happens every night between 1-4am). So I'm happy with that, but we'll see... might have been a fluke.

Has anyone tried this?

https://developers.google.com/speed/

I just used it today and my score is 64/100. Could be better.

The Page Speed Score indicates how much faster a page could be. A high score indicates little room for improvement, while a lower score indicates more room for improvement. The Page Speed Score does not measure the time it takes for a page to load.

Then it lists, in order of priority, changes I should make to improve my page speed. Based on the results, it's my guess that these are things anyone with a vbulletin forum would also have issues with. Does anyone know how to do these three things?

The high priority items:

1. Enable compression:
   I already did this the other day by enabling gzip html output and using a compression level of 1.... so I don't know how I can improve this further? Here is what it says:
   
   Compressing the following resources with gzip could reduce their transfer size by 145KiB (76% reduction).
   
   Compressing /clientscript/vbulletin_css/style00001l/main-rollup.css?d=1332834548 could save 55.6KiB (82% reduction).
   Compressing /clientscript/vbulletin-core.js?v=4110 could save 35.7KiB (70% reduction).
   Compressing /clientscript/vbulletin_css/style00001l/cms-rollup.css?d=1332834548 could save 26.2KiB (79% reduction).
   Compressing /clientscript/vbulletin_overlay.js?v=4110 could save 10.6KiB (75% reduction).
   Compressing /clientscript/vbulletin_lightbox.js?v=4110 could save 8.8KiB (73% reduction).
   Compressing /clientscript/vbulletin_md5.js?v=4110 could save 3.4KiB (63% reduction).
   Compressing /clientscript/vbulletin_cms.js?v=4110 could save 2.4KiB (59% reduction).
   Compressing /clientscript/vbulletin_ajax_htmlloader.js?v=4110 could save 1.2KiB (61% reduction).
   Compressing /css.php?styleid=1&langid=1&d=1332834548&sheet=ss_r ightcolumn_css.css could save 717B (59% reduction).
   
   
2. Combine images into CSS sprites - I have zero clue on this one:
   
   The following images served from *******.com should be combined into as few images as possible using CSS sprites.
   
   /images/buttons//lastpost-right.png
   /images/buttons/search.png
   /images/cms/read_more-right.png
   /images/cms/widget-forum.png
   /images/gradients/selected-tab-gradient-with-top-alpha.png
   /images/misc/arrow.png/arrow.png
   /images/misc/black_downward_arrow.png
   /images/misc/blog/gradient-black-down.png
   /images/misc/blog/top-highlight.png
   /images/misc/navbit-arrow-right.png
   /images/misc/navbit-home.png
   /images/misc/unknown.gif
   /images/pagination/last-right.png
   /images/pagination/next-right.png
   /images/site_icons/html.png
   
   
3. Leverage browser caching - also no idea
   
   The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources:
   
   /images/buttons/lastpost-right.png (expiration not specified)
   /images/buttons/newbtn_middle.png (expiration not specified)
   /images/buttons/search.png (expiration not specified)
   /images/cms/read_more-right.png (expiration not specified)
   /images/cms/widget-forum.png (expiration not specified)
   /images/gradients/gradient-grey-down.png (expiration not specified)
   /images/gradients/selected-tab-gradient-with-top-alpha.png (expiration not specified)
   /images/misc/arrow.png (expiration not specified)
   /images/misc/black_downward_arrow.png (expiration not specified)
   /images/misc/gradient-black-down.png (expiration not specified)
   /images/misc/top-highlight.png (expiration not specified)
   /images/misc/navbit-arrow-right.png (expiration not specified)
   /images/misc/navbit-home.png (expiration not specified)
   /images/misc/unknown.gif (expiration not specified)
   /images/misc/vbulletin4_logo.png (expiration not specified)
   /images/pagination/last-right.png (expiration not specified)
   /images/pagination/next-right.png (expiration not specified)
   /images/site_icons/html.png (expiration not specified)
   http://www.google-analytics.com/ga.js (2 hours)

--------------- Added [DATE]1332869024[/DATE] at [TIME]1332869024[/TIME] ---------------

Found this: https://vborg.vbsupport.ru/showthrea...rowser+caching

1) Can't really do that on most shared hosts.
2) Sprites are multiple images combined into one large image. This large image should be equal to or, preferably, less than in size than the combined size of all the images it consists of. The reason why this is faster is because it reduces HTTP requests. Browsers have a limit on the amount of parallel downloads they can make, so by combining images into a sprite you can download more things faster. vBulletin does not support CSS sprites atm and it would be a pain in the ass to make a modification that does.
3) http://hellboundbloggers.com/2011/06...ve-site-speed/

Google if your friend, especially for number three. :)

I did find a mod for css sprites here. Check it out :) https://vborg.vbsupport.ru/showthrea...266696&page=35

I did google for "leverage browser caching" but found someone had issues after doing it: https://vborg.vbsupport.ru/showthrea...rowser+caching

So I'm hesitant about that one.

Do you have cpanel on your hosting? Reason I ask is I enabled compression for everything in the apache settings. My pages loaded pretty quick to start with but after enabling that they're even quicker.
Cpanel > Software/Services > Optimize Website
Compress Content > Select: Compress all content > Update Settings > Logout
See if that helps.

Should I first disable gzip compression in the vbulletin admincp? (under Cookies and HTTP Header options)






--------------- Added [DATE]1332954249[/DATE] at [TIME]1332954249[/TIME] ---------------

My account has been throttled a crazy amount. So I contacted bluehost.

Here's a snippet of our conversation:

Kevin: [10:18:54 AM] 13354 **** 20 0 180m 20m 8272 R 46.7 0.1 0:00.12 /ramdisk/bin/php5 /home1/****/public_html/****/showthread.php
13841 **** 20 0 175m 15m 7904 R 29.3 0.1 0:00.08 /ramdisk/bin/php5 /home1/****/public_html/****/mgc_cb_evo_ajax.php
14974 **** 20 0 181m 20m 8516 R 24.6 0.1 0:00.11 /ramdisk/bin/php5 /home1/****/public_html/****/mgc_cb_evo_ajax.php
[10:19:05 AM] those are using 46.7%, 29.3%, and 24.6% CPU at the time
Michelle: [10:27:03 AM] i just disabled mgc_cb_evo_ajax.php
[10:27:13 AM] can you already see a difference?
Kevin: [10:35:57 AM] One moment.
[10:38:35 AM] the throttling values are still increaing
Michelle: [10:40:38 AM] is there any other reason why?
Kevin: [10:46:32 AM] you will need to fix the scripts that are consuming so much resources

So I got rid of mgc_cb_evo_ajax.php (which is this chatbox: https://vborg.vbsupport.ru/showthrea...hreadid=168992) which I'm very sad about.

But he says throttling is still increasing.

And showthread.php is using 46.7% CPU? Is this normal? He says I need to fix it, but how???

I don't know if it is relevant but at the time he gave me that number there were 49 people viewing the forum.

Mine is still sitting at 1. That's the out of the box setting. If all the trouble came after you set the compression in cpanel then go back and disable it.
You really need to back up your database and your home directory. And with all this going on, now would be real good time.

I haven't set any compression in cpanel. So it's just been the vbulletin setting. It's probably been throttling like this for some time. I didn't know till the other day when I decided to check. Awful, I know. hahhh

oops

Gzip compression isn't going to affect your CPU. I highly doubt your CPU usage is that high from 50 people viewing a thread.