Всем привет! Сегодня мы поговорим о таких важных для каждого начинающего сайтовода понятиях как «контент», «авторский контент», «защита контента» и «авторство Google» (Google Authorship). Начнем разбираться со всем по порядку…

Как известно первое и одновременно лучшее средство для продвижения молодого сайта к будущим вершинам — это контент. Что означает это понятие? Если обратиться к всезнающей Википедии, то получим примерно следующее определение «контента»:

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

Первый шаг для защиты уникального контента

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

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

Первым шагом на пути защиты контента станет подтверждение нашего авторства в крупнейших на территории СНГ поисковых системах: Яндекс (о настройке оригинальных текстов от Яндекса читайте здесь) и Гугл. Благо разработчики этих компаний пришли к пониманию важности идентифицировать автора и его работы, чтобы бороться в сети с массовым пиратством и подчистить свою выдачу…

Начнем мы с американского интернет-гиганта. Компания Google выводит свой пилотный проект «Авторство Google» (Google Authorship) на новый уровень юзебилети и эффективности. За последний год разработчики немало продвинулись в вопросах настройки авторского акаунта. Сегодня привязать свои статьи и другую авторскую информацию к личному профилю стало намного проще и быстрее.

Инструкция по настройке Авторства Google

Первое, что нам понадобиться в настройке Авторства Google — это личный профиль в социальной сети «Google+». Никогда не пользовались? Не беда! Если у Вас имеется почта на сервисе Гугла – Gmail, то профиль в социальной сети был создан автоматически вместе с созданием почты. Если же Вы до сих пор не обзавелись одной из самых защищенных почт в мире на данный момент, то исправьте это немедленно!!!

Ок, почта у нас уже есть, что дальше? А дальше нам подскажет «как быть» сам Google. Разработчики предлагают два альтернативных пути настроить авторство «вручную» (без всяких там плагинов и скриптов).

Весь смысл настройки «Авторства Гугл» отлично описывается очень простой схемой (смотрите ниже). Наша главная задача — настроить постоянные ссылки с сайта на личный профиль в Google+ (домашняя страничка в данной социальной сети) и наоборот – проложить постоянную ссылку с профиля к нашему сайту.

Итак, поехали!

Первый способ настроить «Авторство Google»

Шаг 1. Заходим на свою почту сервиса Gmail и жмем в верхнем меню почтового ящика надпись «+Ваше имя» (к каждому этапу настройки Вы найдете поясняющий скрин в галерее ниже).

Шаг 2. После предыдущего действия мы должны очутиться на своей страничке в сервисе «Google+» (в моем случае это здесь). Теперь нам необходимо добраться до раздела «Мои публикации», чтобы там вставить ссылку на свой любимый ресурс. Наводим мышь на выезжающее меню «Лента».

Шаг 3. В меню Ленты нас интересует пункт «Профиль», по нему мы и кликаем.

Шаг 4. Вот мы и на страничке нашего профиля. Здесь необходимо проделать сразу две вещи. Во-первых скопируйте из адресной строки Вашего браузера ссылку на свой профиль (в моем случае — это https://plus.google.com/u/0/111149321004865085087) и вставьте ссылку в программу типа «Блокнот» или «Word» (она нам скоро пригодится).

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

Шаг 5. На странице «О себе» и находится тот самый искомый раздел «Мои публикации». Чтобы его отредактировать кликаем на пункте «Изменить» (Осталось совсем немного – потерпите :)).

Шаг 6. Далее активируем форму для добавления ссылки на наш сайт. Для этого жмем пункт «Добавить ссылку».

Шаг 7. В активированной форме вводим ссылку на наш любимый сайт (лучше всего скопируйте из адресной строки Вашего браузера, чтобы не потерять или по ошибке не приписать слеш «/»). Далее добавляем краткое описание ссылки то бишь нашего сайта и жмакаем «Сохранить».

Шаг 8. Убеждаемся в том, что наше редактирование личного профиля «Гугл+» прошло успешно и все изменения сохранились. Результат должен быть примерно таким, как на последнем скрин-шоте галереи.

Шаг 9. На этом мы еще не расслабляемся, а вспоминаем за ссылку на свой профиль в «Гугл+», которая скучает где-то там в «Блокноте» (смотрим Шаг 4).

Все дальнейшие действия я рекомендую проводить все в том же «Блокноте» и ему подобных текстовых редакторах.

Эту ссылку нам нужно будет засунуть в конструкцию типа:

<a href=»[profile_url]?rel=author»>Ваше имя</a>Вместо [profile_url] вставляем URL своего профиля «Google+», при этом учтите, что ссылка обязательно должна содержать параметр ?rel=author ! Без него никак, так что не удалите его случайно.

У меня эта конструкция после всех вышеупомянутых действий выглядит так:

<a href=»https://plus.google.com/u/0/111149321004865085087/posts?rel=author»>Сергей ГеркХард</a>

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

Шаг 10. Это последний этап нашего маленького «путешествия». Перед тем, как поздравить себя с новым достижением и пойти скушать печеньку, следует проверить данные об авторе. Именно эти данные с нашей страницы Google будет использовать в результатах своей выдачи.

Для проверки своего будущего авторства в Гугл есть один замечательный инструмент и находится он здесь. В окне с надписью URL вводим адрес главной страницы нашего сайта и если мы все сделали верно – наслаждаемся полученными результатами! Особенно обратите внимание на контрольные области проверки Авторства Google (смотрите скрин-шот).

Второй способ настроить «Авторство Google»

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

Что значит на одном и том же домене? К примеру, доменное имя моего сайта – gerkhard.com, тогда адрес моей почты должен выглядеть примерно так: info@gerkhard.com. Так называемую именную почту настроить несложно и её поддерживают практически все платные регистраторы доменных имен. Как её настроить? Это уже тема для следующей статьи.

Не будем отвлекаться и вернемся к нашему второму способу. Допустим, именная почта у Вас имеется, тогда поддержка Google рекомендует проделать следующие действия.

Шаг 1. Во всех наших статьях или публикациях, размещенных на сайте необходимо проставить имя и фамилию автора (например, «Автор: Сергей ГеркХард»).

Шаг 2. После того как имя автора к каждой статье проставлено необходимо посетить страницу «Для авторов» и при помощи специальной формы сообщить Google адрес Вашей именной электронной почты.

Шаг 3. Если Вы все сделали правильно, адрес Вашей электронной почты отобразится в вышеупомянутом разделе «Мои публикации» профиля Google+. Для проверки работы Авторства Google необходимо воспользоваться проверочным инструментов Гугл из пункта 10 первого способа. Вот, пожалуй, и все…

P.S. Обычно «Авторство Google» начинает работать с последующим Вашим постом, когда тот попадает в основной индекс поисковика. Проверить это очень легко, пишем статью, добавляем её в аддурилку Google. В течение суток вводим в поисковик точное название нашей статьи/новости и любуемся своей авой с информацией об авторе.

У меня это выглядит так:

Автор: Сергей ГеркХард

Источник: GerkHard.com

В апреле, поисковик Yandex, обрадовал рунетовских веб-мастеров, включением поддержки атрибута rel=»nofollow» в ссылках. Какую пользу это нам — блоггерам принесет? Как правильно прописать атрибут rel=»nofollow» в ссылках и что теперь будет с <noindex>?

Давайте попробуем разобраться в этих новинках Яндекса .

Небольшая предыстория атрибута rel=nofollow

Что такое rel=nofollow?

Rel=» « — атрибут в ссылке <a>, указывающий отношение ссылки к целевой странице. Также, есть еще атрибут Rev=» «, указывающий отношение целевой страницы к ссылке, например (ссылка с rev=»sponsor» указывает, что это спонсорская ссылка). Но об этом в следующей статье.

Nofollow — статус, говорящий о том,что вы не одобряете данную ссылку.

Исходя из вышесказанного:

Rel=nofollow — определяет отношение вашей ссылки к целевой странице как не одобряемое. Применительно к поисковикам, данный атрибут указывает индексирующим роботам, что по данной ссылке не следует переходить на целевую страницу.

Rel=nofollow был введен и стандартизирован в 2005 году, в ответ на многочисленный ссылочный спам, присутствующий в блогах. Инициатором введения была поисковая система Google.

Google, встречая ссылку с данным атрибутом, не следует по данной ссылке и не передает вес PR целевым страницам. Также, данные ссылки не учитывались в расчетах распределения ссылочного веса по ссылкам страницы. Но, так было до 2010 года. На данный момент, Google, также не передает ссылочный вес и не следует по ссылкам с rel=»nofollow», но вот ссылочный вес, внутри страницы, стал распределятся и на эти ссылки но впустую. То есть, если у вашей страницы PR-10 и 10 ссылок на странице, где 5 из них закрыты, то каждая открытая ссылка передавала по 2PR на целевую страницу. Теперь каждая открытая ссылка будет передавать 1PR по открытым ссылкам и по 1PR в пустоту по закрытым. Но эта статья не о Google, вернемся к Яндексу.

Yandex, до апреля месяца 2010г., не учитывал данный статус. В рекомендациях Яндекса находим нашумевший тег <noindex>, который позволял сделать тоже самое и больше. Теперь там и nofollow.

В чем разница rel=nofollow и <noindex>

Так в чем же проблема?
Зачем Яндексу понадобилось вводить поддержку rel=»nofollow»?

се дело в том, что тег <noindex> это личная инициатива Yandex. Данный тег нигде в мире, кроме самого Яндекс, не поддерживается и не стандартизирован. При проверке ресурса на ошибки в коде и поддержке web-стандартов, веб-мастера всегда получали «не валидный» код. То есть, ваш ресурс содержит ошибки. Но, спешу вас успокоить, это не критическая ошибка и практически ни на что не влияет. Для тех кому важен валидный код, вот структура, рекомендованная самим Yandex для валидности вашего кода:

<!--noindex-->Блок вашего закрываемого текста<!--/noindex-->


Еще одна проблема тега <noindex> в том, что зарубежные веб-мастера, не ведая о данном теге, не используют его в разработках своих плагинов к WordPress. Приходится данные плагины адаптировать под Яндексовскую реальность.
Если в комментариях блога ссылки были закрыты атрибутом rel=»nofollow», то для Яндекса эти ссылки были открыты. Это означало, что роботу приходилось путешествовать по всем ссылкам указанным в комментариях.

Атрибут со статусом rel=»nofollow» стандартизирован и используется во всем мире для указания поисковикам, что ссылка не одобрена автором и по ней не нужно следовать.
Например, если закрыть служебную страницу от индексации в robots.txt, а ссылку оставить открытой, робот проследует на данную страницу, но не проиндексирует ее. Зачем тогда тратить ресурсы робота на переходы по ненужным страницам? Еще есть один нюанс, если на вашу служебную страницу ведут открытые ссылки с других внешних источников, то ваша, как бы закрытая страница, попадет в поиск, даже если она закрыта в robots.txt. Об этом также расскажу в следующих статьях.

Исходя из всего этого, по многочисленным просьбам и жалобам веб-мастеров, Яндекс ввел поддержку стандартизированного W3C атрибута со статусом rel=»nofollow». Атрибут закрывает ссылки от переходов роботом и не передает вес. Теперь многое стало проще. Но есть один нюанс. Анкоры ссылок будут проиндексированы как текст.

Зачем нужен <noindex>?

Тег <noindex> очень важен, если вы хотите, чтобы часть текста, со всеми анкорами ссылок и т.д., не индексировалась и не попала в поисковую базу Yandex.
Например, у вас на странице может быть служебная информация, или блок текста с сайта, который используется как негативный пример. Вы не хотите, чтобы поисковик связал ваш сайт с данным текстом или индексировал служебную информацию и сохранил у себя в базе. Для этого данный блок обрамляется тегом <noindex>.

К сожалению, такого инструмента для Google не существует. Вполне возможно, что Google или консорциум W3C в будущем обратят внимание на данный тег или придумают свой, и веб-мастера получат в свой инструментарий еще один полезный инструмент.

Как правильно прописать rel=nofollow и <noindex>

1. Для закрытия ссылок от индексации, с помощью rel=»nofollow», используется простая схема:
   <a rel=»nofollow» href=»http://www.site.com» title=»Подсказка»>Ссылка на сайт</a>
   перехода по ссылке не будет.
2. Для закрытия блока текста тегом <noindex>, со всем содержимым, в том числе и с анкорами ссылок, используется схема:
   <!--noindex-->Блок вашего закрываемого текста<!--/noindex-->
данный текстовый блок не будет проиндексирован в Яндекс, со всеми текстами ссылок.
3. Для закрытия блока текста тегом и ссылок в блоке, используется схема:
   <!--noindex-->Блок вашего закрываемого текста <a rel="nofollow" href="http://www.site.com" title="Подсказка">Текст анкор ссылки</a> Блок вашего закрываемого текста<!--/noindex-->
данный блок не будет проиндексирован в Яндекс, со всеми ссылками содержащимся в данном блоке.

Что изменилось с вводом поддержки rel=nofollow?

1. Для тех, кто ведет ресурсы для людей и не использует спам-продвижения, почти ничего не изменится. Возможно некоторое уменьшение числа внешних ссылок, закрытых с rel=»nofollow».
2. Для тех, кто использовал в продвижении ссылочный спам (спам в комментариях, спам в форумах, соц. сетях, Википедии и т.д), и у кого основная ссылочная масса, дающая ТИЦ, состояла из таких ссылок, будет существенное снижение ТИЦ и как правило, проседание в поисковой выдаче Yandex.

Кратко, о новинках апреля 2010 года в Яндекс:

1. У страницы поисковой выдачи Яндекс теперь фиксированная ширина.
2. Появились в выдаче навигационные цепочки, у некоторых сниппетов и даты публикации.
3. Появился колдунщик видео.
4. В панели веб-мастера появилась возможность просмотра статистики по собственным ключевым словам.

P.S. Теперь осталось дождаться включения поддержки Яндексом канонического атрибута rel=»canonical», о котором я писал в статье о дублированном контенте, и многие блогеры вздохнут с облегчением.
Хорошая новость, в конце мая 2011г. Яндекс стал учитывать атрибут rel=»canonical». Принесет это облегчение или нет, покажет время.

Источник: http://www.wpbloging.com/optimize/nofollow-noindex-dlya-yandex.html

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

apt-get install php-xcache

Настраиваем кеш: Файл настройки /etc/php5/apache2/conf.d/xcache.ini.

realpath_cache_size=4096k xcache.size=40M xcache.slots=8K xcache.ttl=3600

Также можно указать число ядер вашего процессора:

xcache.count=2

понятно, что это для 2-х процессоров.

Источник: http://help.ubuntu.ru/wiki/web-server

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

1 Тестируем текущую скорость

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

1.1 Pingdom

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

Бенчмарк одного довольно известного ресурса.

1.2 YSlow

YSlow– плагин для Firefox, который встраивается в, пожалуй лучший плагин для веб разработчика, Firebug. Он анализирует более 20 факторов, которые влияют на скорость работы сайта и оценивает общую производительность по 100 бальной системе, а каждый отдельный элемент оценкой от A до F.

1.3 Количество запросов и время их выполнения

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

<?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.

2 Web Hosting

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

• Shared Hosting – на одном сервере может хоститься в среднем около 100 человек;
• VPS – на одном сервере может хоститься около 20 человек;
• Dedicated – сервер будет использоваться только вами.

Чтоб просмотреть примерную нагрузку на сервер, залогиньтесь через ssh и введите в консоли команду top.

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

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

3 Установка и настройка сервера

Удостоверьтесь, планируемая нагрузка соответствует мощности сервера и он сможет с ней справиться. В первую очередь это будет зависеть от объема оперативной памяти и процессора. Как правило, Wordpress ставят на Apache, но много удачных решений существует и на базе других http серверов: nginx, lighttpd и т.д.

Не забудьте обновить до последней версии PHP и Apache.

3.1 Отключите неиспользуемые сервисы

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

• Удалите ClamD;
• Настроить SpamD на использование только 1 дочернего процесса;
• Удалите Mailman, если, конечно, вы не собираетесь запускать почтовый сервис.

3.2 MYSQL Query Cache

Поскольку стабильность и скорость Wordpress довольно сильно зависит от работы БД, стоит убедиться, что настройки в my.cnf соответствуют возможностям сервера. В первую очередь следует установить настройки кэширования запросов, добавив в my.cnf следующие строки:

query_cache_type = 1
query_cache_limit = 2M
query_cache_size = 20M

Чтоб настройки вступили в силу придется перезапустить сервис MySQL сервис.

3.3 Кэш компилятора: XCache или Eaccelerator?

Кэш компилятора увеличивает производительность откомпилированных скриптов на сервере, кэшируя их – это поможет сократить время выполнения PHP скриптов. Стоит попробовать и то и другое решение, однако по результатам опытов увеличение производительности при использовании Xcache на 5% выше, чем с Eaccelerator.

3.4 Увеличьте максимальное число соединений на Apache

Увеличение максимального количества соединений в httpd.conf повысит производительность, т.к. сервер сможет обрабатывать большее количество подключений за раз. Однако, следует изменять этот параметр осторожно, дабы не исчерпать весь объем оперативной памяти и не замедлить работу сервера, потому всегда тестируйте новые настройки прежде чем запускать их в работу. Установим к примеру 150 коннектов:

max_connections = 150

Не забудьте рестартить сервис Apache, чтоб применить настройки.

4 Оптимизация кода и графики

Итак, сервер заработал и теперь настало самое время поиграть с кодом Wordpress.

4.1 Отключите хотлинки

Каждый раз когда вы используете свой сервер для хранения изображений вы существенно больше используете его ресурсов. Довольно часто люди заимствуют ваши изображения, ставя хотлинки на своих серверах. Это не только занимает канал, но и создает определенную нагрузку на сервер.
Добавьте следующий код в .htaccess файл, заменив example.com на имя вашего домена, чтобы отключить использование хотлинков:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?example\.com/.*$ [NC]
RewriteRule .*\.(gif|jpg|png|ico)$ - [F,L]
</ifModule>

4.2 Используйте внешний хостинг для хранения изображений

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

4.3 Сжимайте java-скрипт код

Сжатие javascript довольно простая задача. Поскольку он выполняется при каждом просмотре страницы, вы можете уменьшить размер Javascript, удалив все незаполненное пространство. Вот простой инструмент, который поможет сделать это за вас — JavaScript Compressor.

4.4 Javascript в начале страницы

Часто случается так, что сайт начинает загружаться медленно или вообще останавливается, т.к. другой ресурс, с которого вызывается javascript(на пример Digg badges, Tweetmeme и т.д.), не доступен или оффлайн. Чтобы избежать этого вынесите весь javascript код в конец страницы, а то что по каким-то причинам вынести не удалось – попробуйте заключить в iFrame.

4.5 Используйте кэш браузера

Сам по себе кэш браузера, конечно не сделает ваш блог быстрее, однако поможет снизить нагрузку на сервер, кэшируя часто загружаемые объекты(стили, элементы интерфейса и т.п.).
Попробуйте вставить следующий код в .htaccess файл:

FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch "\.(jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>

4.6 Сжимайте статические данные

Вы можете уменьшить размер загружаемой страницы позволив браузеру принимать и передавать данные в сжатом виде. Это также снизит загрузку канала и количество загружаемых данных.
Следующий код в .htaccess может помочь вам в этом:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

4.7 Используйте CDN для статических файлов

Если хранить все изображения на одном и том же домене, то браузер будет ожидать их загрузки одного за другим. Допустим на странице их у вас есть 12 штук, если вы разделите их между тремя поддоменами, они будут загружаться одновременно из трех «разных» источников вместо того, чтоб загружаться браузером по очереди из одного.
Можете попробовать перенести все css & javascript файлы на files.yoursite.com, а изображения и временные файлы на static.yoursite.com. Или же просто использовать CDN(Content Delivery Network) – большая сеть серверов, расположенных по всему миру, которые позволят не только хранить ваши файлы на разных поддоменах, а значит загружать их параллельно, но и доставлять пользователю данные с самого близкого к нему сервера. Все это позволит загружать данные намного быстрее.

5 Wordpress

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

5.1 Обновитесь до последней версии

Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность. Для примера в wordpress 2.8 была существенно оптимизирована работа с БД.

5.2 Отключите Post Revisions

Во всех версиях wordpress, начиная с 2.6, редакции ваших статей каждый раз во время правки автоматически сохранялись. Это замедляет работу БД и увеличивает ее размер без особой надобности.
Чтоб отключить post revisions, добавьте следующую строку в wp-config.php:

define('WP_POST_REVISIONS', false);

Чтобы удалить сохраненные ранее ревизии текста, выполните следующий запрос в PHPmyadmin:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

5.3 Сократите количество запросов

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

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Мы запросто можем переписать в:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Уже на два запроса меньше. Довольно просто, не правда ли?

6 Wordpress Plugins

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

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

PHP Speedy WP
Этот плагин решает другую проблему, обозначенную в этой статье – удаление незаполненного пространства в CSS & javascript. Однако есть некоторые проблемы совместимости этого плагина с WP Super Cache, кроме того он долгое время уже не обновлялся, потому используйте на свой страх и риск.

Optimize DB
Плагин позволяет оптимизировать таблицы MySQL без помощи PHPmyadmin.

Источник: http://habrahabr.ru/post/69046/

Автор: Рудюк С . А.
http://corp2.net
E-Mail: rs@corp2.net

Для корректной работы плагина WP Super Cache при включенной опции (которая рекомендуется по умолчанию) mod_rewrite необходимо в .htaccess сайта внести такие изменения:

# BEGIN WPSuperCache <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / #If you serve pages from behind a proxy you may want to change 'RewriteCond %{HTTPS} on' to something more sensible AddDefaultCharset UTF-8 RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC] RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC] RewriteCond %{HTTP:Accept-Encoding} gzip RewriteCond %{HTTPS} on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L] RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC] RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC] RewriteCond %{HTTP:Accept-Encoding} gzip RewriteCond %{HTTPS} !on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L] RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC] RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC] RewriteCond %{HTTPS} on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L] RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC] RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC] RewriteCond %{HTTPS} !on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L] </IfModule> # END WPSuperCache Правила необхідно додати до /var/www/wordpress/rudjuk.kiev.ua/wp-content/cache/.htaccess також: # BEGIN supercache <IfModule mod_mime.c> <FilesMatch "\.html\.gz$"> ForceType text/html FileETag None </FilesMatch> AddEncoding gzip .gz AddType text/html .gz </IfModule> <IfModule mod_deflate.c> SetEnvIfNoCase Request_URI \.gz$ no-gzip </IfModule> <IfModule mod_headers.c> Header set Vary "Accept-Encoding, Cookie" Header set Cache-Control 'max-age=3, must-revalidate' </IfModule> <IfModule mod_expires.c> ExpiresActive On ExpiresByType text/html A3 </IfModule> # END supercache

Автор: Рудюк С . А. http://corp2.net

Конфиг .htaccess:

# Конфигурационный файл Apache # http://httpd.apache.org/docs/2.4/mod/quickreference.html # http://httpd.apache.org/docs/2.4/howto/htaccess.html # Созданию данного конфига способствовали: # Kroc Camen: http://camendesign.com/.htaccess # http://perishablepress.com/stupid-htaccess-tricks/ # .htaccess из CMS MODx: http://modx.com/ # Некоторые неизвестные авторы # ---------------------------------------------------------------------- # Улучшаем восприятие сайта пользователями IE # ---------------------------------------------------------------------- # Заставляем IE не переходить в режим совместимости в некоторых случаях # https://github.com/rails/rails/commit/123eb25#commitcomment-118920 <IfModule mod_headers.c> # mod_headers не умеет определять тип данных (content-type), но нам нужно отсылать этот заголовок только для определенных типов файлов <FilesMatch "\.(js|css|gif|png|jpe?g|pdf|xml|oga|ogg|m4a|ogv|mp4|m4v|webm|svg|svgz|eot|ttf|otf|woff|ico|webp|appcache|manifest|htc|crx|oex|xpi|safariextz|vcf)$" > Header unset X-UA-Compatible </FilesMatch> </IfModule> # ---------------------------------------------------------------------- # Кроссдоменный AJAX # ---------------------------------------------------------------------- # Обслуживание кроссдоменных Ajax запросов, по умолчанию отключено. # http://enable-cors.org/ # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity # <IfModule mod_headers.c> # Header set Access-Control-Allow-Origin "*" # </IfModule> # ---------------------------------------------------------------------- # Кроссдоменные изображения (CORS-enabled images) (@crossorigin) # ---------------------------------------------------------------------- # Отсылать CORS заголовки, если браузер требует их, для изображений по умолчанию включено. # http://developer.mozilla.org/en/CORS_Enabled_Image # http://blog.chromium.org/2011/07/using-cross-domain-images-in-webgl-and.html # http://hacks.mozilla.org/2011/11/using-cors-to-load-webgl-textures-from-cross-domain-images/ # wiki.mozilla.org/Security/Reviews/crossoriginAttribute <IfModule mod_setenvif.c> <IfModule mod_headers.c> # mod_headers, ну почему ты не определяешь Content-Type?! <FilesMatch "\.(gif|png|jpe?g|svg|svgz|ico|webp)$"> SetEnvIf Origin ":" IS_CORS Header set Access-Control-Allow-Origin "*" env=IS_CORS </FilesMatch> </IfModule> </IfModule> # ---------------------------------------------------------------------- # Доступ к веб-шрифтам # ---------------------------------------------------------------------- # Разрешает доступ к веб-шрифтам из всех доменов. # В качестве альтернативы, можно добавить домен # в белый список, например "subdomain.example.com". #<IfModule mod_headers.c> # <FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css)$"> # Header set Access-Control-Allow-Origin "*" # </FilesMatch> #</IfModule> # ---------------------------------------------------------------------- # Верный MIME тип для всех файлов # ---------------------------------------------------------------------- # Предотвращает MIME-связанные ошибки в Google Chrome при подключении внешних шрифтов. # Запрещает просматривать содержимое бинарных файлов (их принудительная загрузка). # JavaScript # Приведение Javascript к единому типу # http://tools.ietf.org/html/rfc4329#section-7.2 AddType application/javascript js jsonp AddType application/json json # Аудио AddType audio/ogg oga ogg AddType audio/mp4 m4a f4a f4b # Видео AddType video/ogg ogv AddType video/mp4 mp4 m4v f4v f4p AddType video/webm webm AddType video/x-flv flv # SVG # Требуется для svg шрифтов на iPad # https://twitter.com/FontSquirrel/status/14855840545 AddType image/svg+xml svg svgz AddEncoding gzip svgz # Веб-шрифты AddType application/vnd.ms-fontobject eot AddType application/x-font-ttf ttf ttc AddType font/opentype otf AddType application/x-font-woff woff # Остальное AddType image/x-icon ico AddType image/webp webp AddType text/cache-manifest appcache manifest AddType text/x-component htc AddType application/xml rss atom xml rdf AddType application/x-chrome-extension crx AddType application/x-opera-extension oex AddType application/x-xpinstall xpi AddType application/octet-stream safariextz AddType application/x-web-app-manifest+json webapp AddType text/x-vcard vcf AddType application/x-shockwave-flash swf AddType text/vtt vtt # ---------------------------------------------------------------------- # Gzip сжатие # ---------------------------------------------------------------------- <IfModule mod_deflate.c> # Включаем deflate для не стандартных заголовков: # http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/ <IfModule mod_setenvif.c> <IfModule mod_headers.c> SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding </IfModule> </IfModule> <IfModule mod_filter.c> AddOutputFilterByType DEFLATE text/html text/plain text/css \ application/json text/javascript application/javascript application/x-javascript text/x-js text/ecmascript application/ecmascript text/vbscript text/fluffscript \ text/xml application/xml text/x-component \ application/xhtml+xml application/rss+xml application/atom+xml \ image/x-icon image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype </IfModule> </IfModule> # ---------------------------------------------------------------------- # Задаем Expires заголовки (срок актуальности файла) (для лучшего кэширования) # ---------------------------------------------------------------------- # Указываются заголовки с большим сроком "годности", # предполагается, что вы используете кэш на основе названий файлов (all.css?v001). # В дополнение, учтите, что старые прокси могут кэшировать не верно # http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ # Если вы не используете названия файлов для контроля версий, измените кэш для CSS и JS, например на # "access plus 1 week". <IfModule mod_expires.c> ExpiresActive on # Задаем значение по умолчанию (для всех файлов) ExpiresDefault "access plus 1 month" # cache.appcache нельзя кэшировать в FF 3.6 (спасибо Remy ~Introducing HTML5) ExpiresByType text/cache-manifest "access plus 0 seconds" # Ваш html документ <FilesMatch \.(html|xhtml|xml|shtml|phtml|php|txt)$> ExpiresDefault "access plus 0 seconds" </FilesMatch> ExpiresByType text/html "access plus 0 seconds" # Данные ExpiresByType text/xml "access plus 0 seconds" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType application/json "access plus 0 seconds" # Рассылка ExpiresByType application/rss+xml "access plus 1 hour" ExpiresByType application/atom+xml "access plus 1 hour" # Favicon (не может быть переименован) <FilesMatch \.(ico)$> ExpiresDefault "access plus 1 week" </FilesMatch> ExpiresByType image/x-icon "access plus 1 week" # Медиа: изображения, видео, аудио <FilesMatch \.(gif|png|jpg|jpeg|ogg|mp4|mkv|flv|swf|wmv|asf|asx|wma|wax|wmx|wm)$> ExpiresDefault "access plus 1 year" </FilesMatch> ExpiresByType image/gif "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType video/ogg "access plus 1 month" ExpiresByType audio/ogg "access plus 1 month" ExpiresByType video/mp4 "access plus 1 month" ExpiresByType video/webm "access plus 1 month" # HTC файлы (css3pie) ExpiresByType text/x-component "access plus 1 month" # Веб-шрифты <FilesMatch \.(eot|ttf|otf|svg|woff)$> ExpiresDefault "access plus 1 year" </FilesMatch> ExpiresByType application/x-font-ttf "access plus 1 month" ExpiresByType font/opentype "access plus 1 month" ExpiresByType application/x-font-woff "access plus 1 month" ExpiresByType image/svg+xml "access plus 1 month" ExpiresByType application/vnd.ms-fontobject "access plus 1 month" # CSS и JavaScript <FilesMatch \.(css|js)$> ExpiresDefault "access plus 1 year" </FilesMatch> ExpiresByType text/css "access plus 1 year" ExpiresByType application/javascript "access plus 1 year" # Статичные ресурсы <FilesMatch \.(swf|pdf|doc|rtf|xls|ppt)$> ExpiresDefault "access plus 1 year" </FilesMatch> ExpiresByType application/x-shockwave-flash "access plus 1 year" ExpiresByType application/pdf "access plus 1 year" ExpiresByType application/msword "access plus 1 year" ExpiresByType application/rtf "access plus 1 year" ExpiresByType application/vnd.ms-excel "access plus 1 year" ExpiresByType application/vnd.ms-powerpoint "access plus 1 year" </IfModule> # ---------------------------------------------------------------------- # Удаление ETag + Cache-Control # ---------------------------------------------------------------------- # FileETag None бывает не достаточно (для некоторых серверов). <IfModule mod_headers.c> Header unset ETag # Так как мы посылаем expires заголовки с большим сроком, # мы не используем ETag для статичного контента. # http://developer.yahoo.com/performance/rules.html#etags FileETag None ## Браузер должен обновлять документ после заданного в секундах времени, которое задается в Cache-Control. <FilesMatch \.(html|xhtml|xml|shtml|phtml|php|txt)$> Header set Cache-Control "max-age=0, private, must-revalidate" </FilesMatch> <FilesMatch \.(ico|gif|png|jpg|jpeg|ogg|mp4|mkv|flv|swf|wmv|asf|asx|wma|wax|wmx|wm)$> Header set Cache-Control "max-age=31556926, public" </FilesMatch> <FilesMatch \.(eot|ttf|otf|svg|woff)$> Header set Cache-Control "max-age=31556926, public" </FilesMatch> <FilesMatch \.(css|js)$> Header set Cache-Control "max-age=31556926, public" </FilesMatch> <FilesMatch \.(swf|pdf|doc|rtf|xls|ppt)$> Header set Cache-Control "max-age=31556926, public" </FilesMatch> </IfModule> # ---------------------------------------------------------------------- # Запрещаем мобильным провайдерам изменять заголовки сайта # ---------------------------------------------------------------------- # Следующий заголовок предотвращает изменение заголовков сайта # при использовании 3G у некоторых Европейских провайдеров. # Это официальный 'костыль', предложенный O2 в UK. # <IfModule mod_headers.c> # Header set Cache-Control "no-transform" # </IfModule> # ---------------------------------------------------------------------- # Предотвращаем мерцание экрана в старом IE при :hover эффекте # ---------------------------------------------------------------------- # Следующие правила остановят мерцание экрана в IE при :hover, # в комбинации с "ExpiresByType" правилами для изображений (см. выше). # http://www.ibloomstudios.com/article3.php # BrowserMatch "MSIE" brokenvary=1 # BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1 # BrowserMatch "Opera" !brokenvary # SetEnvIf brokenvary 1 force-no-vary # ---------------------------------------------------------------------- # Устанавливаем Keep-Alive заголовок # ---------------------------------------------------------------------- # Keep-Alive позволяет отсылать несколько запросов через одно # TCP-соединение. Будьте в курсе возможных недостатков этой опции. # Включайте, если вы раздаете много статичного контента. # <IfModule mod_headers.c> # Header set Connection Keep-Alive # </IfModule> # ---------------------------------------------------------------------- # Задействуем mod_rewrite # ---------------------------------------------------------------------- # Включенный mod_rewrite необходим для дальнейших настроек. # FollowSymLinks должен быть включен. # Некоторые облачные хостинги требуют установленного RewriteBase: # http://www.rackspace.com/knowledge_center/frequently-asked-question/why-is-mod-rewrite-not-working-on-my-site # Если ваш сайт находится в поддиректории, используйте `RewriteBase /foo`, # где 'foo' - ваша директория. # Если ваш веб хостинг запретил опцию FollowSymlinks, вам может понадобится # закомментировать ее и использовать `Options +SymLinksIfOwnerMatch`, но будьте в курсе # возможного изменения производительности: http://httpd.apache.org/docs/2.4/misc/perf-tuning.html#symlinks <IfModule mod_rewrite.c> Options +FollowSymlinks # Options +SymLinksIfOwnerMatch RewriteEngine On </IfModule> # ---------------------------------------------------------------------- # Убираем или оставляем "www." в начале ссылок # ---------------------------------------------------------------------- # Одинаковый контент никогда не должен быть доступен по двум различным ссылкам - # особенно под различными доменами, так как это может вызывать проблемы с SEO - # дублированный контент. Поэтому вы должны четко выбрать один из вариантов. # По умолчанию, включен вариант 1 (без "www."). # http://no-www.org/faq.php?q=class_b # Если вы предпочитаете использовать вариант 2, просто закомментируйте вариант 1 # и раскомментируйте вариант 2. # ВАЖНО: НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ОБА ВАРИАНТА ОДНОВРЕМЕННО! # ---------------------------------------------------------------------- # Вариант 1: # Замена "www.example.com -> example.com". <IfModule mod_rewrite.c> RewriteCond %{HTTPS} !=on RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC] RewriteRule ^ http://%1%{REQUEST_URI} [R=301,L] </IfModule> # ---------------------------------------------------------------------- # Вариант 2: # Замена "example.com -> www.example.com". # Этот вариант не очень хорошая идея, если вы используете не виртуальные поддомены. # <IfModule mod_rewrite.c> # RewriteCond %{HTTPS} !=on # RewriteCond %{HTTP_HOST} !^www\..+$ [NC] # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # </IfModule> # ---------------------------------------------------------------------- # ---------------------------------------------------------------------- # Встроенное, основанное на названиях файлов, сбрасывание кэша # ---------------------------------------------------------------------- # Если вы не используете билд-скрипт для управления версиями ваших файлов, # вы можете использовать данный вариант. Он перенаправляет запросы таким образом # `/css/style.20110203.css` -> `/css/style.css`. # Чтобы понять, почему это важно и лучше, чем ".css?v1231", # обратитесь к официальной документации `.htaccess`. # P.S. скорее всего, query строка в адресе к статичному файлу может повлиять на кэширование этого файла # <IfModule mod_rewrite.c> # RewriteCond %{REQUEST_FILENAME} !-f # RewriteCond %{REQUEST_FILENAME} !-d # RewriteRule ^(.+)\.(\d+)\.(js|css|png|jpg|gif)$ $1.$3 [L] # </IfModule> # ---------------------------------------------------------------------- # Отключаем предупреждения касательно SSL сертификата # ---------------------------------------------------------------------- # Перенаправляем защищенные запросы правильным образом, например предотвращаем загрузку # https://www.example.com когда сертификат доступен только на https://secure.example.com # <IfModule mod_rewrite.c> # RewriteCond %{SERVER_PORT} !^443 # RewriteRule ^ https://example-domain-please-change-me.com%{REQUEST_URI} [R=301,L] # </IfModule> # ---------------------------------------------------------------------- # Предотвращаем 404 ошибки для несуществующих директорий # ---------------------------------------------------------------------- # без -MultiViews, Apache будет выдавать 404, если запрашиваемого каталога не существует # http://www.webmasterworld.com/apache/3808792.htm Options -MultiViews # ---------------------------------------------------------------------- # Своя страница 404 # ---------------------------------------------------------------------- # Свои страницы для ошибок 500 или 403 можно создать по аналогии. # Если ваш сайт находится в поддиректории, измените адрес соответствующим образом # например ErrorDocument 404 /subdir/404.html ErrorDocument 404 /404.html # ---------------------------------------------------------------------- # UTF-8 кодирование # ---------------------------------------------------------------------- # Используем UTF-8 кодировку для всех переданных text/plain или text/html AddDefaultCharset utf-8 # Принудительно выставляем UTF-8 для некоторых форматов AddCharset utf-8 .atom .css .js .json .rss .vtt .xml # ---------------------------------------------------------------------- # Блокируем некоторые эксплоиты # ---------------------------------------------------------------------- ## Если у вас появились проблемы, закомментируйте данные правила <IfModule mod_rewrite.c> ## Запрещаем доступ к .xml файлам (раскомментируйте для активации) # <Files ~ "\.xml$"> # Order allow,deny # Deny from all # Satisfy all # </Files> ## [Конец] Запрещаем доступ к .xml файлам RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR] # Блокируем возможность посылать base64_encode через URL RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR] # Блокируем передачу тега <script> через URL RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR] # Блокируем выставление переменной PHP GLOBALS через URL RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR] # Блокируем возможность изменять переменную _REQUEST через URL RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) # Посылаем все заблокированные запросы на домашнюю страницу с ошибкой 403 Forbidden error! RewriteRule ^(.*)$ index.php [F,L] </IfModule> ########### [Конец] Блокируем некоторые эксплоиты # ---------------------------------------------------------------------- # Еще немножко безопасности # ---------------------------------------------------------------------- # Чтобы не показывать точную версию Apache в заголовках, # добавьте следующее в httpd.conf (это нельзя сделать в .htaccess) # ServerTokens Prod # ServerSignature Off # Опция "-Indexes" заблокирует возможность просматривать директории посетителями. # Нельзя позволять случайным пользователям просматривать служебные директории вашей CMS. <IfModule mod_autoindex.c> Options -Indexes </IfModule> # Блокировка доступа к "скрытым" директориям и файлам, чьи названияначинаются с точки. # Такие директории могут использоваться системами контроля версий, например Subversion или Git. <IfModule mod_rewrite.c> RewriteCond %{SCRIPT_FILENAME} -d [OR] RewriteCond %{SCRIPT_FILENAME} -f RewriteRule "(^|/)\." - [F] </IfModule> # Блокировка доступа к резервным копиям и исходникам. Некоторые файлы могут быть оставлены # текстовыми редакторами и предоставлять собой большую опасность, если они будут доступны каждому. <FilesMatch "(\.(bak|config|sql|fla|ini|log|sh|inc|swp|dist)|~)$"> Order allow,deny Deny from all Satisfy All </FilesMatch> # ---------------------------------------------------------------------- # Некоторые настройки PHP # ---------------------------------------------------------------------- <IfModule php5_module> # Переименование названия сессии в cookie в что-нибудь другое, чем PHPSESSID # php_value session.name sid # Не показывать, что вы используете PHP # Примечание: укажите это в php.ini, так как это не сработает через .htaccess # php_flag expose_php Off # Уровень детализации логов - логировать все ошибки # php_value error_reporting -1 # Записывать ошибки в лог файл (off не отключает запись лога, а меняет место записи) # php_flag log_errors On # Не показывать ошибки в браузере (production - Off, development - On) # php_flag display_errors Off # Не показывать ошибки, возникающие во время запуска PHP (production - Off, development - On) # php_flag display_startup_errors Off # Не форматировать сообщения об ошибках # Примечание: Поставьте 'On' для вывода var_dump() через xdebug # php_flag html_errors Off # Не заносить в журнал повторяющиеся ошибки # php_flag ignore_repeated_errors Off # Игнорировать источник ошибок при пропуске повторяющихся сообщений # php_flag ignore_repeated_source Off # Максимальный размер лога в байтах # php_value log_errors_max_len 1024 # Строка, которая будет выводиться перед сообщением об ошибке (нельзя оставлять пустым, используйте пробел) # php_value error_prepend_string " " # Строка, которая будет выводиться после сообщения об ошибке (нельзя оставлять пустым, используйте пробел) # php_value error_append_string " " # Увеличиваем безопасность cookie, включив режим HTTP Only php_value session.cookie_httponly true </IfModule> # ---------------------------------------------------------------------- # Правила для Фреймворка / CMS (ниже - для Yii, при необходимости - заменить своим) # ---------------------------------------------------------------------- <IfModule mod_rewrite.c> # Если ваш сайт находится в папке, например "application", тогда изменение названия папки потребует изменения RewriteBase /[путь_к_сайту] # RewriteBase /[путь_к_сайту(не обязательно)] RewriteBase / # Если директория или папка существует, отдавать напрямую RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d # иначе, перенаправлять на index.php RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ index.php [NC,L] </IfModule>

Используемые модули

• mod_headers
• mod_setenvif
• mod_deflate
• mod_filter
• mod_expires
• mod_rewrite
• mod_autoindex

Анализ демонстрационной версии блога на фреймворке Yii инструментом Google PageSpeed Tool
(кликабельно)

До использования .htaccess:

После использования .htaccess:

А так же график загрузки и демонстрация работы сжатия
До:

После:

Количество передаваемых данных уменьшилось на 84,27 килобайт (меньше в 2.6 раз).
Так же мы получаем более тонкое управление кэшированием и некоторые фиксы.

Источник: http://habrahabr.ru/sandbox/55709/

Автор: Рудюк С . А.
http://corp2.net
E-Mail: rs@corp2.net

Для корректной работы кеширования в компоненте Wordpress WP Super Cache необходимо включить такие модули Apache:

 mod_headers mod_setenvif mod_deflate mod_filter mod_expires mod_rewrite mod_autoindex

Включаются они простым указанием симлинка с папки /etc/apache2/mods-available в папку /etc/apache2/mods-enabled.

Автор: Рудюк С . А. http://corp2.net

В прошлой статье я рассказывал об on-line сервисах проверки уникальности текста. В этом же посте я расскажу о двух наиболее популярных программных продуктах: Advego Plagiatus и Etxt Антиплагиат.

Но для начала немного теории.

А именно, нужно разобраться с некоторыми основными понятиями:

• шингл - это отрывок текста длинною в несколько слов
• алгоритм шинглов - это метод проверки текста на процент сходства
• канонизированный текст - это текст без знаков препинания и стоп-слов (в, на, если, до, то и т.д.).

Для большей наглядности приведу пример.

Пусть у нас есть текст:

Копирайтер - это человек, который пишет уникальные статьи.

Канонизированный текст:

Копирайтер человек пишет уникальные статьи

Шинглы длинною, например, в 3 слова будут иметь вид:

копирайтер человек пишет

человек пишет уникальные

пишет уникальные статьи

Примечание: некоторые источники утверждают, что слово "человек" тоже является стоп-словом.

Зачем мы рассматривали эти термины? Все просто: в настройках обеих программ есть возможность выбора длинны шингла.

Помните: чем меньше длина шингла, тем более точнее будет проверка.

Программа Advego Plagiatus

Advego - биржа статей, а каждая уважающая себя биржа имеет в своем арсенале собственный способ проверки текста на уникальность: будь то он-лайн сервис, или программный продукт.

Так в Адвего есть своя программа: Advego Plagiatus.

Для начала работы нужно скачать и установить дистрибутив, размер которого 1.8Mb. Программа поддерживает работу во всех версиях Windows, начиная с 2000.

Проверить уникальность текста можно двумя способами - или скопировать его в специальное поле через буфер обмена, или указать url адрес проверяемой страницы. Также можно сообщить программе какие домены следует игнорировать. Система ищет в интернете полные или неполные совпадения и в результате показывает процент уникальности и где в сети найдено сходство.

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

Программа Etxt Антиплагиат

Etxt также является биржей статей. И тут есть два способа определить уникальность текста - on-line или с помощью программы Etxt Антиплагиат.

Скачать дистрибутив, размер которого всего 921Кб, можно на сайте Etxt.

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

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

Второе - это более расширенные настройки.

Источник: http://seotkach.ru/programmy-proverki-unikalnosti-texta

Одним из важнейших факторов продвижения сайта является уникальный контент.

Поэтому, рано или поздно любой начинающий seo оптимизатор, "блоговод" или копирайтер задастся вопросом: где и как проверить уникальность текста. А так как on-line сервисов данной услуги достаточно много, я решил сделать краткий обзор самых популярных.

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

И так, начнем.

Copyscape

www.copyscape.com

В целом, создатели системы позиционируют свое «детище» как систему проверки воровства вашего контента. Другими словами: Copyscape находит плагиат.

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

Стоит отметить, что Copyscape в своей работе использует Google и Yahoo!.

Без регистрации в Copyscape есть ограничение по IP на количество проверок в месяц, также есть ограничение на количество отображаемых результатов – 10 сайтов.

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

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

Miratools

www.miratools.ru

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

В бесплатной версии установлен лимит на количество проверок: 10 статей (текстов) в сутки. Размер текста не должен быть больше 3000 символов.

В полной версии все эти ограничения снимаются и, конечно же, предоставляются дополнительные функции. Например, возможность проверить текст одним из вариантов: ввести его вручную, или загрузить ZIP архив с несколькими текстами, или же указать адрес страницы (как в copyscape). Также открывается доступ к смене длины шингла – количество слов, по которым проводится выборка. И много других функций, о которых можно прочитать на сайте.

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

Text.ru

www.text.ru

Text.ru является биржей статей. Но, как и во многих других подобных биржах, здесь есть сервис проверки текста на уникальность. Использование данной услуги совершенно бесплатное. Кроме того, сам процесс определения уникальности достаточно быстрый. Что бы запустить анализ, регистрироваться на сайте не обязательно. Все и так прекрасно работает. Но во время большой загруженности сервера (обычно это вечернее время) доступ к проверке предоставляется только зарегистрированным пользователям. В остальное же время формируется очередь по следующему принципу: сначала пользователи, которые сделали заказ пакетной проверки (платная проверка – 0.5руб. за 1000 символов), далее зарегистрированные, а уже потом незарегистрированные пользователи.

Личные наблюдения. Во избежание попадания в длинную очередь, лучше всего пользоваться сервисом до обеда, или же поздно вечером. В остальное время можно прождать минут 20 или больше.

Content-watch

www.content-watch.ru

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

Без регистрации существует ограничение на количество проверок с одного IP - 5. При этом размер текста не должен превышать 3000 символов.

С регистрацией лимит количества запросов увеличивается до 20. И размер проверяемого текста устанавливается до 10 тысяч знаков.

Личные наблюдения. Тестирование сервиса показало хорошие результаты. Заранее не уникальный контент определяется в 100% случаев, и указываются первоисточники. Анализ выполняется достаточно быстро, и по моему скромному мнению - качественно.

Istio

www.istio.com

Основным направлением данного сервиса является проверка и анализ текста и сайтов. Использование Istio абсолютно бесплатное и никаких ограничений нет. Пользователю доступны функции проверки текста на уникальность (используется поиск копий с помощью Yandex.XML и Yahoo), анализ, создание карты и словаря текста, а также проверка орфографии.

Личные наблюдения. Удивило то, что результаты анализа не такие как у других сервисах. Система показывает только 2 варианта: уникальный или не уникальный текст. Все. Кроме того, было выявлено, что результаты проверки ошибочные. Был заранее подготовлен текст с уникальностью 0% - а результат проверки "Уникальный". Еще настораживает факт, что в футере напротив копирайта стоит 2010 год.

Антиплагиат

www.antiplagiat.ru

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

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

Источник: http://seotkach.ru/on-line-proverka-unikalnosti-texta

Предыстория

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

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

Большинство существующих методов оценки производительности основывается на том или ином типе тестирования.

Можно выделить два основных типа тестирования: компонентное и интегральное.

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

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

Зеленый цвет графика в совокупности с некоторыми условно выбранными за эталоны показателями справа позволяет сделать кроссплатформенную обобщенную оценку «неплохой» производительности.

Как радоваться результатам теста

Вы получили в качестве результата некий индекс производительности (скорости). Не важно, хороший или плохой результат — это результат работы ПЛАТФОРМЫ на вашем «железе». В случае клиент — серверного варианта это результат сложной цепочки прохождения запросов по различным участкам. Вы получаете общий фактический результат, который определяется самым узким местом в системе. Узкое место есть всегда.

Другими словами, и настройки СУБД, и настройки ОС, и оборудование оказывают влияние на общий командный результат.

Какой сервер лучше

Данный тест, выполненный на конкретном сервере, дает результат по совокупности настроек hardware, операционной системы, субд и т.д. Тем не менее высокий результат на конкретном серверном оборудовании означает, что при соблюдении нормальных условий такой же результат будет на идентичном серверном оборудовании. Данный тест является бесплатной помощью в возможности сравнить установку 1С:Предприятие под Windows и Linux, три различных СУБД, поддерживаемых платформой 1С:Предприятие 8.

Безопасность теста

Тест абсолютно безопасен. Он не приводит к «падению» сервера (отсутствует «стресс»-алгоритм) и не требует предварительных мероприятий даже на «боевом» сервере. Конфиденциальных данных в результаты теста также не записываются. Собирается информация о параметрах CPU, RAM, HDD. Серийные номера устройств не собираются. Во всем этом можно легко убедиться — код теста 100% открыт. Никакой пересылки информации без вашего ведома невозможно.

Классификация TPC-A-local Throughput / TPC-1C-GILV-A

Тест относится к разделу универсальных интегральных кроссплатформенных тестов. Даже более того, он применим для файлового и клиент-серверного вариантов эксплуатации 1С:Предприятие. Тест работает для всех СУБД, поддерживаемых 1С.

Универсальность позволяет делать обобщенную оценку производительности не привязываясь к конкретной типовой конфигурации платформы.

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

Скачать тест

Данный тест не является коммерческим и его можно скачать бесплатно для 8.2 и бесплатно для 8.3.

Технические подробности

Что происходит в тесте в рамках «одного» такта операции?

Пример исполнения sql-команд можно посмотреть в приложенном файле.

Особенности использования теста на субд PostgreSQL

Установите значение параметра standard_conforming_strings в конфигурационном файле postgresql.conf в значение ‘off’

Как замерить загруженность железа

Надо отметить, что сам по себе тест уже частично выполняет замер. Для более детальной картины рекомендую воспользоваться утилитой Марка Русиновича Process Explorer.

На рисунке показан пример замера для файлового варианта.

Источник: http://www.gilev.ru/tpc1cgilv/