Executive summary: Dissatisfied with my blog’s response time, I looked into a variety of options. For about a month, I tried a wpengine experiment whereby I moved everything to them. It didn’t work out, but I learned a lot along the way. I’ve been dissatisfied about the page load times of my blog for a long time. After some pent-up annoyance, I’d futz with things like swapping out the theme or not running fifty-seven plugins (especially the one that translates prose to the binary language of load lifters). Like a thump on the side of a recalcitrant TV, this would confer sufficient and unsubstantiated improvement that I could focus other things.
Then, in November, someone pinned one of my posts on Pinterest. Traffic shot up 5x for a couple of days before returning to normal. The same post has been repinned every three weeks. While I am thrilled that something I wrote is being referenced by the erudite, mannered and comely pinhabitants, the pinstorms were pincreasing my page load times to a ghastly 15 seconds.
I needed to figure out why it was so slow. Some DuckDuckGoing yielded a set of blogs by Steve Souders, formerly of Yahoo (now of Google) with best practices for improving performance. Many of these were codified into YSlow. Nearly everything they test for, I was doing wrong.
This was also the same conclusion of Webpagetest, which also lets you examine your site from different locations around the world. It gave me a better appreciation for the benefits of content delivery networks. I remain flummoxed about how to address the “cookie-free domain” of images recommendation it always dings me on.
Zoompf offers a free performance scan as a lead-in to their enterprise reporting service targeted at large sites who won’t flinch at the $100-200/month price tag. (Me: flinch) The sample report covers many of the same concepts as YSlow, but in an effort to impress, it just lists pages and pages of stuff sprinkled with up sell. Frankly, I found this presentation unactionable and of dubious value. For example, at the top of the performance list, under the “critical and high impact” category, was a page full of suggestions that I replace every PNG with a JPG. An example reduction of 1294 to 777 bytes would yield “39.954% improvement.”
Um, riiiiiiight. I have this rule of thumb that the more digits of precision someone (or some company) lists, the less likely it is they know what they’re talking about. This image: is fine as a PNG file. And let’s be realistic, the 517 byte savings is not going to amount too much improvement. It would be more effective to make the image part of a CSS sprite and save the extra connection.
An option I hadn’t considered before came via a HackerNews story where some A-list blogger was absolutely gushing about the principals of WPEngine. The premise is they are the WordPress equivalent of SuperFriends who have banded together to
defeat Giganta offer managed WordPress installations.
When stated as a function of the opportunity cost of “things I can do if I don’t have to coax acceptable performance out of my blog,” the $29/month, entry-level plan seemed worth looking into. Though I host a vanity blog in an anonymous cookie-cutter neighborhood somewhere far east of town, past the phone pole with the red shoes dangling from the wires, I was concerned about exceeding the limits of their entry-level plan, especially if I kept being repinned. The price difference between their entry-level ($29/month) and middle tier ($99/month) is steep.
They assured me they were most concerned about bandwidth and general resource allocation (issues partially mitigated through using CloudFlare). I viewed this as a good sign because instead of adopting the shared service provider promise of “infinite bandwidth” and overselling it (which is not unreasonable since everyone overestimates what they’ll use), they were keeping an eye on metering resources to provide quality service for everyone. They also have a reasonable approach to counting visitors.
Migrating my blog to WPEngine was very easy:
- Export a backup of posts from my DreamHost-hosted blog.
- While I was migrating… used my vim-fu to modify the backup so the images pointed to a second domain. This would let me decouple the images from the blog content. (Doing this was an opportunity to clean out all of the non-content cruft that I’ve accumulated since 2002, when I was on Movable Type (before switching to WordPress, back to MT, and again, finally, to WordPress).
- Install my Pagelines theme and plugins.
- Tell CloudFlare to use the new server.
The switchover took about two hours, plus a few hours spread out over the next few nights to reconfiguring Pagelines and plugins to look acceptable. I really appreciated their site backup/staging feature – it let me try plugins without taking down the original. It’s speedy and seamless.
They install, but do not activate, a handful of curated plugins. Being so separated from WP-cool, it was interesting to browse through what’s new and available. My head almost exploded trying to ponder the search engine optimization one. (Too many options.)
Using the WebPageTest, I went from FABF✓ to CAAF✓. Page load time decreased to about 6 seconds. Shortly after my trial started, DreamHost sent me this:
During a recent security scan we have identified that one or more of your hosted sites have been compromised and may have an open security flaw which allowed malicious parties to abuse your site for unscrupulous purposes. Further details regarding what security concerns we found can be found listed below:
After nearly shitting my pants, I determined there was no real damage because the web site was inactive. What appears to have happened is another user on DreamHost was infected. This infection, run via shell, surfed user directories to look for WordPress and specifically subdirectories that were world-writable. It managed to traverse my directory structure, find the opensource theme (WonderFlux) had world-writable directory permission, and deposited a kiddie script in each. The scripts were a relatively old hack that fetches a set of directives from a hard-coded IP address. In essence, it installs a shim to turn the site into a botnet. Pass the Canadian-grown V1@[email protected]!
To be safe, I blew away everything and restored from the known good backup taken when I moved the site over to WPEngine. I also contacted WonderFlux’s proprietor suggesting that the file permissions might be reigned in a notch, changed passwords using my handy-dandy password manager, and used my scripting fu to audit file permissions.
I have a few simple takeaways from this experience:
- Always have a backup no older than the amount of data loss you’re willing to incur.
- Don’t expect help from your web hosting provider. DreamHost deals with hundreds of these things a day. Their support people are happy to run their scanner again, but that’s about all. The “site restore” option buried deep within their control panel is ornamental.
- Even though WordPress components may be inactive or unused, they still represent potential security problems. I’d checked WonderFlux for php shenanigans, but didn’t think to validate its file permissions. (This was clearly my bad.) I should have also deleted it when I was done.
So up to this point, I was feeling a lot of love for giving WPEngine a try.
The first two weeks on WPEngine were great. The three technical questions I had were answered promptly and with great information – Christopher and Donovan had WP-fu. Even with the biggest pinstorm I’d seen yet, page load times were still hovering around the 6 second range.
Then on March 21st, I tried logging into my console to write:
There was nothing in the error logs, so I reported this to support. One of their technicians gave me a “try it now,” and chalked it up to a timeout. I’d later find out this was part of some broader issues. No specific root cause was noted.
A week later, it happened again. It just hit me on the wrong day, and I was amped up on frustration in my support request. Their junior support person responded within 20 minutes saying she couldn’t reproduce it and suggested it might be a “browser issue.” (Browser Issue is becoming the new “Update Windows.”) Since they had a similar site problem earlier that day, I had my doubts, but just in case, I tested it with Chrome, Firefox and Safari. I also logged in from work using IE. Same result.
The following evening, I was still unable to login and heard nary a peep from them. I started moving all of my stuff back to Dreamhost. Reloading the blog database on DreamHost took freaking forever, but I was back online. One more check that they hadn’t responded, so I requested they cancel my account and that they refund the first month per their 60-day guarantee. A few days later, their blog showed more of these 50x problems. And again.
Clearly, they are having some growing pains. I hope they can work past these because the value proposition of not spending evenings farting around with WordPress/Apache/Caching plugins or dealing with the ongoing security issues with PHP and WordPress make their offering interesting.
In the meantime, I’ve been spending my evenings farting around with WordPress/Apache/Caching plugins, coaxing out an improvement over what it was doing before. Now if I can just get back to writing again…