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

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

Лучшие SEO программы для вебмастера

---

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

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

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

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

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

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

---

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

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

Исправляем долгий ответ сервера на Prestashop 1.6 — блог Окатьев.Ру

Или ускоряем скорость загрузки сайта в 10 раз с помощью модуля Prestashop Cleaner

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

Для тех, кто пользуется недорогими shared-хостингами, данная статья также окажет положительное влияние.

Сайт продолжает долго отвечать даже после «тюнинга» сервера БД и web-серверов nginx и apache, которые работают в связке. Парадоксально, но при включении кэширования посредством Memcache/Memcached, которое должно значительно сократить время ответа от сервера посредством кэширования запросов к БД в оперативной памяти сервера, Prestashop 1.6 начинает работать ещё медленнее, а в админ-панели вообще невозможно работать, какое-либо движение в ней попросту останавливается.

Так в чём же дело?

А дело-то вот в чём…

Со временем Prestashop 1.6 накапливает у себя в БД космическую кучу информационного мусора, особенно если ты любишь устанавливать/удалять различные модули, которые расширяют функционал твоего сайта, удалять товары и/или категории, заказы и прочее, что хранится в базе и имеет индексную связь с кучей других таблиц в ней.

При правильном удалении товаров и категорий, например может возникнуть ситуация, когда товар или категория удалены, а ты всё ещё можешь обратиться к нему по известному ранее URL-адресу, но только ты не получаешь «Ошибку 404: Страница не найдена», а получаешь ответ сервера «200, ОК» и белую страничку с надписью «js_def».

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

Что будем делать?

Пилить, Шура, пилить!

Первым делом заходим в админ-панель и идём в раздел «Модули» > «Модули и Сервисы», далее находим через поиск модуль «Prestashop Cleaner» и устанавливаем его.

Затем переходим к настройке, нажав на кнопку «Настроить».

В открывшемся окне нас будут интересовать только два нижних блока: «Functional integrity constraints» и «Database cleaning».

Перед следующими манипуляциями обязательно сделай резервную копию базы данных сайта!

После того, как ты сделаешь резервную копию своего сайта, тебе нужно нажать на кнопку «Check & Fix»

И дождаться ответа сервера.

Если ты не дождался ответа сервера, а получил «Ошибку 502: Bad Gateway», то ничего страшного, модуль в любом случае пофиксит всё в фоне. Подожди ещё 3-5 минут, а затем обнови страницу с модулем и попробуй снова нажать на кнопку «Check & Fix».

При повторном обращении к скрипту, он должен отработать сразу, так как он уже всё вычистил при первом обращении и вверху, над блоками модуля появится отчёт на зелёном фоне с SQL-синтаксисом:

Теперь можно нажать на кнопку «Clean & Optimize»

И также дождаться ответа сервера с отчётом вверху страницы.

Такое сообщение может появиться, если БД твоего сайта не нуждается в очистке и оптимизации.

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

В моём случае на VPS с процессором Intel Xeon E5-2630 v2 @ 2.60 GHz и 8Gb DDR3-1866Mhz, с тюнингованными Web-серверами и СУБД, сервер отвечал в среднем за 2,6 секунды, что при норме в 0,2-0,3 секунды является очень высоким значением. После очистки базы данных с помощью Prestashop Cleaner, скорость ответа сервера снизилась до 1,5 секунд. Как выяснилось далее, то причиной лишних 1,1 секунды во времени отклика являются дублирующие запросы к базе данных от различных установленных модулей.

Отключаем и деинсталируем ненужные модули

Теперь тебе необходимо перейти в раздел админки «Модули» > «Модули и Сервисы» и выставить фильтр в «Установленные» и «Отключенные», то есть те модули, которые не используются вовсе, но так или иначе нагружают сайт своим присутствием в хуках.

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

Устанавливаем Prestashop Cache Manager

Следом тебе нужно установить кэширующий модуль, который ты можешь купить по этой ссылке за 99.99€, либо скачать модуль Prestashop Cleaner.

Логин и пароль на загрузку: okatiev.ru

Затем перейди в раздел админки «Модули» > «Модули и Сервисы», нажми «Добавить модуль», выбери купленный/скачанный файл модуля Prestashop Cache Manager и нажми кнопку «Загрузить».

После этого переходи к настройке модуля Cache Manager.

Модуль может попросить тебя включить Smarty-кэш и отключить использование библиотеки HTML-Minify. Всё это ты можешь сделать в админке в меню «Конфигурация» > «Результат» как показано на скриншотах ниже:

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

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

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

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

Для этого используй панель управления хостингом или правку файла /crontab напрямую через SSH-терминал (Putty — для Windows, Терминал — для Linux и OS X).

После подключения к серверу через SSH или sFTP, тебе необходимо добавить строку вида:

59 *    * * *   root    /usr/bin/wget -O - -q -t 1 'https://site.ru/modules/pm_cachemanager/cron.php?secure_key=hHKy3f6wN0zcUMUB' > /dev/null 2>&1

в конец файла «/etc/crontab». Чтобы отредактировать его используй команды

nano /etc/crontab

или

vi /etc/crontab

Сохраняем изменения и закрываем SSH-клиент

Где https://site.ru/modules/pm_cachemanager/cron.php?secure_key=hHKy3f6wN0zcUMUB строка, взятая тобой из вкладки модуля «Crontab» в админке сайта.

После проведения всех манипуляций, которые приведены выше, я рекомендую очистить Smarty-кэш в админке в меню «Конфигурация» > «Результат» > «Очистить кэш»

Затем очистить кэш модуля Cache Manager с помощью кнопки в боковом меню админки или во вкладке «Maintenance» на странице модуля Cache Manager.

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

Как видно, скорость ответа сервера сократилось у меня практически в 10 раз.

Выводы

Исправляем долгий ответ сервера на Prestashop 1.6

Какие выводы можно сделать? О, их можно сделать целую кучу, но мы сделаем лишь пару основных.

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

В сумме мы имеем снижение скорости ответа сервера примерно в 10 раз: с 2,6 секунды до 0,28 секунд, что положительно влияет на отношение поисковых систем к нашему интернет-магазину, а также на отношение наших клиентов, которые получают теперь информацию с сайта в 10 раз быстрее чем раньше.

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

Как устранить проблему долгого ответа сервера при использовании Nginx и PHP7.0-FPM?

Доброго времени суток!

Несколько лет без проблем работал сервер на Nginx (4 CPU 1GB RAM). Но неожиданно возникла проблема с php-fpm из-за чего сайты на сервере перестали работать. После переустановки системы удалось поднять работоспособность сайта. Но возникла проблема с долгим ответом сервера, и я никак не могу понять, откуда ноги растут.
Конфиги nginx.conf:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
worker_connections 1024;
multi_accept on;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 30;
keepalive_requests 100;
client_body_timeout 10;
reset_timedout_connection on;
send_timeout 2;

types_hash_max_size 2048;
# server_tokens off;

server_names_hash_bucket_size 64;
# server_name_in_redirect off;

include /etc/nginx/mime.types;
default_type application/octet-stream;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;

#access_log /var/log/nginx/access.log;
access_log off;
error_log /var/log/nginx/error.log crit;

gzip on;
gzip_disable «msie6»;

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

конфиг сайта:

server {
listen 443 default_server;
server_name mysite.com;

# Путь к папке с кодом
root /var/www/mysite.com/public_html;

index index.php index.html;
ssl on;
ssl_certificate /path/to/pem.pem;
ssl_certificate_key /path/to/key.pem;

location / {
autoindex off;
try_files $uri @opencart;
}

location @opencart {
if (!-f $request_filename){
set $rule_0 1$rule_0;
}
if (!-d $request_filename){
set $rule_0 2$rule_0;
}
if ($rule_0 = «21»){
rewrite ^/([^?]*) /index.php?route=$1 last;
}

}
location ~ \.tpl {
deny all;
}
location ~* ^.+\.(js|css|png|jpg|jpeg|gif|ico)$ {
access_log off;
expires max;
log_not_found off;
}

location ~ \.php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;

}
}

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

Страницы сайта в среднем слишком долго отвечают роботу

По некоторым сайтам в Яндекс Вебмастере выдаются такие предупреждения:

Страницы сайта speed24.ru в среднем слишком долго отвечают роботу

01.04.2019, 12:27 При обращении к серверу среднее время ответа превышает 3 секунды. Долгая загрузка страниц затрудняет работу с сайтом speed24.ru.

Проверьте ответ сервера и при необходимости обратитесь к хостинг-провайдеру.

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

Рассмотрим популярные причины появления такого уведомления в панели Вебмастера на примере этого сайта speed24.ru.

Высокая нагрузка на сайт

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

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

Плотный трафик

Возьмем для примера самый дешевый шаред-хостинг. Он может выдержать 200 посетителей в день, и даже больше, если нагрузка распределена более-менее равномерно. Трафик в 10 тыс посетителей в сутки для шаред-хостинга скорее всего станет неподъемным. Поэтому нужно сравнить даты предупреждений с пиками посещаемости. Это даст ответ на вопрос, «а не пора ли переезжать»? Большие объемы по обновлению каталога также могут быть причиной непомерной нагрузки.

База данных

Однако сайт speed24.ru не имеет такой нагруженный трафик, чтобы он был причиной конкуренции за ресурсы сервера. Может быть виновата медленная база данных? Действительно, сложные SQL-запросы, которые выбирают нужные данные, могут быть причиной медленной генерации страницы. Некоторые CMS даже выводят сообщения, похожие на это:

Время генерации страницы: 2.6737 секунд
Запросы к базе: 185

InstantCMS

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

Запросы других сетевых ресурсов

Вот с какими проблемами медленной генерации страницы мы сталкивались:

• цены на товары хранились в долларах, и пересчитывались по курсу, который интернет-магазин получал с другого ресурса в режиме он-лайн, с каждым открытием страницы сайт лазил в интернет
• часть содержимого страницы бралась с другой площадки, и также в режиме он-лайн, без какого-либо кеширования
• каждый показ контента запускал задачу проверки очереди email-сообщений и их отправку

Во всех перечисленных случаях задействованы внешние сетевые ресурсы, которые сами могут быть перегружены. И даже работая в штатном режиме, такое сетевое взаимодействие обходится в 0,1-3 секунды на каждый вызов. Решение таких проблем:

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

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

Медленный хостинг

Допустим, что сайт хорошо оптимизирован для нагрузки. Что еще может привести к возникновению предупреждения «3 секунды»?

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

Вот как выглядит смена хостера и технологии виртуализации с OpenVZ на KVM:

Вообще, сообщения «страницы слишком долго отвечают роботу» мы видели на сайтах, которые оптимизированы по скорости, а также на одностраничнике, который полностью сделан на HTML. Почему же такое случилось? Мы подумали и решили, что если такие случаи единичны, то причина кроется в плохом канале связи (возможных сетевых проблемах у хостера), что исправить нельзя, да и нет особого смысла. А если предупреждения сыпятся часто, а видимой причины нет, нужно мониторить нагрузку.

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

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

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

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

Общие причины большого времени ответа сервера

• Плохой хостинг, долгий пинг
  Хостинг должен быть обязательно на SSD дисках и располагаться в той же географической зоне, что и ваш сайт. Если ваш сайт стоит на SSD дисках, но сервера расположены в Америке — то будет идти долгий пинг для связи с сервером и толку тут будет мало.
• Устаревший сервер Apache
  Выбирайте хостинг, использующий nginx вместо устаревшего Apache
• Снижение нагрузки на сервер
  Грабберы и парсеры не только воруют ваш контент, но и создают ненужную нагрузку на сервер. Кроме того  сторонние сайты воруют информация о сайте вместе с картинками, не меняя URL картинок. В итоге при открытии таких страниц будут открываться ваши картинки. Опять нагрузка на сервер

Причины долгого отклика сервера, характерные для сайтов  на WordPress

• Кривой плагин может тормозить генерацию страницы
• Кривой шаблон и какие то ошибки в верстке может мешать нормальной работе
• Вирус на сайте может сильно тормозить сайт
• Ошибки в БД, вследствие чего данные плохо считываются
• большое число запросов к БД

Итак, приступим к работе по уменьшению времени ответа сервера.

Уже не первый год пользуюсь хостингом Erahost. Этот хостинг отвечает все вышеперечисленным требованиям: SSD диски, хостинг в Словении, что не очень далеко, используется сервер nginx. По всем показателям он меня устраивает, ни разу не подвел меня. Так что рекомендую, если что.

Переходим причинам, свойственным сайтам на WP.

Для оценки времени загрузки страницы и числа обращений к БД в шаблоне в файле futer.php пропишем небольшой код

 

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

Ищем кривые плагины