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

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

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

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

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

Где проверить скорость сайта?

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

Google Speed Page — текст скорости сайта от самого Гугла, показываем проблемные моменты как для десктопной версии, так и для мобильной. В времени загрузки не указывает.

Как проверить скорость загрузки сайта?

PR-CY - русский аналог предыдущего теста, скорее всего данные берет именно там, в пользовании удобнее первого.

SiteSpeed — проверка скорости сайта. Мне очень нравится этот тест, не раз его использовал, выдает полную информацию о загрузке всех объектов.

Pingdom Website Speed Test — зарубежный аналог предыдущего сервиса, выдает очень подробную информацию.

Web Page Test — еще один очень подробный тест, которым я не раз пользовался.

MainSpy — показывает время загрузки сайта. Больше никакой информации нет, показывает заниженное время.

Raskruty — очень простенький тест скорости загрузки сайта.

Web Site Optimisation — еще один зарубежный тест скорости ресурса. Выдает подробную таблицу, но вот с кириллице слабовато…

Show Slow — тоже неплохой анализатор скорости сайта. Для работы требует авторизации, но можно войти и через социальные сети.

Red Boot — проверяет доступность и степень сжатия тех или иных компонентов страницы.

Site Speed — показывает время отклика сайта в разных странах. Удобная и важная вещь, особенно, если ваш хостинг находится далеко от ваших целевых посетителей.

Loadimpact — этот сервис не проверяет скорость сайта, а проверяет, какую нагрузку может выдержать ваш сайт. Хотя цель теста в первую очередь другая, но и тут показывается скорость сайта.

Prolog — очень простой и удобный сервис проверки скорости сайта, показывает, что больше всего тормозит сайт.

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

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

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

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

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 мне осталось совсем немного и уверен я достигну этого результата, так как почти все уже сделано, осталось совсем немного…


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

Оцените статью
Просто Линукс
Добавить комментарий

  1. Александр

    Спасибо Вам за подробную инструкцию!

  2. Виталий

    держи ссылку в помощь

  3. prostolinux автор

    Вот засада! Опять эта таблица выросла до 59 мегабайт, и откуда оно взялось? Сейчас буду разбираться….

  4. prostolinux автор

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

  5. campusboy

    Спасибо, классная статья. Давно заметил с помощью плагина query monitor, что крон постоянно что-то делает, что замедляет генерацию страницы на 1 секунду. Просто в config.php прописал define(‘DISABLE_WP_CRON’, true); и нормально стало. Кстати, далеко не все плагины и темы правильно работаю с аргументом autoload в options, и при удалении не подчищают за собой, потому эта таблица постоянно растёт при активном пользовании сайтом и экспериментах. Об этом хорошо рассказано тут https://wpmag.ru/2015/wordpress-options-performance/

  6. prostolinux автор

    Спасибо за полезные советы,обязательно попробую, так как проблему скорости на 100% пока не решил.

    И еще понял одну важную вещь: нельзя тестировать плагины на основном сайте, после их удаления остается всегда много мусора, иногда мегабайты. Ужас!

  7. prostolinux автор

    Как не печально, а google page speed не нравится мое время ответа от сервера. Решил я написать хостеру и получил от него такой ответ:

    Могу сказать, что показатели вашего сайта достаточно высоки. Сам гугл своим сервисом практически равные результаты выдает для своего сайта. Так что это очень и очень хорошо.

    https://developers.google.com/speed/pagespeed/insights/?url=google.com&tab=desktop

    добавлю, что данный сервис параноит немного по отношению к скорости сайтов. Я бы не стал на 100% доверять ему.

    Ну что же. поверим пока на слово, других вариантов пока не знаю, нужно проверить чужие сайты на wordpress, как дела у них?

  8. prostolinux автор

    Вот такая команда еще есть, чтобы почистить базу от мусора:

    DELETE FROM wp_postmeta
    WHERE meta_key IN(‘_edit_lock’, ‘_edit_last’,’_wp_old_slug’)

  9. Максим

    Интересная статья. У меня кстати что-то подобное есть, только касается вообще всего блога — ускорение работы сайта в 17 способов, там и этот пункт есть — связанные с оптимизацией базы данных — http://smarticle.ru/17-sposobov-kak-uskorit-svojj-blog-plaginy-kehshirovaniya-dlya-wordpress/
    Может кого заинтересует

  10. Денис

    Здравствуйте! Очень познавательно, сейчас занимаюсь тем же. Вы особо не расписывали, как почистили таблицу wp_postmeta, можно подробнее? А то именно она у меня весит тонну. Или описанный вами в комментах способ и есть решение?

    Спасибо заранее!

  11. prostolinux автор

    Самое лучшее — это чистить вручную. Я делал так: искомую таблицу импортировал на компьютер и открывал в текстовом html редакторе, и там сразу видно, какой раздел забит мусором. Я запоминал номер строки, шел в базу, искал этот раздел и вычищал полностью.

    После всего этого я создал сайт на поддомене и только там тестирую плагины, и вам так советую ;)

  12. Денис

    Спасибо! Вручную долговато будет) Попробую на Денвере протестировать sql запрос, что вы выше приводили.

  13. Евгений

    Тоже дикая проблема, именно с кроном, решено было сделать следующее В файле wp-cron.php закомментировать строку:
    //ignore_user_abort(true);
    в файл конфигурации WordPress wp-config-php добавляем строку:
    define(‘DISABLE_WP_CRON’, ‘true’);

  14. Генадий

    Респект за статью! Все грамотно и по полочкам.

  15. Владимир

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

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

  16. Владимир

    как найти проблему?
    wp_options 2 мб весит
    найти не могу что вес даёт
    1) в файл конфигурации WordPress wp-config-php добавил строку:
    define(‘DISABLE_WP_CRON’, ‘true’);
    2) В файле wp-cron.php закомментировал строку:
    //ignore_user_abort(true);
    3) как было время отклика 1,2 сек так стоит

  17. prostolinux автор

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

  18. Цифровой

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

  19. Павел

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

  20. prostolinux автор

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

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

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

  21. Павел

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

  22. prostolinux автор

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

  23. Евгений

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

  24. Евгений

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

  25. prostolinux автор

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

  26. Буса

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

  27. prostolinux автор

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

  28. prostolinux автор

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

  29. василий

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

  30. prostolinux автор

    Трудно сказать, это же нужно смотреть, что за таблица и что у вас за плагины стоят. Что это за oembed можете прочитать тут https://wp-kama.ru/handbook/codex/oembed