[система для оптимизации сайта]материал подготовил: Михаил Брод 15.09.2004
Сколько бы ни было систем разработки сайтов, каждая из них будет стараться привлечь к себе внимание за счет своих нюансов, отсутствующих в иных аналогичных системах. Как бы ни были хороши уже известные системы – PostNuke, “Битрикс”, Naumen и другие, – все равно будут продолжаться поиски изюминок, способных привлечь внимание к новой системе. Не стала исключением и система разработки сайтов Cacheable. По мнению разработчиков, “изюминкой” системы являются функция html-кеширования программного кода сайта, механизм “перенаправлений” запросов и оптимизация страниц для индексации поисковыми системами.
Система не претендует на то, чтобы с ее помощью “за пять минут” создать новый сайт. Такую задачу разработчики перед собой не ставили. Задача была иная – оптимизировать работу сервера (уменьшить нагрузку на него) и оптимизировать сайт для его обработки поисковиками. Первая задача решается за счет кеширования динамически создаваемых страниц, вторая – за счет подстановки статических адресов URL динамически создаваемым страницам. Разберем эти возможности подробнее.
Оптимизация нагрузки на сервер. Эта функция осуществляется за счет сохранения результатов работы программного кода сайта, обращений к базе данных, внедрения объектов в виде готовых html-страниц. А это, в свою очередь, снижает нагрузку на сервер и увеличивает скорость его реакции на запросы.
В системе Cacheable страницы сайта формируются на основе шаблонов. Суть их в этой системе заключается в предварительной подготовке общего плана страницы с помощью html-разметки и программных кодов. При обращении к какой-либо странице в этом случае происходит ее сборка, при которой сначала включается его код, а затем он включает в себя искомую страницу. Затем включается механизм кеширования. Этот механизм может быть полезен в тех случаях, когда обновления на страницах, формирующихся в динамическом режиме, на самом деле появляются раз в сутки или реже. Смысл формировать такую страницу при каждом обращении к ней посетителя отсутствует. Целесообразнее, создав первый раз, сохранить ее в виде файла и отдавать по запросу уже сформированную страницу.
Подобную задачу может выполнять и кеш веб-сервера. Но насколько точно он будет распознавать то, что нужно кешировать, а что – нет? Если веб-сервер находится на машине, где вы являетесь системным администратором, очистить кеш для вас сложности представлять не будет. Но если вы – не администратор? Тем более, очистить кеш браузера у пользователя вам не дано. В возможности управления всеми операциями кеширования – отличительная особенность системы Cacheable. С ее помощью вы, как администратор веб-сайта, получаете полное управление над кешем. Одна из основных функций, доступных администратору – очистка кеша. Она наглядно отображает древовидную структуру всех разделов и файлов с указанием времени их создания и времени последнего обращения, статус и маску адреса, использованную при создании папки или файла. Очистка кеша доступна как из администраторской панели, так и при терминальном доступе к сайту. Важный момент – посетители сайта не почувствуют, когда и как выполнялась очистка кеша сервера, и смогут как обычно просматривать сайт.
Администратору сайта проще управлять кешем сайта, чем кешем сервера
Для организации кеширования и, главное, использования его результатов применяется несколько составляющих. Во-первых – файл конфигурации Apache .htaccess. В нем выполняется настройка модуля Apache::mod_rewrite, без которого не будет выполняться вся последующая обработка. Модуль системы module.core.php – связующее з
вено между всеми процессами (из него выполняется вызов каждого из процессов). Он же отвечает за окончательную сборку страницы. Модуль module.redirect.php – обеспечивает связь с базой данных и подтверждает необходимость сохранения страницы в кеше. И последнее – служебная таблица _redirect, содержащая информацию о доступном пространстве URL для данного сайта. Настройки обработки запросов, записанные в файл .htaccess, выполнены так, что запрашиваемый URL будет обрабатываться ядром системы только в том случае, если после его преобразования в физический адрес на веб-сервере не будет являться ни файлом, ни каталогом, а представляет собой файл html-страницы или php-скрипта.
Вступающее на этом этапе в работу ядро системы решает несколько задач – происходит определение того, какая страница будет сформирована, будет ли она динамической, и надо ли сохранять ее в кеше, какое имя будет у создаваемой страницы. Если задано, что страница будет сохранена в кеш, то весь процесс сборки будет происходить с перехватом исходящего потока в строковый буфер, который и послужит телом будущего файла в кеше. А вот размещение файла в кеше может оказаться проблематичным, если не пренебрегать требованиями безопасности. При правильной настройке прав доступ к разделам веб-сервера будет закрыт для пользователя с правами “nobody”, от имени которого работает Cacheable. Поэтому размещение сформированных файлов происходит либо с использованием ftp-протокола, либо, если его поддержка на хостинге не включена, через эмуляцию ftp (ftp_sockets).
Теперь обратим внимание на реализацию механизма перенаправления запросов. В системе Cacheable за нее отвечают две составляющие:
таблица _redirect, встраиваемая в базу данных сайта;
модуль modile.redirect.php, содержащий класс для обработки поступающих на его вход URL.
При работе с кешем сайта задействуется несколько элементов настройки
Таблица _redirect состоит из двух полей: “rdr_url“, которое, собственно, и задает пространство доступных адресов сайта, и “rdr_loadpage” – при совпадении поступившего URL загружается та или иная страница, выбранная администратором при подключении функцией “Add new mask” в панели управления Cacheable. Второе поле может содержать как непосредственную ссылку на подключаемую страницу, так и выражение, которое после преобразования также даст физический адрес. При записи выражений для большей гибкости и удобства используются регулярные выражения, допустимые для обработки в MySQL. В качестве примеров можно привести следующие подстановки (примем, что URL сайта будет иметь вид www.domain.com, а скрипты хранятся в разделе /_pages/ вашего сайта):
rdr_url=/index\.html, rdr_loadpage=/startup.php описывает стартовую страницу сайта, www.domain.com/index.html, загружается скрипт /_pages/startup.php
И, наконец, вопрос оптимизации сайта, работающего под управлением Cacheable. Суть оптимизации состоит не в том, что система применяет к формированию страниц какие-то особенные способы, с помощью которых достигается попадание сайта на первые места в списках, выдаваемых по тематическим запросам. Этот процесс заключается в оптимизации URL-адресов страниц сайта для индексации их поисковыми системами. С чем связана эта необходимость? Для многих поисковых систем динамически создаваемые страницы являются страницами “второго сорта”. Поисковики либо их игнорируют, либо отдают предпочтение сайтам, выполненных в статической манере. Зачастую бывает так, что, найдя в тексте страницы выражение QUERY_STRING либо определив тип страницы по ее расширению, поисковый робот просто игнорирует ее, что влечет за собой исключение из числа индексируемых этой и множества других страниц вашего сайта.
В этой таблице задаются допустимые адреса страниц сайта
Но если подход к динамическим страницам у поисковиков разный (к тому, же он время от времени может меняться), то стати
