Как снизить нагрузку на сервер на дешевом хостинге

Я начала свою борьбу с нагрузкой на сервер с 500 посетителей в сутки в далеком 2015 году и продолжаю её до сих пор. Я сижу на дешевом хостинге за 120-190 руб. в месяц, если вы сидите на аналогичномхостинге всё нижеследующее будет для вас так же актуальным. Большинство дешевых тарифов от самого распространенного хостинга Beget или  Sweb позволяют использовать 60-70 минут процессорного времени в сутки, но есть и не менее бюджетные хостинги которые позволяют использовать 120 минут. Естественно, я читала длинные чек-листы с хабра, пыталась применить на своем сайте, но не все мероприятия оказались одинаково эффективными.

Для начала нужно поставить диагноз сайту. Для этого стоит посмотреть в логи сервера на предмет подозрительных обращений и ошибок. Если нагрузка обрушилась на сайт резко, без всяких видимых причин, т.е. не обновлялись плагины, не менялась тема накануне, посещаемость не выросла, быстрее всего на сайт ведется атака или может быть залили вирус и нужно принимать меры против этих несчастий. Искать и удалять вирус или отбиваться от атаки. Например, подключить Cloudflare и включить режим «Under Attack Mode», как один из эффективных и бесплатных вариантов, но не единственный.

Если в логах видно, что кто-то пытается перебирать пароли, стоит поставить плагин безопасности и забанить всех переборщиков. Плагин безопасности для сайта на вордпресс обязательная вещь, пока я его не поставила, сайт регулярно взламывали.

Логи сервера следует периодически просматривать это одно из самых эффективных мероприятий в борьбе с нагрузкой.

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

Плагин кеширования

Подходящий под хостинг плагин кеширования создаст наибольший выигрыш среди всех предпринятых мероприятий. Не все плагины кеширования одинаково эффективны. Для начала я поставила продвинутый Total Cache и была разочарована. Во-первых, у него очень сложная настройка, во-вторых я не заметила скачка нагрузки вниз. Многие функции не работали на моем хостинге, многие вместо того, чтобы снижать нагрузку наоборот её генерировали. Абсолютно точно это относилось к функции минификации html, css и js, установлено опытным путем.

На дешевом хостинге минификация быстрее вызовет нагрузку, чем снизит её. Некоторые мои статьи были слишком длинными, на моём тарифе не хватало оперативной памяти для минификации страниц. Это было отлично видно в логах сервера. После отмены минификации нагрузка чуть снизилась. И я пользовалась плагином Total Cache год, пока посещаемость сайта опять не выросла.

Следующим шагом я заменила Total Cache на Fastest Cache. И я сразу ощутила эффект, на следующий же день нагрузка отскочила вниз. Fastest Cache сохраняет все страницы в виде html, я поставила срок перегенерации кеша раз в неделю. Настройка плагина очень простая, буквально несколько галочек поставить нужно и всё. Минификацию я не включила даже с установкой Fastest Cache. CSS и JS я сжала вручную онлайн. Я заплатила за платную версию, чтобы перенести загрузку файлов скриптов в footer, хотя на самом деле это типичный развод на деньги, брать 49$ за такую маленькую функцию. Я даже сама знаю в каком месте кода надо прописать несколько букв, чтобы достичь означенного результата.

Сейчас я перешла на использование LiteSpeed Cache. Этот плагин снизил нагрузку на сервер в 2 раза прямо сразу, но для того чтобы его использовать мне пришлось перенести сайт на новый хостинг. Чтобы плагин заработал необходим вебсервер OpenLiteSpeed, он есть не на всех хостингах. Я выбрала хостинг Fozzy, скидка 10% при использовании промокода TRIP-TOGETHER. Даже самый дешевый тариф там позволяет создавать нагрузку в 120 минут, так что рекомендую.

Ниже графики нагрузки. 10 апреля я переключила сайт на новый хостинг. По вертикальной оси отложены минуты на обеих графиках. Посещаемость практически одинаковая. Причем я и по окончании сотрудничества с Sweb много работала с сайтом, т.к. перешла на новую тему и возилась с настройками и по началу я много работала с сайтом на fozzy, полностью сбрасывала кеш по 3-4 раза в день. Моя возня в админской части и по ftp вообще никак не сказывается на Fozzy, а на Sweb это было ощутимо заметно, пики нагрузки были созданы при работе в админке.

График нагрузки на сервер Sweb (было)
График нагрузки на сервер Sweb (было)
График нагрузки на сервер Fozzy (стало)
График нагрузки на сервер Fozzy (стало)

Плагин кеширования нужно подбирать. Total Cache предназначен больше для выделенных серверов, для виртуального хостинга это плохое решение.

Снос лишних плагинов

Когда я первый раз установила вордпресс, я просто наслаждалась использованием многочисленных плагинов. До этого на работе я писала код на php, а потом тестировала его, а потом переписывала. Это было долго и нудно. Вордпресс же радовал, что буквально по нажатию на одну кнопку можно подключить новую функцию и все работало. Я поставила себе плагины аналитики, чтобы смотреть статистику прямо в панели сайта и еще кучу плагинов для создания красивостей.

Когда ситуация с нагрузкой стала угрожающей, пришлось посмотреть, а что же загружают плагины. Я использовала GTMetrix для этого. И я пришла в ужас от бессмысленности и беспощадности многих моих плагинов. Контактная форма грузила свои стили и скрипты на всех страницах сайта, хотя была установлена всего на одной странице. Usernoise загружал Font Awesome весом 500 Кб, чтобы вывести на лицо сайта одну маленькую звездочку. 500 Кб загружались абсолютно на всех страницах сайта.

Вместо контактной формы на странице контакты я просто указала свой e-mail, с Usernoise просто рассталась, как и с плагинами аналитики. Пусть сервера Яндекса и гугла работают, посмотрю аналитику там.

Посмотреть что загружается на разных страницах сайта никогда не вредно. Расставание с неэффективными плагинами существенно снижает нагрузку на сервер.

Правильная настройка оставшихся плагинов

Неправильная настройка плагинов может приводить к избыточной нагрузке на сервер. Я на своем сайте наблюдала два варианта:

  1. iThemes Security пытался сделать бэкап базы данных. Естественно, ему не хватало для этого оперативной памяти, бекап не получался, но он упорно пытался. Этот  процесс приводил к избыточной нагрузке. В настройках плагина можно отменить эту функцию, на дешевом хостинге автоматический бэкап быстрее всего работать не будет.
  2. NextScripts: Social Networks Auto-Poster пытался выполнять какое-то Cron-событие каждую минуту. Т.е. в сутки плагин создавал 1440 лишних обращений к серверу. Мне было лень разбираться, и я его отключила совсем. В логах сервера не видно что это был за Cron, пришлось поставить плагин WP Crontrol, чтобы выяснить это.

WP Crontrol — покажет все события по расписанию, которые выполняются вашей темой и плагинами. Можно сделать расписание чуть пореже в разумных пределах, что так же приведет к снижению нагрузки. Оба этих случая я обнаружила при анализе логов сервера.

Пересмотр настроек плагинов может существенно снизить нагрузку на сервер.

Мой опыт использования CDN (Content Delivery Network)

Я дождалась очередного злостного письма от своего хостера Sweb. В связи с наступлением активного туристического сезона посещаемость моего сайта скачкообразно возросла и нагрузка на сервер, создаваемая процессами на моем сайте достигла критической величины 120 минут в сутки, напомню что согласно договору моему сайту положено было потреблять всего 60 минут процессорного времени в сутки.

wp7

Sweb предложил мне перейти на другой тариф стоимостью всего 800 руб. в месяц!!! Эта не гуманная сумма меня никак не устраивала, тогда я платила всего 120 руб. в месяц, повысить цену почти в 6 раз, это грабеж. В результате жаба меня задушила и я решила попробовать CDN от CloudFlare, в конце концов другого выхода у меня не было.

У  CloudFlare есть бесплатный тариф, именно на него я и подключилась. Больше всего беспокойства вызывало требование переписать на  CloudFlare мои DNS записи, но я сделала это, и в результате вы видите на графике нагрузка на сервер существенно снизилась до порога который Sweb склонен прощать. Момент подключения CDN  я отметила зеленой меткой на картинке.

Я конечно ожидала большего, мне мечталось увидеть цифру 30 минут в сутки, но этого не произошло. CDN это система серверов по всему миру на которые копируется ваш сайт и при запросе, например идущем из США, отвечает сервер расположенный в США, а не в Санкт-Петербурге, что должно сократить время загрузки сайта и попутно этот метод сокращает нагрузку на мой сервер.

Кроме системы доставки контента CloudFlare предлагает еще защиту от DOS-атак, аналитику и минимизацию html, css, и js.  Вот тут я включила минимизацию, раз CloudFlare берет это все на себя.

Бесплатный аккаунт  CloudFlare имеет ряд ограничений, что вполне естественно. За один запрос посетитель может загрузить с CloudFlare не более 100Мб и сервера обновляются в течении 24 часов. Т.е. если продать ссылку покупатель увидит ее не сразу, а в течении 24 часов.

Из недостатков CloudFlare я заметила следующие:

  1. Функция Always Online совершенно не гарантирует показ вашего сайта, если ваш собственный сервер перестанет работать. Многие русские блогеры обещали такую фишку, но на самом деле это не так. На официальном сайте CloudFlare написано, что он не сохраняет абсолютно все страницы вашего сайта, он сохраняет первые 10 html- страниц сайта и лишь некоторые ссылки с них, сами понимаете, что это ничтожно мало для блога состоящего из 400 страниц. Поэтому, когда мой сервер падает, я вижу вместо своего сайта сообщение об ошибке от CloudFlare.
  2. Мой сайт, подключенный к CloudFlare блокируется для интернет соединений, использующих TOR. Я это заметила сидючи в facebook, там я советовала свой сайт людям и некоторые мне отписывались, что страница не открывается. Что характерно, когда они заходили на мой сайт через мобильный интернет у них все открывалось, у меня тоже все открывалось, сайт в этот момент работал. Дело было именно в интернет-соединении.
  3. Невозможно одновременно использовать SSL сертификат от моего хостера Sweb от CloudFlare, они друг с другом не дружат. А бесплатный сертификат от CloudFlare не поддерживается на устаревших операционных системах и браузерах, типа операционной системы Windows Vista и т.д.
Ошибка от Cloudflare
Сообщение об ошибке, которое я вижу если мой сервер слёг
Аналитика на октябрь 2017

Использование CDN даже на бесплатных тарифах способно существенно снизить нагрузку на сервер. При использовании платных тарифов можно вообще о ней забыть.

HeartBeat API

Нагрузка на сервер существенно возрастает в момент, когда я пишу статью, поскольку в этом случает работает мой сервер. Я отключила создание ревизий совсем и даже отключила возможности HeartBeat API, выполняющее автосохранение записи при написании статьи и прочие функции, необходимые, если редакторов на сайте несколько человек. После того, как мне пришлось переписать статью в 3000 слов по памяти, после отключения электричества я вернула эту опцию обратно. Очень она полезная.

Пыталась писать статьи в гугл-документах, но что-то не зашло.

Полное отключение HeartBeat API снижает нагрузку на сервер, но приводит к потере данных в случае форс мажора.

Переход на PHP 7

В октябре 2017 меня постигло очередное горе. После обновления wordpress и плагинов, нагрузка на сервер опять значительно возросла, это при том, что в сентябре посещаемость по сравнению с июлем меньше. В логах ошибок на сервере чисто. Вообще эта картина довольно типична, когда после обновления плагинов возрастает нагрузка на сервер.

Нагрузка за июль, я превышаю. Моя зона синяя.

Я перевела сайт на php7. Это было не просто. Сначала при переключении вместо своего сайта я видела белую страницу с надписью:«Ошибка соединения с базой данных». Хостер мне не смог помочь советами, пришлось разбираться самостоятельно. Оказалось я использовала устаревшее соединение с базой данных. Для его обновления нужно просто перегенерировать пароль соединения с базой данных и всё, но на поиски этого решения я потратила 2 дня.

После переключения нагрузка на сайт начала зашкаливать за разумные пределы, вопреки многочисленным предсказаниям о том, что она просто обязана упасть. Еще несколько дней раздумий и экспериментов и я решила и эту проблему. Оказалось в function.php моей темы я добавила (по советам от опытных вебмастеров из интернета) функцию, которая содержала в себе лишний цикл, давно уже. При работе на php5.3 перегрузки не возникало,  а после переключения на php7 просто начало зашкаливать. Когда я устранила эту проблему, я увидела свою нагрузку наконец в синей зоне.

Нагрузка за октябрь. Пики были вызваны ошибками в function.php, они проявлялись только в о время работы в админке, поэтому мне было трудно понять в чем дело

Однозначно рекомендую переключить сайт на PHP7  и выше. Эта мера реально приводит к снижению нагрузки на сайт.

Использование турбо-страниц от яндекса и amp от гугла

Я настроила себе обе эти опции еще осенью 2018 года. Но явного снижения нагрузки на сервер не заметила. Многие жалуются напротив на возрастание нагрузки из-за постоянного сканирования страниц amp гуглом и турбо-страниц яндексом. При использовании яндекс-турбо нужно кешировать rss-ленты. Яндекс засасывает эти ленты чуть ли не каждый час. Без кеширования турбо страницы однозначно приведут к перегрузке сервера.

Вообще я уже почти жалею, что я связалась с быстрыми страницами от гугла и яндекса. Реально я потеряла на этом изрядную сумму, потому что настройка размещения рекламы в несколько этапов продолжалась чуть ли не 4 месяца, пришлось купить еще один плагин за 30$ для размещения рекламы на amp, мучать свой мозг настройкой  adfox для показа рекламы на турбо-страницах. Если вы не приобщались к этим технологиям, то и не стоит начинать. Нет от них никаких привилегий. На посещаемость сайта внедрение amp и турбо-страниц не повлияло совсем никак.

Один раз после обновления плагина amp, всё пропало, на страницах amp появилась ошибка и вся посещаемость c amp благополучно перешла на обыкновенные страницы. Ничего не поменялось. Общая посещаемость осталась на том же уровне.

Использование технологий турбо-страниц от яндекса и amp от гугла никак не повлияло на нагрузку на сервер и посещаемость. Поэтому не советую.

Удаление лишнего из файла style.css и удаление лишних js-скриптов

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

Любая бесплатная тема, которая позволяет расположить сайдабар слева или справа или сделать два сайдабара содержит много лишнего кода. Любую тему стараются сделать максимально универсальной, для этого приходится включать много кода, который реально никогда не будет использоваться. Если его удалить, вы ничего не потеряете, а вот скорость загрузки и нагрузка на сервер снизятся.

Обычно из иконочного шрифта используется на сайте 5-10 иконок, а содержится их там около 500. Можно создать свой шрифт выбрав только нужные иконки при помощи сервиса fontello, объем загрузки снижается принципиально.

Использование Lazy Load, оптимизация изображений так же может немного снизить нагрузку на сервер, но не в моем случае. Мои изображения грузятся с Cloudflare.


Стоит признать, что лучше всего справиться с нагрузкой на сервер помог короновирус, обвалив посещаемость сайта. Нет посетителей нет нагрузки.

Мой хостер Sweb за 7 лет ни разу не отключил мой сайт за превышение нагрузки на сервер, хотя я почти всегда превышаю. Раньше Sweb присылал автоматические письма при превышении на 120 минут в сутки, после подарка в честь короновируса стал слать письма при превышении в 100 минут. Получение такого письма это просто повод задуматься и посмотреть в логи.

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

Возможно вам будет интересно почитать о том, как расчистить значительное место на хостинге, удалив неиспользуемые картинки.

А у вас бывали ли когда нибудь проблемы с нагрузкой на сервер? Как справлялись? Какой хостинг используете? Может быть вы знаете еще какие-нибудь действенные способы по снижению нагрузки на сервер?

Понравилась статья? Поделись с друзьями.

Привет!
Меня зовут Елена Шикова.
Рассказываю, как вы можете поехать туда, где была я. От получения визы до где покушать, чем заняться. Путешествую с 2008 года, всегда с семейством. 25 страны, 119 города, многие не по одному разу. Отвечаю на вопросы в комментариях к записям. Все фотографии мои, без фотошопа.

Поговорите со мной о технических вопросах

  1. Татьяна

    Турбостраницы и amp-страницы — это боль. Не связывайтесь с ними.
    Я не знаю, сколько времени убила на это всё. Турбостраницы в целом зло, т.к. теряется контроль над контентом.
    К Cloudflare стоит относится с осторожностью. Например, были случаи, когда Роскомнадзор блокировал ip Cloudflare, на котором был запрещенный сайт. И вместе с запрещенным сайтом не открывались и все случайные соседи.
    Бесплатные плагины на WP — тоже боль. Очень многие авторы не заботятся о том, как подключают свои стили. То, что ненужные скрипты и стили грузятся на всех страницах, уже говорилось. Но они еще зачастую грузятся в шапке сайта, что сильно увеличивается время загрузки сайта. Мне пришлось переписать не один плагин, чтобы исправить это.
    Иногда мне кажется, что каждый блогер должен либо нанимать программиста, либо пройти курсы программирования, чтобы понимать, как это все работает, и что с этим можно сделать.

    Ответить
    1. Елена Шикова автор

      Полностью согласна про турбо и amp, я тоже угробила на их настройку огромное количество времени. А после этого надо следить за тремя версиями сайта, после каждого обновления плагина проверять, ничего ли не отвалилось. Виджеты партнерских программ там не показываются надо постоянно помнить, что наряду с виджетами нужно вставлять ссылки. Больше всего влияют на скорость загрузки счетчики аналитики и яндекс-метрики, как бы цинично это не звучало. Гугл с яндексом заявляют о важности быстрой загрузки, а сами ничуть не собираются оптимизировать свои скрипты. Следующим шагом как раз собираюсь побороться за скорость загрузки.

      Ответить