NitrOx, на что стоит обратить внимание:
1. Архитектура движка. Скорее всего, используется один из популярных движков. В той или иной степени они имеют вполне адекватную архитектуру. Но все равно могут тормозить. Чаще всего из-за накрученных плагинов и модулей, которые пишутся (очень часто) людьми, которые слабо представляют архитектуру самого движка. Отсюда лишние запросы, трафик, обращения к файловой системе. Здесь вы можете повлиять на ситуацию, удалив ненужные плагины или заменив их мене требовательными (более удачными в своей архитектуре)
2. Хостинг - канал забитый, много сайтов на одном сервере - никак не повлияете. Разве что можете переехать к другому хостеру.
3. Клиентская часть, верстка. Для начала дать на анализ хорошему верстальщику, он скажет - можно ли улучшить верстку. Возможно придется весь шаблон переверстать. Обращать внимание:
- на количество картинок на сайта (даже самых мелких). Каждая картинка - это обращение к файловой системе сервера, это лишний запрос. Мелкие или однотипные картинки рекомендуется объединять в спрайты (иконки, кнопки, иногда фоновые градиенты).
- на вес картинок. Тяжелые картинки долго грузятся. Рекомендуется оптимизация графики. Использование более подходящих под ситуацию форматов. Вместо PNG -- JPG, где-то вместо JPG -- GIF и так далее. JPG в свою очередь тоже можно оптимизировать, сохранив при этом достаточное видимое качество картинки.
- использование таблиц. По своей специфики могут тормозить общий рендер страницы. Чем меньше таблиц используется в верстке шаблона, тем лучше.
- инлайновые стили и другие параметры тегов. Все стили выносятся в отдельный файл стилей (меньше вес самой страницы, быстрее грузится. Сами стили кеширутся браузерами. В оценке скорости загрузки не участвуют).
- файлы стилей и мелкие скрипты. Если позволяет архитектура, то мелкие скрипты или стилевые файлы лучше объединять. Быстрее загрузится один большой файл, чем две половинки. И, опять же, меньше запросов к серверу.
Ну вот, примерно такой общий свод моментов, которых должно хватить для первичной (ударной) оптимизации. Все остальное, скорее всего, сведется к серьезным переписываниям движка, что довольно дорого.
burunduk, сегодня уже не обязательно :) ЧПУ есть ЧПУ
Но, согласитесь, как-то некомфортно, если страница без расширения, да?)
Я могу долго не отвечать, т.о. полезная информация из лички пропадет для других. А так, пока у меня нет возможности ответить, возможно, ответит кто-то другой. Поэтому, пишите, лучше, здесь.
Для начала, включите вывод ошибок - скрипт нормально отрабатывает? Даже без предупреждений? Проверьте подключение к базе (адрес, имя, логин, пароль) - бывает такое, что просто забывают сменить старые данные. Если скрипт отрабатывает без запинки, разметку на страницу выдает, но картинки все равно не отображаются, то смотрите пути до самих картинок - firebug вам в помощь или F12 в хроме, опере, IE - смотрите, что в выхлопе скрипта и где на самом деле лежат картинки. Ну и, соответственно, правите пути в самом скрипте. Если дойдет дело до этого этапа, то было бы неплохо показать действующий (работающий с ошибкой) сайт, чтобы нам легче было вам посоветовать правильное решение (а не пытаться угадать)
fooger, не совсем понятно, где же тут AJAX, если это банальный редирект?
Не знаю, забанят или нет, но по головке точно не погладят. В мануалах самих поисковиков в общих чертах пишется, что крайне не рекомендуется использовать частые редиректы. С точки зрения поисковиков они оправданы только в случаях смены адреса - переезд страницы, склейка и т.п., что должно сопровождаться соответствующими кодами в заголовках.
По-моему, есть простое правило: "Если path заканчивается на слеш, то это - раздел. Все остальное - конкретная статья". При чем сам раздел лучше реализовать такой же статьей. То есть site.ru/path/to/page/ будет аналогичен site.ru/path/to/page/index
И все будет логично - как для оптимизаторов, так и для программистов.
P.S. А оторвать руки всегда успеется. Иногда справедливее будет оторвать язык тому, кто составляет ТЗ (а потом еще меняет его несколько раз)
vbz, для начала опишите, как работает ваша CMS? Как она определяет, какую именно страницу показывать?
В классическом варианте, пишутся правила редиректа в .htaccess, из которого все человекопонятные ссылки ведут на один файл index.php и передают ему какие-то параметры (название страницы, чп-адрес). Тот, в свою очередь, уже разруливает - для какого параметра какую страницу показывать.
postavkin, попробуйте выводить всю таблицу товаров. Только строчкам, в которых содержится исключенный товар, проставляйте специальный класс. И в описании стилей прячьте все строки с таким классом. Классов может быть много, хоть под каждую группу товаров, хоть под каждый товар. Главное, иметь список этих исключенных товаров. И по этому списку составлять список чекбоксов. Затем уже вешаем на эти чекбоксы обработчик событий onChange, в котором описываем дейтствие - показать или скрыть строчки с определенным классом.
bratan1995, есть такой вариант (сегодня на глаза попалось) - http://homescript.ru/links_man.php
Но, в первую очередь, подумал вот про этот сайт: http://www.wr-script.ru/ - автор балуется простенькими скриптами уже давно. Доски объявлений в том числе есть.
Но если вы хотите серьезно подойти к реализации своего проекта, то лучше заказывать разработку скрипта "по вашему эскизу". Готовых примеров досок можно полно найти. Бесплатных - гораздо меньше. Бесплатных и толковых - еще меньше. А уж если у вы запланировали какой-то особый функционал, то есть проект со своей фишкой, то готового решения не найти. Можно что-то похожее найти и прикрутить, а потом допиливать под себя. Но это будут однозначные костыли, заплатки, дыра на дыре ибо в большинстве случаев (в толковых скриптах) все особенности архитектуры планируются сразу.
Ойо-йой... ну и портянки. Автор кода явно не слышал про шаблонизацию..
Thommy, вы базу данных переносите? - в ней, похоже, хранятся идентификаторы и названия изображений (+иерархия)
