📜 ⬆️ ⬇️

Testing 15+ virtual hosting for Wordpress or how not to disappear from the Yandex index



Step 0: How did it all start?


I have a business card on Wordpress. And one day, the speed of the server’s response to it began to periodically “jump” up to 2000 ms and higher. Yandex noticed this, showed me a critical warning in the Webmaster, and removed 25 pages of the site from the index (left 2). So I lost almost all search traffic, which I was very upset about.

My hosting support was disappointed with me, but I couldn’t do anything, “All servers are working, there were no failures”. And since I obviously need search traffic, there was a motive to change the hosting provider.
')
Next, I chose 17 hosts from the issue and advertise “Wordpress hosting”, installed a clean Wordpress there, and tested them for the speed of the server response. Below are the main results and brief comments on each.

Test parameters




Why I did not test the speed of the site (Pagespeed Insights and GTmetrix)?


The speed of the site, in many respects, is influenced by the correct caching (for example, via W3 Total Cache). Unfortunately, many of the hosters do not support out-of-the-box caching: someone doesn’t have Memcache installed, someone needs to make a request to manually restart nginx after each edit, etc.

Moreover, some hosters install Wordpress from the designer already with local optimization, and hosters, where I put WP manually, will be at a disadvantage. Therefore, taking into account the problem of the speed of the server response, I tested all hosters only for this parameter.


Step 1: Selecting Test Participants


Most of these hosters, one way or another (advertising, search results, etc.), advertise "wordpress hosting", up to "the fastest hosting for wordpress" on the landing pages.


Step 2: Testing the site of the hosting provider




It seemed to me logical that if the site of the hoster itself responds with long delays, then it’s obviously not worthwhile to hope for better performance at base rates. Therefore, at first I drove through official Russian-language websites through checks:



By standards, the server’s response rate should be below 200 ms (a significant portion of site checking services mark download speeds of more than 200 ms with an error, Google’s Google Website Insights starts to show an error with 300 or 400 ms). However, I left the hosting faster than 400 ms (all of a sudden, their sites are incredibly heavy, or they are given, who knows).

As a result, 6 hosters do not go to Step 2:


Step 3: Test Clean Wordpress


All Wordpress, for the purity of the experiment, installed by hand from the archive from the official site. No plug-ins (except basic ones, like Hello Dolly), default theme.

Initially, after removing the indicators of empty sites, I tried to install custom themes and caching there, like W3 Total Cache or WP Rocket, but on all hosting services it worked out of the box (on some W3TC it did not work even on the third day of communication with support), because this I excluded the stage.




Step 4: Results


In theory, everything had to end with the choice of the fastest hosting provider, such a happy ending, since the prices for services of all the hosters were about the same. However, the irony was added by the fact that I wanted to go with Timeweb, which entered TOP3 on both lists. Moreover, the support of E-planet for 3 days could not somehow help me get W3TC to work (suggested using another plug-in) without having to update nginx manually.

As a result, Timeweb support updated “resource records on the side of NS servers”, I translated the site to PHP7 and https (not for speed, out of curiosity), the server response speed dropped to an adequate 250-300 ms, I did not go anywhere, but site re-indexed and gradually returns to the issue)


Step 5: Morality




In the market of hosting providers of the Russian Federation there is a significant variation in the speed of server response across sites, which can negatively (or positively) affect search results. Therefore, it is highly desirable, when choosing a hoster, to check not only the control panel, tariffs, etc., but also this parameter. I hope my tests will be useful to you in this)

PS The primary reason for the slow response of the server, as I later found out, was a violation of the domain link with CloudFare CDN (the domain disconnected for non-payment, and after renewal it began to fail) and the long rebinding of the domain back to the registrar. Therefore, if you decide to use CloudFare as a CDN in conjunction with W3TC and (God forbid) you do not have time to extend the domain, you will know where to dig.

Source: https://habr.com/ru/post/316872/


All Articles