Сократите время ответа сервера — как решить проблему?

Недавно я описал процесс оптимизации скриптов и стилей на своих сайтах, получилось все хорошо, но вот одна большая проблема осталась — Сократите время ответа сервера, пишет мне добрый Google.


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

Сократите время ответа сервера

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

Оптимизация скорости сайта на #WordPress. Сжатие стилей, скриптов, html

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

<!--noindex-->
 <center><?php
 print get_num_queries(). ' - столько SQL запросов к базе.<br />'.
 timer_stop(0, 6). ' - за столько сгенерировалась страница.';
 ?></center>
 <!--/noindex-->

Посмотрим, какое состояние сайта на данный момент:

26 — столько SQL запросов к базе.
1,205022 — за столько сгенерировалась страница.

Это главная страница сайта про линукс. Теперь проверю таким же образом главную страницу этого сайта:

34 — столько SQL запросов к базе.
0,351147 — за столько сгенерировалась страница.

Как видите, запросов к базе данных больше, а скорость генерации страницы в ЧЕТЫРЕ раза меньше. При этом оба сайта на одном сервере, стоят практически одни и те же плагины, правда база данных на этом сайте поменьше, но все базы оптимизированы и весь хлам удален.

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

1. Есть какой то кривой плагин, который тормозит генерацию страницы.

2. Кривой шаблон и какие то ошибки в верстке мешают нормальной работе.

3. На сайте есть вирус, который тормозит его работу. Как проверить на вирусы сайт читайте по ссылке…

4. Ошибки в базе данных и данные долго считываются.

Даже не знаю, что еще можно предположить, начнем с этого, буду шаг за шагом проверить теории и смотреть на результат.

1. Как вычислить кривой плагин?

Тут все просто: сначала вырубаем СРАЗУ ВСЕ плагины и смотрим на результат:
15 — столько SQL запросов к базе.
0,937074 — за столько сгенерировалась страница.
Как видите, мало что изменилось, а это значит, что плагины не причем. Эта теория проверена, идем дальше…

2. Как проверить шаблон WordPress?

Тут действуем сначала по той же схеме, закачиваем какой-нибудь бесплатный шаблон, вставляем в него наш код и смотрим на результат.
27 — столько SQL запросов к базе.
1,170909 — за столько сгенерировалась страница.
Мда, результат тот же, значит тема не при чем, нужно рыть дальше.

3. Как проверить сайт на вирусы?

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

4. Как проверить базу данных?

У меня ушли сутки, прежде чем я решил проблему. Сразу хочу показать результат:

29 — столько SQL запросов к базе.
0,168516 — за столько сгенерировалась страница.

Видите разницу? 1,2 секунды или 0,16 секунд? Это разница в ДЕСЯТЬ РАЗ! Как мне этого удалось достичь?

Как я и предполагал, дело было в базе данных. Никакие чистильщики не помогали, и тогда я стал делать все вручную. Очень помогла ВОТ ЭТА СТАТЬЯ, не знал о таких приемах при работе с базой данных.

Первое, что я сделал, это отсортировал таблицы базы данных, чтобы увидеть, что занимает больше всего места. Получилось вот что:

Сократите время ответа сервера wordpress

Самыми большими и поэтому вызывающими подозрение были 4 таблицы, в порядке убывания:

post — в этой таблице хранятся все статьи, к ней вопросов быть не может.
options — тут хранятся все настройки и к этой таблице вопросы есть.
postmeta — тут хранятся мета описания к статьям — к ней вопросы есть.
comments — в этом разделе хранятся комментарии, к нему вопросов нет.

Сначала я взялся за таблицу POSTMETA и вычистил из нее немного мусора, в основном кэш, который оставил один плагин. Но все это не помогло. Тогда я взялся за таблицу OPTIONS.

Я установил плагин Clean Options (плагин создан ИСКЛЮЧИТЕЛЬНО для чистки ЭТОЙ таблицы), который нашел у меня более ТЫСЯЧИ осиротевших опций! Я удалил примерно 700 ненужных строк из таблицы, осталось 300, которые кажется нужны.

Сократите время ответа сервера вордпресс

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

Далее я сделал так: скачал эту таблицу на компьютер и открыл в обычном текстовом редакторе (лучше для разработчиков, у меня в линукс это Geany), сделал перенос строк и сразу увидел, что занимает ОГРОМНОЕ количество места!

Как сократить время ответа от сервера?

Виновником всему был cron! Если не знаете что это, то вот для справки:

cron — демон-планировщик задач в UNIX-подобных операционных системах, использующийся для периодического выполнения заданий в определённое время.

Я ничего не планировал, и я даже не знаю, какой плагин создал столько заданий! Я зашел в PHPMYADMIN и нашел в этой таблице этот раздел, затея я его безжалостно удалил! Таблица сократилась с 3,5 мегабайт до 168 килобайт! После этого сайт стал летать как ошпаренный!

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

Если вы знаете, почему у меня все так вышло и как этого избежать в будущем, то охотно послушаю экспертный совет. А в целом я ОЧЕНЬ рад, так как сутки у меня были мысли только об этом. Осталось только все это сделать на других сайтах, вдруг и там есть эта проблема, пусть и не в таком масштабе? И напоследок похвастаюсь, плагин кэширования отключен:

скорость загрузки сайта

1,7 секунды — это кажется круто?

Как найти мусор от плагинов?

Нашел еще такой интересный плагин — Plugins Garbage Collector. Он сканирует базу данных и ищет таблицы, которые не принадлежат самому wordpress:

Plugins Garbage Collector

У меня нашлись таблицы, которые уже не используются плагинами, так как я их удалил — в топку! Так тоже можно немного очистить базу данных от мусора.

Как уменьшить время отклика от сервера?

Все это мне очень помогло ускорить сайт, но все же Google Speed сигнализировал мне, что время отклика от сервера очень большое. И виноват в этом не сам сам сервер, так как простые html документы загружаются без всяких задержек, а движок сайта WordPress, который как не ускоряй ракетой не станет. Что же делать?

Проблема решилась легко — установкой на сайт плагином для кэширования и установка плагина, который сжимает стили и скрипты. Но не все было так просто на самом деле, так как далеко не все плагины для кэширования страниц работали так как нужно.

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

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

Из всех плагинов, которые имели разделения между мобильным и обычным кэшем, я нашел лишь один — HYPER CACHE.

hyper-cache

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

pagespeed-insights-vremya-otklika-ot-servera

До 100/100 в Google Speed мне осталось совсем немного и уверен я достигну этого результата, так как почти все уже сделано, осталось совсем немного…


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


Не нашли ответ? Воспользуйтесь поиском по сайту

28 комментариев
  1. Я ничего не планировал, и я даже не знаю, какой плагин создал столько заданий! Я зашел в PHPMYADMIN и нашел в этой таблице этот раздел, затея я его безжалостно удалил! Таблица сократилась с 3,5 мегабайт до 168 килобайт! После этого сайт стал летать как ошпаренный!

    Подскажите пожалуйста, каким образом найти «этот» раздел?=)

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

  3. Привет, друг!
    Это снова я. Давно не был у тебя в гостях.
    Значит работал сайтик мой, все было ок и тут 3 дня назад вдруг в Яше добавилась 1 критическая ошибка. Посмотрел я туда, а там: «Большое время ответа сервера». Начал тестировать ботом самого же Яши, результат:
    400-1200 мс (в среднем 600-700 мс). Что капец как плохо.
    А ведь все было окей до 15-го января. Значит какая-то обнова с плагином пришла кривая.
    Отключаю все плагины — ответ становится 250-300 мс.
    Начинаю по одному подключать. Опять ситуация возвращается.
    Причем непонятно, какой именно плагин.
    Их скорее всего несколько, а точнее дело не совсем в них.
    Потому что отрубал снова и начинал включать по одному, но другие, проблема возвращается.
    Поставил по твоему совету Hyper Cache, но вот незадача.
    После того, как я прописал в wp-config эту строчку «define(«WP_CACHE», true);»
    Сервер стал возвращать ответ 304. И Яша раценивает это именно так.
    Внимание вопрос: 304 для Яши это плохо или где?
    Как унать, изменился ли отклик сервера в лучшую сторону, если он отправляет меня к закэшированной копии?
    Надеюсь я понятно объяснил проблему. 🙂

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

      Плагины всегда будут тормозить, поэтому нужно минимизировать всегда.

      Проверить можно через Google Speed или http://www.webpagetest.org/?url=zmoe.ru более детальный анализ, что тормозит.

      • Мой вопрос решился просто.
        Перепробовал разные плагины.
        То там ошибка, то там иконки пропадают.
        В итоге меня спас вот этот плагин:
        Cache Enabler
        Сайт полетел! Отклик по Яше 30-40 мс.
        Что в 10-15 раз ниже, чем было.
        Ура!

        • Рад за вас, в этом деле все порой индивидуально и без эксперимента не обойтись.

  4. Приветствую автора.
    Мне понравилась статья, точнее ход мысли и действий. Поэтому хотел бы к вам обратиться за платной экспертизой того же самого, что описано в статье на моем сайте http://www.lyubi.ru/ . Мне уже несколько месяцев выдают и Яндекс и Гугол: Критичные долгий ответа сервера, Скорость загрузки – красная, — 5,1s FCP5,5s DCL. Обратился к программисту, сделавшему сайт, он ответил, что с программой все в порядке причина в хостинге. Обратился на хостинг, они ответили, что у них все в порядке, причина в скриптах. Сам разобраться не могу, далек от этого. Подобные платные услуги оказываете? Или какой другой совет лайте.

    • А что у вас за CMS сайта? На каком движке работает? Это вы на конструкторе каком то делали?

  5. Не смог найти ваш E-mail, с вами можно как-то связаться. Есть вопрос, точнее даже заказ по ускорению работы сайта?

  6. вот вы сказали после плагина проверки Plugins Garbage Collector показало мусор ну и как это удаляется. тут все такие простые как 5 копеек. а вот как именно удалить этот мусор подсказать новичкам не судьба?

    • Что там объяснять? Установите плагин, зайдите в него, просканируйте и поставьте галочку напротив того, что нужно удалить и нажмите кнопку УДАЛИТЬ ТАБЛИЦЕ. В статье есть фото, там все показано, будьте внимательнее.

  7. Как сказал недавно дядя из Google: скорость сайта — это ОЧЕНЬ слабенький фактор ранжирования, так что не парьтесь слишком сильно, лишь бы не было ОЧЕНЬ все тормознуто, а за секундами гнаться не стоит. Лучше создавать полезный контент.

Написать комментарий