Forum Replies Created
@Davinder – I agree with you that you can have too much of all the things you mentioned.
The challenge is that speeding up a very slow site often involves reducing a little bit everywhere, because most people are unwilling to accept very drastic cuts in 1 particular area. For this site’s menu items, it has some menus that go to a 3rd level, and it has both primary and secondary nav menus. All of that takes time to generate.
Menus aren’t likely the primary reason this user’s site is slow, but if one doesn’t prune the menus, one has to take more from the other things you mentioned (images, scripts). Big menus like this also present big challenges on mobile responsive design, which this site isn’t using. Personally, I also think the menus are a dizzying array of too many choices, and fewer choices would help guide visitors better. For all of those reasons, I think the existing number of menu items is too many.
If you’re running a Genesis theme, here are a few places where the script might come from:
* a plugin or some settings for an activated plugin (only activated plugins count)
* your child theme’s functions.php file or any files included automatically in that file
* the file that loads your theme’s home page, sometimes home.php or front-page.php (or another template file used to load the page where you see the script)
* the Header and Footer Scripts metabox of your Genesis settings
* Genesis Simple Hooks (if you are using that plugin)
* the Scripts metabox of the single post/page editor
If you see the Aweber script on every page, then the last choice is less likely unless you are using a static home page on your site and only checked the home page for speed. Also, when you locate how the script is loaded, you’ll want to make sure the script is enqueued. You’ll probably be able to tell that based on how the script is added. While it is possible to simply echo the script in a location, if it is enqueued, it can be easily dequeued via a plugin (that acts like an on/off switch) in a situation where it’s not responding.
@CruiseDirections – I’m going to respectfully disagree with some of what @Davinder said. While I agree that there is no actual limit on menu entries, the more menu entries you have, the longer it takes for your site to load. The incremental time for each menu entry is very small, but if you have a lot, it adds up. Your site is fairly slow, with page load times over 5 seconds. Since speed is factor in ranking on a SERP, to the extent that you get business from organic search traffic, that slowless is costing you money.
If your site otherwise loaded in 1 second and you had the number of menu items you do, I would agree with @Davinder that your menus aren’t a problem. But since your site is slow, one of the solutions to get a much faster load time is probably going to include reducing the number of menu items you have.
Your performance has nothing directly to do with your theme in this case. Your slow performance is due to loading awt_analytics.js, apparently an Aweber script. If there is a difference in one theme to the next, it’s likely caused by how you load it. If you load it the same way, difference in timing could be due to the response of their servers, not yours.
In 1 quick test, your site took over 27 seconds to load and the Aweber script represented about 22 seconds of that, so you have other factors making your site slow, but it is has absolutely nothing to do with the Sixteen Nine theme itself.
The simple answer is yes. You can read how Genesis assigns images to content in our article here, http://wpperform.com/genesis-framework-archive-images/.
The important takeaway from that is that it’s possible to specify a “fallback” image when you haven’t specified one of the other types of images, and it would be best to do that via a custom plugin. You just have to take care to actually specify a unique image where you want one and to make sure your starting fallback image is sized generously enough, so that if you change themes and regenerate image sizes, everything still looks good.
iPage is unreasonably cheap, and while we’re lot more in percentage terms, the absolute dollar difference wouldn’t buy a nice meal. I think if you have 1 question in a year’s timeframe, it justifies that difference. We don’t like to let money stand in the way of good relationships, so if you think we’re a good fit, get in touch.
On “nothing anyone would try to steal”, don’t be naive. Bad actors aren’t after your content. They are after a range of things, but a few bear mention: your traffic and your domain/reputation. A bad actor can leverage your traffic in a variety of ways and redirect it to their typically criminal schemes. A bad actor can take over your domain and then blackmail you to try to get it back. Most people on shared hosts don’t review their server logs and would be shocked if they did. The volume of attack traffic goes up and down, but just about any WP site is being attacked many times every day, and that likely includes yours. I don’t say that to scare you, because the vast majority of the “attacks” are scans for vulnerabilities that the attacker can exploit. But if your vigilance drops for an extended period, the odds of your site being compromised go up a lot. It’s not that you aren’t being attacked now, because in all likelihood you are. You’re just unaware of those attacks because you’re surviving them.
I’ll try to save you some time on #2 and #3 – don’t bother. You can read more on how we cover security here http://wpperform.com/wordpress-security/.
For #2, the login URL is hard-coded in WP in many places, so it would take modifications to WP core to achieve this, which would not be recommended.
For #3, it falls into the category of fixing 1 problem creates a bigger problem. Attempts to limit logins (or to run security-related code in WP) necessarily runs through PHP. Running that code slows down your site for all visitors.
If you attempt to limit logins via PHP, attackers can can inadvertently create a DoS (denial of service) attack on your site by repeatedly triggering your code to keep them out. Our article discusses why you can never have great WP security on a shared server, but if you are on a shared server and don’t want to/can’t switch, your best approach is to use secure, complex passwords and to use 2 factor authentication – and that’s it. If you try to do too much security in the wrong hosting environment, you can very easily create situations where you’re site isn’t available. Attacks are real and frequent, but stopping brute force attacks are just 1 of many challenges you have running a WP site.
Even though you are using Genesis, you aren’t limited to Genesis hooks. WP has hooks too.
Try init, as in:
add_action( ‘init’, ‘somefunction’ );
This will give you a sense of the core loading order in WP, which will point you in the right direction.
@William – We do managed hosting, and I think you’d be pleasantly surprised about our pricing. If you’re interested to discuss further, just drop us a note using the email link in my signature.
Here’s a site we built for a client, http://www.mostresource.org. It’s running about 30 plugins (including some hefty ones, like NGG). Cached pages ought to be served up in about 600 ms (6/10 of a second) or less; uncached pages in slightly more, but well under 2 seconds. I think it would be very, very difficult, if not impossible, to serve a complex site like this on a single VPS as quickly as we serve it, especially with high traffic loads.
Nginx is the way you want to go if you opt to become your own server admin. The challenge is that being a server admin leaves all of those unglamorous tasks (optimizing the server, backups, security) to you, which is time away from content creation. If you have the interest to tinker, it’s fun to learn. However, at the end of the day, you have 1 VPS talking to 1 DB server, whereas those doing managed WP hosting like us have multiple web servers talking to multiple DB servers, and that redundancy provides a level of protection that you don’t get with 1 VPS, even if you manage to tweak the performance to try to come close to the performance of managed WP hosting.
October 4, 2013 at 1:51 pm in reply to: Can I Keep HTML Pages So I Don't Have To Redirect? #65388
@Tom – You’re right about the permalink change to which I linked not working with pages, but that is easily fixed with a small plugin. Generally speaking, I don’t disagree with what you said about whether doing what the OP originally asked makes sense. I was only pointing out that it’s possible. What’s possible is not always what’s wise.
@DonnaE – If you have less than 50 pages and you’ve moved a site to WP, you’re better off redirecting the .html links to their new locations on your WP site. Links do suffer some very small hit from an SEO perspective if they are 301 redirects, but in the overall scheme of things, it’s inconsequential. The structure of your permalink (including whether the category is preserved in category archives) is controllable.
If you’re comfortable doing .htaccess redirects, they’re faster than redirects via a plugin and as Tom pointed out, it’s one less plugin that you have to master.
October 4, 2013 at 7:49 am in reply to: Can I Keep HTML Pages So I Don't Have To Redirect? #65345
@Tom – That’s not accurate. WP’s permalink settings allow for great flexibility.
Here’s a simple way to do this. I recall from years ago that there used to be an issue with page permalinks (not posts), but this may have been fixed in later WP updates. Be sure to test permalinks of all content types.