My WP Website Continues to Get Slower.... Suggestions on Layout/Tuning Appreciated!

[iampino]

Hey everyone!

I just found this site while trying to improve the speed/layout of my site. I'm having the toughest time trying to figure out why it is so extremely slow. I've run tests on it with the CSR and everything has seemed fine.

Goto philkrnjeu.com to check it out


2 Things:
1) Please help me figure out why the site is so slow (general loading, using Yslow, etc.). I have optimized, cleaned up databases, removed images, etc., to try and optimize. Need help with that.
2) Any ideas to clean up the layout/general ideas/thoughts appreciated!

Thanks! - Phil

BTW.... Here's some info to help diagnose:

Host: GoDaddy
WP: 3.x (latest version)
Theme: Genesis - Magazine 2.0 Theme

Plugins used:
All in One SEO Pack - 1.6.13.4
AntiVirus - 1.2
AutoBlogged - 2.8.5
Bulk Delete - 1.4
Clean Options - 1.3.2
Crawlable Facebook Comments - .2
Facebook Comments - 1.2.7
Google Analytics Plugin - 1.0
Google XML Sitemaps - 3.2.6
Iframe - 1.7
List Eruption - 1.2
Redirection - 2.2.10
SEOPressor V4 - 4.3.08
Simple Face Connect - 1.1
Simple Twitter Connect - 0.15
STC - Tweet Button - 0.15
TubePress - 2.2.7
Twitter Goodies Widgets - 1.2
W3 Total Cache - 0.9.2.4
wordpress Database Backup - 2.2.3
WP-CMS Post Control - 2.5
WP-PageNavi - 2.74
WP Google Fonts - 2.5
WP System Health - 1.3.3

[Tubby]

Seems to be plenty of plugins . . (not suprised at a loss of site speed)

[somethingelse]

problem one... godaddy. i'm pretty convinced godaddy hates wordpress.

maybe combine some of those plugins - use a social media connect to handle all accounts, rather than individual ones for fb & twitter,
why two fb comment plugins? find one that does both
what's the bulk delete for? turn it of except when you need it, maybe?

i'd guess there are a few others that you've been dragging around since before wp 3.1... post control, navigation? bet you could get away without those
might be better to use a single google font, tho that's probably the least of your worries.

and, ironically, i find that the caching plugins are often a culprit - PARTICULARLY when using godaddy.

I'd start with changing hosts.

[jhilgeman]

Well, there's definitely a few issues.

1. Your theme uses some custom fonts, which are not helping you at all. They are very hard to read in a couple different browsers (I'm running on a 1920x1200 display and the fonts are jagged). They also don't load reliably, so I'd remove those.


2. Your WP processing engine is EXTREMELY slow. It's taking on average 8 seconds to render JUST the HTML for your WP pages. That does not include any images or Javascript or any additional content that the browser loads after it receives the HTML. This means that one or more of your plugins (or your template) are running extremely slow. I would go back through your plugins and try to find reviews on each one to see if they are in widespread use or if you're using some new plugin that a fresh-out-of-college created and released to the public without proper testing.

If you're a PHP developer, you should be able to add code into the WP engine or turn on debugging mode to get an idea of where the problem is (if the reviews don't tell you anything specific about a plugin).


3. You have a couple 404's:
http://www.philkrnjeu.com/wp-content/uploads/2011/08/red_getinstantaccess.png
http://www.philkrnjeu.com/wp-content/plugins/crawlable-facebook-comments/css/fbCrawlStyle.css?ver=3.2.1

Those are taking up 8 - 10 seconds EACH because you have a custom 404 handler that renders -another- WP page, so each time you load the front page, you're loading a total of -three- WP pages from your site. If you remove references to those two assets, then it should definitely make a noticeable improvement in speed, but your biggest improvement will come from figuring out which plugin or piece of code is slowing down your WP engine.

It is definitely a problem in the PHP code, so most of your services like YSlow and such will not be able to see the problem - they'll only see how long it took to load the rendered page.

Just to comment on what somethingelse said, I've used a variety of hosts, and GoDaddy hasn't been terrible. There -are- better hosts for your money, but I don't think GoDaddy has anything to do with this issue, so I wouldn't worry about it if you have a long-term hosting plan with them. If you're getting close to renewing, then I'd suggest 1and1 or WebHostingHub (google for CNet hosting - they have a special deal price with WebHostingHub) - they were both pretty good shared hosting providers the last time I used them.

I just did a quick search on some of the plugin names I didn't recognize - I would definitely try disabling SEOPressor and see if that helps. Not sure what the plugin does entirely, but if you go to the author's homepage and try to leave, it tries to prevent you from leaving and throws all sorts of stuff at you, which is a REALLY bad sign that it's a spammy product. I also did a search for "SEOPressor slow" and found a few different discussions of people having the same problem and saying that disabling it made a huge difference.

I would also question List Eruption and Autoblogged. Both of those are heavily related to spam and spam-like content. In general, I would stay away from any WP plugins that aren't searchable from the main WP plugin directory and have rankings. If you only use plugins that have good rankings from that plugin directory, you're going to have a much better success rate with your plugins and site, and they'll also be free. I'm sorry if you've paid money for bad plugins - I hope it wasn't much, but it's honestly better to cut your losses if these plugins are making your site suffer. I've been doing SEO work for over 10 years, and whenever a plugin hypes itself as the "killer" plugin that will magically give you more subscribers and clicks and such, it usually ends badly (and they can sometimes get you blacklisted on search engines).

[subsystems]

You also have a serious issue before the first page even attempts to load.
When I browsed to philkrnjeu.com it waited 22 seconds before redirecting to www.philkrnjeu.com. Then it took an additional 8 seconds waiting on the page to load.
I doubt the 22 second delay has anything to do with your onsite content.
Also, when I view source and load one of your css pages in the browser, it fails.

Fails to load in browser. Reports 404
http://www.philkrnjeu.com/wp-content/plugins/crawlable-facebook-comments/css/fbCrawlStyle.css?ver=3.2.1

[erima]

Hi,

Your site has several issues - but the one that is causing the most performance issues is:
http://www.philkrnjeu.com/wp-content/uploads/2011/08/red_getinstantaccess.png

which gives a 404 error. Anytime you have a 404 error on your page it will drastically impact performance and also affect and SEO efforts.

Also the facebook crawl style :/plugins/crawlable-facebook-comments/css/fbCrawlStyle.css?ver=3.2.1 HTTP/1.1 is another problem.
you might want to load that when they click on facebook content.

Other than that, it is a great looking site. Hope it helps.


Eric

[Easy Anderson]

Regardless of your other issues, your server is a problem. GoDaddy and the vast majority of the hosting services, Bluehost, HostMonster, etc all pack hundreds of sites on to a server and so your load times are going to suffer for it. Even Rack Space and others do it too, they just charge a boat load more for it.

If you don't want to get hit by Google for slow load times, then you should get a dedicated server from a commercial hosting service or you might want to check out someone like CloudRedHosting.com who specializes on wordpress Hosting for businesses or people that need professional grade hosting for their wordpress site. It is well worth the price.

Cheers,
Andrew

[dgswilson]

Never underestimate the theme when your blog grinds away. There is a link is in my signature to a blog using Default.
Plug ins: broken link checker, akismet, WP-reCAPTCHA, anti-captcha - No sparkles

[Doc]

I agree with the earlier comments about some of your many plugins. I think you could realistically cut the number of plugins in half. Also, GoDaddy is fine as a registrar, but as hosting goes, I think it's the bottom of the barrel. I'd seriously consider moving to a new host.
I ran your site through webpagetest.org, and here are the results: http://www.webpagetest.org/result/111214_1A_2H4SM/1/details/ There are a lot of areas there that are ripe for improvement.

[deepsand]

which gives a 404 error. Anytime you have a 404 error on your page it will drastically impact performance and also affect and SEO efforts.
Nonsense. A 404 page is served up more quickly than a content laden one; and, is of no particular consequence vis-a-vis SEs.

[jhilgeman]

Nonsense. A 404 page is served up more quickly than a content laden one; and, is of no particular consequence vis-a-vis SEs.

Deepsand, that's not true in this case. The user here has a custom 404 page that renders a WP page, so his 404s are full of content, and are having an impact on his performance. By default, most browsers only fetch up to two resources at a time from a domain, so if the browser is waiting 10 seconds for one of the 404 pages to render/load, then it is using up half of the download pipeline that could be used for transferring other assets/resources.

Also, the original poster was correct in that 404s -do- have an impact on SEs, but it's not because of performance. There are a lot of factors that go into SEO, and 404s on a page -will- negatively impact a site's ranking. It holds less weight than other factors, but it does hold weight.

@Easy Anderson - a dedicated server will not always be better. I've been doing web development and running web servers of every kind non-stop for the past 10 years, and I've seen a lot of people that try to switch from shared hosting to dedicated (or VPS), but they try to go with the cheap dedicated servers (e.g. the bottom-of-the-barrel from EV1servers/rackshack/whatever-they're-calling-themselves-now) because of the cost, and they end up with a very poorly-performing server (or worse, a VPS). Or, they purchase a server and don't have the money to afford a good system admin, so they hire someone out of college that doesn't know how to properly configure the server and it ends up running poorly. There are a lot of hidden costs with dedicated hosting, and if you're okay with them, then you can get better performance. I personally prefer to purchase my own hardware for $500-$1000 and pay a small amount per month for some basic 2U rack space and get the performance of a $1000/mo server for only $50 a month. If someone is paying for shared hosting, it's probably because they don't have the cash in the first place to spend on a better-performing hosting solution.

I don't work for GoDaddy, and like I said, there are better hosts (feature-wise), but unless someone can point out specific problems with the performance of a Wordpress site on GoDaddy, there's really no weight behind your suggestion. I know specific reasons why there are better hosts than GoDaddy, but they have nothing to do with a hosted WP site.

[deepsand]

Deepsand, that's not true in this case. The user here has a custom 404 page that renders a WP page
The post in question made a categorical statement, not a qualified one.


Also, the original poster was correct in that 404s -do- have an impact on SEs, but it's not because of performance. There are a lot of factors that go into SEO, and 404s on a page -will- negatively impact a site's ranking. It holds less weight than other factors, but it does hold weight.
That's a very old myth that refuses to die. A 404 signals a resource that is logically non-existent; nothing more. It is only the present of a large number of persistent 404s that might be cause for pause on the part of an SE.

[jhilgeman]

I guess we'll have to disagree on whether or not it affects SE to keep the discussion on track. Regardless, I think it's mutually agreed that 404s are undesirable. Whether they impact SEs or not - they just shouldn't exist on a well-maintained site. If it impacts SE in the process, then that's good news. If not, then at least you don't have 404s anymore. :)

[ronchalice]

Plug-ins, and the fact that your on a server with 7,641 other sites. I have WP running on four hosted servers (one of the non-GD companies mentioned above). Two are running on servers with 639 and 915 sites -- with goes along with the "hundreds" mentioned earlier, one with 10, and one - (I got such a deal...) 3,615.. but not in production use currently. You certainly have a lot of plug-ins. Have you determined exactly what value each of the brings to the table?

[deepsand]

I guess we'll have to disagree on whether or not it affects SE to keep the discussion on track. Regardless, I think it's mutually agreed that 404s are undesirable.
All depends on the reason.

404 because you've no robots.txt? Contrary to "popular wisdom," a non-issue.

404s from IBLs linking to non-extant resources? Ditto.

A gazillion 404s from OBLs on a page with little to no content of value? It'll still be indexed, but may not see the light of day in the SERPs

[Tiggerito]

404s from IBLs linking to non-extant resources? Ditto.

A gazillion 404s from OBLs on a page with little to no content of value? It'll still be indexed, but may not see the light of day in the SERPs

Those are still undesirable .

404s due to internal links should always be fixable and completely avoided, if just for the user experience.
OBL link errors should be fixed for the users experience.
IBLs can optionally be 301ed or a correction requested made. This case it's not just for the users experience but can also help in ranking.

Good point @jhilgeman on the speed of rendering custom 404 pages. A dynamically generated WP 404 page will be a lot slower than static css, javascript and small image files. So having that sort of error will slow down a pages loading and rendering. I'd suspect 404s don't cache as well either, so their impact is greater as the user browses more.

Looking the the Webpagespeed link @Doc posted you can see that the css file that 404s is the critical path that blocks the page from starting to download images. A second 404 for a png is then the critical path for reaching the document complete stage, blocking a lot of the javascript from running.

I estimate fixing the 301 and the two 404 errors will cut around 10 seconds from the pages load time. So about half of it. then the critical path is how slow the WP takes to generate the html file.

[deepsand]

Those are still undesirable
There is a difference between being undesirable and being of material consequence.

404s resulting from IBLs pointing to phantom pages are of no material consequence.

Whether or not such are undesirable depends on how disturbed one gets from seeing them reported on GWMT.

[alienpest]

I took a look, and it loaded faster than I expected from what I have read. I noticed the twitter box seemed to be eating a good deal of resources, some of the plugins are really not needed, and I would add one: "minify" seems to help. It's worth a shot.

[Tiggerito]

There is a difference between being undesirable and being of material consequence.

Yes, and I was pointing out that undesirable was the term used, not material consequence.


404s resulting from IBLs pointing to phantom pages are of no material consequence.

Can't fixing them help your valid backlink equity, PageRank and therefore have a material consequence?

Can't fixing them mean that visitors see what they were looking for instead of an error page, so get a better experience. Isn't that a material consequence?

In the OPs case we are talking about internal links to embedded content, so this is not related to their issue.

[deepsand]

Can't fixing them help your valid backlink equity, PageRank and therefore have a material consequence?
IBLs to phantom pages may in fact not have a legitimate target, as has been frequently reported here.


Can't fixing them mean that visitors see what they were looking for instead of an error page, so get a better experience. Isn't that a material consequence?
Those who click on phantom links are visitors to sites other than the target of such links, such that any untoward consequences vest elsewhere.


In the OPs case we are talking about internal links to embedded content, so this is not related to their issue.
Again, I was responding to the categorical claim that 404s are some how especially pernicious, that for an SE to see one is fraught with dire consequences.

[Tiggerito]

IBLs to phantom pages may in fact not have a legitimate target, as has been frequently reported here.

Those who click on phantom links are visitors to sites other than the target of such links, such that any untoward consequences vest elsewhere.

I just looked up phantom page. it's the first I've heard the term! So now I understand the context of what your talking about better.

How does a phantom page relate to this issue, or even a 404 discussion?

It seems your saying don't fix any 404 errors because you have some very rare examples where it has no benefit?



Again, I was responding to the categorical claim that 404s are some how especially pernicious, that for an SE to see one is fraught with dire consequences.

I do see in his previous post he states "404s -do- have an impact on SEs,", "404s on a page -will- negatively impact a site's ranking. It holds less weight than other factors, but it does hold weight". To me he was not stating it is "especially pernicious" nor "for an SE to see one is fraught with dire consequences". (my bolding).

Or is it related to "which gives a 404 error. Anytime you have a 404 error on your page it will drastically impact performance and also affect and SEO efforts.". I'd argue about the use of anytime and drastically but in the case he mentioned, the 404s ARE drastically slowing down the page, potentially getting the page punished for slowness.

Or have I missed something?

[Tiggerito]

I just posted a suggestion to wordpress.org for a change so these 404s are handled faster

http://wordpress.org/support/topic/404-handling-of-non-html-files-returns-html

[deepsand]

I just looked up phantom page. it's the first I've heard the term! So now I understand the context of what your talking about better.

How does a phantom page relate to this issue, or even a 404 discussion?
I am not using the definition "... a Web page that is optimized for search engines rather than for humans," but rather the plain and ordinary one, "something that seems to appear to the sight but has no physical existence."

A page which is named (appears) in a resource, but has never existed, is a phantom page. If such appears in the <href> of a link, the result may be a 404, or some other HTTP response code, depending on the construction of the URI. They frequently arise from the actions of automated applications such as screen scrapers.


It seems your saying don't fix any 404 errors because you have some very rare examples where it has no benefit?
Not at all. Simply that 404s are no more problematic than are a host of other conditions, and much less so than many.


I do see in his previous post he states "404s -do- have an impact on SEs,", "404s on a page -will- negatively impact a site's ranking. It holds less weight than other factors, but it does hold weight". To me he was not stating it is "especially pernicious" nor "for an SE to see one is fraught with dire consequences". (my bolding).

Or is it related to "which gives a 404 error. Anytime you have a 404 error on your page it will drastically impact performance and also affect and SEO efforts.". I'd argue about the use of anytime and drastically but in the case he mentioned, the 404s ARE drastically slowing down the page, potentially getting the page punished for slowness.

Or have I missed something?
As you here point out, the statement is not one qualified as being within the context of the OP's case, but a categorical one. It is strictly within the context of said categorical statement, one that I recognize as being frequently put forth both here and elsewhere, that I speak. Some even vehemently argue that one must have a robots.txt file, empty if need be, so as to avoid being penalized by the 404 that otherwise arises.

[Tiggerito]

I just looked up phantom page. it's the first I've heard the term! So now I understand the context of what your talking about better.


OK, it seems there are several definitions for a phantom page. So what does it mean?

(cancel that - just saw your post)

[Tiggerito]

Not at all. Simply that 404s are no more problematic than are a host of other conditions, and much less so than many.

And I don't think they are saying anything different. Just that it has some affect.



As you here point out, the statement is not one qualified as being within the context of the OP's case, but a categorical one. It is strictly within the context of said categorical statement, one that I recognize as being frequently put forth both here and elsewhere, that I speak. Some even vehemently argue that one must have a robots.txt file, empty if need be, so as to avoid being penalized by the 404 that otherwise arises.

They both used terms that relate back to the OPs issue. "404s on a page" and "404 error on your page". This is the biggest cause of the OPs speed problems. They are not talking about IBLs, OBLs or phantom pages but 404s related to the issue at hand.

I agree on the robots.txt case (which is also nothing to do with what anyone has talked about). 404s are not evil, but in many cases, fixing a 404 will be good for you. In this case, the 404s on the page are slowing it down to a degree that affects user experience and may even cause some punishment from Google. The exact concern expressed in the OP. I think in this case the 404 errors and how wordpress handles them (slowly) are a very problematic condition.

p.s. I've had to reference a dictionary several times for this thread :-)

[deepsand]

And I don't think they are saying anything different. Just that it has some affect.

They both used terms that relate back to the OPs issue. "404s on a page" and "404 error on your page". This is the biggest cause of the OPs speed problems. They are not talking about IBLs, OBLs or phantom pages but 404s related to the issue at hand.
Well, you don't get a 404 "on a page" or "on your page," but only on requests for pages that don't exist. ;) Therefore, to take those phrases as being qualifiers seems to me to be a bit of a stretch.

And, your saying "I'd argue about the use of anytime" seems to be tacit, if not conscious, recognition that "anytime" is categorical in nature.

Whether or not the member in question intended it to be a categorical statement or not we'll not know unless and until he returns to clarify. From my point of view, given that it gives the appearance of being categorical, and knowing that very many are accepting of such claims, as well evidenced by their being oft times repeated, I felt it important to rebut so as to diminish the risk of a silent reader being misled.

The take away point is that, as we both know, each occurrence of a 404 must be evaluated within its own context of the moment. Obviously those of greatest concern by far should be those generated by broken internal links, as they have an immediate and direct impact on your visitors. Next in line would be broken IBLs that are desired, and which can be remediated; those that cannot might be salvageable via re-directs. Everything else can and should, IMO, be ignored.

[Tiggerito]

The take away point is that, as we both know, each occurrence of a 404 must be evaluated within its own context of the moment. Obviously those of greatest concern by far should be those generated by broken internal links, as they have an immediate and direct impact on your visitors. Next in line would be broken IBLs that are desired, and which can be remediated; those that cannot might be salvageable via re-directs. Everything else can and should, IMO, be ignored.

Totally agree with that, and well put. Hence I put it first.


Well, you don't get a 404 "on a page" or "on your page," but only on requests for pages that don't exist. ;) Therefore, to take those phrases as being qualifiers seems to me to be a bit of a stretch.

I'd agree, I have re-read this thread several times and those were the simplest parts of their statements to indicate that they were talking about 404 errors that happened while the page was loading. Their broader statements back up that case.


And, your saying "I'd argue about the use of anytime" seems to be tacit, if not conscious, recognition that "anytime" is categorical in nature.

Back to the dictionary....Yes, anytime and phrases from both sides of this threads discussion have used general statements with absolute arguments (That's what I currently think categorical means?). When I post I try and consider that, so I use words like probably, seems, likely, think and try ;-)


Whether or not the member in question intended it to be a categorical statement or not we'll not know unless and until he returns to clarify. From my point of view, given that it gives the appearance of being categorical, and knowing that very many are accepting of such claims, as well evidenced by their being oft times repeated, I felt it important to rebut so as to diminish the risk of a silent reader being misled.

This is probably why I joined in as well.

I think in this case the first guy made a statement that would help the OP, so statements like nonsense will mislead the OP and silent readers to thinking that the help given was wrong. Then when someone else backed up the case you started to go off topic and general while using the word categorical! Then I kicked in as the third defender and perpetuated it!!!

Several people have posted here with information that I think will help the OP resolve the issue. I may be wrong as my opinion of the solution may be wrong. But I feel what these people have said is logical and backed by data. So their statements should not be hit with phrases like nonsense and comments that are nothing to do with the issue at hand.

[Ravenhawk]

I really enjoy all the discussions around wordpress running slow and how right off the bat so many try to blame the number of plugins running. I can say with some great certainly that the number of plugins doesn't matter at all but it is the plugins you are running together and if they can play well together. I did see folks point out that he has some plugins and it is time to retire them since their functionality is now in the core. All in all it does not matter if you run 65 plugins or 3 if they are well programed they will have minimum impact and may actually help it speed up. This I know for certain since I run sites that use up to 75 plugins with no effect on load speed..

Now to the real culprit for slow wordpress websites, this is though some extensive testing on my own servers as well as several different hosting companies including GoDaddy. The problem 99% of the time is the server your site is on and its configuration, the number of other sites on that server, the server power, the location of the MySql database i.e., is it local or remote and the configuration of the MySql server itself.

So here is how you fix your problem:
1st ask that your site be moved to a new server.. if that does not work change hosting provider and find a good one that knows how to configure a server properly like beachcomber.net and does not overload them.

--or--

2. Get your own dedicated server and make sure it is configured properly if you do not know how to do it then hire someone who can or again find a company that will do it when you order your server like beachcomber.net

Those are your only real solutions to fix a slow wordpress website.

[davebarnes]

problem one... godaddy. i'm pretty convinced godaddy hates wordpress...I'd start with changing hosts.I have had the same experience with one of my customers' website.
I like GoDaddy for lots of things, but hosting is not one of them.

[jhilgeman]

All in all it does not matter if you run 65 plugins or 3 if they are well programed they will have minimum impact and may actually help it speed up. ... This I know for certain since I run sites that use up to 75 plugins with no effect on load speed..
...
Now to the real culprit for slow wordpress websites ... The problem 99% of the time is the server your site is on and its configuration, the number of other sites on that server, the server power, the location of the MySql database i.e., is it local or remote and the configuration of the MySql server itself.
...
Those are your only real solutions to fix a slow wordpress website.

I strongly disagree. Not every well-programmed plugin will have a minimum impact. A plugin is a vehicle. You can make a cement truck as aerodynamic as possible, but no amount of effiency / good programming is going to turn it into a sports car. And if you have 75 plugins running with no effect on load speed, then you either have no other traffic on that site/server or those 75 plugins just don't do very much individually. If you echo out "Hello world" 75 times in PHP, it'll take a fraction of a millisecond to do, but it will still take time and that is about as simple as you can get. Plugins have structures and need dynamic processing and are in individual files (which disk I/O will impact) - you ARE losing some load time with that many plugins. If you have a plugin that tries to cache HTML and process it, you're probably running the regex engine and output buffering, which will prevent progressive loading, etc, etc, etc

A plugin is code. The more code you add, the slower the PHP engine goes - there is no way around that simple fact. Also, the more plugins you add, the more likely you are to have a conflict between plugins or install one that is either large or poorly-programmed. A developer is likely to say, "Well, my new fancy plugin only slows down my WP installation by 1 second, so that is acceptable." But when you have 75 plugins, each developed by different developers who may say the same thing, you can easily end up with a mess on your hands.

In this guy's case, if you've looked through the plugins he is using, you'll find that there are a few different ones that have a rather suspicious/spammy background and have other people in separate forums talking about how it slows down their WP sites, too. SO in this case, it's is 99% likely that it is the plugin, NOT the host.

I'm only adamant on this point because it takes time to have a host switch servers or even for the person to switch hosts entirely, and it's very unlikely to help him. There are tens of thousands of WP sites running in similar hardware/server configurations (shared and dedicated) and most are running just fine. The main difference is site content and plugins, and content is almost always just regular articles with some images.

If you run Firebug and notice the load times of the resources, you'll also see that his PHP pages are the pieces that are slow to load, not the resources themselves. If it were truly GoDaddy's infrastructure, you would probably see images and Javascript and CSS taking far longer to load, but in this case, it's only the rendering of the PHP pages.

You say that you know your point with certainty because you've been running WP sites with lots of plugins. I understand that background, but I've been doing LAMP development for over 10 years and specializing in optimized architecture (and I've successfully helped hundreds of people with speed problems on their various applications, including WP). Please trust me - this is not host issue in this case.

[wpfox]

Please look at the theme sources. If there is used WP_Query - then you should pay high attention to its params. By default wordpress adds to the query a string to return the count of all rows if only few are returned (for paging, etc).
In the places where you do not need this please add this line to the params list:

'no_found_rows' => true,

so your arguments will look like:
$args = array(
'posts_per_page' => get_option('pst_on1st_page'),

'no_found_rows' => true,

'cat' => get_option('cat_to_show')
);

that line of code will extremely increase database performance.