Quantcast
Channel: Learn How To Make Money Online at The Keyword Academy » Wordpress
Viewing all articles
Browse latest Browse all 2

Is Your Site Too Slow?

$
0
0

Welcome to the very first WordPress Wednesday on The Keyword Academy. Peter Butler – our full time WordPress Ninja and operator of the Code Garage – will be publishing an article each week on how y

our WordPress site can serve your internet marketing business better.

Is your site slow? Most of us can’t answer that question with much confidence. What qualifies as slow, anyway? This ambiguity creates a nice, comfortable excuse. It’s tough to think through – so why worry about it? Seems like it loads up ok to me…

I’ll make things more clear:
If you haven’t given serious thought to speeding it up, your site is slow. I promise.

Having done quite a bit of one on one consulting and troubleshooting work over the past few years in my time with The Keyword Academy, I can say that your site is slow with almost complete confidence. Here’s why:

As an internet marketer, you:

  • use WordPress for your site(s)
  • have multiple sites, and little startup capital, so you’re on an inexpensive shared host
  • are likely using a free theme, which may be outdated
  • LOVE plugins

I’m not saying any of these things to make you feel bad, and I’m not even telling you you need to change your ways – this is just the way our field operates. If you want your site to be faster (and you do), you need to know what you’re up against, and what kind of simple changes you can make to improve your site’s speed.

There are a lot of techniques and tools to help you with the specifics of speeding your site up, but I want to talk about the basics behind those techniques – understanding what is actually happening on your website can help you make better decisions about how to speed it up.

So here it is – to understand how we can speed up your site, lets look at the entire process, from the visitors browser, to the last line of code on your wordpress install, and back again:

normal-request

After the user types in the url for your site, that request gets sent to their ISP, who sends it along to your server (where your site lives). Your server hands off the request to WordPress, which starts to work it’s magic.

WordPress has a lot of things it has to do. It has to:

  • Read the url and figure out what to display (assuming you have permalinks turned on)
  • Go out to the database and find that content, pull it out for use
  • Figure out what theme you’re using, and which part of the theme is supposed to display this particular page
  • format the content it found to fit into that theme.

All along the way, wordpress is checking in with all the plugins you have installed, asking if any of them want to jump in and add or change something. Once all that is done, WordPress spits out some html back to the server, which sends it back to the isp, and back to your visitor’s browser. When you take the time to look at each step, it’s actually impressive that a user can even get a response from your server in a few seconds.

Unfortunately, the magic of the internet is of little importance to your impatient visitor. All he knows is that he wants to see your page, and in a hurry, before he clicks back and checks the next search result. So – magic aside, we’ve got to figure out how we can cut out some of the time consuming steps along the way.

The first 2 steps – going to the visitors ISP, and then to your server – are tough to get around, and we’re not going to worry about them for the sake of this post. Once the request arrives at your server, we want to get the page generated and sent on it’s way as quickly as possible. So, where are the bottlenecks after the request arrives at your server?

  • The Database: Databases are built to be fast, and MySQL, which wordpress runs on, is no exception. It’s blazingly fast at going out and finding exactly what WordPress needs in order to generate a page. However, the fastest database in the world still takes time to work – WordPress has to connect to the database, and then request, and handle the response of every little piece of information it needs for a page – easily 20-30 (but sometimes 80-100) times per page load.
  • Plugins: WordPress does an amazing job at being flexible, and allowing developers to build in useful new functionality with ease. Unfortunately, there’s a downside to all this flexibility – WordPress has to give all active plugins an opportunity to jump in – to the tune of hundreds of times per page load. It adds up.
  • Page Generation: After WordPress gets all the content it needs from the database, checks in with it’s plugins countless times, it still needs to actually build the page the user will see, and it does this by opening up your theme template files, and gluing them together, with content in place, to be displayed. In the grand scheme of things, this part is very fast – but it still slows us down.

This is all very doom and gloom – but there’s a way we can get around the whole mess. Most of the time, the content on your site’s page doesn’t change. The homepage changes when you get a new post, and when people make comments on your posts, those pages change – but compared to each time that your site is accessed, those things happen very infrequently.

Caching Time

So, as you’ve probably already guessed, the trick is to cache the pages of your site. By caching them, we watch when a page first gets accessed, and once WordPress is done working all of it’s magic, we send it back to the user who requested it – but we also save a copy on the server, for future visitors. The next visitor to come along sends a request to the server, but once we get to the point where things take a while – WordPress going through all of the steps it needs to generate the page, we just grab the pre-made version, and send it back to the user. No database calls, no plugin interaction – it’s all already been done, and the results have been saved, and sent off to the user.

cached-request

How much faster does this make my site?

As part of the Uptime Monitoring package at my site Code Garage, I keep track of how long it takes for sites to generate the homepage every time I check to see if they’re online. To test, I ran a comparison over a few days, to check the difference between having caching enabled, and having it turned off. The results? Without caching enabled, the generated the homepage in a respectable 1.28 seconds on average. With caching enabled, that number dropped to a spritely 0.31 seconds – a 400% increase!

But wait, there’s more!

The benefits of a good caching plan go beyond just making your site load faster – on the average shared host, performance will decrease dramatically as the number of users on the site go up. How dramatically? Another quick test:

  • 100 page loads coming from 10 users at a time, without caching: 2.125 seconds average processing time
  • 100 pages loads coming from 10 users at a time, with caching: .549 seconds average processing time

At 10 concurrent users, my poor shared host starts to slow down significantly for each page load – but with caching enabled, it barely breaks a sweat.

What now?

All that’s left is for you to scamper off to find a caching plugin, and install it on your site. My personal favorite is the W3 Total Cache plugin. It’s a bit daunting on first install, and it probably deserves a post just on how to make sure you have it configured properly – but for now, just make sure you have “Page Caching” enabled on the general settings page.

Now go speed your site up!


Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles



Latest Images