Wordpress

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

22.06.1991

Содержание

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

Недавно я описал процесс оптимизации скриптов и стилей на своих сайтах, получилось все хорошо, но вот одна большая проблема осталась — Сократите время ответа сервера, пишет мне добрый 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

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

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

1

2

3

4

5

6

<!—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 секунд? Это разница в ДЕСЯТЬ РАЗ! Как мне этого удалось достичь?

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

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

Самыми большими и поэтому вызывающими подозрение были 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:

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

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

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

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

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

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

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

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

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

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

Как я пытался сократить время открытия сайта отключая плагины

Вступление

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

Начало эксперимента сократить время открытия сайта

Для начала, делаю полную резервную копию сайта. Она всегда к месту. Для анализа нагрузок на сервер со стороны установленных плагинов ставлю и активирую плагин P3 (Plugin Performance Profiler). Все ссылки внизу статьи. На 27-01-2020 этот плагин не поддерживается более 3-х лет, используйте другие инструменты проверок.

  • Если плагин P3 использовался на сайте ранее, удалите все истории сканирования, на вкладке History, в настройках плагина;
  • На вкладке P3, включаю сканирование сайта плагином P3, кнопкой «Scan Now». Использую режим автоматического сканирования «Auto Scan»;
  • Жду результатов, долго жду, сканирование затянулось;
  • По диаграмме результатов вижу, что плагин Jetpack самый тяжелый из всех установленных плагинов. Именно тут меня посещает мысль, что Jetpack основная причина «тормозов» сайта.

Иду дальше. Раздражение большим временем загрузки сайта зашкаливает и чтобы добить себя, ставлю скрипт в Footer чтобы посмотреть время ответа сервера (о нём я писал тут). Вижу неутешительную картинку: время ответа сервера 1,7-2,3 сек, а должно быть менее 200мс по рекомендации Google.

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

Анализирую сайт на Webpagetest по точке проверки: Европа. Это значит, что контрольная точка проверки будет в Европе и запрос будут посылать и получать из Дата-центра в Амстердаме. То есть будет моделироваться ситуация, что пользователь сидит в Амстердаме. Амстердам не Москва, но ближе ничего нет.

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

Вижу такую картинку.

  • Общее время загрузки: 12,823 сек;
  • Ответ сервера: 0,870 сек;
  • Время до начала прорисовки: 3,414 сек;
  • Загрузка до DOM: 12,177.

По таблице Request Details, вижу детали анализа. Тормозят сайт или дольше всего загружаются:

  • Файлы (скрипты) Яндекс метрика,
  • Скрипты Google Analytics,
  • Статистика JetPack (WordPress),
  • Форма подписки mailMunch.

Также вижу, что основные файлы JetPack, загружаются быстро, в рамках 45-50 мс, каждый, правда, их много.

Также вижу, что дольше всего грузятся: картинки превью и фотогалереи расположенные на странице. Обще время: около 5 секунд. Это очень много. При этом я все картинки оптимизирую до загрузки на сайт программой Caesium и на сайте сжимаю фото плагином WP Smush.

Что делаю для исправления

  • Убираю с сайта плагин статистики Google;
  • Отключаю в настройках плагина статистику JetPack;
  • Убираю из виджетов сайта картинки, которые были в отчете Request Details, были выделены, как тяжелые.
  • Отключаю все плагины кеширования. У меня стояла двойка Autoptimizer и WP Fastest Cache. Почему? Есть подозрение, что они у меня работают наоборот.
  • Очищаю папку cache вручную по FTP.

Следующий шаг: Отключаю плагин JetPack, с чего собственно началось. Опять делаю замер скорости, после очистки кэш браузера. Вижу, полное время загрузки сайта 9,161 сек. Сократить время открытия сайта удалось, но не принципиально.

Google (PageSpeed Insights)

Меняю сервис проверки скорости сайта и иду в проверку скорости на Google (PageSpeed Insights). Замер дает такой результат: 64/100, мобильный сайт и  74/100 обычный. Опять плохо. Продолжаю чистку сайта, делая контрольные замеры скорости.

  • Отключаю всю рекламу на сайте;
  • Нашел коды статистики вставленные плагином «Tracking Code Manager». Убираю коды статистики и отключаю этот плагин;
  • Отключаю плагины, которые использую лишь для анализа и проверок сайта. В частности отключаю плагины «WP Smush», сжатие картинок и «Broken Links» для поиска битых ссылок.
  • Очищаю базу данных сайта плагином «Optimize Database after Deleting Revisions», после очистки плагин отключаю.

Опять делаю замеры на PageSpeed Insights. Сервис «ругается», но меньше: 67/100 и 78/100.

В завершении, хочу сжать картинки вручную

  • По FTP иду в картинки сайта (каталог wp-uploads).
  • Копирую картинки последнего месяца на комп.
  • Использую программу «Caesium», сжимаю все картинки и возвращаю на сайт.

Опять замер скорости на Webpagetest:

  • Время до прорисовки: 10,438, полная загрузка 11,918.
Контроль, как удалось сократить время открытия сайта

Другие проверки:

  • Смотрю результаты скрипта в футере: 26.26MB | MySQL:102 | 0,282sec.
  • PageSpeed Insights: 80/100 и 86/100.

сократить время открытия сайта удалось, но не идеально

Лучше чем было, но не идеально. На сегодня всё, пора делать выводы. Замечаю, в PageSpeed Insights внизу анализа строка: «скачать оптимизированные изображения, файлы JS, CSS этой страницы». Что-то новенькое. Скачиваю архив и заменяю файлы, которые сервис оптимизировал для меня. Результат улучшается.

Выводы

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

  • Минимально использовать фото на сайте;
  • Сжимать фото перед загрузкой на сайт, например, программой Caesium.
  • Плагины сжатия фото показывают не идеальный вариант;
  • Не использовать рекламу;
  • Сократить количество плагинов до минимума, а лучше не использовать вовсе.

Итог

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

Отсюда вывод: Тяжелые плагины WordPress принципиально не влияют на скорость загрузки сайта.

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

Кстати, на JetPack есть модуль Photon, который должен ускорять загрузку картинок. Я этого не заметил.

27-01-2020: За время жизни статьи плагин JetPack сильно изменился. В бесплатной версии добавлены 4-функции ускорения сайта, появилось много интересного функционала. Я JetPack продолжаю использовать, а для ускорения сайта ставлю один из плагинов кеширования: Comet Cache или WP Speed of Light. Для сервера Fozzy  плагин LiteSpeed Cache. Плагины Autoptimize, WP Fastest Cache и WP Super Cache перестал использовать. От плагина  W3 Total Cache из-за сложности настроек, не могу получить хороший результат.

Полезные ссылки статьи

  • JetPack плагин: https://ru.wordpress.org/plugins/jetpack/
  • P3 (Plugin Performance Profiler) плагин: https://ru.wordpress.org/plugins/p3-profiler/
  • PageSpeed Insights: https://developers.google.com/speed/pagespeed/insights/?hl=ru
  • Webpagetest сервис анализа скорости сайта: https://www.Webpagetest.org/
  • Caesium программа сжатия фото: https://saerasoft.com/caesium/
  • WP Smush плагин сжатия фото: https://ru.wordpress.org/plugins/wp-smushit/
  • Broken Links плагин поиска битых ссылок: https://ru.wordpress.org/plugins/broken-link-checker/
  • Autoptimize плагин оптимизации: https://ru.wordpress.org/plugins/autoptimize/
  • Optimize Database after Deleting Revisions плагин оптимизации базы данных: https://ru. wordpress.org/plugins/rvg-optimize-database/
  • WP Fastest Cache плагин кэширования: https://ru.wordpress.org/plugins/wp-fastest-cache/

©www.wordpress-abc.ru

Статьи по теме

Похожие посты:

6 советов по сокращению времени отклика сервера (TTFB) в WordPress

Блог WP Buffs |