
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
- Only the speed of the server response was tested (for me it was the most important) for such parameters as:
- DNS Lookup
- Connect to server
- Making a connection
- waiting for an answer
- Download response
- All results are applicable for Wordpress 4.6.1 with the default theme - downloaded, pulled up the database, logged in, everything; no external themes or plugins were used.
- I put test sites on wordpress tariffs or on starting tariffs with SSD disks (even the cheapest SSD tariffs obviously should be enough for a single WP without themes and plug-ins).
- Each site was tested at least 3 times with a break of 60-180 seconds in order to avoid peaks (in all graphs, arithmetic-mean values). Also, I excluded sharply negative indicators if they occurred only 1 time, and did not repeat in the next 5-15 tests. Example:

- Websites were tested on 5 servers (Moscow, Moscow, Amsterdam, St. Petersburg, Kiev) with the help of WEBO Pulsar (I don’t give the link, but mention is needed so that those who wish and / or those who disagree can check on their own) use the average data.

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:
- Hostink - because of the speed of the response of the main site: it is very unstable, reached several thousand ms, therefore I excluded it from the schedule (strongly stretched). At the moment, the server response speed in Russia is within the normal range, in Ukraine in the region of 400-500 ms, in Amsterdam from 7000 ms :)
- HotHat - the speed of the site’s response is magical, but there are neither technical domains, no temporary ips, etc. in the system, so it’s not possible to install and test the site without domain transfer / purchase (too large), technical support throws up his hands.
- Bluehost - due to the speed of response of the main site.
- iPipe - because of the creepy control panel (bought both virtual hosting and vps), honestly tried to create through the designer or at least find working ftp accesses for more than 20 minutes, felt sorry for the nerves, scored.
- InfoBox - due to the speed of response of the main site.
- Hostland - because of the speed of response of the main site.
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.