Сайт о телевидении

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

Как правило, первое, что делает блогер - это устанавливает кэширующие плагины. Нагрузка, если и уменьшается, то незначительно. Далее, начитавшись «якобы гуру», начинают самостоятельно «оптимизировать» шаблон или даже сам WordPress. Тут можно только посочувствовать, особенно умиляют советы о включении например gzip-сжатия в самом шаблоне. Стоит ли говорить, что подобные действия в самом лучшем случае не приводят к результату вовсе, либо, наоборот нагрузка на сервер ещё больше увеличиватся.

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

MaxCache и другие кэши

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

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

«Кэширование» в.htaccess

Некоторые плагины для «ускорения» WordPress меняют файл .htaccess , прописывая в нем инструкции для принудительного кэширования файлов для браузеров на длительное время. Технически браузер не загружает файл с сервера сразу, а вначале проверяет его наличие в своём кэше (на компьютере). Для этого он посылает короткий запрос серверу и сервер может возвратить ответ «Файл не изменился». То есть браузер уже не тянет его с сервера, а берёт из своего кэша. Понятно, что скорость загрузки страницы в этом случае возрастает многократно.

Указание «принудительного кэширования» в .htaccess практически не имеет смысла поскольку не зависимо от этих инструкций, первоначально все файлы должны быть загружены пользователем. Поскольку повторных посетителей (раз-два в неделю) гораздо меньше новых, то эффективность такого кэширования небольшая. Кроме того, следует учитывать тот факт, что браузеры достаточно умны и самостоятельно определят нужно ли загружать старые файлы.

Таким образом «кеширование» в .htaccess можно использовать, но это только лишь может сказаться на трафике для повторных посетителей.

Сжатие с помощью gzip

Другой частой ошибкой является включение gzip-сжатия. Само по себе сжатие позволяет сократить трафик примерно на 30%, но только для текстовых файлов. Как правило файлы изображений плохо сжимаются и выигрыш будет очень маленький.

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

Само сжатие должно быть включено на уровне сервера. Обычно эту инструкци прописывают в .htaccess .

Не путаем трафик и нагрузку на сервер!

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

Нагрузка на сервере характеризуется несколькими основными показателями. В первую очередь - это загрузка процессора (CPU). Обычно измеряется от 0 до 100% (или от 0 до 1). 100% - это значит, что процессор полностью загружен в заданный промежуток времени, например за 1 минуту.

Хостеры как правило учитывают этот показатель и закладывают лимиты в тарифные планы. Например для дешёвых тарифов CPU может ограничиваться 2-3%, а дорогих 10%. При этом предполагается учёт пиков: например в течение 30 секунд сайт может потреблять 70% CPU.

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

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

Нагрузка в виде «процессорного времени»

Когда-то давно хостеры использовали только ограничение на трафик. То есть нужно было платить только за объем скачанной информации. После, сделали трафик безлимитным (точнее очень большим), но ввели ограничение на использование CPU. То есть те же самые сайты, которые раньше спокойно работали на сервере, вдруг стали не укладываться в отведенные лимиты CPU.

Сейчас хостеры придумали очередную «забаву» в виде «процессорного времени». Если раньше был лимит на CPU, который просто не стоит превышать, то процессорные минуты «капают» всегда. Например хостер выделил на аккаунт 100 минут в сутки. Не засисимо от того, превысили ли вы лимиты процессора или нет, берется его загрузка и вся суммируется. То есть даже если за вами очереди в туалет нет, хостер учтёт всё время посещения.

Плохая новость для WordPress-блогеров в том, что, как правило выделенных процессорных минут (обычно 100 минут) хватит примерно для 2 тысяч хостов в сутки. Если посещаемость превышает 2000 посетителей, то для сайта на WordPress превышение процессорного времени будет 10-100% (110-200). То есть хостер вышлет уведомление с просьбой уменьшить нагрузку либо перейти на более высокий тариф.

Потребляемая php-память и MySQL

Давно известно, что WordPress-разработчики давно «забили» на оптимизацию своего «движка». Вместо этого тупо увеличили минимальные требования к серверу. Именно поэтому WordPress требует для работы как минимум 32Мб памяти, а для админки 256МБ.

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

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

Что касается MySQL - запросов к базе данных, то тут более сложная ситуация. Запросы бывают разные. Существую короткие, но затратные по ресурсам sql-запросы, а бывают длинные, но быстрые. То есть в целом, если хостер жалуется на превышение лимитов MySQL, следует провести анализ запросов и выявить медленные. Это задачка для опытного вебмастера, а для рядового блогера решается путем отключения плагинов и/или смены шаблона. Но, в любом случае, использование базы данных достаточно затратно для сервера, поэтому всегда следует стремиться к уменьшению количества запросов MySQL.

Чтобы получить статистику своего сайта добавьте в подвал (как правило файл footer.php ) сайта следующий код:

Этот код выводит потребление памяти, количеств запросов к MySQL и общее время, которое потратил сервер на формирование страницы.

Память должна быть где-то до 15-20МБ (мы говоим о WordPress! Для нормальных сайтов - не более 8-10Мб). Запросов - до 30-40, если их более 100, то не откладывайте вопросы оптимизации. Время будет зависеть от мощности сервера, но обычно приемлемо менее 1 секунды. Причем обязательно нужно снять время несколько раз, просто обновляя страницу (F5): на время может влиять объем трафика страницы и используемого кэша. Я бы рискнул назвать «пограничным» значением - 0,5 секунд. Если время больше, значит нужно подумывать об оптимизации, если более 1 секунды - то тут уже без вариантов.

Трафик

Трафик сейчас особо не влияет на нагрузку сервера, поскольку результирующий php-код по объему занимает небольшую часть трафика. Однако, следует учитывать, что большой трафик напрямую влияет на скорость загрузки страниц посетителями.

Самый простой вариант быстро проверить объем трафика - воспользоваться «Информация о странице» в FireFox.

Думаю, что нормальный размер страницы - менее 50Кб. Если размер больше, то стоит подумать об оптимизации.

Также необходимо заглянуть на вкладку «Мультимедиа». Как правило именно здесь скрывается основной источник повышенного трафика. Вообще любой блогер должен сделить за выкладываемыми файлами и выполнять оптимизацию загружаемых изображений в фотошопе или аналогичных программах. Тут рекомендация одна - чем меньше размер файла, тем лучше. Если размер файла более 100-200Кб, то стоит рассмотреть вариант его размещения в виде миниатюры или даже замены.

Следующий источник трафика - js-скрипты и css-файлы. Можно воспользоваться «Веб-консолью», но удобней воспользоваться расширением HttpFox. HttpFox выдаёт http-заголовки, размер, все адреса и прочую информацию, глядя на которую можно оценить затраты на трафик и время загрузки каждого файла.

Обратите внимание на 304-заголовок - это ответ сервера, что файл не изменился и браузер его возьмет из своего кэша.

Очень часто в WordPress"е загружают несколько копий jQuery. Каждая из них весит примерно по 100Кб, так что есть смысл проанализировать кто «безобразничает» и наказать «сорванца». :-)

Также обратите внимание на сторонние скрипты, например счетчики. Строго говоря, анализаторы трафика не должны учитывать сторонние загрузки, но сейчас ситуация такая, что учитывается всё. Например Google Analitics может загружаться за 5 секунд (Яндекс-метрика ещё дольше, да еще и картинку и ссылку свою лепит), это время войдет в общую загрузку. То есть к таким анализаторам следует подходить с умом, отделяя мух от котлет.

Понятно, что основная проблема WordPress"а - это сам WordPress. Точнее наплевательское отношение к оптимизации кода начиная от самих разработчиков, до плагино/шаблоно писателей и самих блогеров. Данный факт в WordPress"е доведен до абсурда. В wp-config.php вы можете ради интереса временно включить режим отладки (точнее отображение ошибок):

Define("WP_DEBUG", true);

Впрочем, ситуацию всё равно не изменить, но можно попытаться хоть как-то минимизировать.

На сервере :

• Проверьте логи php-ошибок на сервере. Если есть какие-то ошибки, то их следует исправить. В любом случае ошибки должны исправляться, а не скрываться.
• Если есть возможность, попробуйте на сервере включить eAccelerator и PHP как fastCGI. Это позволит немного оптимизировать работу PHP и уменьшит расход памяти.
• Если позволяют финансы, то лучше перейти на VDS (виртуальный выделенный сервер). Здесь уже все ресурсы будут своими и никто не укажет на превышение нагрузки. Правда следует учитывать, что как правило VDS слабее обычного виртуального хостинга и скорость работы сайта уменьшится. Думаю, что нет смысла брать VDS с CPU менее 2ГГц и памятью менее 1Гб.
• Учитывайте, что нагрузка на сервере считается по всему аккаунту. Если у вас несколько сайтов, то следует оптимизировать каждый из них.

В самом WordPress :

• Отключите все неиспользуемые плагины. Любой активированный плагин, даже если он не используется, всё равно требует каких-то ресурсов. Такие плагины следует включать только перед использованием. Это касается всяких бэкапов, статистики и т.п.
• Отключите «спорные» плагины, вроде запрета копирования. Это глупость, которая обходится любым пятиклассником. Вообще, все плагины, без которых ваш сайт может обойтись, следует отключить.
• Поменьше работайте в админ-панели. Админ-панель очень прожорлива в создает большую нагрузку, особенно на страницах загрузок файлов.
• Используйте приведенный мной код статистики потребления ресурсов. Чтобы статистика не была видна на сайте, её можно расположить в html-комментарии.
• Количество говнокода в плагинах WordPress - просто поражает! Такое впечатление, что у плагинописателей одна цель - нанести как можно больший вред сайту. Поэтому по возможности проверяйте каждый используемый плагин на нагрузку. Возможно есть аналог, написанный не так похабно.
• Если сайт потребляет слишком много ресурсов, возможно дело в шаблоне. WordPress-шаблоны, к сожалению, часто делаются слишком ресурсоемкими, поскольку разработчики WordPress полностью сосредоточены на красотах админ-панели и не предлагают вебмастерам удобных и эффективных решений. Поэтому они вынуждены придумывать код, который часто не всегда хорош.

Радикально :

• Используйте MaxCache . Он тоже является «костылём», но если другие варианты не помогают, то кэш позволит хоть как-то привести WordPress в чувства. При этом очень осторожно используйте другие кэши. Обязательно отслеживайте показатели статистики до и после. Доверяйте не красивым текстам, а реальным цифрам.
• Смена «движка» на что-то более легковесное, например MaxSite CMS .

Если ничего не помогает :

• Перейдите на более старую версию WordPress. Я бы посоветовал WordPress 2.3.3, причем моей сборки, поскольку в ней реализован lite-перевод, а также подобрана неплохая коллекция плагинов. Шаблон, да, скорее всего, придется переделывать, но оно того стоит: технически шаблоны WordPress застряли в каменном веке и делаются одинаково с версии 1.5.
• Отключите русский перевод. Русский перевод сейчас занимает почти 700Кб. И это только сам файл, не считая ресурсов на его загрузку, обработку и вывод. Отключив русский перевод, можно получить довольно существенное ускорение работы сайта.

Ну и на последок. WordPress - очень прожорлив. Поэтому не нужно думать, будто бы эта проблема обойтет вас стороной. При увеличении посещаемости уже до 200 хостов хостер предложит перейти на более высокий тариф. При 2 тысячах - потребуется уже отдельный сервер или переходить на MaxSite CMS . В любом случае всех этих трат можно было бы заранее избежать, если сразу пользоваться нормальными CMS. ;-)

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

нам приходят на помощь дополнительные инструменты под названием плагины - рабочие лошадки, помощники в работе наших блогов. Что бы мы без них делали? Чтобы улучшить и ускорить загрузку блога, установим простенькие плагины для для оптимизации и ускорения загрузки блога. В сегодняшней статье установим плагин для чистки территории блога WP -Optimize. Как устанавливать плагины,

Плагины для оптимизации wordpress
1 - WP-Optimize помогает оптимизировать базу данных и таблицы сайта. Это обязательно - необходимый плагин.
Функции WP - Optimize:

• Конкретно чистит наш ресурс от всяческого мусора.
• Оптимизирует - сжимает базу данных блога и таблицы.
• Удаляет все резервные копии записей, когда мы ставим статью на блог и по несколько раз редактируем один и тот же пост, также весь опубликованный контент.
• Удаляет спам комментарии.
• Не конфликтует с другими плагинами.
• Просто и стандартно устанавливается на блог.
• Входим в админку
• Плагины
• Добавить новый
• В поисковой строке вписываем название WP-Optimize
• Устанавливаем
• Активируем

Далее еще проще: В меню слева ищем по названию WP-Optimize, заходим в настройки, видим фото людей, которые отблагодарили лайком.
Жмем лайк Нравится - отправляем на Фейсбук, лайк не отправите, плагин будет молчать и работать не начнет. Как немой и глухой ничего не слышит, так и этот плагин будет бездействовать. Со мной такая история

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

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

Акисмет переусердствовал - он же надежный охранник блога от спамщиков, загнал несколько комментариев для подстраховки в спам - папку. Отрабатывает свой хлеб. :)
А теперь можно чистить. Ставим во всех пунктах чебоксы - птички и жмем слово PROCESS.

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

После чистки плагин деактивируем и один раз в 5 - 7 дней чистим территорию блога.
2. Следующий плагин классический, который не нужно настраивать - по умолчанию он сам знает свои функции от а до я. Для этого постарался автор плагина Макаров, а плагин я нашла на сайте Дмитрия Сидаш sidash.ru/ у которого очень часто прогуливаюсь в поисках интересной и полезной информации. Заходите и вы - многое для себя почерпнете.

SSD Optimize WordPress - данный рабочий инструмент я выделяю из огромной дивизии плагинов полезных, малополезных, не очень полезных, но создающих хорошую нагрузку для сервера и блога. Разгружает от лишнего трафика и несвоевременнных запросов хостинг, на ходу оптимизирует загрузки AJAX библиотек, отключатся ненужные функции, сильно нагружающие систему и в то же время не нарушает работоспособность нашего блога.

Какую пользу имеем от этого плагина:

• Отключает проверки обновлений тем, плагинов, движка
• Отключает автосохранение редактируемой записи
• Включает автоматическую оптимизацию и восстановление Базы данных
• Отключает ревизии постов
• Отключает генераци метатегов
• Подгружает AJAX библиотеки с сайта google, для пользователей
• Снижаем нагрузку на сервер благодаря плагину
• Семь функций защищают сайт от спама
• Запрет в комментариях активных ссылок

Устанавливается аналогично всем плагинам.

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

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

Появился сайт в сети, даже не знаю - когда, но почему - то сейчас находится в АГС. Ссылка будет здесь неактивной http://makarou.com/ssd-optimize-wordpress-5-0. Как скачать данный плагин: Выделяем ссылку http://makarou.com/ssd-optimize-wordpress-5-0, копируем, вставляем в адресную строку. Но выше цитаты ссылка активная, скачивайте и устанавливайте.

Настройки нашего инструмента SSD Optimize WP

Информация о плагине

Все выполняемые функции

Статистика по комментариям и трекбэкам

Мой скайп gvozdika571
Всегда рада видеть вас у себя на блоге

Здравствуйте, уважаемые читатели блога сайт. C Наступившими Вас праздниками!

В этот промежуток времени (где-то около получаса) админка выдает 502 ошибку, а для посетителей сайт хоть и доступен, но страницы открываются довольно медленно (от 5 до 15 секунд). Если бы кеширование на блоге не использовалось, то и они бы выдавали 502 ошибку. Помогает только либо двукратная перезагрузка сервера, либо тупое ожидание пока все само собой рассосется.

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

В общем, за WordPress нужен глаз да глаз. Да, движок бесплатный, при этом профессиональный и попросту чумовой, но излишества всякие нехорошие нет-нет да и проскакивают. Вот. В этот раз взгляд тоже зацепился за «что-то новенькое». Это были три строчки кода (а точнее три служебных гиперссылки) опять же в шапке страницы формируемой WordPress:

Немного погуглив я понял, что «это» появилось в WordPress 4.4 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).

В общем, сие пока решил отложить до прояснения ситуации и появления рецептов «купирования ненужных отростков». Да, опять же, если в теме, то расскажите, ибо сильно эти ссылки меня раздражают. Хотя бы для чего они нужны и не несут ли какого диструктива в продвижение блога. Но тут я пока отступил.

Помимо этого в исходном коде был еще и сильно бросающийся в глаза блок:

Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово emoji в коде. Недавно писал . Чуток погуглил и убедился, что таки да — этот код помогает отображать на страницах WordPress эти самые эмодзи смайлики .

Так как emoji смайлы у меня выводятся от силы в двух-трех статьях, то решил это безобразие убрать, для чего и был произведен поиск рецепта в сети. Решение, как всегда в таких случаях, состояло в добавлении фильтров из папки с используемой вами темой оформления WordPress. В общем, находим в нем место окончания какой-нибудь функции (точку с запятой) и туда добавляем несколько строк непонятного (мне), но вполне себе работающего кода:

Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");

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

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

window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4"}}; !function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL().length>3e3):("simple"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0),0!==d.getImageData(16,16,1,1).data)):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head").appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag"),unicode8:d("unicode8")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag&&c.supports.unicode8||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings); img.wp-smiley, img.emoji { display: inline !important; border: none !important; box-shadow: none !important; height: 1em !important; width: 1em !important; margin: 0 .07em !important; vertical-align: -0.1em !important; background: none !important; padding: 0 !important; }

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

Как пришло осознание

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

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

Во всяком случае по срокам и по тому, что проблема не проявляется после удаления кода поддержки эмодзи, можно было сделать определенные выводы. Я их сделал и написал этот пост. Если проблема вылезет опять, то чуть ниже появится P.S. с сожалениями по поводу напрасно потраченного времени (вами на чтение, а мною на написание).

Решение получилось действительно несуразным, по крайней мере глядя с моей, крайне невысокой в умственном плане, колокольни. Где логика? Не знаю, но все равно приятно, что пусть и случайно, но мучивший меня довольно долго технический казус более-менее удачно разрешился. За сим разрешите откланяться. Спасибо за внимание и еще раз с Наступившими праздниками.

Удачи вам! До скорых встреч на страницах блога сайт

посмотреть еще ролики можно перейдя на ");">

Вам может быть интересно

Пропало левое меню в админке WordPress после обновления Где скачать WordPress - только с официального сайта wordpress.org
Установка WordPress в деталях и картинках, вход в админку WP и смена пароля Пустая страница при просмотре больших постов (статей) в WordPress
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации
Как войти в админку WordPress, а так же поменять логин и пароль администратора выданные вам при установке движка

В этой статье я хочу рассказать о способах оптимизации блога WordPress для снижения его нагрузки на сервер . Рано или поздно всем приходится задумываться над этой проблемой. Так как движок WordPress основан на PHP и MySQL, то каждый раз при каждом обращении к страницам сайта он создает определенную нагрузку на сервер. И чем больше этих обращений, тем больше нагрузка. Так как большинство из нас использует обычный хостинг, то всем приходится подчиняться определенным правилам, одним из которых есть ограничение нагрузки на сервер. Исходя из этого, есть смысл оптимизации своего блога WordPress.

Итак, для начала давайте разберем принцип работы движка на основе PHP+MySQL.
Когда пользователь обращается к какой-то странице сайта, на сервере (при помощи специального серверного языка или просто PHP) идет обращение к так называемой базе данных, которая содержит в себе всю информацию. Затем нужная информация вытаскивается и формируется статическая HTML страница.

Все довольно просто и очень эффективно. Это позволяет нам избежать огромного количества статических HTML страниц, что значительно уменьшает объем занимаемого сайтом места. Также существует множество других плюсов, но есть и свои минуса, одним из которых есть нагрузка на сервер. Есть множество способов ее уменьшения. Я расскажу о трех из них, которыми пользуюсь сам. Они показали неплохие результаты, поэтому есть смысл в их использовании.

Оптимизация блога WordPress при помощи кэширования страниц. Плагин Hyper Cache и его настройка.

Оптимизация WordPress при помощи данного метода состоит в том, что при обращении к страницам сайта, как обычно, генерируется статическая html страница. Разница лишь в том, что она сохраняется в КЭШе. При следующем обращении к этой странице вместо того, чтобы генерироваться заново, она просто берется из КЭШа. Это позволяет значительно уменьшить число запросов к базе данных и как следствие уменьшить нагрузку на сервер.

Итак, первым делом нам нужно скачать и установить плагин Hyper Cache. Для этого переходим на официальный сайт WordPress и скачиваем последнюю версию плагина. Далее копируем файлы в папку \wp-content\plugins\ и активируем плагин через административную панель. Для этого переходим в административную панель — плагины и активируем Hyper Cache.

После установки и активации плагина, переходим к его настройке. Точнее для начала нам нужно активировать кэширование в самом WordPress. Для этого нам придется редактировать файл wp-config.php и вставить в него строку

Define("WP_CACHE", true);

Лучше это делать ближе к концу файла, но не дальше строк

If (!defined("ABSPATH")) define("ABSPATH", dirname(__FILE__) . "/");

Затем нам необходимо соединиться с сервером и выставить права доступа 777 для папки wp-content. В принципе можете поставить эти права на саму папку с КЭШем. После этого переходим в административную панель\параметры\Hyper Cache и активируем его. Затем переходим к самим настройкам кэширования.

• Время жизни кэшированных страниц – устанавливаете время, которое будет существовать страница в КЭШе. То есть после обращения к статье WordPress кэширует эту страницу и сохраняет ее. От значения, которое вы здесь установите, будет зависеть время существования этой страницы, до ее удаления или обновления. Можете ставить по своему усмотрению. Обычно чем дольше, тем лучше.
• Автоочистка – данная функция проводит проверку КЭШа на наличие записей с истекшим сроком. Если такие находятся, то они удаляются. Благодаря этому вы можете быть спокойны, что у вас не будет накапливаться мусор, который может весить довольно много, что в свою очередь приведет к уменьшению свободного пространства на диске. Значение можете подбирать индивидуально. Вполне подойдет 1440 минут.
• Как очищать кэш – ставим значение «Single pages». На мой взгляд, это оптимальный вариант. В этом случае при внесении изменений кэш будет обновляться только для тех страниц, которые были редактированы. Остальные же останутся нетронутыми. При большой посещаемости это имеет смысл, так как если бы каждый раз, когда вы редактировали статью, очищался бы весь кэш, то это бы создало огромную нагрузку на сервер.
• Не кэшировать домашнюю страницу – можете поставить галочку, если не хотите, чтобы сохранялась главная страница. Данная опция имеет смысл, если у вас очень часто обновляется главная страница вашего блога. В принципе ставим по желанию. Лично у меня эта опция включена.
• Исключить URI – сюда можно вписать адреса страниц, которые вы хотите исключить с КЭШа.

Это были основные настройки плагина Hyper Cache. Для того, чтобы проверить его работоспособность, заходим на наш сайт как незарегистрированный пользователь и смотрим исходный код страницы. В конце должна присутствовать такая строка.

Если она есть, то плагин работает нормально.

Снижение нагрузки на сервер за счет кэширования запросов к базе данных.

Для этого можно использовать специальный плагин DB Cache Reloaded . Он кэширует запросы и направляет их не в базу данных, а в кэш, доступ к которому более быстрый. За счет этого уменьшается нагрузка на сервер и увеличивается скорость генерации страниц, что, в свою очередь, увеличивает скорость загрузки самого блога.

Настройки этого плагина очень просты и приводиться не будут. Там все интуитивно понятно. Единственное, что могу предложить, это добавить в footer.php код, который будет выводить информацию о количестве запросов к базе и время загрузки страницы.

Для этого открываем на редактирование файл footer.php и где-то в конце добавляем код

queries in seconds.

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

Естественно можно поиграть со стилями, перевести «queries in» и «seconds», но это по желанию. Лично меня и так все устраивает.

Оптимизация шаблона WordPress

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

Оптимизация header.php

1. Находим код

и меняем его на название своего блога. У меня это

Сайт - создание и продвижение сайтов, блогов, заработок на сайте.

2. Код, отвечающий за вывод описания, заменяем на статический.

3. Строка, отвечающая за вывод кодировки.