Шаг 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» на посадочных страницах.
- Rusonyx
- Mne
- Timeweb
- Beget
- E-planet
- iPipe
- Handyhost
- Hostink
- HotHat
- Джино
- SherlockHost
- Fozzy
- Bluehost
- InfoBox
- Hostland
- ЕвроБайт
Шаг 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 и (не дай бог) не успеете продлить домен — будете знать где копать.
