Selecting the perfect hosting for your websites can be tricky. There are lots of moving parts, so at Agathon Group we try to communicate in simple, friendly hosting plans. You want enough resources for your site to load well, but without overpaying. How much hosting do you really need? It can be useful (and fun) to take a closer look at the details… while watching out for several common but critical misconceptions about those details!
Misconception #1: Pageviews are the most important factor in choosing a hosting plan.
As we host a wide variety of sites for a wider variety of people, this might be the one we hear most often as people are evaluating their options!
Trying to figure out how much horsepower a site needs can be equal parts art and science. The science side of it is often easier to conceptualize: “if I have a certain number of page views, I need to order a certain package.” However, that’s not always a true measure of a site’s resource needs; some very busy sites need few system resources, while some lower-traffic sites need gobs and gobs of system resources. That’s where the art comes in.
Rather than looking at a raw measure of page views, we need to consider a number of factors:
- Does the site use page caching? The busiest part of WordPress is usually the PHP program; caching helps avoid using PHP except when absolutely necessary. This means caching can drastically reduce the busy-ness of your server and, as a result, the amount of server resources you need.
- Does the site offer memberships or e-commerce? If so, these applications can make caching less effective. Membership or e-commerce sites generally need more server resources than a general-purpose blog that sees the same number of page views. Similarly, if your posts get a lot of new comments, WordPress will need to refresh the page cache more often. (We’ll have a post in the future on how to potentially avoid this problem for sites with lots of comments!)
- How many plugins are in use? Are any of them “heavy hitters”? When looking at a site’s resource requirements, one approach is to look at the quantity and performance of your plugins. Even if you’re using caching, your users will occasionally need to request a “fresh”, uncached version of a page. Using a lot of plugins, or plugins that are known to perform poorly, will cause a page cache refresh to take a long time and use more server resources.
There are easily a half-dozen other factors in determining how much horsepower your site may need. The point is that page views isn’t necessarily an effective or primary one of them!
Misconception #2: Server location is a very big deal.
Content Delivery Networks (CDNs) can be very useful in speeding up a site and reducing costs. Most CDNs operate like massive caches, keeping copies of your images and static content to offer to your users as quickly as possible. So when a user requests an image from your site, the CDN caches it and uses that copy for the next user requesting the same image. Most CDNs operate out of a dozen or more locations, meaning users in a similar geographic area can access your static content from a location close to them.
It is this last point that normally attracts people to the use of CDNs. The conventional thinking goes something like this: “Most of my users are on the east coast, but my server is in Los Angeles. If I pay $$$ for this CDN, my users will get my content delivered to them more quickly since it’s coming from a server that is (physically) closer to them.” While that is definitely true, the “physical location” aspect of it can make less of a difference than you think.
To demonstrate, stand up right where you’re at and sit right back down. Go ahead, I’ll wait.
If you’re like me, that took you about 2.5 seconds. That’s about the same amount of time it takes to get from our Los Angeles data center to our Dusseldorf, Germany data center and back… sixteen times. That’s right: a single roundtrip journey encompassing nearly 6,000 nautical miles takes about 150 milliseconds on the internet! Los Angeles to our Toronto data center is less than 85 milliseconds. And Los Angeles to our Denver data center is less than 35 milliseconds. So your users in Philadelphia or New York may be closer than you think!
That’s not to say a CDN cannot be useful. For example, it can save you in bandwidth charges, especially if you have a lot of large images, PDFs, or similar. But normally, that short trip (which is likely less than 2 percent of your page load time) won’t be the biggest factor in your site speed. Beware of jumping on the CDN bandwagon just because of physical geography!
Misconception #3: My site is slow, therefore there is a problem with my server.
There are plenty of ways you can shoot yourself in the foot and slow down your server, including items mentioned above like not employing caching, or installing too many plugins. The good news is that:
- Performance problems with your own site are fixable, because you have control over the variables. We can help you tune your site for peak performance; and
- Believe it or not, the most common reason we see for slow sites isn’t the sites themselves: it’s all the images, ads, and libraries being pulled in from other people’s sites.
Recently, a client came to us asking why their site was so slow on occasions. They had worked to improve their Google PageSpeed scores a few months back and had gotten them over 90 (out of 100). This should have meant their site was speedy… and for the most part, it was! However, when we ran a speed test, we immediately saw a problem and asked: had they added more ads to their site since their previous improvements? In fact, they had, and it caused their Google PageSpeed score to plummet to 18! But when we retested the site using the AdBlock Plus browser plugin (thus removing the new ads), their Google PageSpeed score jumped back up to 86. Clearly, their ads were slowing down their site and affecting their users’ experience.
The good news is that most ad networks we’ve found are interested in their ads running well on their clients’ sites. When we’ve approached them, they’ve been helpful in finding solutions to get things running faster again. But as with any of these misconceptions, the first step is knowing what’s slow before you can fix what’s slow!