Зачем нужна CMS

Одна из больших статей затрат при создании сайта — это программирование. Статические сайт, которые не могут взаимодействовать с пользователями безвозвратно уходят: нужны комментарии, формы заказов, подписки и обратной связи, фильтры товаров и многое другое. Часть такого функционал можно реализовать за счет подключения сторонних сервисов типа внешних комментариев Disqus или формы обратной связи Reformal. Но у такого решения есть и минусы (кто бы сомневался!), да и изменять сайт лучше самому и в понятной административной панели, нежели руками править файлы html.

Вот для облегчения именно этой задачи – поддержания сайта – и были разработаны всякие-разные CMS. Писали и пишут их как энтузиасты «just for fan», так и серьезные дяденьки на заказ за деньги (например, Bitrix).

CMS и CMF

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

• CMF (content management framework) — среда (каркас)  проектирования и разработки систем управления контентом;
• CMS (content management system) – система управления содержимым сайта.

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

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

Другая сторона CMS и CMF в том, что интерфейс первой заточен больше под пользователя и более удобен для поддержания сайта, а второй более удобен для разработчика, но не слишком удобна для пользователя. Но и в первом случае, и во втором, нужно учиться пользоваться админкой для поддержания сайта.

Он-лайновые конструкторы сайта

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

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

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

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

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

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

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

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

Блоговый платформы онлайн

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

LiveJournal или ЖЖ (перевод «живой журнал) очень популярен среди людей, которые просто ведут свой блог. Есть очень раскрученные блоги, особенно по политике. Народ даже научился делать там деньги, хотя это как бы запрещено (или просто не поощряется руководством ЖЖ).

Blogpost – это сервис от «корпорации добра», где еще меньше возможностей, чем ЖЖ. Но и там тоже народ ведет свои дневники.

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

Итак, с онлайн сервисами разобрались, вернемся к CMS/CMF системам.

Типы CMS/CMF

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

Можно еще разделить системы по способам хранения данных: в базах типа MySQL (PostreSQL), в файле базы SQLite и в обычных файлах. Каждое решение имеет как свои плюсы, так и минусы.

СMS на файлах

CMS на хранении данных в файлах имеют огромное количество плюсов для пользователя, поскольку нужно просто сжать на хостинге в архив и скопировать себе на компьютер — вот и весь бэкап. Точно так же легко развернуть сайт – закачал архив, развернул в нужную папку, настроил права на файлы и папки и все готово. Разработчику легко использовать системы контроля версий типа git, удобно работать в любимой IDE.

А вот дальше начинаются минусы, которых не меньше.

Прежде всего, доступ в базу и выборку значений происходит быстрее, чем работа с файлами, требуют меньше памяти. Да и работа с MySQL проще и понятнее для выборки данных для отображения. А значит разработка стоит меньше, плагины становятся проще и их удобнее писать/редактировать. Тут всего это преимущества нет и в помине! Попытки прикрепить выборку через  xml в GetSimple дали положительный эффект, но при большом количестве материалов время генерации увеличивается очень существенно.

Так же трудно сделать уже выборки по условиям (фильтры товаров для примера), комментарии.

Кеширования страниц обычно тоже не реализовано, либо реализовано плохо.

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

CMS/CMF на базах данных

SQLite — это подмножество баз данных, которые имеют свои недостатки. Но буду рассматривать именно в этом разделе, поскольку обычно sqlite — это опция выбора между MySQL или SQLite.

Поскольку база sqlite хранится в одном файле в папке с сайтом, то часть проблем работы с файлом присутствует и здесь: нужно загружать весь файл с память, пока происходит доступ к файлу, блокируются другие запросы к файлу, доступ к данным дольше, чем у MySQL. Но с другой стороны уже гораздо легче делать выборку данных. SQLite поддерживается средствами PDO и написав выборку для PDO, она подойдет и для sqlite и для MySQL.

С другой стороны, переносить такой сайт так же легко, как и CMS на плоских файлах.

MySQL сейчас установлен даже на бесплатных хостингах, так что с этой точки зрения файлы давно потеряли преимущество перед базами. А архивировать сайт можно легко в админке хостера или в веб-интерфейсе доступа к базе phpMyAdmin.

На MySQL создаются более универсальные системы и более производительные.

Производительность движков сайтов

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

Критериями производительности и нагрузки на сервер хостера являются потребление памяти и время генерации страницы. Именно по этим критериям идут жестокие баталии на форумах!

Данные по производительности систем

Я приведу свои данные, которые я лично проверил как на локалке, так и на тестовом  shared хостинге в одинаковых условиях:

Сайты были небольшие и не сильно сложные.  Так что данные не совсем корректные, поскольку известно, что MODX Evolution при большом количестве страниц начинает резко увеличивать потребление памяти и при определенных условиях прекращает работать (виновата система кеширования).

Это то, что выдают сами системы при генерации страницы.

Тестирование в браузере

Все эти данные будут корректны только для потребления памяти. А если глянуть в браузере сколько качается и как отображается страница?

Тут ждет очень неприятный сюрприз!

Google Chrome и расширение PageSpeed дает интересные данные, что средняя страницы в пределах 15-50 кб. Всего лишь. Именно её и генерит  движок сайта, причем можно глянуть время от запроса на сервер и на отдачу страницы. Так вот, он примерно одинаков – около 400 миллисекунд. В это время входит и время получения сервером запроса, запуск движка и генерации страницы и отдача заголовка. И получается, что особой разницы нет. Хороший сервер с широким каналом и тормозным движком легко обойдет плохой сервер с легким движком.

Другая часть проблемы состоит в том, что средняя страница полностью весить около 4 Мб. То есть в 100 раз больше! И это графика, скрипты и стили. Получается, что в среднем страница на нормальном канале в 5 Мбит/с грузится около 3-5 секунд.

Получается, что время генерации пользователю не важны!

Нагрузка на сервер

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

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

И тут есть один тонкий момент: а когда происходит отключение? При посещении 10 человек, 100 человек или 1000?

Самый тяжелый движок WordPress на хостинге Sprinthost.ru на начальном тарифе без кеширования выдерживал 2-3 тысячи посетителей в сутки. Такой наплыв нужно еще обеспечить! Тогда решили просто переходом на более высокий тариф, а впоследствии подключили кеширующие плагины и все решилось в лучшем виде. Сейчас хостер поставил диски SSD и скорость сайтов возросла в несколько раз.

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

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

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

Удобство разработки и использования движка сайта

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

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