Тарифи хостингів виглядають однаково. Скільки місця на диску, скільки сайтів можна розмістити, безлімітний трафік, підтримка цілодобово. За цими рядками не видно головного: чи витримає хостинг саме ваш сайт.
Матеріал для того випадку, коли власного сервера ще не потрібно, а вибрати хостинг уже треба.
Що насправді входить у тариф
Місце на диску й кількість сайтів це найменш важливі рядки. Сайт компанії рідко займає більше кількох гігабайтів, і навіть інтернет-магазин із великим каталогом рідко доходить до дискового ліміту.
Значно важливіше те, що в описі тарифу згадується дрібним шрифтом або не згадується взагалі.
- Кількість одночасних процесів. Скільки запитів сайт обслуговує паралельно, решта стоїть у черзі.
- Обсяг пам’яті на процес. Важка сторінка може в нього не вкластися і обірватися помилкою.
- Максимальний час виконання. Від нього залежить, чи встигне завершитися імпорт прайсу.
- Кількість запитів до бази. У частини провайдерів обмежена, і на каталозі це відчутно.
- Обмеження на планові завдання. Як часто можна запускати й скільки вони можуть тривати.
Саме ці рядки визначають, чи буде сайт працювати рівно. І саме їх зазвичай немає на сторінці тарифів, тому їх запитують у підтримки до оплати.
Друга група рядків, які варто прочитати уважно, стосується того, що станеться в разі перевищення. Одні провайдери просто ставлять запити в чергу, і сайт починає повільніше відповідати. Інші повертають помилку, і відвідувач бачить сторінку з помилкою замість сайту. Треті надсилають лист із пропозицією перейти на дорожчий тариф і дають кілька днів. Різниця тут суттєва, а дізнатися про неї заздалегідь можна тільки прямим питанням.
Ще один рядок, який варто прочитати двічі, це обіцяний відсоток доступності. Три дев’ятки означають приблизно сорок хвилин простою на місяць, і це прийнятно. Дві дев’ятки це вже близько семи годин на місяць, а для магазину такий місяць поганий. Сама обіцянка важить мало, поки в правилах не написано, що ви отримуєте за її порушення. Зазвичай це зарахування коштів у рахунок майбутніх платежів, а не повернення грошей.
Ліміти, через які сайт починає гальмувати
Процеси, пам’ять і час виконання
Спільний хостинг улаштований так, що на одному сервері живуть від десятків до сотень сайтів. Щоб один із них не з’їв усі ресурси, провайдер ставить обмеження кожному.
Коли сайт досягає межі, це виглядає не як помилка, а як повільність. Сторінка завантажується довше, потім ще довше, потім частина відвідувачів бачить помилку сервера. У журналах провайдера в цей момент видно перевищення ліміту процесів, але власник про це не знає.
Друга типова ситуація стосується фонових завдань. Вивантаження замовлень у поштовий сервіс або обмін залишками з обліковою системою не вкладається в обмеження часу й тихо обривається. Ніякого повідомлення при цьому не приходить, і причину шукають у самому обміні, а не в тарифі.
Скільки відвідувачів витримає тариф
Провайдери часто пишуть «до п’яти тисяч відвідувачів на добу», і ця цифра нічого не означає. Як саме її порахували, з опису тарифу не видно.
Реальна відповідь залежить від сайту. Сайт на десять сторінок і інтернет-магазин із фільтрами по каталогу створюють різне навантаження за однакової кількості людей. Перевірити це можна тільки навантаженням, і найпростіший спосіб це дивитися на поведінку сайту в години пік.
Корисно розділяти рівний і нерівний трафік. Тисяча відвідувачів, рівномірно розподілених по добі, це зовсім не те саме, що тисяча за пів години після розсилки. Другий випадок вимагає запасу, який на звичайному тарифі рідко буває, і саме під час розсилок та рекламних запусків сайти найчастіше перестають відкриватися.
Спільний хостинг, VPS і хмара простими словами
| спільний хостинг | віртуальний сервер | хмара | |
|---|---|---|---|
| Що ви отримуєте | місце в чужій системі | окремий сервер | ресурси на вимогу |
| Хто налаштовує | провайдер | ви або підрядник | ви або підрядник |
| Ресурси | діляться із сусідами | закріплені за вами | масштабуються |
| Коли підходить | більшість сайтів | навантаження і свої служби | нерівне навантаження |
| Хто відповідає за збій | провайдер | ви | ви |
Питання переходу зі спільного хостингу на власний сервер має окрему відповідь у матеріалі про вибір між власним сервером і звичайним хостингом. Тут важливо інше: більшості сайтів спільний хостинг підходить, і переїзд потрібен не так часто, як його пропонують.
Версії PHP і бази даних
Їх варто перевірити до оплати, хоча зазвичай це з’ясовують уже після.
- Які версії доступні. Крім найновішої, має бути й та, на яку розрахований ваш сайт.
- Чи можна перемикати самому. У панелі, а не заявкою в підтримку.
- Які розширення встановлені. Частина модулів без них не працює.
- Версія бази даних. Стара версія обмежує можливості й швидкість.
- Скільки баз можна створити. Одна на сайт це мінімум, для тестового майданчика потрібна друга.
Найнеприємніше, коли сайт переїхав, працює, а через місяць виходить оновлення платформи, яке вимагає новішої версії PHP. На хостингу її немає, і вибір стає між «не оновлюватися» й «переїжджати знову».
Пошта на хостингу й чому листи не доходять
З поштою на дешевому хостингу окрема розмова. Технічно пошта там є, але на практиці працює гірше за окремий поштовий сервіс.
Причина в тому, що на одному сервері живуть сотні сайтів, і, якщо хоча б один із них розсилає небажану пошту, страждає репутація всього сервера. Ваші листи про замовлення починають потрапляти в небажану пошту не з вашої вини.
Надійніше розділити пошту на два потоки. Пошта співробітників в окремому сервісі, листи від сайту через спеціалізований сервіс розсилки. Це додає невеликий рахунок і знімає цілий клас проблем. Таку схему налаштовують один раз. На звичайному хостингу ми робимо це в межах підтримки сайту, а на власному сервері це входить у налаштування та обслуговування серверів.
Перевірити, чи є у вас ця проблема, можна за п’ять хвилин. Оформіть на своєму сайті три тестові замовлення, вказавши електронні адреси в різних поштових сервісах, і подивіться, куди прийшли листи. Якщо хоча б один опинився в небажаній пошті, ситуація гірша, ніж здається: покупці, яких ви не бачите, просто не отримують підтверджень.
Друга перевірка стосується адреси відправника. Листи від сайту мають надсилатися з адреси на вашому домені, а не з довільної службової. Це впливає і на довіру одержувача, і на те, чи дійде лист узагалі.
Розташування серверів і швидкість для ваших відвідувачів
Що далі сервер від відвідувача, то більша затримка. На простій сторінці різниця в кілька десятків мілісекунд непомітна, а на сторінці з десятками звернень до сервера вона накопичується.
- Аудиторія в одному регіоні. Сервер у тому самому регіоні або в сусідньому.
- Аудиторія в кількох країнах. Сервер ближче до найбільшої частини, решту закриває мережа доставки контенту.
- Аудиторія на іншому континенті. Сервер там, де покупці, а не там, де зареєстрована компанія.
Це не головний фактор швидкості, і починати оптимізацію з переїзду не варто. Значно частіше причина в самому сайті, і найпоширеніші з таких причин розібрані в матеріалі про те, чому сайт повільно завантажується.
Що хостер робить за вас, а що доведеться робити самому
Межа відповідальності проходить не там, де здається.
- Провайдер відповідає за залізо й мережу. Якщо сервер недоступний, це його зона.
- Провайдер оновлює системне програмне забезпечення. Але не вашу CMS і не модулі.
- Провайдер робить копії сайту. Часто з обмеженою глибиною і без гарантій.
- Ви відповідаєте за сам сайт. Оновлення, безпека, вміст, швидкість.
- Ви відповідаєте за свої копії. Незалежно від того, що робить провайдер.
Останній пункт власники сприймають найважче. Копія на боці провайдера це зручність, а не гарантія: у більшості тарифів вона зберігається кілька днів і не покриває ситуацію, коли проблему помітили пізніше. Самостійно відновити в панелі окремий файл чи базу можна не на всіх тарифах, а на деяких підтримка робить це лише за окрему плату.
Регулярну частину цих робіт закриває підтримка та розвиток проєктів, а що саме до неї належить, описано в матеріалі про те, що входить у підтримку сайту.
Як перевірити підтримку хостера до оплати
Підтримка це головне, за що платять різницю між дешевим і нормальним тарифом. Перевірити її можна за п’ятнадцять хвилин, ще до того, як ви станете клієнтом.
- Напишіть технічне питання. Не «Скільки коштує?», а щось конкретне про ліміти або версії.
- Подивіться на строк відповіді. І чи відповіли по суті, чи посиланням на загальну сторінку.
- Спитайте про перенесення. Чи допомагають із переїздом і чи безкоштовно.
- Уточніть про копії. Скільки поколінь зберігають і як швидко відновлюють.
- Спитайте про ліміти прямо. Кількість процесів, пам’ять, час виконання.
Провайдер, який на технічне питання відповідає рекламним текстом, поводитиметься так само й тоді, коли ваш сайт перестане відкриватися.
Ще один спосіб перевірки це подивитися, як провайдер повідомляє про свої аварії. У нормального є сторінка стану з історією інцидентів, і в ній видно чесну картину: скільки разів були перебої, як довго вони тривали й що робили. Відсутність такої сторінки означає не те, що аварій не було, а те, що про них не розповідають.
Тестовий майданчик і чому він потрібен
Окремий рядок, на який дивляться в останню чергу, а він рятує від найдорожчих помилок. Тестовий майданчик це копія сайту, на якій перевіряють оновлення до того, як вони потраплять до відвідувачів.
Без нього оновлення платформи або модуля перетворюється на лотерею. Ставите на робочому сайті, щось ламається, і виправляти доводиться в бойових умовах, просто на очах у відвідувачів.
У частини провайдерів тестовий майданчик створюється однією кнопкою і входить у тариф. У частини його немає взагалі, і доводиться або платити за другий хостинг, або оновлюватися наосліп.
Червоні прапорці під час вибору
- Безліміт у всьому. Безлімітних ресурсів не буває, обмеження просто не названі.
- Ціна помітно нижча за ринкову. Економлять на залізі, і це видно під навантаженням.
- Немає доступу до журналів. Без них розібратися в помилках неможливо.
- Не можна перемикати версії самому. Кожне оновлення через заявку й очікування.
- Немає тестового майданчика. Перевіряти оновлення доведеться на робочому сайті.
- Оплата тільки за рік уперед. Якщо підтримка виявиться слабкою, гроші вже заплачені.
Коли тариф уже не врятує
Є момент, коли перехід на дорожчий тариф перестає допомагати. Так буває, якщо сайту бракує ресурсів навіть на новому тарифі, потрібна служба, якої на хостингу немає, або фонові завдання не встигають за відведений час.
Тут уже йдеться про власний сервер. Його підбір, запуск і супровід ми беремо на себе в межах послуги налаштування та обслуговування серверів, а порядок переїзду описаний у матеріалі про те, як перенести сайт на новий сервер.
Але спершу варто виключити просту причину. Дуже часто сайт повільний не через тариф, а через власну важкість, і після оптимізації спокійно живе на тому самому місці ще кілька років.
Перевірити це можна самостійно й безкоштовно. Подивіться, скільки запитів до бази робить головна сторінка й скільки з них повторюються. Подивіться, чи ввімкнено кешування. Подивіться розмір зображень. Якщо в цих трьох місцях є що виправити, переїзд лише відкладе проблему на кілька місяців.
Висновки
Під час вибору хостингу обсяг диска другорядний. Значення мають ліміти процесів, пам’яті й часу виконання. Ці цифри рідко пишуть на сторінці тарифів, тому їх питають у підтримки, і сама якість відповіді вже багато говорить про провайдера.
Пошту з дешевого хостингу краще винести окремо, копії робити свої незалежно від того, що обіцяє провайдер, а версії PHP та бази перевірити до переїзду, а не після.
Якщо ви вибираєте хостинг під конкретний сайт, не вирішуйте за таблицею тарифів. Напишіть нам, що у вас за сайт: платформа, приблизна кількість товарів або сторінок, скільки відвідувачів на добу, чи є фонові завдання на кшталт імпорту прайсів. Ми скажемо, які саме ліміти вам потрібні й на що дивитися в конкретному тарифі. Якщо виявиться, що ваш нинішній хостинг нормальний і справа в самому сайті, ми так і напишемо, а замість переїзду покажемо, що варто виправити на місці.