A slightly newer face for Serverwise
Our CEO Matt is an advocate for the idea of implementing a new project about 80% of the way, deploying it, learning, and then iterating until it’s finished.
Even though most everything is never actually finished.
In this blog’s case, it was more about 25% right followed by constant iteration. Now and then, we launch something some more significant changes. In early September I deployed perhaps the most radical change in the Serverwise blog since its deployment.
Get THE BEST DEALS IN CLOUD HOSTING from Los Angeles!Grab a huge 32GB RAM & 320GB of SSD storage for just $109/year!
Let’s talk quickly about what’s changed.
We first migrated the blog from HubSpot (yikes) over to WordPress, I found the Milligram CSS framework, which touts itself as “minimalist.” At 2KB when gzipped, it’s undoubtedly quite small and is pretty easy to get the hang of, but it also didn’t provide enough support when trying to rapidly develop new ways of organizing our content.
I’m willing to admit I was misusing Milligram, but I ended up having to write a dozen lines of additional code for nearly every major element to account for responsiveness. And because it was all one-off
@media screen and (max-width: 960px) ... code, both the breakpoints and the changes they made were inconsistent.
I have since transitioned to Bulma, which is more extensive and far more opinionated (I don’t love seeing
!important in Firefox’s inspector tool), but also far more predictable in how it handles typography and responsiveness. A few additional classes on certain elements means I know exactly what they’ll do in variously-sized browser windows.
If I do have to write responsive
@media code, I can use Bulma’s responsive SCSS mixins, like
@include desktop-only to target predictable breakpoints.
All in all, I have to write about 1/5 the code I used to.
Eventually, we’ll see this across our main page as well.
I’ll write more about monitoring next week, but here’s the gist: I finally realized how important it is.
Thanks to NewRelic monitoring, we discovered that in July the time our web server needed to generate
single.php template pages, much like this one, had tripled. Unfortunately, we didn’t notice this issue until late August.
We spent a few hours diagnosing the issue and discovered a handful of issues, which we fixed and deployed quietly. We then spent time making speed-oriented improvements to our templates, all of which have dramatically improved page generation speed.
It’s pretty self-explanatory. We wanted to make it easier to find the content you want and more comfortable to read it, too. Plus, the Bulma framework will enable us to do some cool things in the future.
More hassle than they were worth. If you want, you can always shoot us an email.
Beyond the blog, we’ve made some plan and pricing changes that might have slipped under your radar.
In late August we introduced a new 24GB RAM plan, built on our resilient KVM platform, to accommodate our large group of users who need a little more RAM breathing room without going all the way to 32GB. It instantaneously (a big surprise to us!) became our best-selling plan, which validated our assumption that not all VPS users are looking for the absolute lowest price 1GB servers.
To make room for the 24GB plan we temporarily disabled the 32GB plan, but that’s back now at $[price plan=”four”]/mo.
We’re now officially a large-to-very-large VPS provider, with our plans starting at 8GB of RAM and ballooning all the way to 32GB. No 512MB plans for us, because why waste everyone’s time with something with such little value?
More on that, too, in the coming weeks.