I have been aware of WPMUDev’s hosting services for over a year now and I have honestly did not feel any urgent need to switch providers. JAFDIP was happily hosted on small IRON that my little consulting company owns and hosted in out data center. However after carefully reviewing their offering and a chat with their support I felt the cost was too compelling not to at least evaluate their services.
First off let me say I like that they offer a relatively decent set of self service tools. Obviously if I am capable of provisioning my own iron then I am capable of handling most issues myself. What I find attractive is the simplicity of the interface and the fact that most of the heavy lifting has been scripted for the user. However they left enough for advanced site owners so that if you have a sophisticated process such as a CICD build pipeline like we do, the integration is relatively straight forward. I will definitely publish an article about this integration in the future.
So to start off JAFDIP is not a particularly large site and we have a relatively fixed group of dedicated visitors, so in order to evaluate the WPMUDev’s hosting services I opted for the entry level $10 per month account. You can review their plans here. The following is that basic specifications for the plan.
Some of the other features that I found attractive were the staging site area, and WordPress Multisite support, as well as the SSH/SFTP access. Something that were not factors to me were the site migration system. We did not use this to migrate the site because the existing hosting environment was already a WordPress Multisite and the goal was to break JAFDIP out into it’s own. Therefore the migration was a bit more involved than a simple wizard could handle.
Anyone who has followed my twitter feed should already know that I am a big fan of WP Migrate DB Pro and the related suite of add-ons. With this product it was a relatively simple matter to not only export JAFDIP from it’s previous Multisite home but convert it back to a WordPress single site installation as well as address the table prefix name changes required for the new WPMUDev hosting.
Once we had the SQL dump of the site we were able to scp the file into a safe space accessible in the new environment and use standard WPCLI db import procedures to hydrate the site. I would also like to point out that we have to bundle up all of the media files from the old multisite uploads path and move them into this new single site installation. This was achieve via a tarball also scp’d into a safe space for later extraction.
The difficult part was revamping our GitLab based CICD pipeline to accommodate the new destination paths. This required a fair amount of trial and error. Initially over simple scp connections that eventually were replaced with a far more advanced rsync process. Using this process were able to ship our plugins, themes and mu-plugins in from our site repository. It is worth noting that our repository does not contain WordPress itself so that is not something that we would deploy. We are expecting that WPMUDev’s systems will help us manager the installed version of WordPress or we will end up utilizing WPCLI to do this.
Ok so this point you are probably wondering why it any of this important?
Let’s take a look at the GTMetrix score prior to the move.
As you can see for self hosted iron the scores are not to bad and while there is as always room for improvement, it’s a can that can be push down the road for more pressing matters. Given that we were willing to delay some of those improvements it cam a quite a shock that switching providers yielded the following:
I think it’s first important to point out that the first summary bar is referencing standard PLT (Page Load Time) stats and the second bar is based on Google’s newer CWV (Core Web Vitals) stats. So you might be thinking to yourself that we’re not actually looking at that much of an improvement because the KPIs (Key Performance Indicators) have changed. Therefore we took a closer look at the old stats and this is what we saw after the move.
The marker on 04 April shows a significant drop in fully loaded time. What I am referencing is that on 02 April we experienced a fully loaded time of 4.2s and at the time marked it had dropped to 1.7s.
This seems rather significant. In addition the team looked at some of the other historical graphs to try and understand why. One thing we noticed is that there was a significant drop in page requests (Page requests is the forth KPI after Googles new CWV that I always keep an eye on).
All of this translated into a considerable improvement of page scores.
Granted these are all related to the old set of KPIs and it is entirely possible that during the move some things were inadvertently abandoned. We did notice that several widgets were deactivated but even after accounting for those the changes to CWV were minimal.
The team will continue to monitor the outcome of this switch as things evolve, especially since this only wraps up the first phase of our migration plan. We have some big plans refactoring the structure of the site as well as some new services that we are considering. Overall it is impressive to see that moving providers had a significantly positive impact.
Finally I would like to point out that we are not even leveraging any of WPMUDev’s performance enhancing plugins or tools at this time. We will evaluate each in turn as time allows.