I recently migrated to Siteground. I was on their platform for about a week before I switched back. I’ll tell you all about it after you grab your cup of coffee.
Full disclosure: this post contains affiliate links.
I’ve been blogging for two years. I had a post that went viral on Pinterest and which to date still produces the majority of my traffic. I took Carly’s highly instructive Pinteresting Strategy course and applied her lessons. Excellent material and I highly recommend it if you are new to Pinterest. I learned I needed to diversify my traffic and to discover how to get SEO working for me.
I read and read. I watched lots of videos. I bought Debbie’s Easy On Page SEO e-book. I learned tons more but the main takeaways were the importance of a snappy site—especially for mobile users.
There are plenty of tools which check the health of your site (Web.Dev, Uptrends, GTmetrix and PageSpeed Insights) and call out opportunities for improvement on a report card. They also gage your site speed.
Why so slow?!
To your average user, 2 seconds is an eternity. I tested my site using the tools. The tools emulate a mobile device. Additionally, I checked it with my Samsung Galaxy S10. The load time was atrocious. I had mostly used my laptop and rarely checked it on my phone. When I did, I was aghast. It took my smartphone 3 to 4 eternities to load! I was losing my potential audience!
I wanted to fix it. I asked around on my Facebook group and many of the bloggers swore by Siteground. After some research I made the switch. Siteground offered a $9.99/mo. introductory rate that ramped up to $25/mo. after a year. That’s steep when you compare it to the Bluehost’s $2.75/mo. I had been paying. In light of the 30-day money back guarantee, I figured what’d I have to lose.
Siteground to the rescue.
I asked Hubby to help with the migration. He’s a web developer. He’s helped edit and/or write portions of this post, so if I my technical understanding seems to have gone up a notch that’s why.
Siteground provided a WordPress plugin for the migration. It took about 5 hours but it worked fine. Once complete, I configured Cloudflare. It’s a CDN whose features help with security and speed. Eventually, everything was ready.
Why so slow, still?!
I anticipated immediate gains but I didn’t notice one. Hubby and I spent days trying to figure out why. I enlisted Siteground support. They tried to help but in the end my site was no faster than it had been on Bluehost.
Apparently, performance isn’t just one thing (inferior hardware or a server overloaded with tenants), but the sum of many. Throwing a new host at the problem only increased my costs.
Let’s figure this out.
That’s not to say the experience was fruitless. I learned about Cloudflare and kept it despite switching back. And I recruited my husband to troubleshoot my site’s performance woes. Using the Web.Dev report card he started addressing the issues first on Siteground and, after moving back, on Bluehost. In retrospect Hubby said it would have been better to address these concerns before migrating to the new host.
One of the important metrics with navigating to a site is what’s listed on the report card as a “First Contentful Paint.” It’s the moment the page renders enough content to give the user the feeling she’s arrived—even if the page continues loading in the background. To keep your users happy, it’s gotta be snappy.
Per the report card, there were a lot of contributing factors to the sluggishness felt by mobile users. To understand these you should understand the structure of a web page.
Pages have visible and invisible elements.
Every page has a head element which includes necessary but invisible metadata and infrastructure followed by a body element that determines what is actually displayed. The upper portion of the body is the portion of the page that fits in your device’s viewport, the part you see before scrolling down. What appears in the upper portion is said to be “above the fold.” Everything else is “below the fold.” Your aim with the first contentful paint is to appease the user by displaying the above-the-fold content quickly.
Well, every plugin in WordPress requires invisible resources (e.g. scripts and stylesheets) that must be loaded. Loading these resources before the initial above-the-fold content will contribute to your site’s sluggishness. The implication is there are ways for site owners and plugin and theme developers to optimize this. Some developers are more diligent than others in figuring out this optimization puzzle.
The “Eliminate render-blocking resources” complaint that appeared on my site’s report card was my first priority. My site carelessly loaded much of its invisibles before its visibles. I was able to determine this by looking under the hood (e.g. Viewing Page Source and Inspect DOM). I had to reprioritize the resource load order to fix this. It wasn’t straightforward, perhaps in part due to the unique design of every WordPress theme, mine included. The Async Javascript plugin was a big help. Additionally, I eliminated superfluous images, fonts, and plugins.
Images must consider the target device.
Another key player in the speed game is images. Images not served in a device-appropriate size bog down a site. Many bloggers are not savvy enough to correct this. Truth is, they’d prefer to not have to think about it at all. They want to concentrate on writing posts, not fixing technical concerns. Sadly, no free plugin I’m aware of eliminates the concern, though WordPress 4.4 did make major strides (imgsets, picture, and webp).
Image size wasn’t a serious concern until Apple put the web in everyone’s pocket. Site developers had to learn to accommodate an increasingly wider variety of devices and nothing slams a smartphone like trying to shove big images down small pipes. While WordPress has improved no single plugin eliminates the problem.
Let’s throw a plugin at it!
WordPress mitigates concerns by way of plugins. Every plugin is a fix for something. The mentality that you can throw a plugin at it may incline users to believing that every issue can be solved this way, but taking this too far has its own issues.
You want a fast site, for example. If one plugin helps some, it stands to reason two will be better. You also need to understand, however, that every plugin adds overhead to processing page requests.
Consider the Russian nesting doll.
Imagine a website is a Russian nesting doll. WordPress is one doll and so is each plugin. When a page request hits a server, it drills through the layers and then formulates a response. That response bubbles up doll by doll and is finally returned to the user who requested it. This is a gross simplification, but as a mental model it helps you visualize an interaction with your web site.
Cloudflare is an even bigger doll, a CDN which wraps your entire site. While it may seem odd to have so many layers, this design is actually a smart way of keeping things modular and manageable.
It should be obvious why you don’t want two layers addressing the same concern. You don’t need a minification plugin for WordPress if Cloudflare is already handling that. Same with image optimization. Relegate every responsibility to a single layer. That’s why you need to understand which layers own what. If you don’t understand you run the risk of hindering your site as much as helping it.
If you don’t want to pour your time into understanding these optimizations it may be useful to periodically pay someone to assist with this. It’ll cost you, but by enlisting an expert you can focus on your bread-and-butter activities.
A word on caching.
If you’re going to attempt this optimization yourself, beware caching. Caches can exist in one or more layers. A cache is software’s attempt to avoid having to do the same work twice in order to improve the response time on like requests.
But a cache can be confuse you while you’re developing. When you’re swapping out plugins and tweaking settings you may, due to caches, not always see the result you expect. You have to disable or routinely clear them, each and every one, to clearly see the effects of your adjustments.
The host is one factor. There are others.
Use my experience to your benefit. Yes, your site should feel snappy, esp. for mobile devices; however, there are a various things to consider before blaming any sluggishness on your host:
- Confirm your page loads prioritize visibles over invisibles.
- Chose plugins sparingly and understand exactly what each buys you.
- Serve images in a device-appropriate size.
- Test your pages using an optimization tool.
- Use a CDN (the free tier to start) for added speed and security.
If you’re thinking of migrating to another host, know what you’re getting and check that you actually got it. I migrated to Siteground expecting speed, but I didn’t notice a difference. I don’t blame them. I had high expectations.
You don’t always get what you pay for.
You can at times pay premiums for the luxury of not having to deal with a problem, but not always. Moving to Siteground didn’t magically solve my speed problem. Cloudflare can, for a fee, relieve you of the responsibility of image optimization (e.g. serve them as webp and in the right size based on device). Always confirm you’re getting what you expected and paid for. Don’t just assume you have.
My site is still not as fast as I’d like it to be. I addressed some issues, but others remain. If I one day make enough to warrant it, I’d leap at the premium services, at not having to fuss with technology. I’m not there yet. For the time being I’m sticking with the economical option and that’s Bluehost.
Jennabel
Pin for later:
