Pull to refresh

Тестирование 15+ виртуальных хостингов для Wordpress или как не исчезнуть из индекса Яндекса

Reading time4 min
Views29K


Шаг 0: С чего все началось?


У меня есть сайт-визитка на Wordpress. И в один прекрасный день скорость ответа сервера по нему начала периодически «прыгать» до 2000 мс и выше. Яндекс это заметил, показал мне критическое предупреждение в Вебмастере, и убрал 25 страниц сайта из индекса (оставил 2). Так я потерял почти весь поисковый трафик, чему весьма огорчился.

Поддержка моего хостинга огорчилась вместе со мной, но ничего сделать не могла, «Все сервера работают, сбоев не было». А так как поисковый трафик мне очевидно нужен, возник мотив поменять хостера.

Далее, я выбрал 17 хостингов из выдачи и рекламы «хостинг для wordpress», установил туда чистый Wordpress, и оттестировал их на скорость ответа сервера. Ниже приведены основные результаты и краткие комментарии по каждому.

Параметры тестирования


  • Тестировалась только скорость ответа сервера (ибо для меня это было самым важным) по таким параметрам, как:

    • DNS Lookup
    • Подключение к серверу
    • Создание соединения
    • Ожидание ответа
    • Загрузка ответа

  • Все результаты применимы для Wordpress 4.6.1 с дефолтной темой — загрузил, подтянул базу, залогинился, все; какие-либо внешние темы или плагины не использовались.

  • Тестовые сайты я ставил на «wordpress-тарифы» или на стартовые тарифы с SSD-дисками (мощности даже самых дешевых SSD тарифов очевидно должно хватать для одного WP без тем и плагинов).

  • Каждый сайт тестировался минимум 3 раза с перерывом в 60-180 секунд, чтобы избежать пиков (во всех графиках среднеарифметические показатели). Также, я исключал резко негативные показатели, если они возникали всего 1 раз, и не повторялись за последующие 5-15 тестов. Пример:



  • Сайты тестировались по 5 серверам (Москва, Москва, Амстердам, Санкт-Петербург, Киев) с помощью WEBO Pulsar (ссылку не даю, но упомянуть нужно, чтобы желающие и/или несогласные могли проверить самостоятельно), использовал средние данные.



Почему я не тестировал скорость работы сайта (Pagespeed Insights и GTmetrix)?


На скорость работы сайта, во многом, влияет правильное кеширование (например, через W3 Total Cache). К сожалению, многие из хостеров не поддерживают кеширование «из коробки»: у кого-то не установлен Memcache, у кого-то нужно делать запрос на ручную перезагруку nginx после каждой правки, и т.п.

Более того, некоторые хостеры устанавливают Wordpress из конструктора уже с местной оптимизацией, и хостеры, куда я ставил WP вручную, окажутся в невыгодном положении. Потому, учитывая проблему именно в скорости ответа сервера, я тестировал все хостеры только по этому параметру.

 

Шаг 1: Выбор участников тестирования


Большинство этих хостеров, так или иначе (реклама, поисковая выдача и т.п.), рекламируют «wordpress-хостинг», вплоть до «самый быстрый хостинг для wordpress» на посадочных страницах.


Шаг 2: Тестирование сайта самого хостинг-провайдера




Мне показалось логичным, что если сайт самого хостера отвечает с большими задержками, то надеяться на лучшую производительность на базовых тарифах очевидно не стоит. Потому, вначале я прогнал через проверки официальные русскоязычные сайты:



По стандартам, скорость ответа сервера должна быть ниже 200 мс (значительная часть сервисов проверки сайтов помечают скорость загрузки более 200 мс ошибкой, Page Insights от Google начинает показывать ошибку с 300 или 400 мс). Однако, я оставил хостинги быстрее 400 мс (вдруг, у них сайты невероятно тяжелые, или их ддосят, мало ли).

В итоге, в Шаг 2 не проходят 6 хостеров:

  • Hostink — из-за скорости ответа основного сайта: она очень нестабильна, достигала нескольких тысяч мс, потому я исключил его из графика (сильно растягивало). В данный момент скорость ответа сервера по России в пределах нормы, по Украине в районе 400-500 мс, по Амстердаму от 7000 мс :)

  • HotHat — скорость ответа сайта волшебная, но в системе нет ни технических доменов, ни временных ip и т.п., потому без переноса/покупки домена (слишком масштабно) установить и оттестировать сайт не представляется возможным, техподдержка разводит руками.

  • Bluehost — из-за скорости ответа основного сайта.

  • iPipe — из-за жуткой панели управления (покупал как виртуальный хостинг, так и vps), честно пытался создать через конструктор или хотя бы найти рабочие доступы ftp более 20 минут, пожалел нервы, забил.

  • InfoBox — из-за скорости ответа основного сайта.

  • Hostland — из-за скорости ответа основного сайта.


Шаг 3: Тестирование чистого Wordpress


Все Wordpress, для чистоты эксперимента, устанавливал руками из архива с официального сайта. Никаких плагинов (кроме базовых, вроде Hello Dolly), дефолтная тема.

Вначале, после съема показателей пустых сайтов, я пробовал туда установить кастомные темы и кеширование, вроде W3 Total Cache или WP Rocket, но на всех хостингах это работало из коробки (на некоторых W3TC не заработал даже на третий день общения с поддержкой), потому этот этап я исключил.



 

Шаг 4: Итоги


В теории, все должно было закончиться выбором самого быстрого хостера, эдаким хэппиэндом, ибо цены на услуги у всех представленных хостеров были примерно одинаковы. Однако, иронии добавляло то, что перейти я хотел с Timeweb, который вошел в ТОП3 по обоим спискам. Более того, поддержка E-planet за 3 дня не смогла как-то помочь мне заставить W3TC работать (предлагали использовать другой плагин) без необходимости обновлять nginx вручную.

В итоге, поддержка Timeweb обновила «ресурсные записи на стороне NS-серверов», я перевел сайт на PHP7 и https (не для скорости, уже из любопытства), скорость ответа сервера упала до адекватных 250-300 мс, я никуда не ушел, а сайт переиндексировался и постепенно возвращается в выдачу )

 

Шаг 5: Мораль




На рынке хостинг-провайдеров РФ есть значимый разброс в скорости ответа сервера по сайтам, что может крайне негативно (или же, позитивно) влиять на поисковую выдачу. Потому, весьма желательно, при выборе хостера, проверять не только панель управления, тарифы и т.п., но и этот параметр. Надеюсь, мои тесты пригодятся вам в этом )

P.S. Первичной причиной медленного ответа сервера, как я позже выяснил, стало нарушение связки домена с CloudFare CDN (домен отключился за неуплату, а после продления начал глючить) и долгой перепривязке домена обратно к регистратору. Потому, если вы решите использовать CloudFare как CDN в связке с W3TC и (не дай бог) не успеете продлить домен — будете знать где копать.
Tags:
Hubs:
Total votes 22: ↑14 and ↓8+6
Comments52

Articles